edgy circle

Building an Ember.js Production Application with Ember CLI

Although Ember CLI is still a work in progress project we used it to develop and deliver an Ember.js production application from scratch. Even at this point I am confident to say that Ember CLI is the best way to develop standalone Ember.js applications.

About four weeks ago we started to develop a new interactive kiosk application for a museum. The applications goal is to provide the visitor with detailed technical data of old Porsche-Diesel and Allgaier tractors.

Fahr(T)raum Traktor Stadl

Back then 0.0.23 was the newest version of Ember CLI. Due to the tight timeframe there was no time to update Ember CLI so the application which we deployed on last saturday is still built with version 0.0.23.

I was not sure if I should write this post since Ember CLI is moving so fast and many things I mention in this post will be different in a month or less. I decided to write it anyway, at the minimum it will serve as an example that there are production applications built with Ember CLI.

In our prior Ember.js projects we used a custom Middleman setup as well as a toolchain based on Brunch and integrated Ember.js via the ember-rails gem into an existing Ruby on Rails application.

None of those solutions were as easy and painless to setup and use as Ember CLI. The ember-rails gem was also pretty easy to use, but since it only makes sense if your intention is to use Ruby on Rails it's an exception. This leaves Ember CLI as the reigning champion.

One of the best things of Ember CLI is the integrated server. It is also one of the first things you will notice when you start using it. First of all it does all the same things you are probably used to by other toolchains. Namely compiling and building your project on the fly when a file change occurs. You also get live reload functionality out of the box. In combination with the blazingly fast compile and build step this makes developing applications a bliss.

The second thing you will notice is the out of the box support for the history location of the Ember.js router. This means the server handles all URLs correctly and always serves the index.html file unless an asset is requested. Support for real URLs is a major advantage over other tools where you either have to use the hash location or roll your own history support.

The ability to proxy API requests to a different webserver is another promising feature of the Ember CLI server. Since our project doesn't have an API I'm missing hands on experience and can't tell you more about it.

Ember CLI uses an ES6 module transpiler which allows you to use and write the future ES6 module syntax. For us CoffeeScript users this was especially nice since it means there is one true way how you can access dependencies from different files. No more weird global namespaces in order to access other classes.

Before I go into the areas which could use some improvements I want to highlight the speed of Ember CLI once more. The few seconds it takes to generate a production build of our application are nothing compared to the minutes we are used from our Middleman setup.

With that I present you my list of things which I wish would be different. Due to the fast paced nature of Ember CLIs development I'm fully aware that most things will be outdated pretty soon. Nonetheless here we go:

  • For people like me who are completely new to NPM, Bower and the ES6 syntax it is often not obvious how to accomplish various goals. There are so many things to learn and understand that the documentation is sometimes missing important explanations or steps. Especially when you are working in a team, add additional libraries or want to update Ember CLI etc. (Yes I know, this is something I can easly improve myself. I'm working on that.)

  • In order to properly cache and invalidate assets it is crucial to have built in fingerprint support.

  • Although live reload is a nice feature it would be great to have the ability to disable it. (Update: This already landed in version 0.0.24.)

  • If you follow the official Ember.js guides your fixture definitions won't work. The fix is pretty easy once you know it. Until the Ember.js guides and examples are fixed there should at least be a notice in the Ember CLI documentation.

  • The temporary file directory is growing continuously. (Update: This is also fixed in version 0.0.24.)

  • Due to the internal resolver and the naming conventions you end up with different files for your model, route and controller which are all named the same. For easier access and a better overview via fuzzy matchers in editors etc. it would be great if you could include special words like controller, route in the file names. Currently you have to remember to prefix everything with the according directory name.

After these little nitpicks I can only repeat myself, Ember CLI is the best tool for developing standalone Ember.js applications. If you have the chance go and try it!

At this point I would also like to thank the awesome people behind it. Thanks to you we have awesome things like Ember CLI, thank you!

Zurück zum Blog