12 ms·

Preact, a fast 3k React alternative

224 points by davideschiera 11y ago

rpedela 11y ago
How big is React gzipped? How much are you saving with this library?
- dceddia 11y ago
  Looks like React 0.14.6 is about 38k gzipped: curl --silent --output /dev/null -H "Accept-Encoding: gzip,deflate" --write-out "size_download=%{size_download}\n" https://cdnjs.cloudflare.com/ajax/libs/react/0.14.6/react.min.js https://cdnjs.cloudflare.com/ajax/libs/react/0.14.6/react.mi... >> size_download=39542
  - warfangle 11y ago
    That doesn't remove everything behind process.env.NODE_ENV !== 'production' though. Though, you do need webpack/browserify/etc to take advantage of that.
    - mikewhy 11y ago
      FYI, react.min.js does do exactly what browserify + envify would do.[1] [1]: https://github.com/facebook/react/blob/401e6f10587b09d4e725763984957cf309dfdc30/grunt/config/browserify.js#L13 https://github.com/facebook/react/blob/401e6f10587b09d4e7257...
      - warfangle 11y ago
        Cool.
- LaurensBER 11y ago
  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 11y ago
    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.
  - pkozlowski_os 11y ago
    If you test currently available dead-code elimination tools for JS you will discover that there are tricks that those tools can't play, most important one being eliminating unused methods on object / classes. AFAIK Webpack2 is using Rollup under the hood. While rollup is great and can build smaller outputs (biggest win seems to be elimination of the module system overhead) it can't perform miracles. In short: size still matters, even with dead-code elimination tools (at least as they are today).
levisegal 11y ago
How does this stack up versus something like riot.js? http://riotjs.com/ http://riotjs.com/
- xaduha 11y ago
  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.
holic 11y ago
Compared to React, what isn't available in Preact?
- Sheepsteak 11y ago
  Last time I checked you couldn't use contexts yet.
  - terrortrain 11y ago
    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 11y ago
      Then how would something like react-redux work without context?
      - boubiyeah 11y ago
        It can already work without contexts. You just pass a store instance via props. I don't like contexts either :(
        developit 11y ago
        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.
    - acjohnson55 11y ago
      As people adopt external state containers, like Flux and Redux, it becomes increasingly impractical to bucket brigade chunks of data and callbacks to the leaves of the component tree via props. Some sort of delivery mechanism that doesn't couple in intermediate components is pretty critical to avoid having to maintain an unbounded amount of glue code. Context isn't without its kinks, but it's pretty useful in cutting boilerplate and decoupling components. The one thing I don't buy is that it's somehow worse than props from an architectural perspective (it's often compared to global variables, which makes little sense to me).
losvedir 11y ago
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?
- TheMakeA 11y ago
  PropType checking is compiled out of the production version of React.
- Ronsenshi 11y ago
  Lack of synthetic events is a huge one for me.
  - developit 11y ago
    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.
- peterhunt 11y ago
  Also property/attribute normalization. Preact: https://github.com/developit/preact/blob/master/src/preact.js#L890 https://github.com/developit/preact/blob/master/src/preact.j... React: https://github.com/facebook/react/blob/3b96650e39ddda5ba49245713ef16dbc52d25e9e/src/renderers/dom/shared/HTMLDOMPropertyConfig.js#L40 https://github.com/facebook/react/blob/3b96650e39ddda5ba4924...
- developit 11y ago
  PropTypes are supported out of the box in preact-compat. You could also use them via a preact vnode hook and the "proptypes" module (npm.im/proptypes), which is just pulled from React's codebase. Synthetic events I'm very much open to feedback on - I tend to fire actual DOM events in my Karma tests, but it seems that less common.
deleted 11y ago
[deleted]
harryf 11y ago
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 11y ago
  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 11y ago
    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 :)
