{"id":5891,"date":"2014-07-10T16:22:48","date_gmt":"2014-07-10T16:22:48","guid":{"rendered":"http:\/\/insideintercom.io\/?p=5891"},"modified":"2020-07-30T13:03:55","modified_gmt":"2020-07-30T12:03:55","slug":"tom-dale-talks-frameworks-standards-and-open-source","status":"publish","type":"post","link":"https:\/\/www.intercom.com\/blog\/tom-dale-talks-frameworks-standards-and-open-source\/","title":{"rendered":"Tom Dale talks frameworks, standards and open source"},"content":{"rendered":"

Intercom recently completed the first phase of a major project to re-write core parts of our product using the Ember.js <\/a>framework.<\/p>\n

As part of that project Tom Dale<\/a>, 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\u2019s some of the highlights.<\/p>\n

Opinionated by default<\/h2>\n

Describing Ember\u2019s place in the world, Tom describes it is an \u201copinionated\u201d framework, which he is keen to point out simply means \u201cthat for any particular task, there’s a default way of doing it.\u201d<\/p>\n

That\u2019s important he says because of a feature of human psychology known as \u201cego-depletion\u201d, a concept that his Ember co-founder Yehuda Katz came across.<\/p>\n

\u201cYou 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,\u201d he says. \u201cIt 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\u201d.<\/p>\n

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.<\/p>\n

\u201cNow, 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.\u201d<\/p>\n

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\u2019s 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\u2019s 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.<\/p>\n

The need for sane defaults<\/h2>\n

\"TomDale_Quote_1\"<\/p>\n

\u201cThere 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,\u201d he explains. \u201cHaving some kind of system to nudge you towards the right decision, even if you are not able to make that right decision yourself.\u201d<\/p>\n

Ember.js uses the tagline \u201ca framework for making ambitious web applications\u201d 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.<\/p>\n

\u201cEveryone 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.\u201d<\/p>\n

The early releases of Ember were \u201cbasically a component library\u201d 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.<\/p>\n

\u201cIf 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.\u201d<\/p>\n

Teasing out abstractions<\/h2>\n

The Ember team also felt URL support was bad in most web apps at the time.<\/p>\n

\u201cI’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.\u201d<\/p>\n

\u201cI 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, \u2018Hey, the URL is the way the web decides what templates and what models are on the screen\u2019. So if anything, I would say that the biggest thing in terms of evolving towards ambitious applications is \u2018never settle\u2019. There’s a difference between teasing out the right abstractions and solving a problem correctly versus scenario solving.\u201d<\/p>\n

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.<\/p>\n

\u201cThe app that I work on, Skylight<\/a> analytics, it’s very D3 driven, is so different from an app like Vine<\/a> or Discourse<\/a>, 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.\u201d<\/p>\n

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.<\/p>\n