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

@locks wrote:

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

Today we have a question asked by Michael 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.

-Michael 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

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

Posts: 2

Participants: 2

Read full topic