Sizes of JS frameworks, just minified + minified and gzipped, (React, Angular 2, Vue, Ember)

framework-sizes.md

Below is the list of modern JS frameworks and almost frameworks – React, Vue, Angular, Ember and others.

All files were downloaded from https://cdnjs.com and named accordingly. Output from ls command is stripped out (irrelevant stuff)

As-is (minified)

$ ls -lhS
566K Jan  4 22:03 angular2.min.js
563K Jan  4 22:05 angular2.0.0-beta.0-all.umd.min.js
486K Jan  4 21:50 ember.1.13.8.min.js
435K Jan  4 21:48 ember.2.2.0.min.js
205K Jan  4 22:06 angular2.0.0-beta.0-Rx.min.js
144K Jan  4 21:59 react-with-addons-0.14.5.min.js
143K Jan  4 21:46 angular.1.4.5.min.js
132K Jan  4 21:56 react-0.14.5.min.js
121K Jan  4 21:35 angular.1.3.2.min.js
5.3K Jan  4 22:00 redux-3.0.5.min.js
706B Jan  4 21:57 react-dom-0.14.5.min.js
63K  Oct 13 03:02 vue-2.0.3.min.js

# 2017
91K  Dec 27 12:24 react-dom-16.2.0.production.min.js
6.5K Dec 27 12:22 react-16.2.0.production.min.js

This gives us following approximations

Name	Size
Ember 2.2.0	435K
Ember 1.13.8	486K
Angular 2	566K
Angular 2 + Rx	766K
Angular 1.4.5	143K
Vue 2.4.2	58.8K
Inferno 1.2.2	48K
Preact 7.2.0	16K
React 0.14.5 + React DOM	133K
React 0.14.5 + React DOM + Redux	139K
React 16.2.0 + React DOM	97.5K

GZipped and minified (plain output)

$ gzip -r .
$ ls -lhS
123K Jan  4 22:11 ember.1.13.8.min.js.gz
119K Jan  4 22:11 angular2.0.0-beta.0-all.umd.min.js.gz
111K Jan  4 22:11 ember.2.2.0.min.js.gz
111K Jan  4 22:11 angular2.min.js.gz
51K Jan  4 22:11 angular.1.4.5.min.js.gz
45K Jan  4 22:11 angular.1.3.2.min.js.gz
42K Jan  4 22:11 react-with-addons-0.14.5.min.js.gz
39K Jan  4 22:11 react-0.14.5.min.js.gz
32K Jan  4 22:11 angular2.0.0-beta.0-Rx.min.js.gz
1.9K Jan  4 22:11 redux-3.0.5.min.js.gz
455B Jan  4 22:11 react-dom-0.14.5.min.js.gz
23K  Oct 13 03:02 vue-2.0.3.min.js.gz

#2017
29K Dec 27 12:24 react-dom-16.2.0.production.min.js.gz
2.8K Dec 27 12:22 react-16.2.0.production.min.js.gz
63K Dec 27 13:18 aurelia-core-1.0.2.min.js.gz

Approximations for GZipped versions

Name	Size
Ember 2.2.0	111K
Ember 1.13.8	123K
Angular 2	111K
Angular 2 + Rx	143K
Angular 1.4.5	51K
React 0.14.5 + React DOM	40K
React 0.14.5 + React DOM + Redux	42K
React 15.3.0 + React DOM	43K
React 16.2.0 + React DOM	31.8K
Vue 2.4.2	20.9K
Inferno 1.2.2	20K
Preact 7.2.0	4kb
Aurelia 1.0.2	63K

---

Also take a look at this awesome tool https://cost-of-modules.herokuapp.com created by @pastelsky

In an age where everyone in the free world has ridiculous bandwidth, does the size of the javascript framework really matter? I do appreciate your efforts, and the size difference is interesting.

Very much so. Many people live in areas that don't have the fastest connections such as Rural areas in the US and many countries in the world. Many countries, including the one I am in, charge for bandwidth and the connection speed is spotty even in the big cities. Where I work we target truck drivers with an app and they often have slow connections and the companies are charged for bandwidth differently than the average person.

thx

Any thoughts about the CPU usage of zipping (server) and extracting (browser) files ? It's moving the cost of bandwidth to CPU, which should be taken in consideration

