and shrinking :) We have some fun related work planned to continue the shrink.

One 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.

there's http://iao.fi/ember-size/ to watch ember size change over the years

Cool, thanks!

* Ember 2.0.0: 424K, 110K gzipped

* Fabrice Bellard's JS PC Emulator [1]: 148.4K, 36.8K gzipped

1: http://bellard.org/jslinux/

Ouch. That's about 8x the size I'd consider acceptable.

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.

A mobile network is basically sub-Saharan. 120 KB of JavaScript is far too much to download, decompress and evaluate on a phone.

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.

As someone who frequently travels on the tube: The rule persists.

And many western users have a limited amount of data on their plans.

Use case also matters. If you're delivering 1mb of javascript for your ecommerce website, that's too much.

Right. But for a dashboard (what I use it for) that will rarely be closed or refreshed, the size is unimportant.

Acceptable for what? Genuinely curious about what you benchmark it against, and where you draw the line and why.

110k is smaller than a lot of images.

Acceptable for use in production.

Okay. Thanks.

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.

For any use in production. Yes, you are right all that must be considered. Still not acceptable.

Our friends at http://www.bustle.com/, http://vine.co/, and twitch.tv (http://www.twitch.tv/directory/) ... (lots more) have demonstrated this to be acceptable for there needs.

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...

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.

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.

This.

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

Another thing is that data on mobile sometimes can be expensive.

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.

You're barking up the wrong tree my friend.

No. If dev's don't take into account the real world environment their app will run in, they are doing a lousy job.

So anything above 14K is unacceptable?

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.

Yeah, I should have written 5-8 times, but MiniHack has some problem with editing comments.

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.