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.
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.
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.
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.
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".
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.
- 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.
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.
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.
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.
What's worse, they are maybe 10s of them every week, distract the community's focus to improve let alone perfect current system.