
Preact, a fast 3k React alternative - davideschiera
http://developit.github.io/preact/
======
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.

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

------
udp
We don't need smaller frameworks, we need more _modular_ frameworks. If the
framework is modular you can take what you need, and replace the parts you
don't like.

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.

[0] [https://github.com/Raynos/mercury](https://github.com/Raynos/mercury)

~~~
cageface
I prefer opinionated, integrated frameworks. I can count on the whole stack
being well tested and don't have to worry about subtle bugs and versioning
issues between components.

The JS community has gone way overboard on factoring everything into a dozen
little submodules, IMO.

~~~
sotojuan
While I feel like I'm close enough to tame the React ecosystem (and like it!),
I honestly agree. Personally I do prefer opinionated. Luckily Ember exists in
the JS world.

~~~
orf
Ember is awesome, it doesn't seem to get much love on HNews though. Which is a
shame because its really really good - I tried react and spent 2 days messing
with various starter packs, trying to get webpack configured and not getting
anywhere. Ember took me half an hour to get started.

~~~
sotojuan
Not just HN. I rarely see it mentioned elsewhere. Even in those "JS fatigue"
articles which is funny because Ember is the antidote to that.

~~~
szines
Because Ember devs already found the best tool years ago and they are super
productive. The community is huge and super active but they definitely totally
ignore this "fatigue" bullshit... you know, if you found your love of your
life, you don't go any more in the dance club to chase other boys/girls... ;)

------
rygine
It's always interesting to see a fresh take on something already in use,
especially when the focus is on optimization.

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.

------
losvedir
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?

~~~
Ronsenshi
Lack of synthetic events is a huge one for me.

~~~
developit
This is extremely interesting to me and I would love to hear why. I skipped
synthetic events because I didn't feel they were necessary, but I would
appreciate additional insight.

------
jallmann
Off-topic, but am I the only one who thinks that classes are the most puzzling
feature of ES6?

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

~~~
nilliams
Well for one 'class Foo extends Bar' will work without any further code to
make inheritance work in the way you'd expect, including use of super() etc.
Whereas your second example is using non-trivial framework code, that some
framework author has to write. See Backbone's extend() for a clear example of
what is required [0]. That's work that every framework author is potentially
going to implement differently, needlessly.

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.

[0]
[http://backbonejs.org/docs/backbone.html#section-247](http://backbonejs.org/docs/backbone.html#section-247)

~~~
jallmann
The question is whether that ~15 lines of code, written once, is worth the
substantial increase in the surface area of the language, especially when
overlapping so much with the existing prototypal inheritance mechanism. The
choice to use Java/C++-style inheritance is a design pattern that doesn't
necessarily reflect the only (or even the best) way to accomplish things.

~~~
Touche
ES6 classes do not use Java/C++ style inheritance, they are still the same as
writing:

    
    
      function Foo() {
    
      }
    
      Foo.prototype = Object.create(Parent.prototype);
    
      ....
    

It's just sugar, nothing more.

~~~
jallmann
The semantics of JS classes are still different in enough subtle ways:
constructors and constructor subclassing, (lack of) object properties,
hoisting, etc. That is on top of the new keywords, new function syntax, etc.
All that needs to be mapped onto the model of "classical" Javascript in order
to completely understand the language. There are enough gotchas there to
disqualify JS classes from being simply sugar.

~~~
Touche
You can add object properties to a ES6 class's prototype, no?

EDIT: Just tested in Firefox and indeed you can.

~~~
jallmann
Not in the class declaration, though. Why force the programmer to go through
the prototype, when ES6 provides such a "convenient" abstraction around it?

~~~
phpnode
Coming to the spec soonish and already supported in Babel -
[https://github.com/jeffmo/es-class-fields-and-static-
propert...](https://github.com/jeffmo/es-class-fields-and-static-properties)

------
levisegal
How does this stack up versus something like riot.js?
[http://riotjs.com/](http://riotjs.com/)

~~~
xaduha
RiotJS couldn't keep it to the original size of about 3 KB, it's about 9 KB
now. They market it as a "React-like", but it appears that this one is way
more "React-like" than RiotJS ever was.

------
dchest
I started using Snabbdom, which is also tiny, but has a nice module/hook API:
[https://github.com/paldepind/snabbdom](https://github.com/paldepind/snabbdom)
(plus 'style' module supports transitions/animations).

------
holic
Compared to React, what _isn 't_ available in Preact?

~~~
Sheepsteak
Last time I checked you couldn't use contexts yet.

~~~
terrortrain
Thats a good thing.

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](https://github.com/facebook/react/issues/580)

~~~
zbyte64
Then how would something like react-redux work without context?

~~~
boubiyeah
It can already work without contexts. You just pass a store instance via
props.

I don't like contexts either :(

~~~
developit
Yup. I've successfully added contexts to Preact, but I still am not 100% sold
on the value. Thankfully, simply supporting them doesn't add much bloat.

------
rpedela
How big is React gzipped? How much are you saving with this library?

~~~
LaurensBER
Perhaps even more important, does library size still matter once dead-code
elimination is an option in Webpack2?

See:
[https://twitter.com/dan_abramov/status/656970508005736448](https://twitter.com/dan_abramov/status/656970508005736448)

~~~
merb
Just take a look, how many libraries are written in ES6, clearly not much. So
dead code Elimination only works if you have ES6 libs and that will take some
time.

------
corywatilo
Yeah, there's already a company called Preact. =]

preact.com

~~~
gnat
A good one, too. The last startup I worked for was one of their first
customers. You fire off events, they machine learn normal behaviour for your
customers and feed the intel to your customer success team so you can prevent
churn and identify your high-performing customers.

~~~
developit
Yeah... causing this confusion is one of my more regrettable mistakes of the
year. Honestly if some amazing name came along I would not be entirely opposed
to changing it.

------
girvo
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].

[0]
[https://github.com/creationix/domchanger](https://github.com/creationix/domchanger)

[1]
[https://github.com/jesseskinner/hoverboard](https://github.com/jesseskinner/hoverboard)

[2] [https://github.com/girvo/domchanger-hoverboard-flux-
challeng...](https://github.com/girvo/domchanger-hoverboard-flux-challenge)

------
lhorie
Re: fast claim, it turns out it's not that fast:
[http://localvoid.github.io/uibench/](http://localvoid.github.io/uibench/) :(

~~~
brlewis
My results: Preact 2.7.3 took 864920; React 0.14.6 took 435580

There were some benchmarks where Preact was faster, but overall half React's
speed.

~~~
localvoid
Preact is using implicit dom recycling, so it heavily breaks use cases like
"tree/[*]/render". Just hold mouse over its time and it will display "max"
time, it will be much closer to reality.

All other libraries either don't have any form of recycling dom nodes, or it
is disabled for this benchmark.

------
igl
Unfortunately no word on browser compat. But wow. I thought
[https://github.com/Lucifier129/react-
lite](https://github.com/Lucifier129/react-lite) was slim.

Is there a 1k-React challenge going on?

~~~
tjelen
I've found this in the project wiki
[https://github.com/developit/preact/wiki/Browser-
Support](https://github.com/developit/preact/wiki/Browser-Support)

------
ivanceras
I've look at react, angular, mithril, and lately elm. It seems elm is here to
stay.

------
kansface
The value proposition of Preact makes no sense to me:

> 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?

~~~
coldtea
> _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.".

------
nnx
How does this compare to Riotjs "A React-like user interface micro-library" ?
riotjs.com

~~~
lhorie
This project aims to be API-compatible w/ a subset of React's API.

Riot, on the other hand, has a completely different API

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

~~~
developit
[https://github.com/developit/preact-
perf](https://github.com/developit/preact-perf)
[https://localvoid.github.io/uibench/](https://localvoid.github.io/uibench/)

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.

~~~
localvoid
All libraries in uibench have batching, and batching doesn't improve
performance, it just prevents from doing unnecessary work during one frame. It
is pointless to test performance of different state changes with enabled
batching.

------
fibo
It makes sense stay tiny if you are creating a small component yo be exported.

------
amelius
And now we're all hoping for Preact Native...

~~~
mbrock
I'm hoping for React Native to be maintained, stable, and performant...

------
elcct
I was thinking about something like that today and now I see this. Awesome!

------
harryf
Oh another JavaScript framework. Of course the world needs that.

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](https://wdrl.info/archive/121) ) and never
seeing your code amount to anything but a series of band aid and kludges.

~~~
imtringued
It's not another framework. It's not even another library. It's an
implementation of an existing library with some features cut out.

~~~
mildbow
We have so many choices in the javascript ecosystem that it's pretty
impossible to make a meaningful choice.

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 :)

------
eddd
I am just sitting here, watching elm organically growing, while people
creating "new" react-flux-redux-ember-angular-dojo-backbone frameworks every
day.

I meant to troll, sorry.

