5 ms·

The file size (ember.min.js) went down due to the cleanup: 1.13.8: 488K, 126K gzipped 2.0.0: 424K, 110K gzipped

iamstef 11y ago
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.
makepanic 11y ago
there's http://iao.fi/ember-size/ http://iao.fi/ember-size/ to watch ember size change over the years
- lclemente 11y ago
  Cool, thanks!
rimantas 11y ago
Ouch. That's about 8x the size I'd consider acceptable.
- j_jochem 11y ago
  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.
  - masklinn 11y ago
    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.
- sbarre 11y ago
  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.
  - rimantas 11y ago
    Acceptable for use in production.
    - benihana 11y ago
      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.
      - rimantas 11y ago
        For any use in production. Yes, you are right all that must be considered. Still not acceptable.
        iamstef 11y ago
        Our friends at http://www.bustle.com/ http://www.bustle.com/, http://vine.co/ http://vine.co/, and twitch.tv (http://www.twitch.tv/directory/ 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.
- buster 11y ago
  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.
  - JustSomeNobody 11y ago
    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.)
    - rimantas 11y ago
      Another thing is that data on mobile sometimes can be expensive.
    - notNow 11y ago
      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.
      - rimantas 11y ago
        No. If dev's don't take into account the real world environment their app will run in, they are doing a lousy job.
  - chebum 11y ago
    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.
- ctolsen 11y ago
  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.
  - rapind 11y 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...
    - mixonic 11y ago
      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 https://github.com/emberjs/ember.js/pull/11576).
      - 11y ago
- onion2k 11y ago
  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.
  - Touche 11y ago
    Use case also matters. If you're delivering 1mb of javascript for your ecommerce website, that's too much.
    - onezeno 11y ago
      Right. But for a dashboard (what I use it for) that will rarely be closed or refreshed, the size is unimportant.
  - nilved 11y ago
    A mobile network is basically sub-Saharan. 120 KB of JavaScript is far too much to download, decompress and evaluate on a phone.
    - onion2k 11y ago
      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.
      - rimantas 11y ago
        And many western users have a limited amount of data on their plans.
- pc86 11y ago
  So anything above 14K is unacceptable?
  - rimantas 11y ago
    Yeah, I should have written 5-8 times, but MiniHack has some problem with editing comments.
  - cwbrandsma 11y ago
    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.
emmanueloga_ 11y ago
* Ember 2.0.0: 424K, 110K gzipped * Fabrice Bellard's JS PC Emulator [1]: 148.4K, 36.8K gzipped 1: http://bellard.org/jslinux/ http://bellard.org/jslinux/

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.

makepanic 11y ago

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

lclemente 11y ago
Cool, thanks!

rimantas 11y ago

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

j_jochem 11y ago
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.
- masklinn 11y ago
  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.
sbarre 11y ago
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.
- rimantas 11y ago
  Acceptable for use in production.
  - benihana 11y ago
    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.
    - rimantas 11y ago
      For any use in production. Yes, you are right all that must be considered. Still not acceptable.
      - iamstef 11y ago
        Our friends at http://www.bustle.com/ http://www.bustle.com/, http://vine.co/ http://vine.co/, and twitch.tv (http://www.twitch.tv/directory/ 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.
buster 11y ago
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.
- JustSomeNobody 11y ago
  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.)
  - rimantas 11y ago
    Another thing is that data on mobile sometimes can be expensive.
  - notNow 11y ago
    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.
    - rimantas 11y ago
      No. If dev's don't take into account the real world environment their app will run in, they are doing a lousy job.
- chebum 11y ago
  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.
ctolsen 11y ago
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.
- rapind 11y 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...
  - mixonic 11y ago
    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 https://github.com/emberjs/ember.js/pull/11576).
    - 11y ago
onion2k 11y ago
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.
- Touche 11y ago
  Use case also matters. If you're delivering 1mb of javascript for your ecommerce website, that's too much.
  - onezeno 11y ago
    Right. But for a dashboard (what I use it for) that will rarely be closed or refreshed, the size is unimportant.
- nilved 11y ago
  A mobile network is basically sub-Saharan. 120 KB of JavaScript is far too much to download, decompress and evaluate on a phone.
  - onion2k 11y ago
    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.
    - rimantas 11y ago
      And many western users have a limited amount of data on their plans.
pc86 11y ago
So anything above 14K is unacceptable?
- rimantas 11y ago
  Yeah, I should have written 5-8 times, but MiniHack has some problem with editing comments.
- cwbrandsma 11y ago
  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.

emmanueloga_ 11y ago

* Ember 2.0.0: 424K, 110K gzipped * Fabrice Bellard's JS PC Emulator [1]: 148.4K, 36.8K gzipped 1: http://bellard.org/jslinux/ http://bellard.org/jslinux/