Intercom recently completed the first phase of a major project to re-write core parts of our product using the Ember.js framework.
As part of that project Tom Dale, one of the founders of Ember, visited our offices for two weeks to consult with our engineering teams. While he was with us I took the opportunity to sit down with Tom for a wide ranging interview which covered topics such as the need for frameworks, organ donation rates, web standards, bikeshedding, and open source. Here’s some of the highlights.
Opinionated by default
Describing Ember’s place in the world, Tom describes it is an “opinionated” framework, which he is keen to point out simply means “that for any particular task, there’s a default way of doing it.”
That’s important he says because of a feature of human psychology known as “ego-depletion”, a concept that his Ember co-founder Yehuda Katz came across.
“You have this finite resource which is your decision-making, and people assume that the harder the decision is, the more it depletes it and so trivial decisions have a trivial impact,” he says. “It turns out that this is not the case and each decision we make, regardless of how trivial, makes a withdrawal from our decision bank which has a finite daily balance”.
Tom cites the example of organ donation rates in countries where they operate a progam for drivers to indicate their preference when renewing their licence.
“Now, the idea of someone taking the organs from your dying corpse is a very heavy thing. Whether you want someone to do that to that to you is not a light decision. It involves morality, religion, expectations of your family etc. Yet, if you look at the different rates of enrollment across all these different countries, you see stark differences.”
In a lot of nations the rate of enrollment is is as high as 99% but in many others its about 60% or even lower. It would be easy to assume that’s the result of cultural differences are responsible but in fact the high enrollment rates are in countries where people are opted-in by default when they renew their driver’s licence or permit, and the low rates occur where opt-out is the default. When people are faced with a decision – no matter how weighty – they will usually just go with the default.
The need for sane defaults
“There are so many reasons that when you come into work, you are not going to be perfect, you are not going to be in tip-top shape, and the only mechanism that humans have discovered for dealing with the fact that we’re not always perfect is having sane defaults,” he explains. “Having some kind of system to nudge you towards the right decision, even if you are not able to make that right decision yourself.”
Ember.js uses the tagline “a framework for making ambitious web applications” which is a pretty bold claim but as Tom tells it there was never any grand vision, when the framework evolved out of SproutCore 2.0, just over two years ago.
“Everyone working on it at the time was building apps for themselves. We all had jobs to do, and so it was a very iterative process.”
The early releases of Ember were “basically a component library” that allowed data-bound templates to be displayed on screen. But in their own work building apps, the Ember team became frustrated there was no convention for managing which templates were on screen at any given time. They also wanted to create a JavaScript framework that would be intuitive to developers in the same way that Rails was.
“If you’re a Rails developer, you could drop into almost any Rails project and kind of understand what was going on, but that wasn’t true in Ember at the time. You would drop into an Ember project and how people manage their controllers, how people manage their views was completely ad-hoc.”
Teasing out abstractions
The Ember team also felt URL support was bad in most web apps at the time.
“I’ll use it for five minutes and I’ll hit the back button and then all of a sudden, I’m not in the app anymore, I’m back at the Google results because they’re not putting any URLs in there.”
“I think that was kind of fortuitous because I think we got the answer to both problems out of one thing, which is the router. We realized, ‘Hey, the URL is the way the web decides what templates and what models are on the screen’. So if anything, I would say that the biggest thing in terms of evolving towards ambitious applications is ‘never settle’. There’s a difference between teasing out the right abstractions and solving a problem correctly versus scenario solving.”
Tom admits that this approach can be unpopular with members of the community as requests for features get turned down but he firmly believes it is in the best interests of the framework.
“The app that I work on, Skylight analytics, it’s very D3 driven, is so different from an app like Vine or Discourse, both of which are a lot more content-oriented. But the fact that we say, okay, well we’ve identified that these problems are common across all of applications means that there’s value there.”
Tom discussed the importance of URLs when he spoke at our Inside Intercom Engineering event which took place during his visit. Watch a video of the talk below.
Ember vs Angular
There’s certainly not a lack of choices when it comes to frameworks, but mention you are using Ember and almost inevitably someone will ask if AngularJS, the Google-associated JavaScript framework, was considered. Does it bother him that people try to boil it down to this simple binary choice?
“I think there are a lot of people for whom they just want to be on whatever the most popular bandwagon is, right? I think that if you’re choosing a JavaScript library purely based on popularity, I think you deserve what you get. But I think there are applications that Angular is really great for and there are applications that Backbone is really great for and things where you would just use jQuery. So I certainly believe in choosing the right tool for the job.”
While stressing his admiration for the team behind Angular, Tom is also not shy at pointing out the areas where he thinks Ember does a better job. The two features he points out are Ember’s conventions and superior support for URLs.
Going native
Looking to the future Tom believes the web should be the platform of choice for developing apps, but that will require a significant effort from standards bodies and browser vendors.
“To be honest with you, I want to kick Cocoa’s ass. All these native platforms, Android SDK or whatever, I want those to be a thing of the past. I want the web to be the way that people develop apps. Today, it’s the way that people distribute documents, but especially on mobile, I think in five years, it can be the way that people deliver apps. The App Store shouldn’t be a thing.”
The spread of evergreen, auto-updating browsers means that new features can be rolled out without having to worry if users are on the latest release. In contrast change at the level of standards bodies is slow. Along with representatives of Google, Mozilla and W3C, Tom is one of the signatories of The Extensible Web Manifesto, which wants to ensure those setting standards are doing so with feedback from practicing web developers. The aim is to ensure the web standards committees introduce new features quickly, which they believe “is critical to the long-term health of the web”.
“Many of the academics have been removed, sometimes forcibly, from the standards bodies. Instead, we’ve replaced them with practitioners, people who are building apps day-to-day, people like Yehuda Katz in my company, people like Rick Waldron at Bocoup. There’s a sense of urgency that yeah, we actually need to compete with native.”
When asked what he’d like to see happen in terms of web standards and development over the next ten years, Tom actually points to what’s failed to happen over the last decade.
“I wish that for the last 10 years, the standards bodies and the browser vendors had been more focused on exposing new capabilities into the platform instead of trying to build nice declarative high-level APIs. Because the high level APIs, one, it takes significantly longer. Two, they’re much more open to bikeshedding.”
Community management
He also believes Ember can remain relevant over the next decade, largely because both he and Yehuda have stepped back from day to day involvement – he says neither of them have contributed code in months. They attend core team meetings and make design decisions but the coding is done by the community.
“I think one thing we’ve consciously tried to do is not to try to dictate what happens in the core team. We say, okay look, you do consulting, you go around contracting with a bunch of different companies, you work at a product company, you’re just like a developer that is hacking on a project over the weekend. All three of those users are just as important to us and by making the barrier to contribution low and by having frequent, small releases, we can get good new ideas in all the time and I’m hoping that those are mitigation strategies that we can use against getting old and stodgy.”
Tom now juggles his day job on Skylight, an analytics and bug-catching tool for Rails apps, with evenings and weekends working on Ember but the framework’s success has meant his role has become very different.
“To be honest with you, most of my contribution today is going around the conferences and giving talks, kind of like spreading the love. You know what no one tells you about open-source? No one tells you, you know, you do it for fun. You’re like, oh, it’s the weekend. I’m going to go work on this open-source project and it’s something different. What no one tells you that if your open-source project becomes successful, really, all that happens is you become an open source manager, which is less fun to do on the weekends.”
Comments