[ohfunkyeah]

Think of a professional vehicle driving. Be it race cars, trucks, etc... Sure, maybe in the early days those cars and trucks looked and worked way different from each other but over time the available ones largely overlap, work similarly, and work well in almost all situations. If every time a new car came out you had to spend several days/weeks trying to figure out how to drive it that would be incredibly annoying. Now just think if you needed to purchase a vehicle and stake your business on it. You look at the options and some come without wheels, some without seats, some had designers that said brakes aren't neccessary, oh and there is an upcoming one that is getting a lot of attention the can also fly... some take gas, others run off vegetable oil. Experimentation is good but there are way too many options parading around as serious contenders.

[dandelany]

The problem with your analogy is that, in it, we are the consumers, the people who buy the car. I would agree with some of your points if you were speaking from an end-user's point of view.

But as developers, we're the engineers. We build the car. It is explicitly our job to do all the hard work of picking out the appropriate parts and assembling them in a way that provides a seamless experience for the end user. IMHO complaining about "way too many options" is like a Ford engineer complaining that there are too many (let's say) turbochargers available with varying levels of quality, and it's unclear which one should go in the new car she's designing. It's supposed to be hard, these are precisely the hard problems we are getting paid lots of money to solve.

[TeMPOraL]

The relation of consumption is transitive. End-users consume our products. We consume libraries and frameworks we use to build this tools. Just like in the analogy buyers would be annoyed by the plethora of choices, many developers are getting annoyed at constantly changing "best library" ecosystem.

> It's supposed to be hard, these are precisely the hard problems we are getting paid lots of money to solve.

And quite a lot of those problems - including this situation - are instances of the so-called accidental complexity. I.e. difficulties we inflict on ourselves, not parts of the problem that's being solved.

Anyway, the problem seems to be more profound in software than elsewhere, and I think it's because of the medium - code is very malleable; it's easier to rewrite a program than to redesign a car that's already being manufactured. So it makes it tempting to consider changing frameworks, instead of picking one that's good enough and sticking with it.

[ch4s3]

>there are way too many options parading around as serious contenders. Its early days for some of these concepts on the web (I mean, discounting some stuff that happened years ago at Xerox Parc which got beat out by worse technology). So by what objective measure are there too many options? There are a few very well established options: React, Angular, and Ember. If you need standards and heavyweight support and reliability, use one of those things. I'm sure in a few years, things will have coalesced and standardized a bit further.