From two directions: 2019 Ember.js Roadmap

The Ember.js community is once again embarking on an open Roadmap process and I'm excited to participate this year. I'd like to focus on two very different needs I see in our ecosystem today:

1. Attracting new users to single page from classic apps.
2. Flushing out the addon story

From classic to single page apps

We should stop thinking about other single page application frameworks as our competition. The vast majority of applications on the web today are not built in javascript at all. Even if a team wants to make the transition from classic to single page applications there is no guidance and very little support for doing it. These are not "legacy" applications, they are actively maintained by excellent developers on forward thinking teams, but are forced to choose another JS framework because their onboarding story allows "sprinkling in" one component at a time.

A special section in the guides on integrating Ember.js into a classic app could help interested developers become comfortable with both the technical process and with the idea that the Ember.js community supported this use case.

Example Content:

1) How the Ember.js router will work within an existing app URL structure and ways development could be staged and put into production one route at a time.

2) What is the best loading experience for users when they are transitioning between the single page and classic app. What could be cached and how? Is there a way to pre-fetch ember resources or otherwise notify the browser that the SPA once parsed will be needed again very soon?

3) How to structure templates to duplicate the structure of the existing classic application to take advantage of existing styles and ensure a consistent user experience during a transition.

4) Advanced tools and techniques for large Ember.js apps to help migrators of fully formed classic applications make good early choices that are likely much different from a brand new single page application that would be expected to discover these options as the application grows to need them.

These changes to the guides would be largely symbolic, but as we gather converts we should pay special attention to the rough edged and try and smooth them out as much as possible. Maybe existing technologies and techniques can fill that roll, but if needed we should be ready to work with browsers and TC39 as advocates for new additions to the web platform to make hybrid and transitional applications a good experience for users and developers alike.

Making addons easier to build well

Addons are a huge part of what makes Ember.js amazing. They provide a single step installation path to some incredible functionality. From full featured accessible dropdowns to essential wrappers for handling asynchronous tasks there are ember addons for a huge range of problems, but I think the number and variety of addons blinds us to some of the significant difficulties developers face in their constructions and maintenance.

In 2019 I'd like to see a focus on documenting and encouraging community patterns for addon development

Configuration

Take a look at any three addons and you're likely to see four ways they are configured by the applications that consume them. Should global options be placed into the apps environment.js file? Or are they more appropriately found in the ember-cli-build.js file? Should it be both? Would an addon be better served creating it's own configuration standard like targets.js or ember-try.js? Maybe the right way is a global service that is overridden by the application to intercept and enhance configuration or options passed into a component at invocation time. All of these patterns are in usage in popular addons and probably a dozen more I'm forgetting or have never seen.

More guidance is needed for addon builders on the best way to provide overridable default configuration in a way that is easy for application developers to use and standard across the community.

Unexpected build situations

When new addons are generated they are provided with a "dummy app" for testing. This encourages addon authors to think of their usage in the narrowest terms. For most addons this might be enough, but as addons become popular they usually run into several problems.

1. Nested Installs

The issue I see hit newly popular addons the most is being included as a dependency of another addon or multiple levels of addons before being included in the app itself.

A search for findHost will turn up usage in hundreds of addons looking for a way to find their containing application. And yet _findHost is a private API.

2. Engines and Yarn Workspaces

Ember.js is an incredible tool for very large applications in very large organizations. These types of ambitious projects are often the first to reach for tools that make breaking up development into smaller teams and more manageable units easier. Two of these tools ember-engines and Yarn Workspaces often cause difficult to understand and resolve issues for addons.

What would help?

I think the addon blueprint needs to be changed substantially to surface these issues immediately and testably.

In the same way ember-try helps find, fix, and report issues with different ember versions we need a tool to encourage best practices in a variety of complicated installation scenarios before they become hard to understand bug reports. ember-cli-addon-tests may fill that roll, but would need to be part of the default blueprint to have a significant impact on this problem.

Dependency Management

Managing dependencies for javscript libraries is hard. It might not be any more difficult for addon authors to manage, but it is certainly not any easier. Addons come pre-installed with more than 20 dependencies upon generation and usually require more of their own. This raises two issues.

1. Blueprint Dependencies

What is the correct way to update dependencies that are part of the default blueprint? Should authors rely on ember-cli-update and wait until the blueprint is updated? Or should they allow a tool like dependabot to keep these blueprint dependencies up to date?

2. Addon Dependencies

What is the right way for addons to declare their own dependencies? Should they be included in the dependencies section of the addon's own package.json or should they be installed into the host app when the addon is installed? If they are installed in the host app how should the app be notified when a new version is required? If they are included in the addon's dependencies how should version conflicts be handled when other addons or the app itself required the same package? Maybe the best answer is to use ember-auto-import in which case it should be added to the default blueprint and surfaced in documentation.

What would help?

The only thing I can think of is to reduce or eliminate blueprint dependencies. Could addons which don't need any special versions of these dependencies rely on a single ember-cli-addon-dependencies package which provides them?

I'm hoping the upcoming changes in embroider will simplify some of the API for addon development, maybe we can change the dependency management story as well.

Ember-try more things

Testing against ember versions is only one part of the story for addons. I would like to see the default blueprint updated to include tests for active versions of ember-cli and (if needed) ember-data as well.

Conclusion

Whew, that is a big list and certainly more than we can accomplish in a year! I'd like to wrap it up with some thoughts:

These are hard problems I face as an Ember.js developer because the easy problems are mostly solved. I think 2018 was an amazing year for Ember.js and I have high hopes for 2019, 2020, and beyond. I think of Ember.js as so much more than the code in the framework, it is a community that believes in shared solutions and goals and I'm incredibly happy to be a part of it. Thanks for reading this far and thanks for being part of what makes Ember.js great!

If you've seen these problems, or even better know a solution you can find me at @jrjohnson_.