Preact, a fast 3k React alternative
developit.github.io
developit.github.io
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.
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.
How the hell is feature ripping and repackaging (after removing carefully crafted edge case handling) diversity?
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.
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.
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.
I'm using mercury [0] in my current frontend project for this purpose. Most of the features of React, none of the commitment. Every single component is interchangeable; the core repository is simply an index.js requiring other modules, which can be depended on individually if you're not looking for a kitchen sink solution.
Especially by using ES6. Also these guys made some cool addon libraries that are as small as the core library.
The only thing I dislike is that the core library is a single source file. Why do people create source files with < 1000 lines..
Decomposing your code into modules is step one. Making the interface between your modules generic enough to easily replace is the next problem, but if your code is a monolithic blob in the first place that's not going to be possible.
My main issue with modularity in JavaScript is the lack of strict typing, because you won't know if your interface fits correctly until runtime - which is why I've been looking into TypeScript and Elm recently.
check out vidom, kivi, citojs, domvm (mine), etc...
domvm is actually one level above pure vdom libs and a level below frameworks. it offers a very fast, stateful and reusable view layer over a vdom diffing engine. it was written to solve some architectural disagreements and speed issues i had with using Mithril MVC for several projects.
How much time did you spend setting up the plumbing for the project? That's key.
All it will really take is one person to merge, say, React with a boilerplate-reduxed Flux framework, a REST library, and a handful of other must-haves, under a single, new product name. Let's call it "Rimble". When people realize they can "import { Component, Actions } from Rimble" we'll see a shift towards monolithic frameworks and the ball will start rolling back in the right direction.
Can you justify why 'monolithic frameworks' is the right direction?
Everything will just work with defaults. Not like this travesty: https://github.com/kriasoft/react-starter-kit
The JS community has gone way overboard on factoring everything into a dozen little submodules, IMO.
Mercury has the classical issues of wrapper models too, whereas with something like flux or similar, you can easily work with good ol JSON.
virtual-dom is a pretty nice lib though, and a strong foundation for people willing to create their alternative, opinionated lib.
However, I completely disagree that Preact is a "React alternative." React is not simply a bunch of code. It's an entire ecosystem with a large community supported by a well-funded entity. A lot of these new libraries and/or frameworks popping up seemingly every other week and claiming to be an alternative to X are just not up to par with the competition and/or the expectations of developers.
Whenever I see something new on the radar, I look at the documentation and commit history. Anything unproven without good documentation, examples, unit tests and/or performance tests is just ignored. If I really like the concept, I'll bookmark it and check on it periodically.
Preact: https://github.com/developit/preact/blob/master/src/preact.j...
React: https://github.com/facebook/react/blob/3b96650e39ddda5ba4924...
How is writing "class Blah extends Component { ... }" any better than "Blah = Preact.createComponent({ ... })", except to save a few keystrokes?
ES6 is full of syntactic sugar to improve readability, but classes substantially increase the "surface area" of the language for... what benefit? Static analysis and tooling, maybe? In that case, why not wait until ES7 is fully baked to build interesting features around the type system, instead of making yet another Java derivative...
And the fact that almost every major framework has implemented something similar themselves is proof enough (for me at least) that the ES6 sugar is valuable. It has nothing to do with Java, it's simply a useful pattern that everybody was already using.
function Foo() {
}
Foo.prototype = Object.create(Parent.prototype);
....
EDIT: Just tested in Firefox and indeed you can.
Even if it is just syntactic sugar, that syntactic sugar makes it much more approachable for devs who want to use classical inheritance (not that I'd encourage that).
super.propertyOnSuper ~= this.__proto__.propertyOnSuper
super() in constructor ~= ParentConstructor.call(this)
https://github.com/isaacs/inherits/blob/3af5a10c6b51f9e99d9f...
To me the readability benefit of classes, "extends" and "static" that work intuitively, "constructor", "super", etc. is immense, especially when you pair with something like Facebook Flow that let you declare the members with types. I consider it one of ES6's most compelling features. No more writing out "MyClass.prototype" just to declare basic classes with methods.
I don't write nearly enough JS to say there is unequivocally a better way to write programs, but it's a bit disappointing that no one has figured out more advantageous ways to leverage the nature of the language without, IMO, leaning so much into cultural "learned behavior" from other OO languages.
There's no change in the type system. Javascript is still a prototype based language.
There's no real value to a class system in a dynamic language, beyond synthetic sugar. Arguable prototypes are better since you don't get to question "if everything is an object, and classes are objects then what class is a class of?"
With ES7 decorators, you can put a mixin into a class... which gives you class sugar + traits, so essentially multiple inheritance without the downsides of it.
ES7 can be enabled today via Babel.
Context is not a good feature, and even the developers didn't want to write documentation for it because they didn't want people to use it. https://github.com/facebook/react/issues/580
I don't like contexts either :(
curl --silent --output /dev/null -H "Accept-Encoding: gzip,deflate" --write-out "size_download=%{size_download}\n" https://cdnjs.cloudflare.com/ajax/libs/react/0.14.6/react.mi...
>> size_download=39542
Though, you do need webpack/browserify/etc to take advantage of that.
[1]: https://github.com/facebook/react/blob/401e6f10587b09d4e7257...
See: https://twitter.com/dan_abramov/status/656970508005736448
AFAIK Webpack2 is using Rollup under the hood. While rollup is great and can build smaller outputs (biggest win seems to be elimination of the module system overhead) it can't perform miracles.
In short: size still matters, even with dead-code elimination tools (at least as they are today).
preact.com
[0] https://github.com/creationix/domchanger
[1] https://github.com/jesseskinner/hoverboard
[2] https://github.com/girvo/domchanger-hoverboard-flux-challeng...
There were some benchmarks where Preact was faster, but overall half React's speed.
All other libraries either don't have any form of recycling dom nodes, or it is disabled for this benchmark.
Is there a 1k-React challenge going on?
> Preact is an attempt to recreate the core value proposition of React (or similar libraries like Mithril) using as little code as possible, with first-class support for ES2015.
I understand building a faster React, an easier to use React (forms are a nightmare), but a smaller React? We are talking about saving on the order of 30kb. This doesn't even matter on mobile. Can anyone give me a compelling use case?
Less code can also mean its easier to understand and has pruned the legacy/redundant parts (being ES2015 only).
And being able to read the whole code of your framework in one sitting, and understand it, is great.
Besides, it's not like "as little code as possible" is their ONLY goal. They're not merely building a drop-in React replacement with less code. The reference to "Mithril" looks like they'll also investigate their own APIs and ways of hooking components etc, which will be similar in concept but different than React's exact APIs -- they already dropped the non-stateless components APIs.
[addition] Regarding the "order of 30kb savings". Here's an excerpt from their site: "The React-based demo was 1.8mb of JavaScript. This demo, using exactly the same code and with the same functionality, is 60kb.".
Riot, on the other hand, has a completely different API
In the second benchmark, Preact is only faster in around half of the tests. However, this benchmark only tests complete top-down re-renders and intentionally triggers synchronous rendering in Preact. In a normal app composed of Components, Preact batches state changes which improves performance considerably.
If I was recommending a development path to a young developer I would have to say choose the "dark side" and become an app developer and let Apple / Google feed you your framework. Don't waste your time on the web - you'll waste your life learning this weeks flavor of the month framework while lacking core understanding of the underlying technology ( https://wdrl.info/archive/121 ) and never seeing your code amount to anything but a series of band aid and kludges.
But, it's very possible to lose time trying to figure out what you "should" choose or even what your choices might be.
And since that's what the parent is bemoaning, your distinction is pretty useless.
Note: If you want to use react then the correct choice is react + redux + webpack. If you want to validate a startup idea, then the correct choice is jquery :)
Anyway, for sure there is a tonne of cruft and confusion when starting a new js project(SPA app) nowadays. Esp if you want to use react: it's one of the blessings/curse of using a library vs a framework.
If, however, you stop looking for the "right" way to do things by reading blog posts etc,and just take the easiest path with react, then redux and webpack will take you far enough.
The web is the platform that works across all devices. Sure an app is great when you already use that site, but before they're invested, are people really gonna download an app?
Not to mention that you're heavily reliant on Apple and Google for your framework. With the web, you can use whatever you like, you can even roll your own if you want.
Sure there are a lot of JavaScript libraries, but how else will ideas evolve?
We're trying to avoid snarky dismissals here, especially in response to new work. Substantive criticism is fine, so this comment would be better with just the second paragraph.
I feel sorry for the young developer
I meant to troll, sorry.