Ember's min+gzip distribution size grows continuously (1.5 KB / month)

[joliss]

Ember is 54 KB min+gzip right now. I don't think that's unacceptably large, and it's certainly no blocker for 1.0.

But last year around this time (d1fd4ec850b0b32f21a51068a56c318478bf6632), it was 34 KB.

So I went sleuthing and plotted how the min+gzip size developed over time: https://gist.github.com/joliss/5570851 (script)

It looks like there was no single commit that caused a jump in Ember's file size; rather, we've had a "death by a thousand paper cuts". Ember seems to be continuously growing at a rate of around 1.5 KB per month.

I guess there are a bunch of approaches to deal with this:

• Is there anything we can remove or slim down?
• Is there anything we can extract into an optional library?
• Should we try to slow the continuous growth a bit? (How?)

Slowing the continuous growth is probably trickiest problem, since we don't want to stall development either. jQuery seems to be very aggressive about file size (perhaps more than we should be), but maybe we can still learn from them?

[tchak]

We could move ember-states to ember-data package, as it is only used there now.

[tchak]

And currently we ship ember-testing in prod builds. Seems bad.

[gilesbowkett]

total newb here, but there's also a package called ember-old-router. name like that stands out as potentially delete-able.

[stefanpenner]

I wouldn't be terribly worried about this growth, that being said we should be aware that it is something we should keep in mind. One thing we would benefit from is a system of distributing packages, this should help prevent the kitchen-sink effect.

@tchak shipping ember testing in prod builds does seem bad. I also think the state_manager is a very important part of ember, that being said I think now that new router does not use it, it can likely get a substantial refactoring.

@gilesbowkett old-router needs a custom build to be adding to the prod build.

[joliss]

One thing we would benefit from is a system of distributing packages

This just in: I'm working on a browser compilation library (broccoli) written in Node. (Like I said at EmberCamp I would -- finally. ^_^) Asset compilation is kind of orthogonal to package distribution, but I think it needs solving before distributing makes sense. We can then distribute compilable packages on top of npm, or whatever we want.

Broccoli is mostly vapor-ware right now, but the first usable alpha should be out in two or three weeks; maybe another month or two till it is good enough to actually build stuff with it. It will definitely take another few months though to get it stable and mature enough to rely on it for distribution (as opposed to just "a private build tool").

</unwarranted-hype> ;-)

[trek]

+1 for moving ember-states to ember-data or just as a stand-alone package. Many people use it, but nothing in core requires it and most of functionality it was used for is duplicated in the new router.

The main things that seem to be the root case of the growth size:

• additional functionality added to the framework
• additional functionality added that not every app will need
• edge-case and bug fixing
• integration code required to make Ember work with newly extracted microlibs
• performance improvements (which sometimes comes with a size tradeoff)

Of the above, some we can address, some are harder:

• additional functionality added to the framework We already have custom builds that exclude some of the more user-facing APIs. Ember just does more than it did a year ago and I don't think anyone wants to trade the router or better array proxy behavior to shave 10kb.

• additional functionality added that not every app will need @visionmedia pinged some of us on twitter about using https://github.com/component/component with Ember. A more separated Ember would allow people to build only with the parts they need but the only parts I can think of as extractable are

  • the various form element views and their associated handlebars convenience helpers that are part of the ember-handlebars package.
  • possibly some existing CP macros (or new ones like @jamesarosen suggests in #2645 could be added without increasing everyone's build size)
  • mixins that are useful but not used internally (can't think of any off-hand, but we should look)
  • a router-less build for people who don't like the router's mandated application structure

  For the most part though more surface facing APIs rely on lower level APIs and there's very little (kb-wise) provided the framework that isn't used internally.

• edge-case and bug fixing / performance improvements Not much can be done here. We're not a library so can't punt on this stuff, leaving it to each developer, to save size.
• integration code required to make Ember with with newly extracted microlibs I think extracting smaller libs is an excellent forcing function for better modular design in the framework, but the library + integration code end up being slightly larger than when the functionality was embedded. Added all up and they contribute a few kb. That said, the amount of flack we got for being "a monolith" (even when it wasn't really true) was sufficient that I don't think anyone would argue we should back off of the microlib strategy.

@gilesbowkett the main ember build doesn't include ember-old-router, there's a special build for people who need it.

[trek]

All that said, I think we're at an inflection point where we'll soon want to start adding functionality useful to a large, non-majority number of people that doesn't need to be in core. A build system (component-, grunt-, broccoli-, whatever-based) would allow us to provide these as "official" additions. They can be optional but part of our test and support structure.

Most importantly it would allow people to build and share higher-order plugins without recreating functionality. I'd hate for total app size to bloat because an authentication plugin, a file upload plugin, and a pagination plugin all have to recreate similar CP macros when they could be sharing.

The lack of easy ways to do this is probably my biggest frustration with the browser ecosystem.

[jamesarosen]

I vote for not putting Ember-States inside Ember-Data since we have strong use cases for it, but don't use Ember-Data. I have no strong feelings on keeping inside Ember or extracting it to its own add-on.

I'm happy to do Ember-CPMacros as an add-on. It's pretty small, so it might make a good experiment.

[stefanpenner]

i agree with @jamesarosen ember-states should stay in ember, we can re-evaluate this once a great package management solution is put in place.

[krisselden]

ember-states can be simplified if old router is dropped

[trek]

once a great package management solution is put in place.

Yes. From our moon-based homes. I'll fly up on my space-car.

[stefanpenner]

@trek <3

[stefanpenner]

So i am unsure if there is a metric by which this issue can be closed, can we transition this discussion to discourse? Should we close the issue and keep the discussion open? Should we keep the issue open forever?

[joliss]

I'm assuming all interested parties have seen it by now, so closing it sounds fine. Feel free to re-open if anybody wants to use this issue for tracking or whatever. (Discussion either here or on Discourse sounds fine; if on Discourse, leave a link please.)

[stefanpenner]

@joliss thanks for bringing this to attention, we totally don't want to explode in size. We should be cautious.