Update: As with many things Ember, this post has been outdated. Using the new router landing in 1.0, one way to do this is as follows:

1
2
3
4
5
6
7
8

App.ApplicationController = Ember.Controller.extend

  routeChanged: ( ->
    return unless window._gaq
    Em.run.next ->
      _gaq.push(['_trackPageview'])
      mixpanel.track_pageview()
  ).observes('currentPath')

Inevitably, if you are building any web application, you are going to need some form of analytics. Single page javascript applications are no exception. Unlike normal applications, however, integrating Google Analytics and Mixpanel is not as trivial as including some javascript in the page’s header and forgetting about it.

CoffeeScript is great. I’m not going to spend any time backing that statement up in this article, but you are free to stop reading if it’s not your cup of tea.

My main gripe with CoffeeScript, however, is a small impedance mismatch with the Ember.js object model. Creating classes using the new operator in coffeescript does not translate well to the Ember convention of creating object’s via the create method.¹

Update: Ironically, this “redux” is once again out of date. Please consult the new Ember.js Router Guides

Four months ago, in February, I wrote a blog post detailing a strategy for handling routing and layout in Ember.js. This was at a time when there was no support for these features in Ember’s core. Today, however, this is not the case. Ember now has the notion of a Router and an {{outlet}} handlebars helper. These two features supercede the libraries in the previous post (Ember Layout has been completely deprecated and Ember RouteManager has been temporarily frozen.)

The other day I compiled this list of hacker archetypes. These represent the types of hackers I have come across over the years. To be clear, this is just for fun and all of these types of hackers are talented, but have distinctively different styles.

At the core of any web application is a mapping between urls and application logic; a mapping between what is in the browser’s address bar and what should be displayed on the screen. Rails has routes.rb, Django has URLconf, Backbone.js has controllersBackbone.Router, and Sammy.js has Sammy.js.

Having used Ember.js for a few months now, I have compiled a list of gotchas that I have encountered. Many of these will change/be fixed as Ember matures, but until then I hope these will serve as pre-emptive time savers for other developers.

If you’ve been following the Javascript MVC landscape lately, you might have noticed a growing tension between Backbone.js and Ember.js. Being championed by Jeremy Ashkenas and Yehuda Katz respectively, both frameworks reside in decidely different camps. Ember.js favors deep abstraction and sensible defaults, whereas Backbone.js embraces the micro-framework mentality of providing a minimalist set of features whilst encouraging integration with a wide variety of other frameworks.

UPDATE: This is no longer the preferred way of handling routing and layout in Ember. Please read this updated post.

I am long on Ember.js. I previously wrote a brief comparison of some of the more popular javascript frameworks, and Ember came out on top. I am now in the process of incorporating it into GroupTalent in a big way.

1. Static content should be served statically
2. Disqus rocks
3. Ruby
4. Google rewards fast loading times
5. Markdown
6. Flat files are awesome
7. Sass
8. Compass
9. HAML
10. GitHub Pages
11. This guy did it
12. Linode disk alerts are annoying
13. No more caching plugins
14. Hacker cred
15. Security
16. Octopress Classic is the new Kubrick
17. Built on top of Jekyll
18. Web interfaces suck at content creation
19. Easily preview locally
20. Version with GIT
21. Compose in VIM
22. Wordpress has customer service
23. Score 93/100 instead of 55/100 on PageSpeed
24. Happiness as a developer
25. This Graph:

In case it’s not obvious, I spent some time migrating this site over to Octopress.

UPDATE 1/14/2012: Added Batman.js and Angular.js due to popular demand and because they looked impressive.

Over the last several months I have been in a constant search for the perfect javascript MVC framework. Driven by a dire need for the right level of abstraction and features, I have tried out - some more cursorily than others - every framework I could get my hands on. Here lies a brief synopsis of each framework. Lastly, I share the framework which I ultimately decided on.