Ember.js in 2018 — Let’s market the future

In my article for the ‘Ember.js in 2018’ call for blog posts, I explore the effect of the framework’s imminent, large-scale changes on developer experience & discuss Ember’s interim marketing strategy.

Ask any developer why they love Ember.js and the word “stability” is usually one of the first terms used to describe the framework.

I’ve been working with Ember.js since late 2013. I’ve stuck with it because I strongly identify with two of its core tenets:

• Convention over configuration
• Stability without stagnation

These ideals have guided Ember’s development well through the years and have produced a fantastically productive developer experience (DX).

However, there’s a nagging problem with the current state of Ember for those who have bought deeply into Ember’s conventions:

In the next 12 months, the framework is set to change beyond recognition.

One would argue this is a positive & exciting problem to have. Of course it is.

By 2019, I have no doubt our framework will have been virtually reborn, offering a new & improved developer experience for those who already appreciate Ember, whilst also being capable of compelling React/Angular/Vue developers to dip their toes into the Ember ecosystem.

However, for those existing Ember developers, there’s a long road of instability ahead.

More than any other framework, Ember has to be sensitive to DX changes due to its convention-heavy approach. By nature, our community values stability and Ember sells itself on it. The looming spectre of large conceptual changes in how we interact with the framework is deeply unsettling. These uncertainties affect how we build our apps in the present day and lower our confidence in the long-term value of the code we’re writing.

It’s arguable that every major area of the framework will change beyond recognition in the next year:

Syntax: ES6 Classes

The biggest DX change of the lot, the adoption of ES6 classes will turn the entire syntax of the framework upside down. Altering the whole mental model of how to define resources, new concepts will need to be taught to the developer — decorators (and how to access them), tracked properties and class inheritance (with or without mixins?) to just to name a few.

Filesystem: Module Unification

In addition to an entirely new syntax for resources, a developer’s understanding of where to place files is to change. Module unification will allow co-location of related files and is generally accepted to be a superior method of structuring applications. Due to the large differences in the two layouts, there will likely be a disorienting period where developers need to get used to traversing both ‘legacy’ codebases and the ones with the new module unification.

Templating: Angle bracket components

Angle bracket (Glimmer) components will introduce an entirely new method for invoking components, with closer syntax to standard HTML/web components. There’s also a shift to defining passed properties to components as @props, which will be an additional concept for developers to train themselves.

Route State: The controller saga

It’s an issue that has lingered for far too long — do we or don’t we use controllers? I’ve long since restricted my controller logic to the manipulation of query params via Ember Parachute. Hopefully, a resolution to the controller question will be made in the next year, which will have an affect on how we handle long-lived route state & query parameters in both components and routes.

Styling: CSS Blocks

Tight integration between Ember CLI and CSS Blocks is likely to occur in the next year. Whilst I’m sure CSS Blocks will land as an addon and not as required knowledge, most developers will want the boon of writing scoped styles, with svelte stylesheet bundles. CSS Blocks is a large conceptual change for defining and structuring styles, which will require a lot of learning.

Language: Typescript support

Whilst Ember will always be a JavaScript-first framework, Typescript adoption amongst the JavaScript community is rapidly increasing and support for typed Ember apps is getting to the stage where Typescript may become the dominant language for apps and addons.

Modules: NPM installing

One downside of Ember is the difficulty of including packages without writing shims or having to ingratiate yourself with the finer details of the largely undocumented Broccoli.js library. Work is ongoing to just make npm install work, but there will most likely be new configuration to learn for fine tuning module imports — such as configuring imports for Fastboot vs browser builds.

Performance Decisions: Engines? Code splitting?

Most Ember apps currently suffer from bundling everything into monolith app.js & vendor.js payloads. Code splitting along route boundaries is being explored to solve this problem, which may require some learned configuration. In the interim before code splitting lands, Ember Engines can achieve lazily loading of parts of an Ember app. Hopefully, Engines will reach a stable 1.0 with better documentation and become an awesome weapon in an Ember developer’s arsenal.

Addons: Updates galore

With all the changes to the Ember ecosystem particularly surrounding syntax, file structure and templating, addons will have to keep-pace. Just one poorly maintained addon can cause friction and delays in updating existing applications.

Considering all the changes listed above, it’s indisputable that Ember today will differ greatly to the Ember of tomorrow.

Therefore, it’s a fair question to ask whether Ember can actually offer any semblance of ‘stability’ throughout all these convention changes and whether the community should at all be trying to market & teach the framework in its current state.

A totally juxtaposed situation — I am incredibly productive with the existing framework and have very few complaints about the developer experience. But at the moment it’s very difficult to recommend Ember to a fellow developer who has absolutely no past experience with it.

When questioned about Ember, I’m constantly repeating the words “Ember’s got plans for that, the new <enter-feature-here> is landing soon”.

Having been through the process myself, I’m acutely aware a new developer would have to go through all the current rigours of Ember’s steep learning curve — then in a year’s time, retune most of their newly found expertise. This shift may be quite difficult to achieve without the depth of knowledge and experience that comes with working with Ember for many years.

It almost feels like the current state of Ember is not particularly marketable.

There’s a clear conflict between selling ‘stability’ to a developer as one of the main draws of the framework, whilst simultaneously acknowledging the whole developer experience will differ vastly just shortly down the line.

Which is why, I’d be tempted to begin to market the near-future ‘dream’ of Ember, ahead of time.

Outside of our Ember community echo chamber, there’s a belief that Ember is dying. That perception needs to change — fast.

So why not seize the moment and build a slick marketing site specifically for the ‘experience’ of Ember we know will knock the socks off the wider developer community?

Ember could be drumming up interest ahead of time for a coordinated marketing launch, packaged beautifully with a bold, new style so the community can hype and amplify where the framework is going.

ES6 syntax, the new file layout, new templating etc. — the new features will land in 3.x releases as non-breaking changes, but let’s prepare to show off the sum of all those amazing parts. Sell the vision, right now!

A ‘relaunch’ of Ember in the minds of those who dismiss it.

Because at the moment, only hardcore Emberistas know what’s in store.

Sure, references can be found in core team blog posts here and there about the new features. But that’s not particularly accessible for the wider developer community.

In similar terms, the Ember Statusboard is great, but it’s a reference, not a marketing tool. We need something that pulls everything together and proclaims “Ember isn’t dying, it’s actually got awesome stuff ready to land…very soon!”

A change of perceptions is what’s required and marketing the Ember ‘2019 vision’ ahead-of-time may even onboard more ambitious developers who can help us achieve it.

Ember 4, perhaps?

The problem with the current system of using major semver releases as deprecation busters is that it’s not particularly exciting to read about on HackerNews or Reddit. People expect a major release to be of major interest.

If the goal is to expand the Ember community and capture market share from React/Angular/Vue, then attaining maximum interest is key.

I say, let’s go grab it.

To conclude, I love Ember. Thank you to everybody involved. I do feel as if I’m standing on the shoulders of giants when I solve difficult problems with such elegant solutions.

I can’t wait for all of the things I’ve detailed to land and I’m excited to see the wider developer community’s reaction to what Ember can and will offer.