
Preact : a smaller, faster React alternative - thmslee
https://blog.logrocket.com/introduction-to-preact-a-smaller-faster-react-alternative-ad5532eb6d79
======
sctb
Previous discussion:
[https://news.ycombinator.com/item?id=15053082](https://news.ycombinator.com/item?id=15053082)

------
amelius
To all people who write React-alternatives: please modularize as much as
possible. For example, JSX-like syntax is not necessary and some developers
might not want to use it; therefore, it should be in a separate module that is
completely optional. Also, the virtual-DOM part may be useful in itself,
therefore it should also be a separate module. React offers some tools to more
easily manage state, but please acknowledge that there are developers out
there that have even smarter ways to deal with state.

~~~
demarq
I disagree, and prefer monolithic frameworks than modular ones.

Catering for a common configuration of modules allows the maintainer and
contributors to make more assumptions. These assumptions allow them greater
freedom to optimize performance and simplify interfaces.

Lego like frameworks have to be uber generic thus catering to theoretical
computer science aesthetics rather than real world practical use cases.

if a developer wants to stray from the "recommended" path, they should do so
at their own cost. The community should not belabor themselves to accommodate
outliers.

maintaining these projects is really hard work.

~~~
git-pull
Echoing this. Some personal anecdotes:

Back in 2012, I remember when Backbone Marionette broke into pieces. It made
"logical" sense, but the instances you'd actually want to pull in the event
library without taking in Marionette is rare.

There's a certain sense you have to be tactical with decoupling stuff. I
decouple front ends from libraries because I don't want my users to be forced
to use my CLI front end when they just want an abstraction with minimal
requirements.

I get away with it because there's 1 library and 1 frontend.

In JS, there's a front end, a library, and an extension marketplace that make
you wonder what they were thinking when they were decoupled. Stuff like
extract-text-webpack-plugin.

Guess what that plugin does: It allows you have your CSS show up as CSS files
instead of JS. But the title denote that, (forget that fact you'd expect
webpack to have such simple stuff in webpack itself.) It instead is "extracts
text", despite the fact the convention of "text extraction" means nothing to
web developers.

------
StreamBright
Is this viable to use as a drop in replacement for React? I am concerned about
the license using React, that would be the sole reason to chose something
else. I also got few projects in React that we would like to keep.

~~~
danmaz74
Be very careful. If FB holds any patents covering React, they are also enough
likely to cover Preact. And there is no patent grant at all with Preact.

~~~
pluma
Also, for all we know FB might hold patents covering parts of Angular or Vue
as well. Avoiding React because of the patent grant is a complete non-
sequitur.

The only thing we know about FB's patents is that using React means they won't
sue you over patents covering React and they won't revoke the grant if you
countersue (unless you countersue for patents _you_ hold over React).

The entire hysteria seems to only be backed by armchair lawyering and open
source purism (the latter of which is orthogonal to whether there is a legal
risk or not). There are plenty of major corporations that likely hold an
arsenal of patents who use React despite these concerns.

Unless you're an Apache project (and thus have to worry about open source
purity) or a direct competitor who intends to sue people over patents (and
thus have to worry about patent warfare), stop worrying about patent grants.

~~~
StreamBright
What about the following situation:

We are approached by a big company to buy our startup. In that case do they
have the same limitation of not being able to sue Facebook? Do you think that
Amazon or Google would be as happy buying your startup with React as without
it? I was just wondering about this angle.

~~~
pluma
Amazon uses React. [https://medium.com/@blairanderson/amazons-new-brand-
stores-u...](https://medium.com/@blairanderson/amazons-new-brand-stores-
utilizing-react-framework-a22f56e9e206)

