[Cartwright2]

I'm not sure that we should be doing this.

Yes, it stands to reason that if you take framework X, cut out a lot of functionality, remove some of the "ugly" code that addresses edge cases, then you end up with a similar, reduced framework which is smaller in file size.

But this is done at the cost of polluting the Javascript framework environment. The biggest problem right now is pollution, we're all drinking from the fire hose of frameworks and someone needs to cut the supply so we can double-down on the good stuff and stop jumping from one framework to the next like a plastic bag caught in a strong breeze.

Preact is now a decision point for any developer who Googles "react alternative" and scans far enough through the search results. This isn't right. This contributes to decision fatigue. It's time to stop churning out new frameworks that are only marginally different from what's already available.

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

[hannibalhorn]

One example of a library that has started out this way is lodash, and I think most now consider it superior to the original underscore library. So starting an effort like this sometimes has great results.

Of course, anybody considering using Preact at this stage should already be intimately familiar with React, and it shouldn't factor into a "Backbone or React or Angular or Ember" type decision.

[wesleyfsmith]

I have to disagree. The inherent nature of open source is forking projects just to make some small change that you really want. Sometimes those changes make it back into the original project and improve it. Code diversity is far more important than "developer fatigue".

[boubiyeah]

Yeah... Competition is almost always good.

I wished React was more modular; I will never use propTypes (using typescript), server side rendering or target older browsers with it so I'm probably paying for > half the size of React without needing it. Every detail count.

[andrewclunn]

Except it targets the React API, so the fracturing isn't really an issue.

[rickycook]

well there's now 2 copies of the code, so everything is being maintained twice, there are twice as many opportunities for bugs, they have a list of "preact only" extensions (eg preact-router) that are only necessary because there's now another franework

[bronson]

biodiversity is a good thing.

[jhall1468]

Frameworks aren't life and this isn't diversity anyway. It's React without contexts, refs and proptypes that has fewer developers and significantly less testing. And it's not the only one, because react-lite is React without server-side rendering.

How the hell is feature ripping and repackaging (after removing carefully crafted edge case handling) diversity?

[aytekin]

Reminds me of Firefox. At the time, Mozilla/Netscape was very slow. Firefox, a small and very fast version of Mozilla, came out and took over.

[Cartwright2]

React isn't slow.

[thecrazyone]

You're missing the point he's making. Preact is leaner than react. FF was leaner than mozilla.

React isn't slow (yet?), but it's not hitting any universal limits, there's always scope for leaner, smaller and faster software (yes it is, see benchmark).

benchmark: http://www.stefankrause.net/wp/?p=283

Edit: Added some reference benchmarks.

[elcct]

What if you need something very lean for a specific purpose that React would do well, but it is just too big to justify it. That's ironically an edge case where React fails to deliver and this project fits neatly.

[developit]

In my case, I wanted to take advantage of React-style components, but needed to use them in a massive (MM users) 10-year old website built on jQuery and Backbone, backed by PHP. Since there is no room for overhead, Preact fits very nicely.

[brlewis]

Mithril was too big?