Moduliarzing Ember.js while keeping sane defaults

These are some thoughts I had about Ember.js' future and potential areas to focus on. I did miss the #EmberJS2019 (by quite a lot) but I still though this might be worth sharing.

In the EmberConf 2017 keynote, Tom and Yehuda announced Glimmer.js and the idea of starting apps with Glimmer.js and then allowing people to install their way up to full Ember.js package by package. I've always been a huge fan of the idea (we even built and open-sourced a showcase PWA with Glimmer.js and our own website simplabs.com is a Glimmer.js app as well) but it never really took off.

I think it's time to go back to this idea and make it a reality. Providing a slimmer subset of Ember.js would open it up for many more use-cases that are not currently great fits (obviously mobile apps with hard requirements on minimal bundle size come to mind here among others). It doesn't really matter how this is done - with the original idea of starting with Glimmer.js or the other way round, starting with the full Ember.js and then slimming that down by removing packages not needed for a particular project. The point is I don't think tree shaking etc. can get us where we need to be - only explicitly opting in to or out of particular features you want/don't want for an app, actually allow to remove all of the associated weight.

And this could also be only the first step - if it's possible to opt out of particular parts of Ember.js, we could also allow replacing these parts with other packages that are better fits for a particular project. Some of Ember.js' main selling points have always been for users not having to choose packages for particular features needed for their project and then not having to write glue code that connects these hand-picked components. I believe we could still prevent people from having to write the glue code and still let them hand-pick packages for particular parts of functionality though. If we can decouple the core of Ember.js from things like the router, the component layer etc. and define clear specifications for what Ember expects from these additional building blocks, it'd be possible to use a custom router, a custom component layer etc. and still benefit from Ember's promise of everything working together instantly without any custom glue code. The custom router or component layer implementation just has to adhere to the respective specifications Ember.js defines for these building blocks. That would enable you to have different routers that all work well with Ember - you could have one that supports loading and error states, hooks etc. as the current one does and then another one that doesn't have any of these features (and thus not the added weight and complexity) and works well for mostly static pages where you simply want to render a differnt template when the URL changes.

This could be very similar to one of the main ideas behind Rails 3 (one of the main driving forces behind which was Yehuda Katz if you're not familiar with Rails' history - some more info here) which also aimed for decoupling the core of Rails from specific individual components and letting users plug their own libraries of choice instead (e.g. you can use Rails with ActiveRecord but also with Sequel among others, you can use MiniTest or RSpec etc.).

And to be clear, I don't think this means giving up on the idea of batteries included which for the majority of users and projects is still a hugely benefitial concept. Instead, it'd be opening up the framework for scenarios where users absolutely want to provide their own set of batteries for particular parts of the overall system by formulating the requirement Ember.js has for those batteries so they can fit in to the system seamlessly. Ember.js should still ship with a set of standard batteries that are a great fit for many/most projects but I don't think we need to force this exact set of batteries on everyone interested in using the framework.

The benefits of this would be huge I think:

• allowing opting out of particular parts of Ember.js would enable using it in projects where its weight is currently preventing adoption
• letting people opt out of or choose their own packages for individual aspects of their system if they absolutely want or have to while still making sure their projects benefit from Ember.js' stability guarantees and letting them benefit from advancements in Ember.js' core and the standard packages they decided to use
• the previous leads to another advantage which I think would be crucial for wider adoption: if Ember.js itself is pluggable we don't have to convince everyone about every aspect of Ember.js to convince them at all - if someone agrees with everything in Ember.js but for some reason they absolutely want to use JSX, they can simply replace the rendering layer

Parts of this already exist - e.g. the new JavaScript modules API introduced with 2.16, component manager API that allows for using custom components etc. I think now is a great time to bring all of these together and leverage them to provide a pluggable and flexible system that would eventually make wider adoption a much easier achievable goal.