Hacker News Reader

Comment by slezakattack | Hacker News Reader

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.

View on HN

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.

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

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

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/

Unlike Angular 1 -> Angular 2, React Fiber will be fully backwards compatible with the current React.

I probably wouldn't claim 100% compatibility but we're already passing ~95% of the tests, and intend to fix more. There will likely be a few minor differences but we also have 20 thousand components that need to "just work" so we're striving for as much compat as possible, and any changes would be very contained.

Fiber is simply a fully-backwards-compatible performance enhancement, though that does it a huge disservice. It's actually figuring out how to run different parts of a render() function in different clock ticks, essentially making renders asynchronous so that animations don't jitter or drop frames, and different parts of the render tree can be prioritized out of order. Unless you were doing weird stuff with low-level animations or React internals, user code won't need to change, but it will instantly become buttery smooth. See https://github.com/acdlite/react-fiber-architecture for how.

Now, the preference for stateless functional components that has been popularized for user code by Redux is certainly a trend, and a focus of performance attention. But that's nothing new.

You can think of it much more like putting a more advanced engine & drivetrain in a classic race car.

Practically speaking for an end user not a lot will change, but React will be faster, non-blocking, and have a whole new set of applications.

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.

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.

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?

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.

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.

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.

Reply on news.ycombinator.com