CodingItWrong/ember-bundle-size.md Secret

## ember-bundle-size.md

      
    Raw
  

              ember-bundle-size.md
            
          
    One reason developers are hesitant to consider Ember is the perception that they think it's huge and bloated. Is that correct? I've heard core team members say that it's only around 100 KB, but when running the app it seemed larger to me. I wanted to see for myself.
Let's install ember-cli from master—we’ll need 3.4-beta or newer for an extra option for slimming Ember down:
$ npm install -g https://github.com/ember-cli/ember-cli.git
We'll also install a tool called broccoli-concat-analyser to investigate our bundle size. Broccoli is the build tool Ember uses. broccoli-concat is a Broccoli plugin that bundles multiple files together. And "analyser" is how British people spell "analyzer" ;-)
$ npm install -g broccoli-concat-analyser
Now let’s create a new Ember project:
$ ember new ember-bundle-size
An Ember project includes everything out of the box to run an Ember app, so we can go ahead and do a build to see how big it is.
Run an Ember build with a few extra options:
$ CONCAT_STATS=true ember build --environment production

CONCAT_STATS=true outputs statistics on the bundle that will allow us to analyze it.
—environment production specifies that this should be a production build (TODO what is the specific impact?)

When the build finishes you should see sizes for the different files created. It should be something like this, although your numbers may differ slightly:
Built project successfully. Stored in "dist/".
File sizes:
 - dist/assets/ember-bundle-size-d41d8cd98f00b204e9800998ecf8427e.css: 0 B
 - dist/assets/ember-bundle-size-e9e5eefbf060a5c028d536e0f88fa64b.js: 4.62 KB (1.33 KB gzipped)
 - dist/assets/vendor-d41d8cd98f00b204e9800998ecf8427e.css: 0 B
 - dist/assets/vendor-f1aa6e86bf44cbf85eb695fcd3018bf5.js: 720.72 KB (189.76 KB gzipped)

vendor.js is what we care about here because it’s where the library code lives. It's 720 KB ungzipped (whew!), 189 KB gzipped. Now let's see what's contributing to that size.
At the root of your project you should see a concat-stats-for folder. Run broccoli-concat-analyser ./concat-stats-for. When it finishes processing, it should give you a file:/// URL you can open in your browser.
IMAGE
This says:

My overall vendor.js file is 188.79 KB gzipped
119.02 KB of that is Ember
22.1 KB of that is jQuery
36.87 KB of that is ember-data

Let’s see if we can slim some of this down!
Removing Dependencies

One thing contributing to the size is Ember Data. You don't have to use Ember Data though; you can make basic fetch or axios requests, use ember-redux, or even use Firebase or Apollo. Because your data layer is so flexible, there’s no real way to compare it across frameworks, and you aren’t locked in—you can always change it. So for a more parallel comparison to React we should remove Ember Data and just count ember.js itself.
Removing Ember Data is easy; we can just run npm remove ember-data. Rerun the build and our gzipped size is only 157 KB. Rerun the analysis and we can confirm that Ember Data is no longer included.
IMAGE
The other big piece in the bundle is jQuery. When Ember was released in 2011 cross-browser compatibility was terrible, and jQuery handled a lot of those issues. But Ember has been updated to no longer depend on jQuery as of version 3.4, so it can be removed.
To do so, we need to set an Ember feature flag. Run ember feature:list and you can see that jquery-integration is enabled. To disable it, run ember feature:disable jquery-integration.
Now we can remove the jQuery module. Run npm remove @ember/jquery. Run the build again and our bundle size is only 128 KB. Run the analyzer and we can see that ember.js itself is the bulk of the size.
IMAGE
The Cost of 98 KB

Let's think about this bundle size. 128 KB is larger than other frontend view libraries; for example, React is 30 KB gzipped. That's a 98 KB difference, so React is 1/4 the size. That's a real savings, and if Ember doesn't provide you any benefits over React then it certainly makes sense to go with React.
But I would argue that Ember provides a lot of benefits over React. Addons mean you can spend less time writing plumbing and low-level code and more time building your app's features. Standardization means no Googling how to use two libraries together; there are plenty of resources. Stability means you will always have a no-rewrites upgrade path to take advantage of the latest web platform features.
If bundle size is the reason you choose React over Ember, you're giving up all of those benefits…to save 98 KB. And don't forget that your app's total code size is a lot larger than React's 30 KB. Say your app is only 500 KB total. Switching from Ember to React only saves you 20% of the size.
So the question is, how hard are you willing to work for 98 KB? How many hours per week of developer salaries are you willing to spend wiring up libraries yourself, rewriting code from scratch that already exists in Ember addons, upgrading dependencies and troubleshooting version incompatibilities, and training new developers on your custom framework consisting of a hand-picked combination of libraries?
For some applications, all that effort to save 98 KB is worth it. There is a measurable increase in business revenue when bundle size is decreased, because competition is so fierce. But I think the number of such applications is a lot fewer than we think.
If nothing else, we should stop thinking that Ember is a behemoth. Those of us who use it are trading away a whole class of expensive problems for 98 KB of code. That seems like a pretty amazing deal to me.