[dandelany]

With respect, friend, you do it to yourself... If a mention of a new library on HN is enough to shake your confidence and make you think your entire app stack is wrong - that's not a Javascript problem. I understand feeling overwhelmed with all the new libraries, but get confident with a JS stack that you like, and stop worrying about all the hype.

[chrshawkes]

Inferno is basically React, so instead of contributing to react to make it better they made a new project instead. Hipster hype is a PROBLEM in the JS community.

[trueadm]

That is so far from the truth that it's unbelievable. Inferno has the same surface API as React – the public endpoints. Everything under the hood is different though and it's different for many good reasons which I'll cover in a blog post in the coming weeks for the official 1.0 release of Inferno (and its website).

If there's nothing wrong with your app and you're using React – keep using it. If you are experiencing performance issues on mobile, maybe Inferno is an option with its compatibility layer until future versions of React can fix your issues.

Note: I'm the author of Inferno

[dandelany]

Inferno is very similar to React, but with enough differences in implementation that the contributors decided to make it its own project. Competition is good. Cars weren't invented by everyone focusing their effort on building the same car. Instead, many teams built many cars with similar, overlapping functionality, and over time, the good parts stuck around, and the bad parts came out in the wash. JS UI libraries are no different. I don't understand everyone's apparent obsession with uniting around "one true JS framework". Use what works for you. Build what you want to build. But don't complain that someone built this library that you don't want to use.

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

[WhitneyLand]

Why should someone not be able to create whatever project they want and try to make something useful or just for an experiment?

It also seems:

1). You criticize quickly without knowing all the benefits of what he's trying to accomplish

2). He never mentioned hipsters but your own personal projects actually advertise hipster in the name