Google uses React. In fact, that's why the language used in the patent grant
was changed.
[https://github.com/facebook/react/issues/7293#issuecomment-2...](https://github.com/facebook/react/issues/7293#issuecomment-233302318)

Apple uses React.
[https://twitter.com/soprano/status/705516380913692672](https://twitter.com/soprano/status/705516380913692672)

Twitter uses React. [https://www.infoq.com/news/2017/02/twitter-react-mobile-
stac...](https://www.infoq.com/news/2017/02/twitter-react-mobile-stack)

Microsoft uses React.
[https://microsoft.github.io/reactxp/](https://microsoft.github.io/reactxp/)

Seems like they don't care what some guy on Medium thinks.

~~~
c12
Seems like sound logic that given many different companies including those in
competition with Facebook are using React that there should be no worries for
the rest of us.

------
outsidetheparty
I'm really curious, what did they have to throw overboard to lighten the load
from 45kB to 3kB? They list a handful of missing bits[1] -- I'm not a React
developer so I don't know how significant they are, but they don't _sound_
like the sort of things that'd multiply the size of the codebase by fifteen...
So what's the deal? How so small?

[1] ([https://github.com/developit/preact/wiki/Differences-to-
Reac...](https://github.com/developit/preact/wiki/Differences-to-React))

~~~
krirken
Some key points:

1\. Preact eliminated white/black lists and uses regexes instead [1]. These
lists take up huge amounts of space in React/ReactDOM [2].

2\. No synthetic events, just native `addEventListener` [3].

3\. Only target the DOM for rendering, no React Native to worry about.

4\. Less invariants, error handling, and error messages

[1]
[https://github.com/developit/preact/blob/master/src/constant...](https://github.com/developit/preact/blob/master/src/constants.js#L11-L12)

[2]
[https://github.com/facebook/react/blob/master/src/renderers/...](https://github.com/facebook/react/blob/master/src/renderers/dom/shared/SVGDOMPropertyConfig.js#L32-L121)

[3]
[https://github.com/developit/preact/blob/master/src/dom/inde...](https://github.com/developit/preact/blob/master/src/dom/index.js#L69)

------
masklinn
If you want something which is even smaller and simpler, there's snabbdom[0].
The core vdom implementation is 200 SLOC, everything else is provided via
modules, either first-party (toggled classes, event listeners, thunks,
hyperscript, …) or third-party (jsx, template strings, …)

[0]
[https://github.com/snabbdom/snabbdom](https://github.com/snabbdom/snabbdom)

------
federicodalmaso
For Scala lovers, here are the scala.js facade:
[https://github.com/LMnet/scala-js-preact](https://github.com/LMnet/scala-js-
preact)

------
sandGorgon
anyone can chime in on whether preact can be covered under the same patents
that apply to react ?

~~~
floatboth
Patents don't apply to React. React includes a license addition that prevents
you from suing Facebook for software patents, _in general_.

~~~
pluma
Preact doesn't come with any patent grant, especially not one from Facebook.

If you're worried about having to sue Facebook, nothing stops Facebook from
hitting you with patents covering Preact. However the patent grant does
prevent them from hitting you with patents covering React if you use React and
aren't suing over your own patents that cover React. You're even allowed to
countersue them if they sue you first (again, as long as you don't countersue
over React).

IOW if you're concerned about Facebook patents:

Preact: no protection

Angular, Vue, Ember: no protection

React: full protection as long as you don't sue them first and don't
countersue over React patents

Unless you have inside knowledge of FB's full patent arsenal, using ANY code
written by ANYONE puts you at risk of being sued. The only difference with
React is that you actually know they can't sue you over that specifically.

~~~
tomduncalf
> if you use React and aren't suing over your own patents _that cover React_

Is this correct? The way I read it, it concerned any software patent

~~~
pluma
Read the full patent grant.

> The license granted hereunder will terminate [..] if you [..] initiate [..]
> any Patent Assertion: (i) against Facebook or any of its subsidiaries or
> corporate affiliates

> [..] Notwithstanding the foregoing, if Facebook [..] files a lawsuit
> alleging patent infringement against you in the first instance, and you
> respond by filing a patent infringement counterclaim in that lawsuit against
> that party _that is unrelated to the Software_ , the license granted
> hereunder _will not terminate_ under section (i) of this paragraph due to
> such counterclaim.

[https://github.com/facebook/react/blob/master/PATENTS](https://github.com/facebook/react/blob/master/PATENTS)

In other words: if Facebook sues you (and it can't be about React if you use
FB's React with the grant) and you countersue, the grant will ONLY terminate
if the patents you use concern React.

So you can still defend yourself as long as you don't attack React.

EDIT: FWIW (ii) and (iii) are basically scenarios where you sue other people
over using React, so those aren't really relevant when trying to countersue
Facebook.

------
fleetfox
To nitpick proptypes aren't part of react core anymore.

------
xuan
how does this compare with react fiber?

------
antigirl
People seem to be praising Preact, like its a revolutionary. Its an amazing
alternative, especially if you dont agree with the React license but its a
complete rip off of React so credit where credits due.

~~~
noway421
It's not a rip off, it's an implementation of react api.

