[terrortrain]

Nope. People should always create and attempt improve upon whats out there.

Don't try to stifle innovation for the sake of making decisions simpler.

If you don't want to make decisions, don't use libraries, or use an opinionated framework.

[Cartwright2]

> People should always create and attempt improve upon whats out there. Don't try to stifle innovation...

I agree completely and my argument is that a lot of the Javascript libraries being pushed around over the past three to four years are neither creative nor improvements over what already exists. React is innovative. Redux is (arguably) innovative. jQuery was innovative. Many other libraries have been innovative. I'm arguing against the hundreds upon hundreds of "me too" libraries that make it so much harder to find the truly innovative stuff. These libraries do nothing but add to decision fatigue. Developers have to make decisions, sure, but we need to have limits too.

[steego]

> These libraries do nothing but add to decision fatigue. Developers have to make decisions, sure, but we need to have limits too.

Nonsense. These "me too" libraries add to the decision fatigue only if you're including them in your list of candidate libraries in the first place. Personally speaking, I won't even consider Preact until one of the following events has occurred:

1: I tell myself I really really need a 3k React-like library. 2: I've heard more than a few people mention Preact. 3: I discover something really awesome about it that will save me lots of time.

Apart from those events, I'll simply ignore it and not worry if I made the wrong decision. You have the power to ignore me too libraries.

[dimgl]

I agree with this as well. Just because I've heard of Mithril.js doesn't mean I'm going to now start considering Mithril for my projects.

One of these Javascript libraries could end up introducing an innovative idea or have a feature that other libraries don't. It wouldn't make sense to just stop making them because there's a lot of them out there.

Javascript fatigue only happens when you start giving all libraries equal consideration and using new frameworks just because they're what's "in".

[smt88]

The fatigue doesn't come from giving all libraries equal consideration. It comes from having to decide what's "in" and for how long. Sometimes it takes days of research just to decide if something is popular, let alone whether it's going to last.

[mattlutze]

> Nonsense. These "me too" libraries add to the decision fatigue only if you're including them in your list of candidate libraries in the first place.

Unless you're one of the minority of folks who read all the new trends and follow all the new releases, you won't know not to include some or all of the Me Toos in your AOA.

Most anyone who falls into the less-than-expert experience level included, which covers a ton of folks having to waste far too much time evaluating all these different libraries (and sometimes or often making bad choices as a result).

What's the technical debt and wasted time in the industry due to "I've got an idea" library glut? More than a bit, I'd wager.

[true_religion]

Jquery-UI in particular had a lot of competitors, and it just overran all of them before itself dying an ignoble death of stagnation while CSS improved to the point that most of what it offered could be done simply in another way.

[jordanlev]

I would actually not consider jQuery to be innovative as much as it was a refinement/improvement of existing libraries such as Prototype and Dojo. I think jQuery is great so this isn't a knock against it, but rather just saying that sometimes one thing comes out that is revolutionary but then something else that is an improvement/iteration on that smooths out the rough edges and becomes "the one framework to rule them all" (for a few years, at least).

[ratbeard]

jQuery's api seemed innovative and quite different than the other libraries I used at the time.

- css selectors to get at nodes. Very dom-focused, but without messing w/ prototypes like _Prototype_ did

- almost every function in the api acted on both single nodes and collection of nodes. It seems like it started the 'chaining' trend.

- no complicated class/namespace hierarchy to learn. Every function was on $ or $.fn. `$('.foo').hide('slow')` vs the equivalent in Prototype involved instantiating an Animation object and passing in the dom node, as I recall.

- cared about file size and not clobbering other globals.

[coldtea]

Improvement on an existing design is still innovation.

The invention of rubber tires WAS innovative, even if we had stone/wooden wheels for milennia.

And the iPod was innovative, even if we had heavy, crappy UI, plasticky third party mp3 players before that.

[terrortrain]

Making something better by making it more lean, more stable, or more understandable is still innovating. Originality isn't the only factor.

[dustingetz]

Freedom of speech

[rimantas]

So maybe it is time to stop and instead of making of/searching for yet another JS lib just think, should I be doing this on the web in this way at all. This trend to make everything on the web into some kind of application has already thrown out of the window all the good that was done for the web in the past 10-12 years.

[boubiyeah]

What? This is 2016, apps on the web are proven to work well for quite some time now.

[at-fates-hands]

>> Nope. People should always create and attempt improve upon whats out there.

Unless like he states, it causes decision fatigue. What's easier? Looking through a small group of well documented and supported frameworks OR trying to a find a decent framework among hundreds of frameworks; many of which, I might add, are either poorly documented or have inherit issues you won't discover until you're already too deep in your project to change.

It's interesting to note that in virtually every industry, they realize that giving the customer too many choices leads to fewer sales, less success and leaves them paralyzed and unable to make a decision. Yet, in software development, we firmly believe the exact opposite is true? That somehow giving developers more and more choices is somehow better?

Some more support for what I was saying:

https://www.gsb.stanford.edu/insights/research-too-many-choi...

“People fail to realize that relatively rigid structures can often simplify goal pursuit by removing the need to make choices, especially when people are already well into the process” she says.

http://www.nytimes.com/2010/02/27/your-money/27shortcuts.htm...

That study “raised the hypothesis that the presence of choice might be appealing as a theory,” Professor Iyengar said last year, “but in reality, people might find more and more choice to actually be debilitating.”

Research also shows that an excess of choices often leads us to be less, not more, satisfied once we actually decide. There’s often that nagging feeling we could have done better.

[terrortrain]

This isn't a customer experience, there are no corporate overlords trying to maximize profit from FOSS.

FOSS projects exist because people want to make them. If someone feels the need to contribute their own time, FOR FREE, in an attempt to improve on something, there is no reason to put them down.

If the project is not useful for anyone it will just die away. It may, however, contribute something great. FOSS developers shouldn't give a damn about your customer experience with the language. They should care about contributing to the ecosystem in whatever way they feel they can.

Some projects turn out better than others, and some innovate in different ways. This one is attempting to innovate by recreating react with a different footprint. Don't use it if you don't like the idea, but don't discourage people from creating because you don't have the same values as them.

[pacomerh]

I'm supporting this mentality. You should always be looking for ways to make existing things better. This is exactly how React was born damn it.

[esailija]

I didn't know React was born by taking another library and removing all the polish and most features from it and then publishing it with almost the same name.

[eva1984]

No, such derivative work, is pretty much the opposite of innovation. It is like 'Apple made another color variant of this year's iPhone, awesome, check it out'.

What's worse, they are maybe 10s of them every week, distract the community's focus to improve let alone perfect current system.