[Wintamute]

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.

[mbrock]

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...

[Wintamute]

> 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.

[mbrock]

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"!