- mildbow 11y ago
  Silly downvoters: they are responding to your tone rather than the content of your post. Anyway, for sure there is a tonne of cruft and confusion when starting a new js project(SPA app) nowadays. Esp if you want to use react: it's one of the blessings/curse of using a library vs a framework. If, however, you stop looking for the "right" way to do things by reading blog posts etc,and just take the easiest path with react, then redux and webpack will take you far enough.
  - LukeB_UK 11y ago
    I downvoted because of both content and tone. The web is the platform that works across all devices. Sure an app is great when you already use that site, but before they're invested, are people really gonna download an app? Not to mention that you're heavily reliant on Apple and Google for your framework. With the web, you can use whatever you like, you can even roll your own if you want. Sure there are a lot of JavaScript libraries, but how else will ideas evolve?
dchest 11y ago
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).
deleted 11y ago
[deleted]
udp 11y ago
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
- merb 11y ago
  then you should look at this library. Currently I'm skeptical about every js library, however this library makes a lot of things good. Especially by using ES6. Also these guys made some cool addon libraries that are as small as the core library. The only thing I dislike is that the core library is a single source file. Why do people create source files with < 1000 lines..
  - developit 11y ago
    It started as a CodePen. Thankfully, someone switched the build to use Rollup, which makes it very easy to move things around. Modular structure (in terms of files) will be part of the 3.0 major bump.
- Touche 11y ago
  Mercury fans always say this but I'm never seen anyone swap out random libraries it uses, like dom-delegator. Stuff is still made to be used together, you could swap out dom-delegator if your version had the exact same API, but then what would be the point.
  - udp 11y ago
    When I ported my frontend to TypeScript I swapped out the whole observ* suite for my own typed observables. Sure, some of the components are too specific to replace trivially, but then those most likely aren't the ones you're interested in replacing. Decomposing your code into modules is step one. Making the interface between your modules generic enough to easily replace is the next problem, but if your code is a monolithic blob in the first place that's not going to be possible. My main issue with modularity in JavaScript is the lack of strict typing, because you won't know if your interface fits correctly until runtime - which is why I've been looking into TypeScript and Elm recently.
ivanceras 11y ago
I've look at react, angular, mithril, and lately elm. It seems elm is here to stay.
jallmann 11y ago
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 11y ago
  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 11y ago
    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.
    - qaq 11y ago
      It's to a degree for people who are not primarily JS developers and often have no clue about prototypical inheritance. It also to a good degree reflects how V8 or some other engine actually treating your code under the hood.
corywatilo 11y ago
Yeah, there's already a company called Preact. =] preact.com
- gnat 11y ago
  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 11y ago
    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.
deleted 11y ago
[deleted]
- iamflimflam1 11y ago
  It's still best practice for most normal websites that are mostly static content with a bit of jquery and Ajax sprinkled on top. But for sites that are more like applications people are thinking about the components that make up those applications. These components are self contained and reused so it makes sense to have everything in the same small file.
Cartwright2 11y ago
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 11y ago
  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 11y ago
    > 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.
    - steego 11y ago
      > These libraries do nothing but add to decision fatigue. Developers have to make decisions, sure, but we need to have limits too. Nonsense. These "me too" libraries add to the decision fatigue only if you're including them in your list of candidate libraries in the first place. Personally speaking, I won't even consider Preact until one of the following events has occurred: 1: I tell myself I really really need a 3k React-like library. 2: I've heard more than a few people mention Preact. 3: I discover something really awesome about it that will save me lots of time. Apart from those events, I'll simply ignore it and not worry if I made the wrong decision. You have the power to ignore me too libraries.
amelius 11y ago
And now we're all hoping for Preact Native...
- mbrock 11y ago
  I'm hoping for React Native to be maintained, stable, and performant...
deleted 11y ago
[deleted]
elcct 11y ago
I was thinking about something like that today and now I see this. Awesome!
kansface 11y ago
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 11y ago
  >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.".
girvo 11y ago
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-challenge https://github.com/girvo/domchanger-hoverboard-flux-challeng...
eddd 11y ago
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.
igl 11y ago
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 11y ago
  I've found this in the project wiki https://github.com/developit/preact/wiki/Browser-Support https://github.com/developit/preact/wiki/Browser-Support
nnx 11y ago
How does this compare to Riotjs "A React-like user interface micro-library" ? riotjs.com
- lhorie 11y ago
  This project aims to be API-compatible w/ a subset of React's API. Riot, on the other hand, has a completely different API
