4 ms·

You'll have to excuse my ignorance as I just like to lightly follow the JS web dev community and am no way a JS expert, but what is the reasoning behind the Rea

You'll have to excuse my ignorance as I just like to lightly follow the JS web dev community and am no way a JS expert, but what is the reasoning behind the React spin-offs? There's Inferno, Preact, ivi, and possibly more, but are all of these so different that they require their own repository? Is it out of the question to simply contribute to the other existing open source projects? I imagine there are some backwards compatible breaking changes but it feels a bit weird to have so many React-like spinoffs. Could anyone shed a light on this? I'm genuinely curious.

nojvek 10y ago
React as an API is brilliant. A Couple of methods only. The libraries conform to the API and achieve different things. Preact is react but simple. It's very lightweight, readable and gets the job done. Inferno is heavily optimized at the cost of readability. React is the original project which is now a monolith. Smaller than angular but still big. Remember on average every 1Mb of JS Will take about a second to parse and initialize. Smaller, we'll architected libraries like preact and mithriill means you can make pages load within a blink of an eye.
- trueadm 10y ago
  Inferno is 8kb, it's smaller than the Mithril re-write and is on par with Preact in terms of parse performance. I think you may have looked at the older Inferno codebase, as the current one is very slim and readable.
- lukeed 10y ago
  Size isn't everything ;-) A smaller footprint _does_ usually signify a faster load time, but that can easily be overruled by how its internals are parsed (aka, interpreted by the browser). For example, 1kb script can intentionally block the mainframe for 10seconds, thus making it slower than a 40kb moderate-performing competitor. Inferno is optimized for the entire performance profile. Preact may load & parse faster -- but only by a HAIR (10-50ms). Inferno does everything else much faster. So, do you consider the `load` event (which will occur once in the UX) to be more valuable than the every other interaction?
  - nojvek 10y ago
    Inferno only works super fast if you use the babel transpiler that creates the blueprint calls. While this is a great idea, debugging it is a nightmare at times. I'd rather have simple h or createElement calls. I personally prefer Typescript jsx as all my Components are type validate and refactoring is a breeze. What I like about preact is its simplicity. I can debug preact and figure out what's going on. Inferno on the other hand seems a bit like assembly. Reusing property names across different contexts is a no-no in my book. I once worked on a database with generic extra_1 extra_2,... fields. They were abused pretty bad and only one guy knew what they meant in what context. While trueadm is a perf wizard I would definitely love to see some of the opts being done at the V8/chakra level rather than obfuscated js code.
    - trueadm 10y ago
      This isn't true anymore. Blueprints were removed from Inferno quite some time ago. Inferno uses createVNode calls, which are very much like createElement calls.
trueadm 10y ago
Note: I'm the author of Inferno and know the authors of Preact and Ivi well. That's a great question and one I frequently get asked. The "current" React codebase is legacy in many ways, the React team are hard at work on React Fiber which is complete re-write of the entire codebase. The legacy codebase isn't something we can actively make better (I've had my PRs merged though) without a huge rewrite. If we tried to make changes, it would break React for many people due to how coupled many things are. A lot has changed in the last few years and the approach to virtual DOM has been one of them. Going forward, the React team are making big efforts to change this.
- btown 10y ago
  Certain optimizations that Inferno can do, like avoiding prototype objects, are pretty closely tied to React's API. Are these bottlenecks, or could React (with Fiber and the planned 2017H1 optimizations [0]) eventually become comparable to Inferno's performance for all but the most complex applications? [0] https://github.com/reactjs/core-notes/blob/master/2016-12/december-08.md https://github.com/reactjs/core-notes/blob/master/2016-12/de...
  - trueadm 10y ago
    There's no reason why React can't learn from Inferno. In fact, I'm aware that they're using a lot of the internals of Inferno to improve React Fiber. I'm sure we'll see more on this in the future :)
- 6DM 10y ago
  I haven't kept up with React like I should. When you say they're undergoing a re-write, is this going to be like Angular 1 vs Angular 2? I just took a quick look at their react fiber demo page [0], is it going to be opinionated react as redux based? That's the vibe I'm getting from this. [0] http://reactbits.github.io/fiber/ http://reactbits.github.io/fiber/
  - trueadm 10y ago
    Unlike Angular 1 -> Angular 2, React Fiber will be fully backwards compatible with the current React.
