Comment by underwater | Hacker News Reader

Comment by underwater | Hacker News Reader

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.

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.

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.

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/

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.

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.

What are example real world websites using Inferno?

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

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

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

Use Java, of course! I heard you write it once and it runs everywhere. And it doesn't rely on that horrible, outdated Web model. Compiles to binary blobs, just the way you like it.

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

Reply on news.ycombinator.com