The file size (ember.min.js) went down due to the cleanup:
1.13.8: 488K, 126K gzipped
2.0.0: 424K, 110K gzipped 1.13.8: 488K, 126K gzipped
2.0.0: 424K, 110K gzippedOne thing to note, often we must trade-off bytes for supporting older features. As those go away, we shrink. But moving forward the plan it to have more of a pay-as-you-go model. Utilizing ember-cli to do the r.js optimize esq step, to strip unused portions etc.
Nothing ground breaking, its tried tested and true in many other ecosystems. But when it lands it will provide nice value for our ember apps.
* Fabrice Bellard's JS PC Emulator [1]: 148.4K, 36.8K gzipped
110k is smaller than a lot of images.
Acceptable for what use in production?
E.g: is it an internal tool? Is it a landing page? Is it a SPA that has to do a bunch of things before content can get rendered? These considerations have an effect on what is an acceptable webpage weight for most teams.
Traditionally those sites may have also consider I am sure they will continue to be happier as the byte size shrinks, but in the interim they are able to deliver what appears to be a great user experience, in-light of your concerns.
Even though you always hear about the mobile web, web devs simply aren't trying hard enough to make the mobile web experience pleasant. They'd rather complain about mobile safari or mobile chrome than actually look at their own product.
(Yes, this is a generalization, but generally, the mobile web sucks.)
You're barking up the wrong tree my friend.
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...
* 155K of vendor JS (Ember, jQuery, addons)
* 76K of app JS
* 26K jQuery
* 6K raven JS
* 127K analytics JS
* 300K main layout JS
* 274K homepage app JS
* + stripe
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).
That said though, if your ember.js code blocks rendering, or causes lots of repainting, and you're building a site rather than an app, then I'd question if you're making the right choice.