Touche 10y ago
React is multi platform whereas most of the derivatives target only the browser. This means that whereas React includes event delegation Preact and Inferno can just use the browser's event delegation. As one example of why you might create a spinoff.

nojvek 10y ago

React as an API is brilliant. A Couple of methods only. The libraries conform to the API and achieve different things. Preact is react but simple. It's very lightweight, readable and gets the job done. Inferno is heavily optimized at the cost of readability. React is the original project which is now a monolith. Smaller than angular but still big. Remember on average every 1Mb of JS Will take about a second to parse and initialize. Smaller, we'll architected libraries like preact and mithriill means you can make pages load within a blink of an eye.

trueadm 10y ago
Inferno is 8kb, it's smaller than the Mithril re-write and is on par with Preact in terms of parse performance. I think you may have looked at the older Inferno codebase, as the current one is very slim and readable.
lukeed 10y ago
Size isn't everything ;-) A smaller footprint _does_ usually signify a faster load time, but that can easily be overruled by how its internals are parsed (aka, interpreted by the browser). For example, 1kb script can intentionally block the mainframe for 10seconds, thus making it slower than a 40kb moderate-performing competitor. Inferno is optimized for the entire performance profile. Preact may load & parse faster -- but only by a HAIR (10-50ms). Inferno does everything else much faster. So, do you consider the `load` event (which will occur once in the UX) to be more valuable than the every other interaction?
- nojvek 10y ago
  Inferno only works super fast if you use the babel transpiler that creates the blueprint calls. While this is a great idea, debugging it is a nightmare at times. I'd rather have simple h or createElement calls. I personally prefer Typescript jsx as all my Components are type validate and refactoring is a breeze. What I like about preact is its simplicity. I can debug preact and figure out what's going on. Inferno on the other hand seems a bit like assembly. Reusing property names across different contexts is a no-no in my book. I once worked on a database with generic extra_1 extra_2,... fields. They were abused pretty bad and only one guy knew what they meant in what context. While trueadm is a perf wizard I would definitely love to see some of the opts being done at the V8/chakra level rather than obfuscated js code.
  - trueadm 10y ago
    This isn't true anymore. Blueprints were removed from Inferno quite some time ago. Inferno uses createVNode calls, which are very much like createElement calls.

trueadm 10y ago

Note: I'm the author of Inferno and know the authors of Preact and Ivi well. That's a great question and one I frequently get asked. The "current" React codebase is legacy in many ways, the React team are hard at work on React Fiber which is complete re-write of the entire codebase. The legacy codebase isn't something we can actively make better (I've had my PRs merged though) without a huge rewrite. If we tried to make changes, it would break React for many people due to how coupled many things are. A lot has changed in the last few years and the approach to virtual DOM has been one of them. Going forward, the React team are making big efforts to change this.

btown 10y ago
Certain optimizations that Inferno can do, like avoiding prototype objects, are pretty closely tied to React's API. Are these bottlenecks, or could React (with Fiber and the planned 2017H1 optimizations [0]) eventually become comparable to Inferno's performance for all but the most complex applications? [0] https://github.com/reactjs/core-notes/blob/master/2016-12/december-08.md https://github.com/reactjs/core-notes/blob/master/2016-12/de...
- trueadm 10y ago
  There's no reason why React can't learn from Inferno. In fact, I'm aware that they're using a lot of the internals of Inferno to improve React Fiber. I'm sure we'll see more on this in the future :)
6DM 10y ago
I haven't kept up with React like I should. When you say they're undergoing a re-write, is this going to be like Angular 1 vs Angular 2? I just took a quick look at their react fiber demo page [0], is it going to be opinionated react as redux based? That's the vibe I'm getting from this. [0] http://reactbits.github.io/fiber/ http://reactbits.github.io/fiber/
- trueadm 10y ago
  Unlike Angular 1 -> Angular 2, React Fiber will be fully backwards compatible with the current React.

Touche 10y ago

React is multi platform whereas most of the derivatives target only the browser. This means that whereas React includes event delegation Preact and Inferno can just use the browser's event delegation. As one example of why you might create a spinoff.