10 ms·

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

79 points by expression100 10y ago

wje 10y ago
Sadly, this article has nothing to do with an inferno OS port to js. http://www.vitanuova.com/inferno/ http://www.vitanuova.com/inferno/
- sedachv 10y ago
  Agreed and similarly disappointed. Can we please change the title to point out that this is specific to ReactJS?
  - idbehold 10y ago
    This isn't about ReactJS.
  - trueadm 10y ago
    This has nothing to do with React. This is a JavaScript library called Inferno – the title makes sense to people in the JavaScript scene.
  - dang 10y ago
    OK, we've attempted to do that and still be accurate.
- wolfgang42 10y ago
  My interpretation of the title was that it was going to discuss how the Dis VM[1] compared to popular JS VMs, but I was sorely disappointed. (Inferno, for those not aware of it, is a rather obscure successor to the almost-as-obsure Plan 9 From Bell Labs. Plan 9, in turn, was supposed to be the replacement for UNIX. Unfortunately it failed because UNIX was "an existing codebase that is just good enough"[2]; its main lasting contribution was the invention of UTF-8[3].) [1] http://www.vitanuova.com/inferno/papers/dis.html http://www.vitanuova.com/inferno/papers/dis.html [2] Plan 9: The Way the Future Was http://www.faqs.org/docs/artu/plan9.html http://www.faqs.org/docs/artu/plan9.html [3] http://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt http://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt
  - trueadm 10y ago
    I'm sorry, this topic has nothing to do with the operating system. Inferno in this context is a popular JavaScript library for building UIs, not an operating system.
    - wolfgang42 10y ago
      Yes, I figured that out as soon as I started reading the article. :) I just figured I'd give some context to thread readers who'd never heard of the OS and were wondering what we were going on about.
- jordic 10y ago
  It would be amazing to have acme on a browser :)
mmanfrin 10y ago
I misunderstood the title and was very confused as to why Dan Brown would have things to say about Javascript perf.
slezakattack 10y ago
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?
underwater 10y ago
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.
- vvanders 10y ago
  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-android-benchmarks http://www.anandtech.com/show/7384/state-of-cheating-in-andr...
- trueadm 10y ago
  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.
marknadal 10y ago
Pro tip: function calls (especially anonymous ones) are the biggest performance bottleneck. I've done pretty extensive research on this: http://youtu.be/BEqH-oZ4UXI http://youtu.be/BEqH-oZ4UXI .
- o_____________o 10y ago
  Is there a written summary of this anywhere?
  - marknadal 10y ago
    I tried to give a summary in the video description (click the view more). I hope that helps.
    - o_____________o 10y ago
      Thank you, missed that
- dcherman 10y ago
  So I watched that and heard that you used BenchmarkJS which I believe intentionally prevents optimization from occurring, otherwise many tests would just end up being optimized away. Have you considered how function inlining might affect your results versus benchmarks like you ran in the video? Have you profiled them side by side under actual usage? "Anonymous" function calls (function expressions, either immediate or not) are generally only more expensive because they're re-created all the time. Sometimes this is necessary to create a closure, often it's not. If you were to profile `var foo = function() {}`, performance should match the function declaration variant identically, so it's not the method of declaration that affects performance.
  - marknadal 10y ago
    That is something I have been suspecting of BenchmarkJS, which is unfortunate because I am/wasn't expecting to be responsible for building a better benchmarking tool (we are already building a database and a distributed testing framework). FireFox does inline, and we can tell even with BenchmarkJS, which is why I think V8 wasn't (although it has improved significantly recently). We ran an "actual use" test that saved 100M+ records a day for $10 total (on about 100GB+, processing, storage, backup). However since it is an "actual use" we don't know if inlining happened or not (I still suspect not, since I haven't seen that in V8 - but again, maybe that is BenchmarkJS killing it, despite seeing it in FF). Correct correct. The function call is still expensive (anonymous or not), and managing scope is extremely expensive. You are on top of this stuff! Sounds like you do performance testing regularly?
findjashua 10y ago
the big motivation for small size seems to be shaving the time spent on parsing the js. Is there any reason this can't be parceled off to a background worker, and using the main thread only for rendering?
igl 10y ago
React's event system is one of its strong points. Like with many alternatives, I stopped looking into them when i read "no event system" in the README. Perf is not the single most high priority in a framework.
- trueadm 10y ago
  Inferno also has its own event system like React does.
s2d2 10y ago
I love it. When it comes to PCs I am a speed junkie. Maybe because the first thing I started to learn as a kid was 3D graphics dev. Anyway most websites are incredibly slow and clunky. With 20+ scripts and everything pops up or moves while loading. On the speed of pure JS. I recently developed a JS game just for fun. Optimizing in a language with GC sucks.