You can just create gzip / brotli in build time and then deliver the compressed one based on http headers, the result is 0% CPU cost on your server and saving like 80% of the bandwidth, CPU cost in client side is negligible compared with the amount of KB he wont download.

It's Feb 2022 and each framework keeps on adding more features.

Angular 13 is now 178.59 kb or 47.93 kb (min+gzip)
Ember 4.1.1 is now 673.77 kB or 179.33 kb min+gzip)

Angular 13 without routing is 100.80 kB or 29.42 kb (min+gzip)

Ember 4.1.1 is now 673.77 kB or 179.33 kb min+gzip)

Sounds like you bundled the whole app? the starter packages, ember-data, ember-welcome-page etc aren't needed (css, images, etc)

Ya gotta do the bundle analysis graph and pick ember-source out (the meta package containing tho whole framework)::

Add Svelte.JS, Solid as well , the bundle sizes will be much smaller for these frameworks.

Anyway you can add Arc2D on to this list? It's a W3C compliant native JavaScript ES6 Framework which has built in SPA, HTML5 WebComponents features and more.

Website: https://www.arc2d.com
Arc2D Docs: https://www.arc2d.com/resources/index.html?path=docs/topics/DocHome
Arc2D CDN Source: https://cdn.jsdelivr.net/gh/nashorn/od-cocoon@latest/framework.min.js

Really insightful stuff.

So glad I don't depend on JS or CSS frameworks other than my own (had the fortune of starting off back in the day when jQuery and Mootools were kicking off).

Huge bloatware really for most situations. It seems like developers have completely lost the understanding that load times are important for people who want information fast. There was a time when a flashy fade or a smooth dropdown menu was a wow factor but now, people simply want to get to information fast. If you removed all the whizz and the fades most wouldn't even question where it had gone.

You have dropdown menus loading 50 options with sub-options for no reason when a granular menu could be achieved on demand with screen refreshes. A screen refresh isn't a bad thing if the content it cached on the previous screen is so tiny it makes the next screen load like lightening. It's as if they think loading absolutely all your content at the start is going to make a faster experience for the end user only they miss the part that, if the initial load takes ages to happen, most people get frustrated and leave or the site is so bloated their browser hangs. If that doesn't happen, even a refresh still takes ages to process again because the cached content being re-used is so massive.

The worse one really is the calls to go back over the DOM HTML and then start applying things to it onDOMReady style.
Needless reasons to go and select checkboxes by fetching all elements of a certain type when the checkboxes could have been pre-selected when their HTML was created. Dozens of these onDomReady processes adjusting things in the background, making subsequent background calls to fetch things that MIGHT get clicked on by the user but all ultimately adding to the clunky slow loading experience on initial entry to a website.

I've seen developers force end users to download 1MB-2MB of frameworks (CSS, JS, pre-loaded images) so they can do a background call or make a box fade into view. Feel sorry for the 4G mobile users mostly. So many websites take 30 seconds to load properly before you can even read a page and that's connected to your local network!

The assumption that everybody has fast networks speeds is an example of how enclosed developers are becoming.
As long as it works fast on their latest Apple Mac with 600MBps connection then surely it will work for John down the road in a factory trying to view it on his 4 year old phone with 4G trying to order parts quickly in his lunch break. Pretty sure John doesn't care if the drop down menu slides in or not.

Great eye opener all the same with your examples.
Thank you.

RIP MooTools.

Huge bloatware really for most situations.

you live in a bubble.

For most of these frameworks, the companies using them have at least 10x their own code compared to the collective size of all tools they use put together.

Huge bloatware really for most situations.

you live in a bubble.

For most of these frameworks, the companies using them have at least 10x their own code compared to the collective size of all tools they use put together.

I think, to be fair, there are different types of bubbles we live in. If you have to develop a site that needs to be used by the west and the far stretches of the east at the same time, you are more likely aware of how a website needs to work on a mobile phone with bandwidth choking than you are if you are advertising an iPad to people that you can mostly guarantee will have a good connection, the latest browser(s) and a fast device.

Software provided to eastern schools for example or poor regions (some in areas where finding a good local hosting provider is nearly impossible) has to be more efficient because schools have bandwidth limitations and it's spread thinly over the masses. People struggle with 4g connections and so on. You can't be feeding them 4MB of frameworks per student per device if only 100kb of that framework gets used.

