Hacker News new | ask | show | jobs
by rapind 3968 days ago
It seems comparably pretty terrible to me actually after a bit of checking.

React comes in around 26k, Flux is another 1k or so, and say you throw in underscore that's still something like 30k combined. Add another 5k if you need an es5 shim / sham (say you're supporting earlier IEs). Another 4k for superagent. So it looks like somewhere around 40k minified and gzipped to run a reasonable React app.

The nice thing is that you don't even need jquery once you're in react land, unless there's an addon you absolutely must have and would be a pain to reactify. We haven't had to use jQuery in our last few projects.

That's 3X though and not 8X. 8X sounds like a biased exaggeration. I don't understand why people have to polarize so much over js frameworks...

1 comments

Comparing framework size directly is not very meaningful. For example Bustle.com, already running Ember 2.0 today, sits at:

  * 155K of vendor JS (Ember, jQuery, addons)
  * 76K of app JS
Artsy.net is a universal/isomorphic JS website using Backbone. Backbone is maybe a tenth the size of Ember, maybe. Their homepage payload sits at:

  * 26K jQuery
  * 6K raven JS
  * 127K analytics JS
  * 300K main layout JS
  * 274K homepage app JS
  * + stripe
Now I also think Artsy does a lot more than Bustle, to be fair. However the point is that framework size is only a part of the story. The complexity of your code, how you ship it, and how concisely the framework lets you express a design are all extremely impactful.

Ember gives you a big bang for your buck with that 108K (a minified, gzipped 2.0). In practice not many people find this to be the main performance hurdle in their apps, but regardless we're working toward smaller payloads (something we call "svelte builds") and better initial execution performance (https://github.com/emberjs/ember.js/pull/11576).

Good point.