I've been a huge fan of ember's progress over the past year and a half, and while I've been riding the canary release train the entire time, enjoying (testing/debugging) features before everyone else does, it's relieving to finally see so many of the features that bring ember into the current state of javascript finally landing. Some may doubt this, but I've been holding back on promoting ember because I believe in the vision of the future (which is nearly now), the vision of Octane, where ember is just a thin layer on top of native javascript -- which is immensely important to reducing the learning curve and improving adoptability and searchability.

This post is inspired by the call for blog posts to determine the Ember 2019 roadmap (and the one from last year) -- while, over the past years I have not worked with ember professionally, I've enjoyed being involved in the community and being involved with the framework as whole as a hobby, there is no greater feeling than taking long breaks from a side project, and knowing exactly where you left off without any catchup/recall cost (I know this is hyperbole.. shhh). However, as I've been trying to stay up to date with the other ecosystems, mainly React, as that's been what I've professionally been doing the past almost three years, I've made note of things that are high on the hype train that I think will allow for ember's adoption to soar.

Octane

This is the edition that was started as a result of last years community blogging efforts. Ember, over the years, and especially with Module Unification, has kind of had a reputation for over-promising and under-delivering -- so it would be totally stellar to see this released soon. As far as I'm aware, there is only one major feature flag still on canary that has yet to make it to enabled by default, EMBER_METAL_TRACKED_PROPERTIES. Then the only remaining things are documentation. Which, I'll be helping with at the end of May as I'll be between jobs for a couple weeks. Exciting!

Website Redesign

