At NDC, Jon and K Scott sat down with Tom Dale (co-founder of Ember.js) and Rob Conery to recap their cage match battle, compare Ember.js and AngularJS, and hear from Tom about where Ember.js is headed.
Download / Listen:
Herding Code 169: Tom Dale and Rob Conery on the Ember.js / AngularJS Cage Match at NDC [audio://herdingcode.com/wp-content/uploads/HerdingCode-0169-NDC-Ember-Angular-Cage-Match.mp3]
Show Notes:
- Intro
- (00:18) K Scott and Rob asks Tom and Rob to introduce themselves and recap the Cage Match.
- (01:22) Tom describes the challenge and thanks Peter Cooper for moderating. Rob describes the scenario – start with installation and creating a new project, then move to routing and navigation between views.
- Demo vs. Reality
- (02:28) Rob says it’s fun to do a demo with Angular, but once you need to do more structured things you have to start over and reimplement with modules, etc.
- (02:43) Tom says that seeing the TekPub screencast about AngularJS informed a lot of their design for Ember.js. The result is a framework that gives you the same simplicity in getting started, but also grows with your application pretty easily.
- You Just Don’t Do That
- (03:22) K Scott asks if they pretty much match up if you’re looking at a feature checklist, and if it’s more about how you implement things. Rob says AngularJS is much more component based and talks about some things that came up during the cage match which were tricky in Angular, because "you just don’t do that".
- (04:18) Jon asks if there’s an overall effect to how you build your application because it’s just not how the framework works. Tom says it’s unacceptable when your designer comes to you with a user interaction design for you to tell them it’s just too hard to do in your framework, so you won’t do it. As framework developers, they spend a lot of effort on composability. Rob says that he sees Ember.js as more prescriptive, while AngularJS provides more building blocks. Rob says it seems like Rails to him, in that it just goes a lot better for you if you give in and go with the framework’s opinions.
- (06:13) Jon asks about how customization works in Ember.js, compared with Angular’s use of directives and filters. Tom says that’s done via helpers, referencing an example from the cage match.
- Client-side MVC implementation and The Importance of URLs
- (06:34) Rob asks Tom if it makes sense to say that "if you can think of it in a server-side framework like ASP.NET MVC or Rails, you can think of it in Ember.js". Tom says it’s not the same, because server-side MVC requests are short-lived compared to client-side applications. The real challenge is how you manage that state over time.
- (07:17) Tom says that they think URLs are really important. Their challenge has been how to marry the concepts of desktop MVC with the fact that they have a URL, and he thinks they’ve nailed it. Jon asks how that compares to Angular; Rob says that it’s not a primary concern in AngularJS or Backbone.
- (08:37) Tom says he considers your web application broken if he hits refresh and doesn’t see the same thing he saw before. Everyone screws this up, not because they’re idiots but because it’s hard, and if you don’t have this built into the framework you’re using you’ll mess it up. (09:06) K Scott asks what kinds of applications are the sweet spot for Ember.js. Tom says his first real professional programming gig was working on MobileMe / iCloud apps. They were big apps written in SproutCore. He says it’s important to be able to add features without breaking old features. Functional reactive programming and strong conventions help support this.
- State and Scope
- (10:38) Jon asks about the difference in maintaining state between Ember.js and AngularJS. Tom talks about how the Ember.js controller is similar to Cocoa and explains how the the controller presents the model to the template. Rob describes the $scope in AngularJS and compares the way AngularJS handles things more explicitly, whereas Ember.js is more conventional.
- (12:19) Tom says that he thinks the way AngularJS leverages JavaScript’s prototypal inheritance is really elegant, but it breaks down when you have very deeply nested UI’s pushing you into directives and more complex decisions. Rob says that you can share scope between AngularJS controllers, but the isolated scope situation is one of the things you struggle with in Angular.
- Testing, testing
- (13:54) Jon asks Tom about his comment on testability. Tom says that Angular’s Karma test support is really nice, and they’re working on catching up in Ember. Rob says that in AngularJS you’re just working with basic objects, which is really nice when you’re testing.
- (16:08) Tom says Ember.js requires you to do things correctly from the beginning; they won’t give you any foot guns to make things easier. Helpers help.
- (16:42) K Scott asks how change detection works. Tom explains the differences – AngularJS uses dirty checking against the DOM, while Ember.js uses accessors (like Backbone). Tom says that the performance is better in Ember.js. Angular’s situation will improve when they get object.observe, which ironically will happen at the same time Ember’s situation improves due to support for object proxies.
- (18:37) K Scott says he’d like to be able to conventionally wire up events. Tom talks about event delegation in Ember.js.
- The SEO Elephant in the Room
- (19:53) Tom says the biggest issue with JavaScript client-side applications today is SEO and describes why he’s not happy with the SEO solutions the other frameworks provide. They’re working on a solution that uses leverages the fact that they use Handlebars for templating to run a server-side process to generate SEO friendly content without any PhantomJS dependency.
- Using Ember.js When You’re Not Tom
- (22:28) Jon says that one issue with highly conventional frameworks is that it can be hard when you’re getting started and don’t know the conventions. Tom agrees and says that you’ll be frustrated if you experience learning difficulty before you feel the power and says the solution is documentation and good tooling. He mentions a coming Chrome extension that will show you what controller and model are backing content on the screen when you hover over it. K Scott says he’s pretty impressed with the Ember.js documentation.
- What’s Next? How about some Prollyfills?
- (24:45) K Scott asks about what’s coming out next. Tom talks about Polymer and Web Components. Jon asks if this was related to something he saw on Twitter the other day and Tom says it’s #extendthewebforward. The idea is that browsers should express primitives so browser vendors can innovate at the JavaScript level – rather than building speculative features into the browser, shipping a JS library that works cross-browser and can function as a polyfill (or "prolly"fill) if the feature doesn’t ship.
- So who won? Any missed opportunites?
- (29:45) K Scott asks who won the cage match and Rob admits to having been destroyed. K Scott asks why Rob keeps challenging framework authors to cage matches.
- (30:52) Jon asks Tom about the curveball that he threw at Rob during the cage match. Rob and Tom agree that coding a directive on the fly is not easy.
- (31:42) Jon asks Tom if there’s something that Rob could have asked Tom that would be hard in Ember. Tom says that they just added a competitor to filters using bound helpers, but if Rob had thrown list sorting at him he’d have had a hard time.
- (32:54) Jon asks about a viewer question on the emphasis on getting started vs. maintainability. Rob says that they’d first focused on composability, but nobody wanted to use it until it was easy to get started. Framework libraries don’t get the luxury of forcing a difficult learning experience on developers – if he can’t show value in 5 – 10 minutes, you’ll leave.
- Wrap?
- (34:42) K Scott asks Rob and Tom what else they’ve got going on. Rob plugs some TekPub videos (listed below) and Tom plugs some upcoming classes he and Yehuda will be offering (also listed below).
Show Links: