Live data from Hacker News

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

survivejs.com

21–30 of 51 posts

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

#21
post #2

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

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

[2] Plan 9: The Way the Future Was http://www.faqs.org/docs/artu/plan9.html

[3] http://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt

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

#22
post #20

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…

Please, please, write more, and more details!

To much web developers have that "works on my (fastest possible) desktop or notebook" attitude, and every developer that understands and talks about what's actually going on by most of the users (those using the slower devices) is worth gold.

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

#23

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

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

#24
post #2

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

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

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.

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

#25
post #22
post #20

Earlier quoted context omitted.

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…

Please, please, write more, and more details! To much web developers have that "works on my (fastest possible) desktop or notebook" attitude, and every developer that understands and talks about what's actually going on by most of the users (those using the slower devices) is worth gold.

The interview actually talks quite a bit about how I went about making these changes. Worth fully reading!

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

#26
post #24

Earlier quoted context omitted.

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

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.

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.

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

#27
post #17
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/

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.

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

#29

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…

>Browsers are stuck optimizing an outdated model

Well, you can always switch to Java applets, Flash or Silverlight. Oh, wait...

>parsing and compiling JavaScript on the critical path is madness.

You know what's madness? Pushing so much client-side code that it destroys your website's performance - despite giant leaps in capabilities of CSS, expressiveness of the language itself, faster CPUs, and tons of engine optimizations.

>The only benefit of that model is that a web developer can right click and view source to see some unreadable minified JavaScript code.

No, the main benefit of that model is that the Web consists of pages, rather than opaque executable blobs.

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

#30
post #20

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…

I love your work with Inferno, congratulations.

Is there any place that the community usually hangs out like a chat room or a forum ?

Post reply on HN