The Website Redesign RFC was merged at the beginning of April of this year. It looks amazing! With the upcoming Octane changes, and entire paradigm shift in how ember is to be developed, implementing the redesign shortly after the release of Octane would be amazing. I mean, look at these pictures. (I'm very excited about this, but I have no idea on progress or timeline). With ember becoming more and more modern as time progresses, it's time we get the site up to date as well. It could hurt ember's growth otherwise.

Project Structure

Module Unification was originally planned to ship with Octane but as people were playing with it, it become clear that it was uncovering more questions about ergonomics than answers. Most notably (that I dealt with anyway) are local-lookup rules for tests, helpers, modifiers, everything. With the current state of Module Unification there are a lot of implicit rules that the developer needs to know about in order to use it effectively. Through bugging a bunch of people on the ember discord early on in 2018, I learned all the tips and tricks when implementing emberclear (source) -- but expecting everyone, especially those not comfortable with ember to begin with, to learn all that is asking too much.

There are a couple new~ish RFCs to help with part of this problem, SFC & Template Import Primitives and Component Templates Co-location. The SFC and Template Import Primitives one will allow addon authors to experiment with different project structures, as components could be imported from wherever, eliminating the need to memorize implicit local lookup rules and building on existing knowledge in how JavaScript module imports work. This RFC would also allow for Single-File Components which would be super handy for little things like buttons, links, etc. The Component Template Co-Location RFC will bring pods-like co-location of component and template files to the classic layout, which will be a huge improvement to project-browseability. I'm violently against the classic layout, so this would be a very welcomed change.

Query Params

Query Params are something that everyone agrees needs to be better. ember-parachute has taken a stab at making query params better. I've submitted an RFC and implemented a prototype addon that uses decorators to totally abstract away the boilerplate atd awkward APIs that the query params documentation currently instructs us to use -- bringing query param usage up to date with the rest of the modern world.

All I want is something like this:

import Route from '@ember/routing/route';
import { queryParam } from 'ember-query-params-service';

export default class ApplicationRoute extends Route {
  @queryParam('r') isSpeakerNotes;
  @queryParams('slide') slideNumber;

  model() {
    return {
      isSpeakerNotes: this.isSpeakerNotes,
      slideNumber: this.slideNumber
    }
  }
}

where the @queryParam decorator can be used anywhere -- components, routes, etc.

Better Error and Loading state handling

According to the routing guides on error and loading substates, for both errors and loading state, we need a template in various locations depending on our route structure and, for loading, which routes we think are slow enough to warrant a loading indicator (whether that be a spinner, or fake cards or other elements on the page). Additionally, there is a loading action fired per route that can optionally be customized in order to set parameters on the route's controller. I think this is needlessly complicated, and we can do better.

Maybe something we could do to make things less configuration-based and also be more explicit is to set properties on routes.

import Route from '@ember/routing/route';
import ErrorComponent from 'my-app/components/error-handler';
import LoadingComponent from 'my-app/components/loading-spinner';

export default class MyRoute extends Route {
  onError = ErrorComponent;
  onLoading = LoadingComponent;

  async model() {
    const myData = await this.store.findAll('slow-data');

    return { myData };
  }
}

This is just spit-balling here, but setting components to use as the error and loading state render contexts allows us to more intuitively tie in to the dependency injection system as well as have very clear shared resources for this common things. The actions that are called on error and loading could still exist, as those may be useful for maybe redirecting to different places in case of a 401 Unauthorized / 403 Forbidden error, but the main thing that I want, specifically for error states is that for any error that occurs within a route's subtree, the onError component should be rendered. This would catch errors that currently break the UI entirely, or are only printed to the console. Not only should network errors that occurs within the beforeModel, model, and afterModel hooks, but also during rendering. With component centric development, errors can happen anywhere, and it would be fantastic to have a centralized placed to handle those errors.

This is somewhat inspired by some React work I've done recently, where instead of directly using the react-router Routes, I wrapped them in an ErrorBoundary, which does exactly as I describe above. Any error that occurs, whether during rendering or otherwise is caught be the ErrorBoundary, and then an error-parsing component is rendered that can display the error in a meaningful way to the whomever is looking at the screen -- all without having to have the console open. It's great for that added insight into what's going on when the UI doesn't have as expected.

Route Splitting & Svelte Builds

In a world where most online devices are low-powered pocket-computers, to reach the broadest possible audience, it's important now, more than ever, that we pay attention to how our apps are shipped to each device. embroider is kinda beta~ish atm and enables route-splitting. I've done route-splitting in React, and other webpack-using projects… and it feels very manual. With ember I expect things to just work without having to configure things, and as I read the embroider readme right now, there is a splitAtRoutes option to enable, to make things "just work", no need to await import('file'), no need to come up with a loading scheme for your router to wait for the route subtree to load -- embroider does that all for you, which is super exciting! (Seriously, I can't express how excited I am for embroider to become the main build system for ember apps -- I've been in the React community so long, and hearing everyone make an excessive big deal over tiny apps needing route splitting and then watching all the hoops they have to jump through to implement it is exhausting… it's so relieving to to see a proper implementation). I would like to see embroider as a default sooner, rather than later, especially as Octane brings in a new wave of fresh blood, people are going to be wondering where the features are that embroider provides.

Additionally, along the same lines of shrinking bundle size, Svelte builds are to strip out unused features in ember. I don't know if this work has started, and I'm still a little fuzzy on the details, but it seems like for the crowd that are targeting PWAs and very low powered devices, where JS parse time is a serious issue, this would be a huge improvement -- for everyone.

Data

The changes I want to see in the data space may not exactly be ember-data related, but I know that there is a bunch of incremental progress to make the ember-data experience both more flexible and more friendly. The biggest things I want to see from data as a whole is for the { json:api } Operations Spec to land, so that we can have worry-free implementations. Operations is really exciting to me, because it brings parity to GraphQL while still having strong semantic correctness with relational data. Operations allow for easier websocket implementations while still using the { json:api } format -- and maybe more importantly, allows for sanctioned bulk behavior without hacks. Operations, generally, can be used today, but not with ember-data -- I'm very excited with the direction ember-data has been going lately, and I'll be even more excited as operations start to solidify.

Those are my main focuses this year, and I'll probably try to find a way to help progress each of them, as I'll actually be working with ember for the better half of this year. I'm very excited about all of this, and want it all now. :)