Which Javascript framework to use? Angular vs. Ember vs. Marionette

If I’ve already got a server side page built and I just want to fancy up the UX with some dynamic features, e.g. - adding a new text box when I push a button, this is super simple with ng bindings.

Two way data-binding is pretty awesome. If we couple this with $resource or $http then we have simple model-view layer with persistence with very little effort.

Dependency injection keeps the code nice and clean but it sucks that you end up having to attach a bunch of extra strings to your controllers just so you can minify code and not break things.

Creating a custom directive for an existing jquery plugin. I can go download a jquery plugin like jquery.colorwheel.js and have this thing up and running in minutes. But not if I have to go write an angular directive for it - I already deal with too many 3rd party plugins as it is without having to write my own angular interfaces for them.

Routing in angular is a pain to me. I don’t like the ngRoute service and I have to go study the docs just for routes. Angular seems to work better for me when I let the server-side tackle routing.

Obtrusive javascript is somewhat of a code smell to me. Sure it is easy to use but it still couples the presentation layer (html page) with logic. If you think about it, <button ng-click="foobar"> and <button onclick="foobar"> are both still obtrusive.

How easy it is to get going. For me, Ember comes the closest to behaving like a server-side MVC framework. You have routes, controllers, views, models, etc.

Naming conventions are very nice. If you follow the standard naming conventions which are very similar to Rails, then it makes coding with Ember so much easier.

Handlebar templating is what I primarily use. However what if I wanted to switch this to a different templating language? I hear HTMLbars will solve a lot of problems with Handlebars.

Chrome dev tools integration is very very awesome. It helps me speed up troubleshooting and I have a clear picture of what is going on inside my application just be inspecting chrome tools. Angular has one of these tools as well, but I haven’t used it all that much.

Tom Dale and Yehuda Katz are programming heroes of mine. We all have developers that we listen closely to what they have to say. These guys are very opinionated about their development styles

Testing in ember is not an after-thought. The guys have documentation and examples. I have played with karma, jasmine and phantomjs and a framework that promotes BDD or TDD is pretty awesome in my opinion. The guys at angular use testacular so they get + points for that.

Ember community in IRC (irc.freenode.net #emberjs) is very helpful. I have found that #emberjs has more activity than #angular and #documentcloud and these guys are pretty helpful.

Ember is very promising. To me this framework seems to be the most promising. It still has a lot of things to figure out and is still a bit unstable but with HTMLbars on the rise and the level of awareness this framework has gotten in the past year, I know Ember is just going to keep getting better and better.

My biggest complaint is how difficult it is to bring in a jquery plugin. This probably needs some explanation. Let’s use jquery.chosen plugin as an example.

First, checkout this jsbin example I made using chosen plugin.

Like many other jquery plugins, the chosen plugin manipulates the DOM which ultimately means that we can’t call $('element').chosen() until after

1. the models have been fetched
2. and the handlebar template rendered into DOM

So at what stage do you call the chosen plugin in Ember? In Marionette, this is trivial as we have this nifty little hook called onRender where we can setup a jquery plugin once a view has rendered.

Scourging through documentation and stackoverflow pages and pestering people on IRC, I finally find there is a function called didInsertElement along with

Ember.run.scheduleOnce('afterRender',this, this.onRender)

which seem to work great - except if you don’t change routes this never executes! This is all very confusing to me.

After some searching I find some options from some random blog on the internet. On top of this, because Ember junks up your DOM with <script> tags then it later pollutes the DOM so you have to modify the chosen.js source code to ignore that. Now I decide I want the ability to bring in custom tags so I need to switch to select2.js and I am in the same boat again. Lots of frustration here just to bring in a simple jquery plugin.

Lastly, I could just pray that some poor unforunately soul has had this same exact frustration has me and created a special handlebars helper or something (which sure enough one exists).

Having a simple process like onRender that is called anytime a view and using an unobtrustive templating engine like HTMLbars will be a game changer for me. We have to remember that single page applications are very likely to have lots of 3rd party plugins in them.

If you have a jquery plugin that messes with the DOM (which most do), then chances are you are going to bang your head against the wall at least once trying to get Ember to work with it.

Putting logic in handlebars views makes things difficult. This isn’t really Ember’s fault but it is pretty easy to create some crazy wicked nested views full of #if #else and eventually you find yourself tracing through handlebar templates and cursing it simultaneously.

Emberscript pre-compliation is a custom fork of coffeescript and can be buggy. Writing annotations just to save several lines of code and then running through several stages of pre-compliation is not my ideal workflow for writing javascript applications. I prefer a generator over annotations any day because:

I prefer 20 lines of simple, readable code over 5 lines of complex code.

Composite style architecture can scale. You can write 100k line of code applications with Marionette. Modules which can be dynamically included/excluded, a lot like operating system. Derick Bailey is another one of my programming heroes and knows the importance of architecture.

Marionette stays out of my way. It is probably the easiest framework for me to bring in other 3rd party plugins because it doesn’t make me adhere to a scope like angular and I have complete control over when views are rendered.

Focused by design. What does this even mean? It means that I don’t have to shift through pages of documentation to understand what Marionette and Backbone can do. The docs are all on a single github page and can be read front-to-back in probably less than an hour.

So what does Marionette do? I’ve made a list.

1. Organize your views into either Regions, Layouts, ItemViews, CompositeViews or CollectionViews.
2. Organize your application so you can bubble up events from views -> controllers -> application.
3. Organize event handling with Backbone.wreqr for application-wide message bus

Simple right? Marionette has no opinion about your model/persistence later and relies completely on Backbone for this. There are a lot of things in Marionette you will have to go find elsewhere, like how to handle promises, routing and persistence. You won’t find things like two-way data-binding or computed properties out of the box with Marionette.

Fortunately, there are Backbone plugins out there for these types of features. Heck I even wrote one myself.

Brian Mann’s videos show you how to make an enterprise worthy application. When I was first learning Marionette I was confused. I didn’t know how it should be used, and then I saw these videos and it improved not only my Marionette skills but my overall performance as a developer in Laravel and other frameworks.

Composite style architecture is complex. There is a reason people like MVC frameworks. They know to find their models, they can view app/models. To find controllers, app/controllers. Marionette has no structure except for that you give it. Creating a new Marionette single page application can be a daunting task to start with just because you have to organize your code with intent. You don’t just drop a file in models/users.js but instead face the challenge of how to broadcast the users entity?

Routing as an afterthought is something Derick Bailey and Brian Mann evangelize. I can’t say I agree 100% because routing is an essential part of single page applications. The reason why this bothers me is that when you rely solely on events to do your routing then it takes a lot more time.

For example, if you have route to #users and write a link <a href="#users">Users</a> in your navigation then you are done. Simple right? But in Marionette the preffered thinking seems to be that we should

1. listen to an event on <a class="js-clicked">Users</a> DOM element inside of the users’ Item/Collection/Composite View
2. bubble the event up using a trigger to parent controller.
3. parent controller listens for triggers on child views.
4. the controller would handle a trigger from child view in a function and take necessary action, which would to be call some event like App.vent.trigger('!route:to:users')

If none of that makes sense to you then you aren’t alone. Basically, it is a lot of work for something as simple as routing.

Testing in Marionette can be wearisome. Unlike Ember, which has the Chrome dev tools integration, in order to test I have to set breakpoints and follow execution and that can prove to be difficult since there are many events flying around everywhere. Often times I find myself just doing console.log. Also I have tried using karma/mocha with Marionette and because the Marionette.Application is a singleton it is hard to test in isolation.