The EmberJS of the future... today!
Tags: javascript, ember, typescript, decorators
Published: 2018-09-18 19:15:48

---
title: The EmberJS of the future... today!
published: true
description: A look at some upcoming features you can start playing with today.
tags: javascript, emberjs, typescript, decorators
---

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](https://discordapp.com/invite/zT3asNS)


### [Async Lifecycle Hooks](https://gitlab.com/NullVoxPopuli/emberclear/blob/master/packages/frontend/src/ui/routes/chat/route.ts)

![Ember route demonstrating server-side rendering gates as well as [decorators](http://ember-decorators.github.io/ember-decorators/latest/), and async-aware lifecycle hooks](https://thepracticaldev.s3.amazonaws.com/i/1oiicra01ryslttayncw.png)


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](https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage) or [indexeddb](https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API), which don't exist in a server-side context. 

 - `beforeModel` is a guard for access to the route. In [emberclear.io](https://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.


### [<Angle Bracket /> Syntax for Components](https://gitlab.com/NullVoxPopuli/emberclear/blob/master/packages/frontend/src/ui/routes/login/template.hbs)

![Template for the login route demonstrating component invocation using Angle Brackets](https://pbs.twimg.com/media/DmDpD52U8AArQgP.jpg)

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](https://handlebarsjs.com/) 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](https://www.youtube.com/watch?v=G9hXjjHFJVs) can be customized, but is not shown here)

### [Testing](https://gitlab.com/NullVoxPopuli/emberclear/blob/master/packages/frontend/src/ui/routes/settings/acceptance-test.ts)

![Testing comes for free out of the box with ember](https://pbs.twimg.com/media/DmDp4uQUUAEyK31.jpg)

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](https://gitlab.com/NullVoxPopuli/emberclear/blob/master/packages/frontend/src/ui/components/current-chat-name/component.ts)

![Example dependency injection service consumption within a component](https://pbs.twimg.com/media/DmDquC-V4AAbLbi.jpg)

In my opinion, a dependency injection container makes _all_ the difference in the completeness of a framework. By default, [Ember comes with dependency injection](https://guides.emberjs.com/release/applications/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](https://en.wikipedia.org/wiki/Singleton_pattern).

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

### [Keyboard Accessibility](https://gitlab.com/NullVoxPopuli/emberclear/blob/master/packages/frontend/src/ui/routes/application/template.hbs)

![Declarative Keyboard shortcuts](https://pbs.twimg.com/media/DmDsqFaUwAAWNWI.jpg)

Want to add keyboard accessibility to your app? The Ember addon [ember-keyboard](https://github.com/patience-tema-baron/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](https://gitlab.com/NullVoxPopuli/emberclear/blob/master/packages/frontend/src/ui/components/keyboard-press/component.ts).





### 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](http://ember-decorators.github.io/ember-decorators/latest/) (and even [custom decorators](https://gitlab.com/NullVoxPopuli/emberclear/blob/master/packages/frontend/src/utils/decorators.ts))
 - [Module Unification Layout](https://github.com/emberjs/rfcs/blob/master/text/0143-module-unification.md)


These are production ready in _any_ app today:
 - [TypeScript](https://github.com/typed-ember/ember-cli-typescript)
 - [`<AngleBracketInvocation />`](https://github.com/rwjblue/ember-angle-bracket-invocation-polyfill)
 - [server-side-rendering](https://www.ember-fastboot.com/)
 - [service workers](https://github.com/DockYard/ember-service-worker)
 - 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](https://github.com/emberjs/rfcs/blob/26c4d83fb66568e1087a05818fb39a307ebf8da8/text/0000-roadmap-2018.md)



-----------------------------------------


A little about me – on twitter, I'm [@NullVoxPopuli](https://twitter.com/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.