Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Hitchhiker's Guide to Modern JavaScript Tooling

reactkungfu.com

Post reply on HN
Print view View original

51–60 of 120 posts

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#51

Post by SonicSoul »

joesmo wrote: post #48

"The biggest weakness of such small tools approach is that it is hard to learn what to use and how to configure it." No. By far the biggest weakness of such a small tools approach is a Balkanization of development tools that generally refuse to work with one another and often don't work very well by themselves. One library I really wanted to try was using Browserify but I wanted to use brunch/bower because my workflo…

yes there is this overhead, but it also reduces dependency on any specific framework, avoids using big one-size-fits-all monoliths, let's you choose the best tool for the job, makes your team a lot more well rounded by understanding pros and cons of each of those libraries.

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#53

Post by joesmo »

SonicSoul wrote: post #51
joesmo wrote: post #48

"The biggest weakness of such small tools approach is that it is hard to learn what to use and how to configure it." No. By far the biggest weakness of such a small tools approach is a Balkanization of development tools that generally refuse to work with one another and often don't work very well by themselves. One library I really wanted to try was using Browserify but I wanted to use brunch/bower because my workflo…

yes there is this overhead, but it also reduces dependency on any specific framework, avoids using big one-size-fits-all monoliths, let's you choose the best tool for the job, makes your team a lot more well rounded by understanding pros and cons of each of those libraries.

I don't see how this reduces dependencies on any specific framework or in any way affects that at all. I'm the one who chooses what dependencies and frameworks I work with. The only way these tools affect which dependencies I choose is that they limit the ones that can work with each other. Nor does it "avoid using big one-size-fits-all monoliths," because that wasn't a problem I had in the first place. The article is about build tools in case you haven't noticed.

It does not let me choose the right tool for the job. That's exactly what I'm describing in the post. It forces you to use whatever the authors of library X thought is the right tool for the job. And the authors of library Y and the authors of library Z ... etc. to the point where it becomes impossible to actually work with libraries from different sources together unless you manually manage them.

It does not make the team a lot more rounded to learn and understand a bunch of build tools that do the same thing as each other. What would make it more rounded is if these tools weren't so shitty, worked together, and there was only one of them so they could focus on actually building stuff instead of mentally masturbating about stupid build tools that don't work.

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#54

Post by iandanforth »

There is a fairly important point that is missed by this article. You do not need build tools to write JavaScript and depending on which tools you use there are significant drawbacks to using any them.

Before you dive into the world of build tools and process management I urge you to write unminified, ES5 (aka the JavaScript that runs without transpilation today) until it hurts.

Write unminified JavaScript and watch your page load times.

Write ES5 and time how long it takes you to complete projects of a given size.

Write reactjs code but use the JSXTransformer. Watch page performance. Watch how many times you reload the page in a given sitting.

It's really only when you find yourself with a problem that you can quantify that these tools start to make sense.

Discover for yourself why these tools exist or you'll waste a ton of time learning the newest thing and in the end not have gained much at all.

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#55

Post by lowboy »

TazeTSchnitzel wrote: post #25
aaronem wrote: post #16

Earlier quoted context omitted.

Well, you do at minimum need something that understands CommonJS modules, if you want to pack isomorphic code to run in the browser, so you need Browserify or Webpack. And you need a module downloader that resolves and installs dependencies, so you need NPM and/or Bower. And, if you want to write unit tests (which you should!) then you need a Javascript test harness, because otherwise you're going to have a bad time…

> Well, you do at minimum need something that understands CommonJS modules, if you want to pack isomorphic code to run in the browser, so you need Browserify or Webpack. No, you don't. These are optional. You only need these for larger applications that need packing. > And you need a module downloader that resolves and installs dependencies, so you need NPM and/or Bower. No, you don't. You can manually keep things up…

> No, you don't. You can manually keep things up to date.

Sure, but there are better things I could be doing with my time.

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#56

Post by mbrock »

this_user wrote: post #46
mbrock wrote: post #30

Earlier quoted context omitted.

I wrote code in Notepad for years. Often now I use cat instead. Sometimes even ed, which is surprisingly useful for many editing tasks. Knowing how to do things in the most basic, fundamental way is nourishing. And I've heard from many people that the JavaScript ecosystem—by which they seem to mean all the stuff they hear that everyone else is using—makes them feel overwhelmed. So it's good to have this clear explana…

Of course you can write code using cat but there is no good reason to do so. That would be like being a carpenter who refuses to use powertools and instead relies on manually operated ones. If you don't understand how to use the tools of the trade that will greatly improve your productivity, then you simply are not a professional.

You don't know that there's no good reason to do what I do. I use many different tools. Try ed sometime, it might improve your productivity. Professional? I deliver and get paid.

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#57

Post by joemaller1 »

talles wrote: post #52

Does webpack started to be more popular than browserify? I'm starting to see people talking more about webpack than the former...

The React world embraced WebPack after a modularity-kerfuffle back in January[1]. Pete Hunt followed that with his webpack-howto repo [2] which kind of turned the tide.

I really like Gulp/Browserify/Watchify/BrowserSync, but I'm starting to feel left behind and need to give WebPack an honest try.

[1]: http://blog.namangoel.com/browserify-vs-webpack-js-drama

[2]: https://github.com/petehunt/webpack-howto

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#59

Post by s986s »

joesmo wrote: post #48

"The biggest weakness of such small tools approach is that it is hard to learn what to use and how to configure it." No. By far the biggest weakness of such a small tools approach is a Balkanization of development tools that generally refuse to work with one another and often don't work very well by themselves. One library I really wanted to try was using Browserify but I wanted to use brunch/bower because my workflo…

Perhaps your research didn't lead you to an answer, however I feel like the bower/browserify isn't that big a bridge to cross. A tool like literalify[1] will allow you to 'require' globals. If you wish to require bower components, browserify-ing them isn't going to work quite well simply because normal javascript adds globals while commonjs has you explicitly get what you desire. As for CSS, there are ways to [2] inject it on the fly. Though at that point your making your bundle much larger than it needs to be.

[1] https://github.com/pluma/literalify [2] https://github.com/substack/insert-css/blob/master/index.js

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#60

Post by joemaller1 »

joesmo wrote: post #48

"The biggest weakness of such small tools approach is that it is hard to learn what to use and how to configure it." No. By far the biggest weakness of such a small tools approach is a Balkanization of development tools that generally refuse to work with one another and often don't work very well by themselves. One library I really wanted to try was using Browserify but I wanted to use brunch/bower because my workflo…

Unix much?

My biggest hesitation about WebPack is that it does too much and duplicates so many other tools. If I'm already using Gulp to watch files and BrowserSync (love!) as my local dev server, why do I need WebPack when I'm only going to be using one of its abilities? Isn't this bloat?

Post reply on HN