Preact : a smaller, faster React alternative

https://blog.logrocket.com/introduction-to-preact-a-smaller-faster-react-alternative-ad5532eb6d79

by thmslee • 9 years ago

74 48 9 years ago

blog.logrocket.com

sandGorgon2• 9 years ago

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

weego• 9 years ago

By what mechanism could you imagine your use of some random javascript library would be affected by being in a patent dispute with Facebook?

spacetexas• 9 years ago

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.

floatboth• 9 years ago

Patents don't apply to React. React includes a license addition that prevents you from suing Facebook for software patents, in general.

sandGorgon2• 9 years ago

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.

pluma6• 9 years ago

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.

vbezhenar• 9 years ago

Can you write hello world without infringing someone's patent?

amelius2• 9 years ago

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.

rtpg• 9 years ago

JSX is purely a transpiler thing, so you don't have any code in the final package to handle that aspect

amelius2• 9 years ago

Yes, but why install it if you don't need it? From the perspective of the developer who might have to dig into the sources of his libraries, it is just clutter.

demarq• 9 years ago

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• 9 years ago

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.

skratlo• 9 years ago

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

chrisweekly• 9 years ago

Here's where the distinction between "framework" and "library" is meaningful, yes? There are valid (and pragmatic) reasons to prefer one over the other.

danpalmer• 9 years ago

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.

awjr• 9 years ago

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.

mateuszf• 9 years ago

You can use React and virtual dom without JSX. Not that it's pleasant though.

fleetfox• 9 years ago

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

antigirl• 9 years ago

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• 9 years ago

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

federicodalmaso• 9 years ago

For Scala lovers, here are the scala.js facade: https://github.com/LMnet/scala-js-preact

StreamBright4• 9 years ago

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.

cygned• 9 years ago

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.

StreamBright4• 9 years ago

Let me know the results. There might be other people in similar situation too.

tuxracer• 9 years ago

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

danmaz742• 9 years ago

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.

pluma6• 9 years ago

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.

StreamBright4• 9 years ago

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.

masklinn3• 9 years ago

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

xuan• 9 years ago

how does this compare with react fiber?

outsidetheparty• 9 years ago

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

krirken• 9 years ago

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

sctb• 9 years ago

Previous discussion: https://news.ycombinator.com/item?id=15053082

Preact : a smaller, faster React alternative

Related Stories