If a company is adding 10X more code to the existing frame work (like I believe you mean) then that makes the situation even worse because the end user is downloading even more JS and CSS on top of the framework designed to make things efficient in the first place.

Anyway, I agree, there are different bubbles we live in so taking all of them into account is important based on the goal.
Take it easy NullVoxPopuli.

Take it easy NullVoxPopuli.

<3

---

In general, I 100% agree with you. Most companies are actually really bad at writing accessible software, and it's infuriating.

Take it easy NullVoxPopuli.

<3

In general, I 100% agree with you. Most companies are actually really bad at writing accessible software, and it's infuriating.

I know what you mean but granted, there are those that are awesome too. Hey, when ever I feel bad about my coding, I go to a WIXX website and view the source code then monitor the Network part to see what it's doing. Always makes me feel better hehe! 👍

At a certain point architecture not framework size becomes the bigger performance issue. Regardless of framework, SPA performance doesn't scale and I haven't found the awkward embedded micro-frontend SPA architecture to noticeably improve performance either. You have to break up jumbo SPAs into independent apps and use (drumroll) the internet to hyperlink apps together into a cohesive product.

I am a huge fan of tiny frameworks though. Preact and Svelte and Riot are tangibly lighter and faster, but for me they also set a tone for the project: smaller, simpler, easier is our ever-present goal. I like to approach it as if we're building a fleet of carbon fiber race drones, not a Boeing 747.

We have an inmense internal app with Angular and it have a normal weight, like 90KB/screen, except the ones that use one superpowerfull grid that weights like 500KB+- Normally frameworks allows you to lazyload by modules, for example, if you reach the login screen you would download login screen module and app module, the if you navigate to sales/order you donwload sales and order modules only becouse core is already, then if you navigate to sales/order/detail you only download detail module. At component level you can do exactly the same, download if it is needed. I just see that some projects are so bad designed that need to be split in multiple apps becouse they have like 10-30 minutes of build time. All our components except chartjs and ag-grid are handmade, me have minimal css and js and all works fast El jue, 15 jun 2023 a las 18:54, Jordan Brennan ***@***.***>) escribió:

…

***@***.**** commented on this gist. ------------------------------ At a certain point *architecture* not framework size becomes the bigger performance issue. Regardless of framework, SPA performance doesn't scale and I haven't found the awkward embedded micro-frontend SPA architecture to noticeably improve performance either. You have to break up jumbo SPAs into independent apps and use (drumroll) the internet to hyperlink apps together into a cohesive product. I am a huge fan of tiny frameworks though. Preact and Svelte and Riot are tangibly lighter and faster, but for me they also set a tone for the project: smaller, simpler, easier is our ever-present goal. I like to approach it as if we're building a fleet of carbon fiber race drones, not a Boeing 747. — Reply to this email directly, view it on GitHub <https://gist.github.com/Restuta/cda69e50a853aa64912d#gistcomment-4600762> or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFBSV35YHPXXLFGKZN4RV43XLM45XBFKMF2HI4TJMJ2XIZLTSKBKK5TBNR2WLJDHNFZXJJDOMFWWLK3UNBZGKYLEL52HS4DFQKSXMYLMOVS2I5DSOVS2I3TBNVS3W5DIOJSWCZC7OBQXE5DJMNUXAYLOORPWCY3UNF3GS5DZVRZXKYTKMVRXIX3UPFYGLK2HNFZXIQ3PNVWWK3TUUZ2G64DJMNZZDAVEOR4XAZNEM5UXG5FFOZQWY5LFVAZDSNRZGIZDINFHORZGSZ3HMVZKMY3SMVQXIZI> . You are receiving this email because you commented on the thread. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> .

You can't use ReactJS alone. You need like 3 more libraries to make it working for the basic uses. react-dom, redux and react-router and the 3 basic if you want to create a very decent app. Comparing ReactJS alone is a false comparison compare to fully featured frameworks like Angular and VueJS. Please add these 3 libraries and you will see how bloated ReactJS is.

You can't use ReactJS alone. You need like 3 more libraries to make it working for the basic uses. react-dom, redux and react-router and the 3 basic if you want to create a very decent app. Comparing ReactJS alone is a false comparison compare to fully featured frameworks like Angular and VueJS. Please add these 3 libraries and you will see how bloated ReactJS is.

That's true you know , maybe redux can be skipped considering the careful use of context and useReducer() no ?