I've commented on this subject before[0], I think the past few years of web development has largely been about answering basic questions. Now there are well tested answers to those questions. I'm sure people will still reinvent these wheels, but now you don't have to when working on a large project.
Babel, Webpack et al are more useful when you're building a web-app, something generally comparable to a native app. The toolchain is complex, sure, but no more complex than what xcode or Android Studio do for you. I think the difference is that this has been a community effort, rather than a corporation assembling a product, so a) there are more people sharing opinions and b) the disagreements and exploration has been more public.
Writing front end code is like writing a CLI. It starts off really easy - you have a use case (whether that's a page about your cat or a script that echoes "meow"), you solve for it, you show it off.
But then people ask for it to do other things. So you have to extend the code - perhaps we need to add flags so users see dog stuff instead of cat stuff. Oh, now users want an actual ascii animal to see so we cater to that. Now they want to name it so let's accept input somehow. They want to issue commands to it so let's deal with parsing and conditional branches.
The problem is that we have to deal with constant changes from browsers, from stakeholders, and from users. Stakeholders want certain features from our programs, users expect a certain standard of performance, and browsers hamper us with incompatibilities.
So we build libraries that solve some of these problems. jQuery helped us build websites, but then web apps became a thing. Backbone/Ember/Angular helped us build web decent web-apps, but then performance became a thing. React/Angular2/Ember2/Vue help us build performant applications... until the next thing.
I think the real problem are the choices people opt-in to. I use React and don't have JavaScript fatigue - but I've also chosen not to use JSX, Babel, Webpack, SSR, live reloading, linting, typing, automated deployment, trello, TravisCI, Docker, k8s, etc. Just libraries imported with script tags, writing ES5 (current standard, 100% implementation), using React.createElement and I've had no issues.
People may opt-in to reinvention and questioning basics, but there are plenty of individuals that get by just fine.
I haven't worked with Java for a long time, but from what I've been hearing from colleagues who are exploring writing production software with it, .NET Core is currently a bit of a mess, showing that even coherent dev stories can easily slip into disorder.
There's lots of strong leadership. React, Angular, Vue, Ember, etc. all have very intelligent, hard-working people backing them. These frameworks aren't "reinventing the wheel", it's the complete opposite: the community has finally freed itself of jQuery/global scope/imperative DOM and these frameworks are all pushing the border in one way or another.
It's the field that is progressing rapidly. Browsers are constantly adding new APIs, problems are being solved, etc. The difference is that it's open source
> a lack of strong stewardship/leadership
You can't have leadership in a field which has no owner. It's not like Oracle owning Java and deciding what happens with it.
> people reinventing the wheel.
This is a stereotype by people who don't really know the subject. Every new tool improves on the previous one. For example, grunt was the first JS build tool, it had some issues (huge configurations, and speed) some someone invented gulp, which uses streams for speed and code instead of configuration. But streams don't handle splitting files in bundles and other problems so well, so webpack was invented. There are overlaps but they all solve different problems, and all improve on the previous generation. They are not "reinventing the wheel"
Snark aside, just because a product exists doesn't mean it's perfect, it doesn't mean that it can't be improved on.
Gulp is significantly easier to work with than make for many usecases, and tools like webpack aren't really comparable to make.
Most of the churn seems to come from people reinventing the wheel over and over again.
Now half (maybe more) of the libraries are being written in languages that aren't javascript so now there are multiple competing ecosystems on top of javascript.
And then you have things like angular creating churn within the framework.
React isn't just Angular with a different name -- they have fundamentally different views on how web development should be done. They also fit different use cases (Angular is a one-stop-shop, React is minimalist by design). Same thing with the build systems. Add in the fact that a lot of this wasn't possible until recently (i.e. Webpack is fundamentally enabled by ES6-style imports) and of course things are going to change rapidly.
> Now half (maybe more) of the libraries are being written in languages that aren't javascript so now there are multiple competing ecosystems on top of javascript.
I'm not sure what you mean by this. Elm-html is the only example I can think of that is non-Javascript. If you're referring to Angular2 being Typescript you can still use it just fine with regular JS.
But secondly, what makes them crappy? I've used make, and IMO it's pretty crappy itself. Have you had to maintain a recursive makefile? It's a complete nightmare to say the least. And i'm far from the only one to think make is worthy of a "remake". In fact even in just the C/C++ world there is cmake, qmake, autotools, scons, ninja, bazel, premake, waf, shake, tup, etc...
If you run your same search in pip, or ruby gems, or composer, or cargo, or cpan, or any other package manager for any other language and i'm sure you'll see it's fair share of build tools, frameworks, libraries, and unmaintained stuff.
It's not a problem, and it never will be.
It's a problem because every time I need $tool I might have to evaluate dozens of choices, check for compatibility, investigate the ones that suit, hope to god the rest of the community is familiar with it, hope it is supported in future, etc. And then with the rate of churn you might have to do the same in a year. Make has been supported for 30 years, I know it's not going anywhere.
> In fact even in just the C/C++ world there is cmake, qmake, autotools, scons, ninja, bazel, premake, waf, shake, tup, etc...
So there's already dozens of tools, why reinvent them in javascript? Every ecosystem does this but it least most seem to settle on one or two tools, this doesn't seem to be happening in the javascript world.
Maybe it's me, but I've never looked at a list of tools and thought "this is too many!". The more the merrier IMO, and if they are good then they will rise to the top over time. If you don't want to choose, just pick the most popular and deal with it, it'll feel the same as another platform where there's only one to choose from.
But you could also just use make, it's all about your needs. Do you want your project to still build in a few decades with very little change? Then choose the tools for that. You just making a pet project that just needs to live until the domain expires? Try out something new! Afraid of change? Stick with make!
>Every ecosystem does this but it least most seem to settle on one or two tools, this doesn't seem to be happening in the javascript world.
For the most part JS has settled. When it comes to "stuff like make" it's basically gulp or grunt (or make and friends). Yeah there are other smaller players, but there's also a few dozen Java build tools that you've probably never heard of.
When I last looked into it I gave jake a go, but then you run into problems where other random tools only have grunt/gulp plugins. The core tools of the ecosystem just seem to be picking all the wrong abstraction points.
99% of tools have a CLI and it's generally pretty damn good.
If you don't have many "tasks" or they are pretty simple, just use npm's built in "npm run scripts" which works fantastically for smaller projects IMO.
I agree though about the lack of ability to pass flags. I wanted something that lets me make command line commands as tasks, build a dependency tree ala gulp, and pass in optional flags to trip things like prod vs dev builds.
But at the end of the day getting make to cooperate on all platforms was a mess, and it sure as shit didn't scale well or do stuff in parallel at all. So a simple if somewhat inelegant gulp file seems the best bet for us.
(I imagine this is how new build systems are born!)
There is the problem of diffraction of efforts, and spreading knowledge too thin. You see some of the problems in the way linux distros do packaging - every major distro family has its own packaging system, born from NIH syndrome. The result is less portability of both packages and skills.
Some competition is good, but there is a point beyond which lots of choice becomes counter-productive. Troubleshooting also becomes harder when the various tool communities are smaller on average.
And there's something to be said about smaller single-purpose tools. Adding a ton of features to something like make to support every possible option isn't a good idea IMO. Sometimes a small opinionated package with a "correct" way to use it is best for some circumstances.
Regardless, I really think that the market will sort itself out. If it's oversaturated then some big players will rise to the top and the rest forgotten. Unlike a Linux distro package manager, anyone can add anything to NPM with zero oversight. It makes the "floor" of quality much lower, but fragmentation isn't that big of a deal as the effort to publish is so low.
If you'd stopped the churn two years ago, people would be using Bower for front-end package management in addition to NPM, and Gulp or Grunt for task automation. Now a few churns later, NPM is the only package manager you need since you can use Webpack to automatically cut out your duplicated front-end packages. And now NPM provides all the task scripting most devs would need, so no more Gulp or Grunt.
Things are getting simpler and easier, but if you're looking from the outside you'll just see a long list of names of tools.
We should stop being so content with not being/using the worst.