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

31–40 of 51 posts

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

#31

Post by ploxiln »

trueadm wrote: post #20
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…

It's probably not the same people making these comments, but it's funny to juxtapose "these web technologies are plenty fast, and size is no issue" and "I need 32GB ram + 4 real cores on my macbook for serious web dev".

If the whole system is dedicated to a single page, sure a few hundred KiB of minified javascript is absolutely fine. But neither the developer's system or the user's system is dedicated to a single page. It adds up. It tends to keep adding up until some significant percentage of people hit the limit where stuff is slower than makes sense, considering the AAA games I was playing on a laptop 13 years ago with literally less than 10% of what common laptops today have.

Anyway, kudos for caring about efficiency.

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

#33

Post by acqq »

trueadm wrote: post #25
acqq wrote: post #22

Earlier quoted context omitted.

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!

Thanks. I've read it, what I'd like to see is more of the stuff addressed to other developers, exactly like in your response above.

You understand the issues because you personally compared, measured, whereas most of the developers just consider something as "working" if they personally "don't wait" too much for the stuff they are producing. That's why I wanted to motivate you to consider talking about your experiences that more developers can directly use.

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

#34

Post by danabramov »

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

Earlier quoted context omitted.

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.

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

#35

Post by trueadm »

igl wrote: post #32

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.

Inferno also has its own event system like React does.

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

#36

Post by trueadm »

HugoDaniel wrote: post #30
trueadm wrote: 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…

I love your work with Inferno, congratulations. Is there any place that the community usually hangs out like a chat room or a forum ?

We have a Slack if you're interested: https://inferno-slack.herokuapp.com/

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

#37

Post by o_____________o »

marknadal wrote: post #15

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 .

Is there a written summary of this anywhere?

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

#38

Post by s2d2 »

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.

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

#39

Post by underwater »

trueadm wrote: post #20
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…

I worked on JavaScript performance at Facebook. I completely agree that we need the things that you mentioned. The problem is that no one is building them.

Instead we get demo apps and poorly thought out blog posts that compare library bundle sizes. It's a distraction that doesn't address the problem and diverts attention from the real problems with web performance.

For almost any real world application the fixed overhead of React/Inferno/Preact will be quickly dwarfed by the overhead of application code, even with code splitting. Unless you can address that cost then you shouldn't be building a client rendered mobile app.

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

#40

Post by underwater »

gambler wrote: post #29
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…

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

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

And if I can't create something that fits well into that model then what should I do? Create a native app on a proprietary system instead? Change my product to fit the stunted capabilities of the platform?

Front end engineers have internalized the idea that execution is slow, and that the only way we can create performant applications is to defer control to the browser. This is not true for any other platform -- it's merely an artifact of legacy design choices that we continue to pay for today.

Post reply on HN