lhorie 11y ago
Re: fast claim, it turns out it's not that fast: http://localvoid.github.io/uibench/ http://localvoid.github.io/uibench/ :(
- brlewis 11y ago
  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 11y ago
    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.
rygine 11y ago
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.
idontgiveafuck 11y ago
I dont give a fk.
mikemikemike 11y ago
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 11y ago
  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 11y ago
    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 11y ago
It makes sense stay tiny if you are creating a small component yo be exported.

224 points by davideschiera 11y ago

rpedela 11y ago

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

dceddia 11y ago
Looks like React 0.14.6 is about 38k gzipped: curl --silent --output /dev/null -H "Accept-Encoding: gzip,deflate" --write-out "size_download=%{size_download}\n" https://cdnjs.cloudflare.com/ajax/libs/react/0.14.6/react.min.js https://cdnjs.cloudflare.com/ajax/libs/react/0.14.6/react.mi... >> size_download=39542
- warfangle 11y ago
  That doesn't remove everything behind process.env.NODE_ENV !== 'production' though. Though, you do need webpack/browserify/etc to take advantage of that.
  - mikewhy 11y ago
    FYI, react.min.js does do exactly what browserify + envify would do.[1] [1]: https://github.com/facebook/react/blob/401e6f10587b09d4e725763984957cf309dfdc30/grunt/config/browserify.js#L13 https://github.com/facebook/react/blob/401e6f10587b09d4e7257...
    - warfangle 11y ago
      Cool.
LaurensBER 11y ago
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 11y ago
  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.
- pkozlowski_os 11y ago
  If you test currently available dead-code elimination tools for JS you will discover that there are tricks that those tools can't play, most important one being eliminating unused methods on object / classes. AFAIK Webpack2 is using Rollup under the hood. While rollup is great and can build smaller outputs (biggest win seems to be elimination of the module system overhead) it can't perform miracles. In short: size still matters, even with dead-code elimination tools (at least as they are today).

levisegal 11y ago

How does this stack up versus something like riot.js? http://riotjs.com/ http://riotjs.com/

xaduha 11y ago
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.

holic 11y ago

Compared to React, what isn't available in Preact?

Sheepsteak 11y ago
Last time I checked you couldn't use contexts yet.
- terrortrain 11y ago
  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 11y ago
    Then how would something like react-redux work without context?
    - boubiyeah 11y ago
      It can already work without contexts. You just pass a store instance via props. I don't like contexts either :(
      - developit 11y ago
        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.
  - acjohnson55 11y ago
    As people adopt external state containers, like Flux and Redux, it becomes increasingly impractical to bucket brigade chunks of data and callbacks to the leaves of the component tree via props. Some sort of delivery mechanism that doesn't couple in intermediate components is pretty critical to avoid having to maintain an unbounded amount of glue code. Context isn't without its kinks, but it's pretty useful in cutting boilerplate and decoupling components. The one thing I don't buy is that it's somehow worse than props from an architectural perspective (it's often compared to global variables, which makes little sense to me).

losvedir 11y ago

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?

TheMakeA 11y ago
PropType checking is compiled out of the production version of React.
Ronsenshi 11y ago
Lack of synthetic events is a huge one for me.
- developit 11y ago
  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.
peterhunt 11y ago
Also property/attribute normalization. Preact: https://github.com/developit/preact/blob/master/src/preact.js#L890 https://github.com/developit/preact/blob/master/src/preact.j... React: https://github.com/facebook/react/blob/3b96650e39ddda5ba49245713ef16dbc52d25e9e/src/renderers/dom/shared/HTMLDOMPropertyConfig.js#L40 https://github.com/facebook/react/blob/3b96650e39ddda5ba4924...
developit 11y ago
PropTypes are supported out of the box in preact-compat. You could also use them via a preact vnode hook and the "proptypes" module (npm.im/proptypes), which is just pulled from React's codebase. Synthetic events I'm very much open to feedback on - I tend to fire actual DOM events in my Karma tests, but it seems that less common.

deleted 11y ago

[deleted]

harryf 11y ago

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 11y ago
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 11y ago
  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 :)
