Interview with the author of React-like Inferno about JavaScript optimisations
survivejs.com
survivejs.com
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.
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...
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.
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.
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.
Is there any place that the community usually hangs out like a chat room or a forum ?
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.
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.
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.
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.
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.
(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
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.
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?
I'd rather have simple h or createElement calls. I personally prefer Typescript jsx as all my Components are type validate and refactoring is a breeze.
What I like about preact is its simplicity. I can debug preact and figure out what's going on. Inferno on the other hand seems a bit like assembly. Reusing property names across different contexts is a no-no in my book.
I once worked on a database with generic extra_1 extra_2,... fields. They were abused pretty bad and only one guy knew what they meant in what context.
While trueadm is a perf wizard I would definitely love to see some of the opts being done at the V8/chakra level rather than obfuscated js code.
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 make changes, it would break React for many people due to how coupled many things are.
A lot has changed in the last few years and the approach to virtual DOM has been one of them. Going forward, the React team are making big efforts to change this.
[0] https://github.com/reactjs/core-notes/blob/master/2016-12/de...
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.
Practically speaking for an end user not a lot will change, but React will be faster, non-blocking, and have a whole new set of applications.
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.
"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.
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?
The biggest takeaways that I've had are mainly that if you really want to optimize, then write the kind of code that the various engines can optimize best. With that in mind, TypeScript is not only a great language, it's actually a great performance tool since it can help you to identify polymorphic functions that maybe could be changed to monomorphic ones if they're in the hot path.
I've got another fun hacky kind of optimization for you though that I've mainly used for benefit in some angular code/expressions that are executed potentially millions of times. If you can make some assumptions about the name of the property being accessed for security reasons and it's going to be repeatedly used, compare the following:
// Setup
const makeGetter = (prop) => new Function("obj", "return obj." + prop");
const slowGetter = (obj, prop) => obj[prop];
const fastGetter = makeGetter("foo");
const obj = { foo: "bar" };
// Test
slowGetter(obj, 'foo');
fastGetter(obj);
This is primarily an optimization for Internet Explorer, but if I recall it was somewhat positive in other browsers at the time as well. It makes more sense if you consider it in the context of executing a simple angular expression repeatedly, though 1.6.0 might narrow that gap significantly now that the expressions sandbox was removed as I think they generate code similar to my "makeGetter" factory. Haven't re-tested yet.