Preact : a smaller, faster React alternative(blog.logrocket.com)
blog.logrocket.com
Preact : a smaller, faster React alternative
https://blog.logrocket.com/introduction-to-preact-a-smaller-faster-react-alternative-ad5532eb6d79
48 comments
Previous discussion: https://news.ycombinator.com/item?id=15053082
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.
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.
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.
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.
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.
Can you prove that the demand for "monolithic frameworks" and that "the community" of such frameworks is bigger than what you call the "outliers"? Composing software from small reusable libraries can hardly be called "theoretical computer science aesthetics".
Here's where the distinction between "framework" and "library" is meaningful, yes? There are valid (and pragmatic) reasons to prefer one over the other.
Agreed, I use Django for backend development and one of the main reasons is the consistent set of interfaces and architectural decisions, that all work well together.
I could probably get something faster or smarter with Flask + sqlalchemy, etc, but it's going to require much more thought and overhead on my part, and ultimately take longer to maintain.
I could probably get something faster or smarter with Flask + sqlalchemy, etc, but it's going to require much more thought and overhead on my part, and ultimately take longer to maintain.
I'm sorry, why would you be using React etc unless you wanted virtual DOM and JSX. Much of why I like React is precisely because it has those features. This really makes no sense to me.
You can use React and virtual dom without JSX. Not that it's pleasant though.
> Not that it's pleasant though.
"Raw" react is perfectly OK, and react + hyperscript[0] is great.
[0] https://github.com/mlmorg/react-hyperscript
"Raw" react is perfectly OK, and react + hyperscript[0] is great.
[0] https://github.com/mlmorg/react-hyperscript
I definitely preferred Mithril's m('div') over JSX <div></div>. The closing tags are overly verbose for me.
As soon as the markup reaches a certain level, the verbosity (closing tags in particular) of JSX benefits you more than the terseness of hyperscript. Of course you can argue that you should split your components into smaller chunks, but that is, in my experience, rarely good just for the sake of readability.
FWIW the hyperscript helper is generally h rather than m, and there's a hyperscript helper available for react with the expected semantics[0]: https://github.com/mlmorg/react-hyperscript
[0] in the sense that it supports normal hyperscript semantics and replacing the selector with a React component
[0] in the sense that it supports normal hyperscript semantics and replacing the selector with a React component
My group tried Mithril both with and without JSX. With JSX was more readable for the code we were writing.
JSX is purely a transpiler thing, so you don't have any code in the final package to handle that aspect
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.
It can be an almost drop in replacement for many projects. You may have to lean on the officially offered https://github.com/developit/preact-compat depending on the project. If you add preact-compact you do lose some of the size advantage over react but that's not really an issue if licensing is your main concern.
Seems the preact author might want to consider marketing preact as not only the lighter weight alternative, but also the MIT licensed alternative to react (Although if more projects included that surprisingly controversial patent clause it would mark the end of software patents. Isn't that a good thing?)
Seems the preact author might want to consider marketing preact as not only the lighter weight alternative, but also the MIT licensed alternative to react (Although if more projects included that surprisingly controversial patent clause it would mark the end of software patents. Isn't that a good thing?)
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.
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.
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.
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.
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.
Amazon uses React. https://medium.com/@blairanderson/amazons-new-brand-stores-u...
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...
Apple uses React. https://twitter.com/soprano/status/705516380913692672
Twitter uses React. https://www.infoq.com/news/2017/02/twitter-react-mobile-stac...
Microsoft uses React. https://microsoft.github.io/reactxp/
Seems like they don't care what some guy on Medium thinks.
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...
Apple uses React. https://twitter.com/soprano/status/705516380913692672
Twitter uses React. https://www.infoq.com/news/2017/02/twitter-react-mobile-stac...
Microsoft uses React. https://microsoft.github.io/reactxp/
Seems like they don't care what some guy on Medium thinks.
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.
True, at least we are not directly using React in that case. I think there is a difference between directly using React or through software like Preact. I am going to ask our lawyers about this.
Same here.
I am going to try to replace React with preact for the larger projects (webpack makes it easy) and run the e2e tests.
Let me know the results. There might be other people in similar situation too.
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...)
[1] (https://github.com/developit/preact/wiki/Differences-to-Reac...)
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...
[2] https://github.com/facebook/react/blob/master/src/renderers/...
[3] https://github.com/developit/preact/blob/master/src/dom/inde...
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...
[2] https://github.com/facebook/react/blob/master/src/renderers/...
[3] https://github.com/developit/preact/blob/master/src/dom/inde...
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
[0] https://github.com/snabbdom/snabbdom
For Scala lovers, here are the scala.js facade: https://github.com/LMnet/scala-js-preact
anyone can chime in on whether preact can be covered under the same patents that apply to react ?
Patents don't apply to React. React includes a license addition that prevents you from suing Facebook for software patents, in general.
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.
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.
> 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
Is this correct? The way I read it, it concerned any software patent
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
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.
> 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
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.
It isn't structured this way - I think your reading is slightly incorrect.
What the FB licensed agreement says that is any patent grants which apply to reactjs/caffe2 will be revoked and FB will countersue for infringement on reactjs/caffe2 patents.
I don't think a general agreement to prevent any kind of lawsuit is completely legal and acceptable in a court of law.
I don't think a general agreement to prevent any kind of lawsuit is completely legal and acceptable in a court of law.
By what mechanism could you imagine your use of some random javascript library would be affected by being in a patent dispute with Facebook?
Patents regard underlying functionality so if Preact infringes on the patent through using the same or sufficiently similar mechnism's to react functionality, it's a toss up but due to the nature of open source code the user might be liable.
Depends on the ruling of use of open source code that is in a way productized. Also depends on if Preact's implementation is sufficient to infringe on React's patents (if they have any weight to them that is and are upheld)
Its not a random library, its extremely similar to React.
Depends on the ruling of use of open source code that is in a way productized. Also depends on if Preact's implementation is sufficient to infringe on React's patents (if they have any weight to them that is and are upheld)
Its not a random library, its extremely similar to React.
The "Patent" issue with React is not with the patents related to React but with its license, so it would not impact Preact.
Nope. If Facebook owns any patents for mechanisms that are used in Preact, they can sue you.
I'll say more: if you use Preact and there are such patents (I have no idea if there are any), they could sue you even if you don't sue them first, because Preact isn't covered by any patent grant.
I'll say more: if you use Preact and there are such patents (I have no idea if there are any), they could sue you even if you don't sue them first, because Preact isn't covered by any patent grant.
If I were Facebook and a patent troll, I would closely inspect what Preact does and what patents I have that cover it and then go out and sue every company openly using Preact preemptively because switching from React to Preact indicates they might be planning to sue me in the future (and if I bankrupt them, I might acquire their patents this way).
That Facebook isn't doing this should tell you something.
That Facebook isn't doing this should tell you something.
I have no idea where this comes from but this doesn't make any sense whatsoever.
React comes with two things:
* a copyright license for the source code, which is a BSD-style open source license
* a patents grant license for "the React software distributed by Facebook" (i.e. official React releases but not third-party forks)
The former is unconditional except as defined in the terms of the BSD-style license itself. It does not magically terminate even if you walk up to Mark Zuckerberg and personally punch him in the face.
The latter is conditional and terminates if you sue Facebook, or if you get sued by Facebook and countersue over patents covering React. If Facebook sues you and you countersue them over a patent covering e.g. their social graph algorithms, you are still protected by the React patent grant. Only if you also happen to have patents covering React and decide to use them to countersue when Facebook sues you over other patents they hold, only then the patent grant is revoked.
Patents don't give a fuck about source code. Software patents are about abstract ideas. Source code is an expression of that idea and thus only protected by copyright. Software patents apply whether the patent holder expressed that idea or anybody else did.
If Preact does something the same way React does something and Facebook has a patent for that, you have no protection whatsoever. Even worse: Facebook likely already knows which of their patents apply to Preact or not, so if they wanted they could easily sue you for using Preact if they had such patents and felt particularly patent trollish that day.
You can't escape this. You don't know whether Facebook has patents for React. But you also don't know whether Facebook has patents for Angular, or Vue or Ember or even jQuery.
Angular, Vue, Ember and Preact are using the MIT license with no patent grant. Sure, if you're lucky, a court might say that the license implies a patent grant but there is no language in that license to hint that this is in any way intended (unlike, say, the Apache license).
Oh, and even if the MIT license would imply an unconditional patent grant, what makes you think the authors hold all the relevant patents? What if Facebook owns a patent for Vue? What if Google holds a patent for Ember? What if Apple holds a patent for React?
The reason you're upset isn't that React has an explicit patent grant with explicit limits. The reason you're upset is that you don't like software patents.
That's fair and I personally think software patents are bullshit, but raging against Facebook or worse the React maintainers over this and spreading FUD is not how you deal with it.
React comes with two things:
* a copyright license for the source code, which is a BSD-style open source license
* a patents grant license for "the React software distributed by Facebook" (i.e. official React releases but not third-party forks)
The former is unconditional except as defined in the terms of the BSD-style license itself. It does not magically terminate even if you walk up to Mark Zuckerberg and personally punch him in the face.
The latter is conditional and terminates if you sue Facebook, or if you get sued by Facebook and countersue over patents covering React. If Facebook sues you and you countersue them over a patent covering e.g. their social graph algorithms, you are still protected by the React patent grant. Only if you also happen to have patents covering React and decide to use them to countersue when Facebook sues you over other patents they hold, only then the patent grant is revoked.
Patents don't give a fuck about source code. Software patents are about abstract ideas. Source code is an expression of that idea and thus only protected by copyright. Software patents apply whether the patent holder expressed that idea or anybody else did.
If Preact does something the same way React does something and Facebook has a patent for that, you have no protection whatsoever. Even worse: Facebook likely already knows which of their patents apply to Preact or not, so if they wanted they could easily sue you for using Preact if they had such patents and felt particularly patent trollish that day.
You can't escape this. You don't know whether Facebook has patents for React. But you also don't know whether Facebook has patents for Angular, or Vue or Ember or even jQuery.
Angular, Vue, Ember and Preact are using the MIT license with no patent grant. Sure, if you're lucky, a court might say that the license implies a patent grant but there is no language in that license to hint that this is in any way intended (unlike, say, the Apache license).
Oh, and even if the MIT license would imply an unconditional patent grant, what makes you think the authors hold all the relevant patents? What if Facebook owns a patent for Vue? What if Google holds a patent for Ember? What if Apple holds a patent for React?
The reason you're upset isn't that React has an explicit patent grant with explicit limits. The reason you're upset is that you don't like software patents.
That's fair and I personally think software patents are bullshit, but raging against Facebook or worse the React maintainers over this and spreading FUD is not how you deal with it.
Can you write hello world without infringing someone's patent?
To nitpick proptypes aren't part of react core anymore.
how does this compare with react fiber?