[dstaley]

One of the things I really wish Ember would focus on is reducing the amount of JavaScript shipped to the browser. I just tried out the included project with ember-cli, and the default JavaScript bundle is 2.7 MB (591 KB gzipped)[1] for an app that doesn't have any functionality. I know that you get a lot with that 591 KB (Ember's router, the Glimmer VM, etc.), but it's still much more than what you can get your React app down too, especially on initial load. For comparison, my _entire_ React application (which includes emotion, react-router, and a full data synchronization library) is only 356 KB (104 KB gzipped). Don't get me wrong: there's certainly applications where the size of the JavaScript doesn't matter, and I think Ember is _great_ for those use-cases. I just wish it could be used for smaller, mobile-focused applications without being several times larger than an equivalent React app.

[1] Apparently this is the development size. The production size is 712.29 KB (180.80 KB gzipped). My point still stands though.

[wycats]

You're not alone! The Ember core team broadly agrees with this goal.

With Octane, we focused on landing broad ergonomic improvements in a compatible release of Ember.

At the same time, we've been working on updating the way that Ember builds JavaScript so that it can make better use of tree shaking and code splitting tools in modern bundlers. That project is called Embroider[1] and it currently builds substantial Ember codebases.

Wrapping up Embroider and shipping it by default is a substantial part of the work we have planned for 2020[2].

Also, now that Octane idioms fully replace the need for Ember's original object model (designed in 2012!), I would expect it to become an optional feature, meant to be used primarily as a transition path. When combined with tree shaking, that should substantially change the default byte size of Ember.

It's too early to say exactly how that will shake out (no pun intended), but it's a big priority for the Ember community next year.

[1]: https://github.com/embroider-build/embroider

[2]: https://github.com/emberjs/rfcs/blob/2018-2019-roadmap/text/...

[pzuraq]

This is actually going to be my next project, now that we’ve shipped Octane there’s a lot of code that we can slowly start to move away from! The plan is to move toward optional features and then deprecations for many of the classic features, allowing Octane users to opt-in to the benefits progressively, while still supporting Classic users for some time as they transition.

Definitely curious how you got these numbers though. Our current estimate of Ember’s size is ~160kb after min/gzip, and Ember Data (the only other large library installed by default) should be less than that. Jquery should not be included by default anymore, which would be a large chunk. Were you building a production build? `ember build —env=production`? That will cut out a significant chunk of debug code and assertions that are only used for development builds as well.

[dstaley]

Sorry, I was apparently producing a development build. I'm used to create-react-app, which eliminates this exact scenario by always building in production mode, so that people can't accidentally ship a development build to production.

[gavinjoyce]

The idiomatic way of shipping an ember app is with ember-cli-deploy [1] which, among other things, will ensure that it ships a production build.

[1] https://github.com/ember-cli-deploy/ember-cli-deploy

[gavinjoyce]

Perhaps you're measuring a development build?

I just tried a new ember 3.15 app production build, the JS payload comes in at 712.29 KB (180.80 KB gzipped)

`ember new myapp && cd myapp && ember build --environment='production' && ls -la dist/assets`

[dstaley]

Ah yes, I didn't realize "ember build" produced a development build. For comparison, create-react-app always builds in production mode to eliminate this exact scenario!

[wycats]

I think that's probably a good change to the default. Today, `ember build` is analogous to `ember s`, and most people deploy to production with `ember-cli-deploy`.

But that's not a good enough reason :)

Thanks for surfacing this!

[nullvoxpopuli]

I share your concerns.

fwiw, here is a small-medium sized app's bundle: https://emberclear.io/bundle.html (ignore the fact that ember is in that report twice, that's a problem with my analysis, and not the actual bundle)

Over the next year, the framework team is focusing _hard_ on reducing bundle size. Including: stripping deprecated features (which will be huge... at least 20kb (min+gzip), iirc)

[pier25]

My current Mithril app weights 30kb gzipped. That includes a router and an http client (both included in Mithril).

[nullvoxpopuli]

what does it do?

[pier25]

Not much, it’s a library of assets for a marketing department, but it’s certainly not a hello world.

[nullvoxpopuli]

yeah, ember (today) doesn't fit the small project space (it's more geared towards medium to large+ projects).

That IS a goal for the next edition (octane being the first edition). Def need better small / toy project support.

[Touche]

Just for anyone reading, 100kb is the max you want for initial load if targeting mode. This means that Ember is a bad choice for most web apps today. React isn't a great choice either because the lack of features and relative large size means you have to add more stuff and quickly get large builds.

[nullvoxpopuli]

100kb is an ideal right now. Many apps will have more than that in just CSS.

[Touche]

100kb is the max amount of JavaScript. There's a number for all resources but I don't know what it is offhand.

Using more than 100kb of CSS is a red flag and probably means you are using a framework like Bootstrap and not just importing the parts you need.