I'm not sure that we should be doing this.<p>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.<p>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.<p>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.
We don't need smaller frameworks, we need more <i>modular</i> frameworks. If the framework is modular you can take what you need, and replace the parts you don't like.<p>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.<p>[0] <a href="https://github.com/Raynos/mercury" rel="nofollow">https://github.com/Raynos/mercury</a>
It's always interesting to see a fresh take on something already in use, especially when the focus is on optimization.<p>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.<p>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.
Where do the savings come from? I can't imagine that React.createClass() is all that much code. I'm guessing a lot of space saving comes from not doing PropTypes (which I find immensely useful) and not having a synthetic event system (meaning you can't test with TestUtils.Simulate.click()). What else is missing I wonder?
Off-topic, but am I the only one who thinks that classes are the most puzzling feature of ES6?<p>How is writing "class Blah extends Component { ... }" any better than "Blah = Preact.createComponent({ ... })", except to save a few keystrokes?<p>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...
I started using Snabbdom, which is also tiny, but has a nice module/hook API: <a href="https://github.com/paldepind/snabbdom" rel="nofollow">https://github.com/paldepind/snabbdom</a> (plus 'style' module supports transitions/animations).
Interesting. In terms of "React alternatives that are tiny", I have a really big soft spot for domChanger[0]. Really cute syntax, and it works pretty well -- I built most of a TodoMVC implementation with it and Hoverboard[1] (a tiny Flux implementation). I also completed a partial "Flux Challenge" implementation with that same combo [2].<p>[0] <a href="https://github.com/creationix/domchanger" rel="nofollow">https://github.com/creationix/domchanger</a><p>[1] <a href="https://github.com/jesseskinner/hoverboard" rel="nofollow">https://github.com/jesseskinner/hoverboard</a><p>[2] <a href="https://github.com/girvo/domchanger-hoverboard-flux-challenge" rel="nofollow">https://github.com/girvo/domchanger-hoverboard-flux-challeng...</a>
Re: fast claim, it turns out it's not that fast: <a href="http://localvoid.github.io/uibench/" rel="nofollow">http://localvoid.github.io/uibench/</a> :(
Unfortunately no word on browser compat.
But wow. I thought <a href="https://github.com/Lucifier129/react-lite" rel="nofollow">https://github.com/Lucifier129/react-lite</a> was slim.<p>Is there a 1k-React challenge going on?
The value proposition of Preact makes no sense to me:<p>> 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.<p>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 !== faster code. I wouldn't even try this without seeing some impressive performance benchmarks. Giving up the support of the entire react team and community in exchange for a small framework that may or may not be faster is a huge ask.
Oh another JavaScript framework. Of course the world needs that.<p>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 ( <a href="https://wdrl.info/archive/121" rel="nofollow">https://wdrl.info/archive/121</a> ) and never seeing your code amount to anything but a series of band aid and kludges.
I am just sitting here, watching elm organically growing, while people creating "new" react-flux-redux-ember-angular-dojo-backbone frameworks every day.<p>I meant to troll, sorry.