Ember so far

For the last months I've played around with a - at least for me - new client framework, EmberJS. I've done a some things with Angular and Backbone, but wanted to try something new. I didn't know too much about Ember - my information was mainly from an article in the Ghost Development Blog. But I wanted to try it out and find out what everyone mean by "strongly opinionated".

The first application

Since I'm one of these guys who tries to remember everything but fails terribly at it, I kinda like note apps. Some time ago I've already implemented a very small note taking module for a project:

I'm terribly sorry for the mispositioned save button. Thankfully this module is deprecated and nowhere in use.

This was done in Angular and one of my first experiences with it. The ng-switch directive made it pretty easy to switch between the single views and a very simple service is responsible for loading the notes.

This time I wanted more. I love to play around with frameworks and libraries, therefore my note module must be bigger this time. It had to have notebooks, the possibility to search notes, maybe even tags and things like that - pretty much everything I like about a good note app. After a few days I had a result:

It's far from being done (that might also be the reason for not seeing any editing), but already looks pretty cool. Some facts about it:

• it uses three (nested) routes; notes for the overview, notes/:notebook_id for a specific notebook and notes/:notebook_id/:note for a specific note.
• there's no backend involved at the moment. Data comes fixtures, one of the most useful features I've seen for a long time.
• the word counter is implemented as a computed property:

var Note = DS.Model.extend({
  name: DS.attr('string'),
  content: DS.attr('string'),
  notebook: DS.belongsTo('notebook'),
  date: DS.attr('string'),

  words: Ember.computed('content', function() {
    var content = this.get('content');
    if( ! content) {
      return 0;
    }
    
    return content.split(' ').length; // not the most accurate measurement, but should be okay for now
  });
});

• word highlighting is implemented as a helper

import Ember from 'ember';

export function highlightWord([content, toHighlight]) {
  if(toHighlight) {
    var regex = new RegExp(toHighlight, 'g');
    var replc = '<span style="background-color: #e9e8d4; font-weight: bold;">' + toHighlight + '</span>';
    return Ember.String.htmlSafe(content.replace(regex, replc));
  }

  return content;
}

export default Ember.Helper.helper(highlightWord);

Everything else about this project is pretty basic and there's no further magic involved. This piece of software just needs a few lines to work properly and could be used in production pretty fast by just doing a few things, mainly switching from fixtures to a real backend (which is done very easily by using a different adapter).

What I like about it

I now understand this "strongly opinionated thing". It basically just means that you should do things the ember way. They tell you where to put your stuff, what conventions to follow, etc.. This saves you a lot of time, and you can focus on implementing features and not too much on code organization, etc.. Thanks to Ember CLI, which is used for creating ember applications, this is done even faster.

Since you don't spend too much time of thinking how to organize things, you can directly dive into creating stuff. It's easy to learn, there are a lof of resources (which is also kinda bad, see What I don't like about it) and you can actually see what you did pretty fast (other than spending a decent amount of time by setting up the project, configure things, etc.).

Oh, and fixtures. I fucking love fixtures. I've already tried to switch from a fixture adapter to a REST adapter - and it worked like a charm. By changing a few lines (not including the backend itself) I had "real" data coming from a "real" backend.

What I don't like about it

Having a lot of resources has one big disadvantage; not all of the things you may found are up to date. For example: if you search for "ember fixtures" you may be redirected to the v1.10.0 api docs - on ther other hand, there's not a single word about fixtures in the v1.13.0 (or further) docs. This is a bit weird, since the feature still exists and works fine.

Another example would be views. In older versions a view was used for "encapsulating templates of HTML content, combining templates with data to render as sections of a page's DOM, and registering and responding to user-initiated events" (regarding to the view api). In v1.13.0 and further versions views are deprecated and were replaced with components. The reason for this is that views were limited to existing HTML tags and components are not (see here for a more detailed explanation). If you look up a problem nowadays you might find a view implementation - which is deprecated. All you have to do is to use its logic and implement it as a component - that's not too hard, but you need to know this - and if you're new to Ember this might be a bit confusing. This problem isn't caused by EmberJS directly, but they could probably provide some kind of hint in their v1.x (not v2.x) guides what happened to views and why they're gone. This would make newcomers life a bit easier (even if it's still not too hard to find out yourself).

Conclusion

I like Ember. I like not giving a fuck about code organization or - simplified - doing things the ember way. Even a lot of things are still new (or even confusing) to me, it's still very likely that I'll use EmberJS in some of my upcoming projects.