This seems to suggest the rate of framework churn has rather settled down. Are JS devs finally starting to be satisfied with their current tools and not needing to restart every 18 months?
It's funny to me that certain people are so disdainful of the churn in web development on a forum dedicated to "hackers". Web application development is hard, and the reason why there's so much churn is because smart, inventive people are constantly finding better ways to do things. Things aren't just resetting from scratch every 18 months. The web apps I'm working on today are way more modular, composable, testable, and maintainable than the ones I was writing as little as two or three years ago. Just because Java systems development hasn't changed significantly in the last 5 years doesn't mean Java devs are any more or less reasonable developers than web folks.
It also follows that at some point, these smart, inventive people will come up with fairly stable frameworks that are sufficiently flexible and powerful to accommodate most of the problem space out there. It is reasonable to ask if such a point has been reached...
Browserify -> Webpack has been noisy. Babel 5 -> 6 equally noisy, but better for moving forward
Today, I think webpack, babel, react, redux and fetch cover a LOT of ground for client-side dev. There's a few other bits around that, and I think CSS tooling is starting the a similar shakeup to node's tooling options.
In the end, almost all the JS features I care about seem to be at stage-3 now, so who knows when they'll be in the major browsers.
The better question is: are the apps someone with two or three fewer years of experience than you more modular, etc?
My experience is on the backend rather than the frontend, but in that domain, at least, system quality is still way more about developer maturity than ecosystem maturity. You can figure out a terrible, hard-to-maintain lazy way of solving today's immediate problems in any language.
And yet React's claim to fame is that it popularized techniques other than OOP, which was plaguing the JS world up until recently.
I'd love to give Flow a try -- just waiting for the right opportunity.
Replace JavaScript with Java in all browsers and make it much easier, dependable, predictable and reliable.
Furthmore, it's not even JS that's really the problem. It's the entire JS/DOM/CSS stack.
There will still be more churn as people come up with ways to be more productive, however it will be hopefully concentrated in areas other than build process tooling.
Specifically the fact that we still don't have modules or widely-deployed http2 is what makes the build tool complexity necessary.
The fact that people keep thinking that a 2 and a half month old project is the solution to all of their web development problems is exactly why there's so much churn.
Every new tool overtakes the previous generation by being superficially more simple, only to add complexity of its own over time until the next generation repeats the cycle. It turns out the complexity is there whether you acknowledge it or not, and over time your leaky abstractions will burst.
You can't generate more complexity with a tool that reduces opportunity for developer choice.
A basic example is that a starter app would normally require you to connect 10s of libraries together just to get started. It is difficult to argue that not having to do so is actually more complex.