The Baseline Costs of JavaScript Frameworks

As a US based user of an A53 based phone, where I use firefox. I&#x27;m here to tell you more than 50% of the sites I visit with it (HN being one that actually works well) are completely unusable. There was a saying back in the 1990&#x27;s that developers should be forced to use obsolete hardware to assure that their software was usable for the regular user, and its even more true today. Developers running around with the latest iphones does nothing to actually represent what the average user actually sees.<p>Picking on amazon, I generally don&#x27;t even bother going to their site unless i&#x27;m on my desktop, where I can physically watch them frequently spike my 4+ Ghz CPU for a few seconds when I type in the search bar, or click a page. Doing the same on my phone or cheap tablet frequently results in a 10+ second waits. The other day I was typing on my tablet and the amazon search completion was literally taking 20+ seconds to display each _character_ and a completion list for it.

&gt;Or consider not using a framework at all. For websites that primarily display content, it’s more efficient and cost-effective to just send some server-rendered HTML down the wire. If there are areas of your website that require interactivity, you can always use JavaScript to build those specific parts.<p>This should be the takeaway from the article. There&#x27;s absolutely no need for javascript on most websites that use javascript. I understand if you&#x27;re forced into it by the time and economic contingencies of your work but if you bring JS frameworks home to your personal sites you&#x27;re doing it wrong.

I&#x27;m not surprised that Angular ships a larger bundle than React and Vue, it intentionally covers a much larger surface area of functionality. But Angular also includes build tools meant to reduce the size of the final bundle - can anyone tell if those were used in this comparison?

