We’d like to migrate Discourse’s asset pipeline over to use EmberCLI. EmberCLI is the standard way to develop Ember applications and Discourse’s approach has long been a source of confusion for people approaching our project with an Ember.js background.
async/await are very hard to integrate into our current system.
In the next major version of Discourse (2.5) we plan on migrating over to EmberCLI. This is going to take quite a while to do, so we will do our best to keep two versions of our front end application working. Adventurous people should be able to opt-in to EmberCLI and others can continue to use the application “as is,” until we reach a point where we feel things are stable.
- importing everything from the same paths
- using different extensions for raw handlebars / ember handlebars
- getting rid of computed property deprecations
- changing to ember’s
Locationmodule from our custom module
Boot Discourse via EmberCLI: This will likely involve finding new issues as things in (1) are fixed and repeating the same approach.
Integrating Theme Components and Plugins: We’ll need to do some investigation here to integrate existing extensions to Discourse as seamlessly as possible.
Identify any performance (or other) bottlenecks: it should be as fast as our current system, or faster.
Come up with a timeline to switch over: it’ll need to be generous so people have a long time to beta the feature and provide feedback.
When we’re fully migrated over, a lot of stuff that is currently broken or hard to do like source maps and
async/await should just work.
Additionally, for some developers who only want to work on the front end parts of Discourse, we might be able to set things up so that they can only run EmberCLI pointed at a server like try.discourse.org to hack on the front end application without having to run an entire Ruby/Rails server with Redis/Postgres.
This is going to be a big project but in the end our application will be much better for it!