Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Interview with the author of React-like Inferno about JavaScript optimisations

survivejs.com

Post reply on HN
Print view View original

11–20 of 51 posts

Re: Interview with the author of React-like Inferno about JavaScript optimisations

#11

Post by lukeed »

nojvek wrote: post #8
slezakattack wrote: post #7

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 backwar…

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…

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?

Re: Interview with the author of React-like Inferno about JavaScript optimisations

#12

Post by btown »

trueadm wrote: post #9
slezakattack wrote: post #7

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 backwar…

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 m…

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

Re: Interview with the author of React-like Inferno about JavaScript optimisations

#13

Post by trueadm »

btown wrote: post #12
trueadm wrote: post #9

Earlier quoted context omitted.

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 m…

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

Re: Interview with the author of React-like Inferno about JavaScript optimisations

#14

Post by underwater »

I've spent a lot of time optimizing the startup time of large React codebases. In my experience the size of the React bundle is irrelevant; it will be quickly dwarfed by the product code for any meaningful application. The real problems in startup speed are twofold:

Browsers are stuck optimizing an outdated model - parsing and compiling JavaScript on the critical path is madness. The only benefit of that model is that a web developer can right click and view source to see some unreadable minified JavaScript code. The cost is that every web user has to wait hundreds or milliseconds or multiple seconds for the browser to do busy work. Even advancements like Service Workers don't do anything to mitigate this problem.

The second problem is that browser vendors are locked in a arms race chasing artificial metrics. This started years ago when the Chrome team introduced V8 with a huge PR push to sell the benefits of their JIT. It looks awesome to say that your browser tops SunSpider but those metrics don't necessarily correlate to how sites use JavaScript. Firefox has a heavily optimized JIT that kicks in when a function is run 1,000 times. When loading Facebook the hottest codepath is run 900 times.

Re: Interview with the author of React-like Inferno about JavaScript optimisations

#16

Post by vvanders »

underwater wrote: post #14

I've spent a lot of time optimizing the startup time of large React codebases. In my experience the size of the React bundle is irrelevant; it will be quickly dwarfed by the product code for any meaningful application. The real problems in startup speed are twofold: Browsers are stuck optimizing an outdated model - parsing and compiling JavaScript on the critical path is madness. The only benefit of that model is tha…

The benchmark thing is pretty common in GPU vendors as well. It was pretty widely documented a while back that certain vendors were removing thermal limits[1] when certain Android benchmark apps were detected.

Only real solution is to write your own private benchmarks that match your use case and aren't shared widely but not a lot of people have that luxury.

[1] http://www.anandtech.com/show/7384/state-of-cheating-in-andr...

Re: Interview with the author of React-like Inferno about JavaScript optimisations

#17

Post by 6DM »

trueadm wrote: post #9
slezakattack wrote: post #7

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 backwar…

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 m…

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/

Re: Interview with the author of React-like Inferno about JavaScript optimisations

#18

Post by trueadm »

6DM wrote: post #17
trueadm wrote: post #9

Earlier quoted context omitted.

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 m…

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.

Re: Interview with the author of React-like Inferno about JavaScript optimisations

#20

Post by trueadm »

underwater wrote: post #14

I've spent a lot of time optimizing the startup time of large React codebases. In my experience the size of the React bundle is irrelevant; it will be quickly dwarfed by the product code for any meaningful application. The real problems in startup speed are twofold: Browsers are stuck optimizing an outdated model - parsing and compiling JavaScript on the critical path is madness. The only benefit of that model is tha…

Note: I'm the author of Inferno

I commonly hear the same thing – you've benchmarked React and it performs fine. Did you benchmark this on a modern MacBook/laptop by any chance?

The realism is that the desktop market is only 15% of the entire global online market. In developing nations, Android mobile performance is essential. React, Angular, Ember and other libraries have never performed well in this space.

If you're shipping a huge bundle for your app – you're doing something wrong too. You need to take into account that mobile users are likely to have a 3G connection at best and are likely to be on a 5+ year old device. You need to endorse code-splitting, service workers and other PWA features to better accommodate those users. Inferno will deliver the best in class mobile performance when paired with those features.

Post reply on HN