It's big, sure, but that's just another piece of decision making information. If you're building an app that'll be deployed for users in sub-Saharan Africa then it's clearly too much, and you need to revise your technology decisions. On the other hand, if the majority of your users are affluent westerners with broadband connections then it's less than the size of a single, full-screen background image, so arguably it's actually a relatively small download. What is "too much" changes - 120kb library, for some users, isn't too much.
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.
My Nexus4 has a faster internet connection and more RAM than my parent's laptop, and it's almost a 3 year old phone. Most (75%+) smartphone users in the UK have devices that can easily cope with a 120kb javascript library. Your rule is wrong for western countries.
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.
Ember is fairly all-encompassing. Sure, if you compare it with JQuery, it's big. But if you compare it to the full stack of libraries you need in order to run a reasonable React app, it's not too shabby at all.
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...
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).
Exactly my thoughts. Only one JS framework of that size. You'll probably include a few more JS (analytics and what not)... no wonder my "unlimited but limited" mobile plan is hitting the limit every month.
Artsy.net home page weighs 5.2Mb compressed. Less than 20% of that is JavaScript that is fully cached between page views. Let's suppose average visitor will watch 3 pages on average visit. He'll consume 800Kb of JavaScript and 12Mb of images. Most likely, next visit visitor browser won't download any JS at all. If people are OK browsing so image-rich website on their phones, developers shouldn't bother about 140Kb of Ember.JS if it helps them deliver app faster. JavaScript is less than 10% even for the first time visitor.
I don't know artsy.net, it's probably image heavy.
But an average webpage size of over 1.5MB is not acceptable onmobile, imo: http://www.websiteoptimization.com/speed/tweak/average-web-p...
Also: http://royal.pingdom.com/2011/11/21/web-pages-getting-bloate...
It's far more then it should be. Graphics can be size optimized, SVG or jpg. A JS framework doesn't need to be 100k where most webpages are probably only using a small subset of functionality. And i also don't want to download a gazillion other JS files for web tracking and such things. Ever download on a high latency connection hurts.
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.)
Your problem is a mobile network operators' problem primarily and not web/mobile devs'. Don't blame us for making the experience for you or us all prohibitively mediocre when those carriers are to blame for their ridiculous limitations imposed on data consumption and their exorbitant data plans.
That is really the thing, for a line of business application (which is what I write) I can hardly think of anything meaningful I can do in only 14k. If you are writing a marketing page for a random potato distributor I can see it, but even the standard run-of-the-mill home page has 1 meg of images, even more if there is video.
In 1999? Depending on what you're doing, ~100k of scripts is completely acceptable. If you just want some fancy UI interactions on a landing page, it is overkill though.
That's not 100k of scripts here, that's 110k of minified, gzipped javascript before you've started writing your own application, and it doesn't include ember data.
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.