One of the reasons I love writing about JavaScript frameworks is that they are incredibly impressive pieces of engineering. That, and the fact that they have made my life as a frontend developer much, much better. That said, there is always room for improvement.

Using HTTP Archive (top ~500K sites) to analyze the state of JavaScript on mobile, we can see that 50% of sites take over 14 seconds to get interactive. These sites spend up to 4 seconds just parsing & compiling JS. (ref)

This state of affairs may be about to change in a big way.

The Era of Framework Compilers

Although there have been smaller frameworks that have made fantastic improvements in mobile performance, the big three — React, Angular and Vue — have not really been the best options in this area.

There is now work underway with both Angular and React that promises to change this up and dramatically improve important performance metrics like Time-to-Interactive (TTI).

Angular Ivy

Angular had a fairly massive size when it was first released. There have been some significant improvements since then, but things are being taken to a whole other level with Ivy, a new renderer that will become optionally available in Angular 6.

Ivy’s most crucial target is cooperation with Angular Element. By encapsulating Angular components to custom elements (web components), we can achieve standalone publication, independent importing and independent usage of Angular as widgets…

…The most important part of this strategy is code size. Even wihout (sic) common runtime library, Angular should work with minial (sic) size. Components used as Angular Elements will not depended on external packages like forms and router, hence creating great value for size reduction.. (ref)

There is a demonstration site up of Ivy’s huge potential. Although it’s the simplest possible example, the bundle size is about 3.2 KB! 😮 Considering that the bundle size for a similar Angular app without Ivy would be around 45KB, this is a stunning improvement.

React Prepack

The React team is also hard at work on some future performance improvements, although with a slightly different emphasis. The work centers around another project at Facebook, called Prepack, that is at the heart of a new React compiler.

Prepack is a tool that optimizes JavaScript source code: Computations that can be done at compile-time instead of run-time get eliminated. Prepack replaces the global code of a JavaScript bundle with equivalent code that is a simple sequence of assignments. This gets rid of most intermediate computations and object allocations…

…The Closure Compiler also optimizes JavaScript code. Prepack goes further by truly running the global code that initialization phase, unrolling loops and recursion. Prepack focuses on runtime performance, while the Closure Compiler emphasizes JavaScript code size.

The team working on Prepack have created a REPL that you can use to try it out. The default example they include results in a dramatic reduction in the size of the code, but that’s not always the case. So, it’s unclear how much of a reduction in bundle size we’ll see once this work is released. That said, bundle size isn’t the only thing that matters with regard to start up time.

I recently wrote an article that featured the results of a UI Benchmark test of Inferno, Preact and React. The results are in the image below (click to see larger).

You’ll notice that Preact is the fastest under JS Init Time (smallest bundle size of the three) but by First Render Time, Inferno is long gone. Inferno absolutely smokes the other two frameworks and indeed, Inferno shows up in other benchmarks as being very, very fast, even though it often doesn't have the smallest size. I‘m connecting the dots a bit here, but this could be what we see from React once the work on Prepack is ready. Perhaps it won’t have the smallest bundle size, but it may very well have an outstanding TTI, which is really what makes a difference to users.

As an aside, why the heck aren’t more people using Inferno?! It’s freaking awesome! Perhaps not coincidentally, it looks like the React team member leading up the compiler work is Dominic Gannaway, the original author of Inferno.

The Future Is Already Here

Yes, React and Angular are the two most widely used frameworks, so what happens with them is noteworthy. However, I’d be remiss if I didn’t mention that there is already a very good compiled framework available now — Svelte.

The common view is that frameworks make it easier to manage the complexity of your code: the framework abstracts away all the fussy implementation details with techniques like virtual DOM diffing. But that's not really true. At best, frameworks move the complexity around, away from code that you had to write and into code you didn't.

Instead, the reason that ideas like React are so wildly and deservedly successful is that they make it easier to manage the complexity of your concepts. Frameworks are primarily a tool for structuring your thoughts, not your code.

Given that, what if the framework didn't actually run in the browser? What if, instead, it converted your application into pure vanilla JavaScript, just like Babel converts ES2016+ to ES5? You'd pay no upfront cost of shipping a hefty runtime, and your app would get seriously fast, because there'd be no layers of abstraction between your app and the browser.

Svelte is a new framework that does exactly that.

Svelte is authored by Rich Harris. Another one of Rich’s big projects is Rollup, which is a module bundler typically used in libraries (it’s used by both React and Angular, for example). So, Rich knows a helluva lot about optimizing JavaScript, and with Svelte, it shows.

A companion to Svelte is Sapper. Sapper is to Svelte, what Next.js is to React. It’s a framework with all the good stuff you’ll need to build a real app baked in — routing, data fetching, code splitting, etc. When I took it out for a test drive, the gzipped size for the app was around 11 KB! Keep in mind, this was not a stripped down, “Hello World” example. It included the works.

Even if Svelte isn’t the right framework for your next project, consider giving it a star on GitHub. It’s definitely deserving of more attention — and usage!

If you’ve enjoyed this post, sign up for my weekly newsletter. I curate the best JavaScript writing from around the web and deliver it to readers every Thursday. The sign up form is right below this article.

Until next time, happy coding…