I used to write all my static sites using Hugo, until I saw a site that was built using Gatsby. Gatsby has a larger overhead on the initial page load but feels much faster and subsequent page loads have less overhead (or maybe more, if it&#x27;s prefetching a lot of adjacent pages which you&#x27;ll never navigate to).<p>It seems to me that the next logical step is a site that ships the initial page request in vanilla JS, then async loads react and then async fetches the overhead and then runs Gatsby. This would be the ideal if we&#x27;re optimizing for <i>perceived</i> latency. So the first page load is fast, then as long as you stay on that page for a second or two before clicking elsewhere, everything after that point will be snappy too.<p>Ofcourse, many other devs are optimizing for network usage, etc, so to each their own.

One thing it should be noted with Angular is that there is currently work on a new renderer that should allow framework bundle size to be optimized with the whole framework being tree-shakeable.<p>I wonder how Angular would compare once that is done, as this has long been known as probably the main negative with Angular performance-wise, the initial load (but it should be faster than most of the rest once it does load).

Tangental, but it&#x27;s frustrating creating a website and optimizing it for performance down to the bone; and then having &#x27;mission critical&#x27; plugins totally rip the potential performance gains to shreds.<p>My ecommerce site [0] (built on a custom stack, not shopify; making it orders of magnitude faster). I got it down to 600kb with 27 network requests total (with it being heavily media&#x2F;image based). Now find me any other ecommerce site which can boast a comparable network payload.<p>Unfortunately, after throwing google analytics + fb ad trackers + a chat widget + a youtube video, the network requests have ballooned to 100+. It&#x27;s very ironic how these companies promote the development a performance driven web, but the tools they want us to embed do quite the contrary. They do, however, offer a lot of value. What to do?<p>[0] — www.getfractals.com

Damn, Svelte is not on there. I&#x27;d be curious what the author thinks to it as an approach <a href="https:&#x2F;&#x2F;svelte.technology&#x2F;" rel="nofollow">https:&#x2F;&#x2F;svelte.technology&#x2F;</a>

&gt; your React application will never load faster than about 1.1 seconds on an average phone in India, no matter how much you optimize it<p>What about cache? In that 1.1s figure, 0.9s are for the download of react.<p>Is it reasonable to assume that for most subsequent loads the website would load in 0.2s?

A nice way to improve the time-to-interactive is to prefetch the framework after you load an initial basic page.<p>Here&#x27;s Addy Osmani explaining how it works: <a href="https:&#x2F;&#x2F;medium.com&#x2F;dev-channel&#x2F;a-netflix-web-performance-case-study-c0bcde26a9d9" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;dev-channel&#x2F;a-netflix-web-performance-cas...</a>

That&#x27;s assuming you don&#x27;t do any server side rendering right?<p>I can send completely readable html over the wire that becomes interactive once the JS finishes loading.<p>What am I missing.

I&#x27;m the only person on my current team (an internally-focused engineering team) who has experience building websites&#x2F;apps for <i></i>external paying clients<i></i> (e.g. people who will freak out if anything fails to load faster than they can blink, on their phone&#x27;s 3G connection).<p>I was taken aback by how many times I had to argue with my team, our sister teams, our consultants&#x2F;contractors, and even our (non-technical) leadership about NOT building a SPA when we came across 1 form in our large codebase that required some extra interactivity.<p>For some reason many developers seem to be fine turning a blind eye to the actual page-rendering time, maybe because it&#x27;s hard to benchmark with tools? (although I&#x27;m skeptical of that). I find an overlap however in that those same developers seem to not understand why multiple database query roundtrips are worse than 1 query followed by some in-memory munging.<p>I&#x27;m sure I&#x27;m biased by my background, where we were profiling like mad, doing crazy things like purposely modifying images&#x2F;hand-building sprites to pack better, minifying CSS before SASS&#x2F;LESS existed, and every millisecond to finish rendering mattered. Good times.

This is why I&#x27;m a happy user of Preact - the core feature set of React minus the bloat. Especially with some recent additions to React (context, hooks) which I don&#x27;t have any need for, I&#x27;m glad to stay with the smaller surface area of Preact instead.

&gt; If you want your application to become interactive on your users’ devices in under 5 seconds, can you afford to spend a fifth of that time just booting up React?<p>If you care about load time you should pick a framework because of the value it brings, rather than what it costs. That one second overhead might make your application code twice as efficient.<p>For example Next.js and React will give you route based bundle splitting and navigation preloading for free. Yes, a vanilla JS app could implement the same, but requires a lot more boilerplate to achieve. So in practice most devs are more likely to skip that part and their lightweight no-framework app becomes a bloated mess.

I wonder how much bootup time Ember.js takes nowadays. I mean, a few years back Ember was probably the worst when it came to initial loading times (it has other strengths), but I heard it got better over the years.

&gt; Frameworks exist for a reason.<p>People keep saying that...

&gt; Truth is, when you build your application on top of a modern JavaScript framework, you agree to pay a certain baseline performance cost that can never be optimized away. In exchange for paying this cost, you gain maintainability, developer efficiency, and (hopefully) better performance during runtime.<p>All of that is completely subjective except for that final bit about runtime performance. I bet nobody can prove runtime performance improves in correlation with layers of abstraction.

It&#x27;s simple. Don&#x27;t use frameworks for content consumption. It adds no value to the end user. No, I don&#x27;t need your full fledged my-data-sucking SPA just to read an article on your site. Keep it simple.<p>The best example?<p><a href="https:&#x2F;&#x2F;www.react.rocks" rel="nofollow">https:&#x2F;&#x2F;www.react.rocks</a> is a site built on react to advocate people to use React.<p>This is how it looks like without JS.<p><a href="https:&#x2F;&#x2F;webcache.googleusercontent.com&#x2F;search?q=cache:WRll6h8NQc8J:https:&#x2F;&#x2F;react.rocks&#x2F;example&#x2F;react-chrome-redux+&amp;cd=6&amp;hl=en&amp;ct=clnk" rel="nofollow">https:&#x2F;&#x2F;webcache.googleusercontent.com&#x2F;search?q=cache:WRll6h...</a><p>A site built on React to advocate React doesn&#x27;t serve its primary purpose. The irony.

This isn&#x27;t about JS frameworks, it&#x27;s about rendering data on page load.<p>Whether the server renders the data into HTML it responds with or there&#x27;s some XHR request made by a client library (including VanillaJS) or framework, you&#x27;re always incurring some cost. But data-on-load what users generally want and expect from modern web apps.<p>Having recently built an almost 100% HTML-based web app, I can tell you the user interactions feel unpleasant. Removing JS from web apps is silly at this point.

Comparing a barebones view layer libraries (Vue, React etc.) with full frameworks (Angular, Ember etc.) is not comparing apples to apples.

I am surprised by the fact that author completely ignores client side caching using browser and service worker, as well as SSR.<p>One key point of PWA is that it works offline and loads faster after after first load (even after you deploy new changes, with basic service worker configs from sw-precache). So you need 1 second for <i>first load only</i>. Subsequent loads are much faster.

Why would you compare React&#x2F;Vue vs Angular??? I don&#x27;t think the author understands the difference between frameworks and libraries.<p>React vs Vue can be a valid analysis, same as Angular vs Ember. It&#x27;s silly to benchmark React&#x2F;Vue vs Angular&#x2F;Ember.<p>Lets create a benchmark of ponies vs zebras&#x2F;horses!

This is why obsoleting frameworks by expanding the native component model of the web is good for the world.

Including megabytes of unrelated .gifs in the blog post kind of undermines the point here...

Please stop using gzip size for these sorts of comparisons. One, gzip affects download speed, but <i>not</i> JS evaluation and compilation. Two, it makes the libraries seem much smaller than they actually are.

Of all the client-side JavaScript libraries available for making responsive web applications, I&#x27;ve found that Elm suits me best. I haven&#x27;t done any benchmarks, but it feels faster than React and Angular to me and the Elm compiler eliminates virtually all runtime issues before I ever deploy my code.<p>Another alternative to large client-side libraries I&#x27;ve been looking at lately is Phoenix&#x27;s LiveView. It is a server-side rendering library that uses web sockets. I&#x27;ve only just started using LiveView, but so far my pages seem to perform better than React or Angular.

He&#x27;s not using SSR which is wrong in 2018. Vue&#x27;s startup performance will also supposedly double in the next version. Looking forward to that.

To better make sense of this data it needs to be compared against the time needed to build a non-trivial interface using each of the frameworks.

The main conclusion from this article isn&#x27;t accurate. This is one reason to load common libraries from a known CDN so that if any website has downloaded that library version previously, and the user&#x27;s cache has not been cleared or expired, the next time that library can just be loaded from cache, even if from a different website.

It doesn&#x27;t mention framework versions..

Not using server side rendering, not using a cdn or some form of caching. Not sure this is a good test of anything other than how to fail at implementing SPAs.

This person doesn&#x27;t know a thing about Angular and he is benchmarking it?! Angular is not loading the whole RxJS and I doubt AOT was setted properly.<p>This is a misleading paper again. I would like that 3 experts on each framework do their best to provide the same app and then we could compare.

&gt; in exchange for paying this cost, you gain maintainability, developer efficiency, and (hopefully) better performance during runtime.<p>You also gain responsiveness to user interactions, a programmatic way to reason about your application&#x2F;website &amp; and some animation-sugar if you want. Don&#x27;t throw the baby out with the bath water simply because people follow trends instead of good design practices.

&gt; your React application will never load faster than about 1.1 seconds on an average phone in India, no matter how much you optimize it<p>Weren&#x27;t your assets deployed on Netlify&#x27;s CDN? Shouldn&#x27;t that make location roughly irrelevant (assuming enough PoPs)?