I think it's good to note that you don't actually need a single one of these tools to make functioning software. You can pack your scripts with cat and download libraries with wget and use regular old JavaScript without transpilers. When you have a problem with this, you can use tools... But you don't have to top-load every project with a whole suite of complex tools just for the sake of it.
No one needs anything. You can write code in notepad. No one wants that, and no one wants to have a million globals on the browser or hit F5 every single save any more. While there is a learning curve to something like gulp, you really only need to set it up once and you can use it on every project as simply as typing "npm i".
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 explanation of the "modern" tools. But it's also good to know that it's all optional and that you can start without them. It is entirely possible to make a modern web application with just a few plain JS files included with script tags. Yet people think the first step is to learn about half a dozen sophisticated tools that they don't even know why they need. So I say start with Notepad. Be aware that there are popular tools to improve your workflow... But also that sometimes the best workflow is the one you fully understand.
I agree that it's essential and nourishing to understand the basics, but I feel that familiarity with the basics and expertise with these tools represents a minimum baseline standard for professional frontend development, especially when working in teams on medium/large web apps. Granted it's not easy to get up to speed with all of it, but many fields in programming and CS are not easy either. As browsers become increasingly standardised and stable and web languages grow up (ES6+) we'll be able to do increasingly sophisticated things, and frontend web development will attract more serious programmers ... we're seeing that now with the interest in React and functional JS, there's a lot of cross pollination between JS and the Clojure/Haskell communities which until now have remained in their ivory towers. Modern/professional frontend development won't and indeed shouldn't be something you can still just get done with Notepad and a few <script> tags.
Well, one thing about JavaScript is that it's a very flexible language in itself without any additions. It's similar to something like Scheme. And good Schemers can accomplish a lot of cool stuff with the proverbial Notepad. I'd rather hire someone with no clue about Gulp or npm but who understands all of JavaScript and knows how to do stuff in the simplest possible way, than someone who's mastered all of these tools and can't do anything without a framework. Forgive my bluntness. I disagree with the premise that sophistication requires complexity. I prefer to see it the other way around. Maybe I'm growing older. When I see a complex build tool replaced with three lines of bash, that makes me happy. And when I notice someone has given a bit of thought to making a simple solution based on fundamental needs instead of installing all kinds of stuff, like the commenter who mentioned downloading 200 MB of code just to initialize a project...
> When I see a complex build tool replaced with three lines of bash, that makes me happy
Amen to that! I think what I'm trying to say, and I suspect that we agree, is that there's the right tool for a job. Setting up a project to use 200mb of over-complicated npm modules and tools probably signifies the work of an inexperienced craftsman. Likewise, a non-trivial project built entirely from home-grown native Javascript may well run into complexity problems too as it re-implements features for which simple, well-tested and widely-used open source modules are available. Our desire for simplicity will lead us variously towards either of these extremes, and our experience tells us how to tread. We want our projects to be "simple", but that doesn't mean they're going to be "easy". The barrier to entry for frontend development is increasing in terms of developer capability, but that doesn't mean complexity is increasing, or that well architected projects that use modern tooling aren't simple.
Yeah, I think it's a continuous tension in software development, and for various reasons I have a hunch that it's useful to kind of try to nudge the JavaScript world towards the appreciation of basic, stupid, non-fancy simplicity. Actually that's true for way more than JavaScript. I felt the same thing very strongly the last time I installed desktop Ubuntu... I can sometimes get slightly obnoxious in my nudging, because "moving parts" complexity irritates me on a visceral level. Which can lead to NIH syndrome... By the way, Nick Bostrom uses the term "infrastructure profusion" to describe a particular nightmare scenario of AI, and I think it's evocative, so I've started to think of human intelligence as prone to this profusion, too. A perfect example would be something like if you had problems with your multiple JavaScript build tools and so you started a new build tool project to coordinate all your other build tools... Call it something cool, like "Leviathan"!
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.
What does it matter if I'm "right" about using a fundamental Unix command to enter text once in a while? What do you think I'm arguing, that cat is the best text editor and everything else sucks? Some guy said I'm not a professional even before I had a chance to give an example, which is rude and ignorant.
"No good reason to do so" is a bit strong, what about basic concatenation of two files when you're working at the command line `cat file1 >> file2` is much faster than anything else.
The OP may not be talking about editing files line by line.
Like any tool, the value of these tools becomes apparent only when the alternatives become inconvenient. If your workflows are simple enough that you don't need them, more power to you!
Also, while JS lib/framework fatigue is a very real thing, ever since I switched to React+Webpack, I haven't felt the urge to switch to the 'latest n greatest'.
They are a major milestone in the JS dev tools space, and a pretty safe bet for someone who just wants to pick something and not have to think about it afterwards.
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 instantiating your modules and injecting mocks into them. You could do this in just plain Node, sure, but you'll end up reinventing a lot of wheels if you do. So you need Mocha, or something very like it.
But build tools are sort of a luxury, sure. You can get by just fine with make, if you already know how to use it. And nobody needs transpilers, except people who just don't have enough problems in their lives already.
> 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 to date.
> 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 instantiating your modules and injecting mocks into them.