mildbow 11y ago
Silly downvoters: they are responding to your tone rather than the content of your post. Anyway, for sure there is a tonne of cruft and confusion when starting a new js project(SPA app) nowadays. Esp if you want to use react: it's one of the blessings/curse of using a library vs a framework. If, however, you stop looking for the "right" way to do things by reading blog posts etc,and just take the easiest path with react, then redux and webpack will take you far enough.
- LukeB_UK 11y ago
  I downvoted because of both content and tone. The web is the platform that works across all devices. Sure an app is great when you already use that site, but before they're invested, are people really gonna download an app? Not to mention that you're heavily reliant on Apple and Google for your framework. With the web, you can use whatever you like, you can even roll your own if you want. Sure there are a lot of JavaScript libraries, but how else will ideas evolve?

dchest 11y ago

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

deleted 11y ago

[deleted]

udp 11y ago

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

merb 11y ago
then you should look at this library. Currently I'm skeptical about every js library, however this library makes a lot of things good. Especially by using ES6. Also these guys made some cool addon libraries that are as small as the core library. The only thing I dislike is that the core library is a single source file. Why do people create source files with < 1000 lines..
- developit 11y ago
  It started as a CodePen. Thankfully, someone switched the build to use Rollup, which makes it very easy to move things around. Modular structure (in terms of files) will be part of the 3.0 major bump.
Touche 11y ago
Mercury fans always say this but I'm never seen anyone swap out random libraries it uses, like dom-delegator. Stuff is still made to be used together, you could swap out dom-delegator if your version had the exact same API, but then what would be the point.
- udp 11y ago
  When I ported my frontend to TypeScript I swapped out the whole observ* suite for my own typed observables. Sure, some of the components are too specific to replace trivially, but then those most likely aren't the ones you're interested in replacing. Decomposing your code into modules is step one. Making the interface between your modules generic enough to easily replace is the next problem, but if your code is a monolithic blob in the first place that's not going to be possible. My main issue with modularity in JavaScript is the lack of strict typing, because you won't know if your interface fits correctly until runtime - which is why I've been looking into TypeScript and Elm recently.

ivanceras 11y ago

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

jallmann 11y ago

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 11y ago
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 11y ago
  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.
  - qaq 11y ago
    It's to a degree for people who are not primarily JS developers and often have no clue about prototypical inheritance. It also to a good degree reflects how V8 or some other engine actually treating your code under the hood.

corywatilo 11y ago

Yeah, there's already a company called Preact. =] preact.com

gnat 11y ago
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 11y ago
  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.

deleted 11y ago

[deleted]

iamflimflam1 11y ago
It's still best practice for most normal websites that are mostly static content with a bit of jquery and Ajax sprinkled on top. But for sites that are more like applications people are thinking about the components that make up those applications. These components are self contained and reused so it makes sense to have everything in the same small file.

Cartwright2 11y ago

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 11y ago
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 11y ago
  > 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.
  - steego 11y ago
    > These libraries do nothing but add to decision fatigue. Developers have to make decisions, sure, but we need to have limits too. Nonsense. These "me too" libraries add to the decision fatigue only if you're including them in your list of candidate libraries in the first place. Personally speaking, I won't even consider Preact until one of the following events has occurred: 1: I tell myself I really really need a 3k React-like library. 2: I've heard more than a few people mention Preact. 3: I discover something really awesome about it that will save me lots of time. Apart from those events, I'll simply ignore it and not worry if I made the wrong decision. You have the power to ignore me too libraries.

amelius 11y ago

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

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

deleted 11y ago

[deleted]

elcct 11y ago

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

kansface 11y ago

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 11y ago
>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.".

girvo 11y ago

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-challenge https://github.com/girvo/domchanger-hoverboard-flux-challeng...

eddd 11y ago

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.

igl 11y ago

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 11y ago
I've found this in the project wiki https://github.com/developit/preact/wiki/Browser-Support https://github.com/developit/preact/wiki/Browser-Support

nnx 11y ago

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

lhorie 11y ago
This project aims to be API-compatible w/ a subset of React's API. Riot, on the other hand, has a completely different API

lhorie 11y ago

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

brlewis 11y ago
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 11y ago
  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.

rygine 11y ago

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.

idontgiveafuck 11y ago

I dont give a fk.

mikemikemike 11y ago

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 11y ago
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 11y ago
  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 11y ago

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