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

Ember 2.2.0 is 111K when gzipped, and only 93K when compressed using brotli (q11) compression. That's 18 KB of noticeable saving.
You can get highly compressed javascript libraries on PageCDN. See:
jQuery CDN
Bootstrap CDN
Ember CDN
Vue CDN
Angular CDN
React CDN
and others.

Thank you @praisedpk

@NullVoxPopuli I can't seem to find it on cdnjs (that specific version)

@DayBr3ak

This comparison is plain wrong if you care about app size.

I don't think a compiled list of sizes pulled from public CDN could be wrong in a way you presented. It's up to you which comparison to make and what conclusions to make.

Angular 2 compiles down your app to a bundle. The library size is not representative at all for the final app size.

This implies that compiling your app to a bundle is the only way of using Angular 2. I think it's this implication that is wrong. There are different ways to compile most of the frameworks and, usually, the more sophisticated compiler is the better the results are. At the same time, it's not uncommon to not use a compiler at all and just pull libraries from CDN directly. Therefore this comparison could be useful if you are doing that.

@Restuta, ember isn't going to be on cdnjs, because it's part of a framework and requires ember-cli to build along with your app.
Today, Ember 3.14 is 112-116kb min+gzip. See: https://emberclear.io/bundle.html I'm not sure why the analysis shows ember in there twice. my downloaded files don't include it twice 🤷‍♂️

Is it updated?

is what updated? my link? yes :D
https://emberclear.io/bundle/broccoli.html

ember 3.19 is 116kb min+gzip.

Is it possible to get this updated?
I would really appreciate it 🙏

https://emberclear.io/bundle/broccoli.html

ember 3.22 is 114kb (min+gzip)

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

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.

Your comment is a bit old and you may have changed your mind since but I feel the need to mention two things about your comment :

• Rich world and free world are not synonyms,
• Do you imply that only rich people in rich countries deserve good internet usage conditions ?

Framework Size does matter, it shows your total LOC and architecture.
If you can achieve the same results + more features with a framework of 1400 lines of code and minimal dependencies VS a framework/library with 50,000 lines of code & hundreds/thousands of dependencies, it shows that framework has poor architecture for that many lines of code that another framework achieved the same features/concepts with very few lines of code + FASTER operations..etc.

Then again, just my opinion, right? :)
https://github.com/Arc2D-Framework/arc2d-skelton

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 ?