Yeah, from the outside I can understand the "everything keeps changing!!" complaint, but having been involved in JS for a few years, every single tool that got replaced was replaced for completely valid reasons, that couldn't have been solved incrementally by improving what was already there.
Because that's what leads to monumentally difficult to use tools.
Instead of choosing between gulp or grunt, you'd need to choose which config flags you want for this hypothetical "gunt". So instead of having simple to use tools (but a bunch of them), you have a few tools which take weeks of learning before you can even scratch the surface on them. And it leads to tools that have settings that nobody knows about because nobody uses them, and weird security holes and issues because of legacy support for an option that was added 3 years ago which when combined with a new flag causes everything to break...
Gulp is very simple, it's like 4 functions, and like 3 or 4 "conventions" you need to learn. There is no config, there are no settings, and there isn't any baggage. And that's the theme with JS tools. Rather than bloating current tools, you make a new one. Switching between them is easy, as they are all very trivial in nature. The power comes from combining those trivial tools.
Even if that were the case I would think learning powerful tools over the span of a few weeks would be worth the effort if you had the reliability that these tools would exist for years to come.
It seems like the rapid change and throw-away-ability of the tool ecosystem reflects the final product as well -- and maybe that's the large difference which is emergent from web technology? What is the average lifespan of a web application?
I don't think the past few years will be representative of web development in the future. The community has had a lot of churn because basic questions (How do I ensure my code has what it needs to run? How do I include dependencies? How do I efficiently deliver my code?) weren't answered, but now those questions have robust, widely used solutions, we don't have everyone figuring that out for themselves (and writing throwaway tools).
I think most of the current crop of tools that are in vogue will stick around for a while. There have been a few challengers to Webpack offering feature improvements (Rollup, Broccoli), but the ideas they introduced were added to Webpack, rather than replacing it.
I use maybe 3 main tools for my build system. Gulp, webpack, and babel. And I only use gulp because it is a bit easier to read than just putting stuff in a makefile (which is replacing one tool with another), or just using bash scripts.
If we were going with the "add options instead of adding tools" way of doing things, I might have one tool, but 100 flags and settings that I would need to manage and change, and you can't ignore the flags and settings just because you want defaults, because the defaults would work in a way that's out of date, or there might no be defaults at all.
Just because there are tools out there, doesn't mean you need to use them all. You can ignore everything you don't need in your project. And that includes ignoring the downsides, bugs, security issues, breaking changes, and baggage that comes along with them.
In half the cases parent presented, there were no "existing tools" to update(manual polyfills -> modernizr/6to5, script tags -> package managers like bower/npm, nothing -> eslint/type checkers, writing ad-hoc scripts for your own os -> grunt/gulp).
The rest of the examples are cases of merging two large ecosystems(web development and nodejs) together - that spawned browserify/webpack for bundling, npm for package management.
Many of these tools did try to update and adopt the new schemes. The grunt developers spent a lot of time optimizing their architecture in order to achieve the same speeds that gulp had. NPM has not stopped evolving - major version 3 tries to address a lot of the problems that yarn tackles. Babel evolves to adopt new javascript features.
I see the churn in development tools as a very natural progression, but that might be because I've been following it for a while and have seen and felt the pain points that each of these tools try to solve. I see a lot of effort within the javascript community to remain "compatible" wherever possible - for example, there are tons of guides how to migrate from grunt to gulp, there are matching tasks to ease your migration, etc. Library developers often release both on npm and bower, and craft elaborate "UMD loaders" for their libraries to allow for commonjs/AMD to exist side by side.
All in all, I find living with "javascript fatigue" to not be very exhausting. In our company, we have a wide variety of projects - some use literally no tooling, some use just bower, some use grunt, some use gulp, and our latest ones use the "modern stack" with webpack, etc. All of these projects are still actively maintained and their respective tooling stacks work and provide the benefit they were added for.
The problems the "newer" tools try to solve may not even be problems your development process has. If you've never really suffered performance problems working with grunt, then perhaps you've never felt an urge to migrate to gulp. Maybe you've never been bitten by npm's non-deterministic installations and poor download performance(I really haven't, so I haven't migrated to yarn, for example).
The magnitude of web development projects has ballooned in the last couple of years, and the tools are racing to handle it. It's not surprising that tools that are fit for a large web application with tons of code and a large team aren't really fit for a few javascript files to decorate a mostly static site built by a single developer. The churn is there, if you need it, but you don't have to use any of the newer libraries or tools.
The thing is, in other languages, frameworks and libraries can evolve without being replaced. It's called version 2. I can't help but think that in the JS world, you are more likely to ditch the old project because JS code is more difficult to read and maintain than languages that have more static typing, a somewhat higher entry bar, and a culture that values stability.
In other words, this is the consequence of optimizing for new entrants and writability versus readability and maintainability. It also becomes much harder to funnel talented people into being contributors to existing projects rather than starting their own.
In other languages there are very large projects that are heavily refactored and improved to support new patterns and use cases with regularity. Just yesterday I was using Antlr 4, which has been around for 25 years. But it's been updated many times. Maven was started in 2002, and maven 3 in 2008. It's stable and production quality. The openssl library goes back to 1998. Vim goes back to 1988 -- also rock solid and reliable. We're using a networking stack that is pretty damn old. But in the JS world, I can't help but think they would never be able produce anything that reliable because 6 years later they would be on their 6th re-write of Vim. And no, it's not (IMO) because other languages have corporate sponsors.
Javascript came out of the webspace which (was) primarily throwaway code. It was a bad thing to have an old website. They prioritized rapid prototyping, which was appropriate for that business case. However as Javascript is maturing and branching out to server-side programming and at the same time the client side becomes more complex, you can't keep re-writing all your tools every couple of years, or even every 5 years. You need tools that last decades, even as they are incrementally improved. If you don't have that, you are going to be subject to increasing exponential costs that are going to weigh very heavily on the language. Soon, you'll need to spend almost all your resources just re-writing stuff. It's no different than the developer that builds non-sustainable housing that has to be torn down every 10 years but is really cheap to build. Long term, a city built that way will necessarily be smaller in size and more expensive to maintain than a city built with housing that is more expensive to build up front but lasts a lot longer. Exponential decay is going to catch up to languages that like to keep re-writing all their libraries.
More importantly, I don't see an awareness on the part of the JS community that this is a serious problem that they need to tackle. They look at all the new libraries and the fact that they have the most code on github as a good thing, instead of as a warning side that they are already spending way too much time re-writing stuff.
So when there is announcement -- here is your standard webstack and it contains a tool less than a year old, a lot of people are gonna say "WTF", and explaining to them that Yarn has some new feature that NPM doesn't kinda misses the point. Of course it has some new features -- but still -- "WTF"?
> However as Javascript is maturing and branching out to server-side programming and at the same time the client side becomes more complex, you can't keep re-writing all your tools every couple of years, or even every 5 years.
The client side becoming more complex is the reason why new tools keep being developed.
> If you don't have that, you are going to be subject to increasing exponential costs that are going to weigh very heavily on the language. Soon, you'll need to spend almost all your resources just re-writing stuff.
No one is forced to rewrite their code when a new tool is released.
> They look at all the new libraries and the fact that they have the most code on github as a good thing, instead of as a warning side that they are already spending way too much time re-writing stuff.
There is a post, somewhere around here, that characterizes the JS culture as being one where shipping is the win condition. And I think this reflects what you describe better than the idea that other cultures merely value stability; JavaScript seems to value Github stars. And, as you say, that leads to a desire to rip out, rewrite, and own things, even if it doesn't necessarily make sense.
