Readers' Questions - "What is the status of ember-engines?"

Learning Team
1

Welcome to the first answer of the Reader’s Questions section of The Ember.js Times!

Today we have a question asked by @villander in Issue #32:

What the status of ember-engines? The community needs some clarification on what work is required (if any) to push ember-engines towards a better condition or 1.0 release.

‐ @villander

Our answer comes from none other than @dgeb. Please read below and comment!

Engines have been labeled “experimental” since they were introduced to the Ember ecosystem a couple years ago. Despite this label, engines are used by a number of companies, including Chase and LinkedIn, in production sites with many thousands of users. It seems natural to want to declare them stable and move forward. However, to understand the status of engines and what’s blocking 1.0, it’s important to understand the different aspects of engines and how each integrates with Ember and its ecosystem.

First of all, the base classes that enable engines to work at all exist in Ember itself. The Engine and EngineInstance classes are extended by Application and ApplicationInstance respectively. They are fully integrated into every Ember app and should be considered as stable as Ember itself. Thus, this aspect of engines is not at 1.0, it’s almost at 3.0 :slight_smile:

The ember-engines addon is what’s typically used to engage with the engine-related classes in Ember to turn a regular Ember addon into an “engine”. The ember-engines addon has both build-time and run-time concerns, and each has its own API, configuration, and level of stability.

Most of the run-time aspects of engines have been spelled out and vetted thoroughly by the community in the Engines RFC. The APIs used to declare engine dependencies and engine routes, as well as usage in templates, are all implemented as described in the RFC and can be considered stable.

On the other hand, the aspects of ember-engines that are not as stable are the build-time concerns. There are some minor configuration API issues we’d like to improve, such as the lazyLoading flag on the engine (rather than also allowing control from its host). However, the main sticking point is that there are a huge number of overlapping concerns related to building engines and building applications, and major work is being planned by the CLI team on both. We’d like to offer lazy loading of Ember applications based on boundaries other than engines, such as routes. Ember’s upcoming module unification work will unlock a lot of these capabilities with its more deterministic layout. And when we redesign the APIs needed to unlock lazy loading throughout Ember, we don’t want to be limited by the experimental APIs arrived at just for engines.

So the choice to keep the “experimental” flag on engines is a bit nuanced and perhaps deserves an asterisk. I would say that engines have proven to be production ready and many of the APIs are fully stable. Hopefully we can shore up the build-time concerns in the coming year while unlocking new capabilities for all Ember applications. If you want to follow along and/or help out with this work, see the Packaging RFC and related issues for Ember CLI.

‐ @dgeb

This answer was published in Issue #33. Don’t forget to subscribe to the newsletter to get development news right in your inbox. You can also submit your own questions! You will find a link at the bottom of the newsletter.

See you in the next issue!

15 Likes
2

Thank you for writing this up @dgeb!

2 Likes
3

Thanks @dgeb and @locks ( as representative of “Ember.js times” )

It was great to have this answer. Now go work hard for the growth of embe-engines. I’m excited about what’s coming.

1 Like
4

Great writeup!

Would also be interesting to learn the status of the module unification work :slight_smile:

1 Like
5

I’ve heard there’s a little form you can submit questions to :wink:

1 Like
6

Thanks, much appreciated! :slight_smile:

7

Thanks @dgeb and @locks!

We have been considering splitting up our application into engines for a while now so that we could reduce the amount of data that needs to be initially downloaded and parsed (and for some reusability as well). The way we were going to approach it was mostly along route boundaries because that seemed to make the most sense for out application.

However, if there is a work in progress to allow this to be done automatically in the future without having to split up the application into Engines, that might obviously be a better route for us.

Would you recommend that we wait for the improvements to CLI based on the module unification or that we go ahead with Engines? We are not under time pressure to deploy a code splitting solution, but I think that we would like to have something working by the end of the year. More importantly though, we would like to go with a solution that will be supported and improved long term.

Thanks!

1 Like
8

Hi @mmiklo!

That’s a question that’s probably on a lot of other Ember developers’ minds.

I’d start by saying that engines can introduce a new level of modularity that isn’t present in a standalone application.

Engines are developed in a separate package, which could be in-repo, from applications and other engines. Any components that you want to share between packages will need to be split out into shared addons (which could also be in-repo).

Engines are isolated from their host at run-time as well. Each engine has its own container and run-time dependencies, such as services and routes, must be declared upfront.

The additional modularity that comes with engines can add a level of architectural rigor, but it can also feel like a lot of overhead. If this overhead sounds like more trouble than its worth and you’re not under time pressure to support code splitting, I’d recommend waiting a bit for a lighter-weight solution that will work within a standalone app. However, if there’s a portion of your app that feels quite distinct from the rest, such as an admin panel, it might be a good candidate for an engine regardless of what other options are available.

More importantly though, we would like to go with a solution that will be supported and improved long term.

I wouldn’t worry about this, as I expect that we’ll support both code splitting and engines long term.

Hope this helps!

1 Like
9

Thanks for such a thorough answer @dgeb, I really appreciate this! This definitely helps a lot!

2 Likes