Skip to content

Instantly share code, notes, and snippets.

@Restuta
Last active March 7, 2024 00:01
Show Gist options
  • Save Restuta/cda69e50a853aa64912d to your computer and use it in GitHub Desktop.
Save Restuta/cda69e50a853aa64912d to your computer and use it in GitHub Desktop.
Sizes of JS frameworks, just minified + minified and gzipped, (React, Angular 2, Vue, Ember)

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

@NullVoxPopuli
Copy link

NullVoxPopuli commented Oct 13, 2019

@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 🤷‍♂️

@JayTailor45
Copy link

Is it updated?

@NullVoxPopuli
Copy link

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

ember 3.19 is 116kb min+gzip.

@jamesta696
Copy link

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

@NullVoxPopuli
Copy link

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

ember 3.22 is 114kb (min+gzip)

@Skaant
Copy link

Skaant commented Jan 11, 2021

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

@Skaant
Copy link

Skaant commented Jan 11, 2021

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 ?

@jamesta696
Copy link

jamesta696 commented Jan 11, 2021

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

@Olb
Copy link

Olb commented Jan 12, 2021

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.

@bhaltair
Copy link

thx

@jorgellose
Copy link

jorgellose commented Apr 5, 2021

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.

@0xMurage
Copy link

0xMurage commented Feb 11, 2022

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)

@NullVoxPopuli
Copy link

NullVoxPopuli commented Feb 11, 2022

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)::

@ChinmayMoghe
Copy link

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

@jamesta696
Copy link

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

@greatBigMassive
Copy link

greatBigMassive commented Jun 15, 2023

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.

@NullVoxPopuli
Copy link

NullVoxPopuli commented Jun 15, 2023

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.

@greatBigMassive
Copy link

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.

@NullVoxPopuli
Copy link

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.

@greatBigMassive
Copy link

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! 👍

@jfbrennan
Copy link

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.

@jorgellose
Copy link

jorgellose commented Jun 15, 2023 via email

@mackignacio
Copy link

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.

@ChinmayMoghe
Copy link

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 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment