The EmberJS of the future... today!

Ember has some exciting features that take it from a "dated" framework that some may be more familiar with to an exciting, ergonomic, and fully featured frontend toolset for ultimate productivity.
If you've previously brushed off Ember as something not worth trying, check this post where I will demonstrate some of my personal favorite features that I'm using right now on emberclear.io.

NOTE: Some of these are somewhat bleeding edge, and not yet released officially. Each feature has a vigorous Q.A. process, and getting through all the backwards-compatibility scenarios and upgrade paths takes some time. So, the official guides will not have some of these features mentioned. The breakdown of what is production-ready / still in experimental phases is at the bottom of this post.

To stay as up to date as possible, please join the Ember Community Discord

Async Lifecycle Hooks

Here is a route-handler - demonstrating async lifecycle hooks that are disabled in a server-side rendering context via a decorator. One may want to do this because an app may interact with localStorage or indexeddb, which don't exist in a server-side context.

• beforeModel is a guard for access to the route. In emberclear.io, in order to chat, you must have your "account" set up.
• model is what fetches the data for the route. The data api supports graph-data – In the findAll invocation, I specify that for each message, I also want the sender. This helps reduce the number of requests to the backend.

Syntax for Components

Following in the footsteps of angular, react, and vue, Ember also has <AngleBracketInvocation /> of components, which allows your code to feel more natural and more readable – especially in comparison with the older (and sometimes hated) Handlebars syntax, where a template would be loaded up with {{ ... }} everywhere.

Now, the {{ ... }} are only used for non-HTML values, or in other words, dynamic / interpolated values.

• {{input ... }} is a helper which abstracts away some <input configuration as well as sets up 2-way data-binding.
• {{t ... }} is a helper which looks up an internationalization / i18n key for dynamic translations.
• @title is a notation that tells the component that the variable is intended for use as an argument to the component, rather than an HTML attribute to tag. For example, you can, in the FocusCard template, specify ...attributes and all HTML attributes specified on the <FocusCard ... /> invocation would pass through to the ...attributes usage. This is a big advantage over this.props in react, in my opinion. Being explicit with intend by default is so undervalued in javascript.
• lastly, {{action ...}} dictates what the button will do when clicked (the bound dom event can be customized, but is not shown here)

Testing

Ember applications come out of the box with an async-aware testing framework that uses real browsers. No jsdom or fake browsers to cause worry about weird compatibility issues between your tests and reality. The tests ARE reality.

By default, Ember ships with QUnit, but mocha and chai are also widely supported as an alternative if you have your heart set on a particular set of testing tools.

Dependency Injection is a Must

In my opinion, a dependency injection container makes all the difference in the completeness of a framework. By default, Ember comes with dependency injection. No need to wire up all your dependencies. No need to import everything. No need to worry about how many instances of a class you have, since services singletons.

The Ember dependency injection container boosts productivity by helping manage application-level state without any glue code whatsoever.

Keyboard Accessibility

Want to add keyboard accessibility to your app? The Ember addon ember-keyboard makes it easy by providing a set of utilities that allows you to do common keyboard-accessible tasks like toggle modals.

The component in the example screenshot is powered by this template-less component: KeyboardPress.

Summary

At the time of writing this, some of the features are available for testing and experimental use by early adopters.

---

But, you can experiment with the following today:

• decorators (and even custom decorators)
• Module Unification Layout

These are production ready in any app today:

• TypeScript
• <AngleBracketInvocation />
• server-side-rendering
• service workers
• async/await in tests

Even though each of these features may not yet officially be supported, there are still a good number of people trying things out and using these addons and features in production. So, if you're willing to spend some of the extra time to have the bleeding edge, it's worth it ;)

Note: If you want to look even more into the future: Ember Octane

---

A little about me – on twitter, I'm @NullVoxPopuli, and I love programming and the abstractions that people are coming up with to make development more productive and more fun. I have 2.5 years of professional experience with react, and 4 years of casual / hobby experience with Ember. I like them both. And I prefer to use each for specific purposes. I think Ember fits more of the "fully-featured app" purpose than react does – though, technically, react and its supporting ecosystem can solve all the same problems Ember does. With Ember, it's really nice to not have to figure out all the glue code between all the libraries like in the react ecosystem. "Productivity through Constraint" is my motto when it comes to frameworks.