79 points by expression100 10y ago

wje 10y ago

Sadly, this article has nothing to do with an inferno OS port to js. http://www.vitanuova.com/inferno/ http://www.vitanuova.com/inferno/

sedachv 10y ago
Agreed and similarly disappointed. Can we please change the title to point out that this is specific to ReactJS?
- idbehold 10y ago
  This isn't about ReactJS.
- trueadm 10y ago
  This has nothing to do with React. This is a JavaScript library called Inferno – the title makes sense to people in the JavaScript scene.
- dang 10y ago
  OK, we've attempted to do that and still be accurate.
wolfgang42 10y ago
My interpretation of the title was that it was going to discuss how the Dis VM[1] compared to popular JS VMs, but I was sorely disappointed. (Inferno, for those not aware of it, is a rather obscure successor to the almost-as-obsure Plan 9 From Bell Labs. Plan 9, in turn, was supposed to be the replacement for UNIX. Unfortunately it failed because UNIX was "an existing codebase that is just good enough"[2]; its main lasting contribution was the invention of UTF-8[3].) [1] http://www.vitanuova.com/inferno/papers/dis.html http://www.vitanuova.com/inferno/papers/dis.html [2] Plan 9: The Way the Future Was http://www.faqs.org/docs/artu/plan9.html http://www.faqs.org/docs/artu/plan9.html [3] http://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt http://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt
- trueadm 10y ago
  I'm sorry, this topic has nothing to do with the operating system. Inferno in this context is a popular JavaScript library for building UIs, not an operating system.
  - wolfgang42 10y ago
    Yes, I figured that out as soon as I started reading the article. :) I just figured I'd give some context to thread readers who'd never heard of the OS and were wondering what we were going on about.
jordic 10y ago
It would be amazing to have acme on a browser :)

mmanfrin 10y ago

I misunderstood the title and was very confused as to why Dan Brown would have things to say about Javascript perf.

slezakattack 10y ago

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?

underwater 10y ago

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.

vvanders 10y ago
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-android-benchmarks http://www.anandtech.com/show/7384/state-of-cheating-in-andr...
trueadm 10y ago
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.

marknadal 10y ago

Pro tip: function calls (especially anonymous ones) are the biggest performance bottleneck. I've done pretty extensive research on this: http://youtu.be/BEqH-oZ4UXI http://youtu.be/BEqH-oZ4UXI .

o_____________o 10y ago
Is there a written summary of this anywhere?
- marknadal 10y ago
  I tried to give a summary in the video description (click the view more). I hope that helps.
  - o_____________o 10y ago
    Thank you, missed that
dcherman 10y ago
So I watched that and heard that you used BenchmarkJS which I believe intentionally prevents optimization from occurring, otherwise many tests would just end up being optimized away. Have you considered how function inlining might affect your results versus benchmarks like you ran in the video? Have you profiled them side by side under actual usage? "Anonymous" function calls (function expressions, either immediate or not) are generally only more expensive because they're re-created all the time. Sometimes this is necessary to create a closure, often it's not. If you were to profile `var foo = function() {}`, performance should match the function declaration variant identically, so it's not the method of declaration that affects performance.
- marknadal 10y ago
  That is something I have been suspecting of BenchmarkJS, which is unfortunate because I am/wasn't expecting to be responsible for building a better benchmarking tool (we are already building a database and a distributed testing framework). FireFox does inline, and we can tell even with BenchmarkJS, which is why I think V8 wasn't (although it has improved significantly recently). We ran an "actual use" test that saved 100M+ records a day for $10 total (on about 100GB+, processing, storage, backup). However since it is an "actual use" we don't know if inlining happened or not (I still suspect not, since I haven't seen that in V8 - but again, maybe that is BenchmarkJS killing it, despite seeing it in FF). Correct correct. The function call is still expensive (anonymous or not), and managing scope is extremely expensive. You are on top of this stuff! Sounds like you do performance testing regularly?

findjashua 10y ago

the big motivation for small size seems to be shaving the time spent on parsing the js. Is there any reason this can't be parceled off to a background worker, and using the main thread only for rendering?

igl 10y ago

React's event system is one of its strong points. Like with many alternatives, I stopped looking into them when i read "no event system" in the README. Perf is not the single most high priority in a framework.

trueadm 10y ago
Inferno also has its own event system like React does.

s2d2 10y ago

I love it. When it comes to PCs I am a speed junkie. Maybe because the first thing I started to learn as a kid was 3D graphics dev. Anyway most websites are incredibly slow and clunky. With 20+ scripts and everything pops up or moves while loading. On the speed of pure JS. I recently developed a JS game just for fun. Optimizing in a language with GC sucks.