‘Choose Your Own Adventure’: EmberJS Co-Creator Tom Dale

These days Tom Dale is a senior software engineer at LinkedIn. His tech sector pedigree is bona fide: Dale cofounded Tilde and worked on Skylight, the performance profiler for Rails apps, along with stints at Strobe (an HTML5-based platform for mobile web apps, bought by Facebook) and Apple.

Dale is best known, however, for his work in helping to create Ember.js, the open source JavaScript web framework that in February released Ember 3.0.0. The New Stack caught up with Dale to talk about life at LinkedIn, where he continues cultivating the Ember.js core while working at propelling the platform into the future with projects like Glimmer.js.

So is it true you are a self-taught programmer, no computer science degree, and yet you somehow ended up co-creating one of the longest-enduring JavaScript framework?

It is true, I do not have a CS degree! I more or less picked up programming on my own, teaching myself Rails so I could put together a World of Warcraft website. Yes. That happened. This was my very early 20s and I was working at the Apple Genius Bar. I had a friend who worked in the Apple corporate offices, and he knew I was programming, and he came to me and said, “So there’s this project that we want to build, but we don’t actually have the budget to hire real software developers.” They basically had this kind of rogue operation where they pulled in some retail employees to start work on this web development project, and from there I got on the MobileMe team…

So basically I was lucky enough to get pushed right into the deep end in my first programming job! Apple built all the MobileMe websites and web apps in SproutCore, which Charles Jolley created. So SproutCore was an open source project that took Cocoa, the Apple Objective C framework for building Mac apps, and ported it to JavaScript.I think SproutCore truly was revolutionary. It really doesn’t get enough credit. This was really the first mainstream framework with some popularity to do client-side rendering; where all the UI, all the DOM was created in the router and not on the server somewhere. We take all this for granted today but it was a genuinely controversial idea back in 2007. And there I got to work with Charles and the MobileMe team. I knew zero JavaScript, learned it on the job.

So honestly it was mostly being in the right place at the right time.

And, eventually, SproutCore morphed into Ember.js?

That happened outside of Apple… basically, I was working on SproutCore, transitioning MobileMe to iCloud, when Charles left to start up a company called Strobe. He partnered with [Ember.js co-creator] Yehuda Katz, who had a stellar reputation already, he had worked on jQuery, on Rails. That was when I met Yehuda.

So SproutCore was a port of Cocoa to JavaScript, to the web, and that meant trying to extract over things like CSS and the DOM in way that made building a web app like building a native app. But it turns out that web developers really like working in the browser — their tools are HTML and CSS. This is what the browser has been optimized for, and there is already a wealth of resources around that. And SproutCore meant a lot of manual DOM work. Yehuda, meanwhile, had just written Handlebars, the client-side templating engine for JavaScript. So he suggested we add this templating language to SproutCore for everyone who wants to work in the browser, who wants to write HTML, but doesn’t want to go through this painful customization process.

It was the right thing to do, but it was kind of controversial and also confusing, so instead of SproutCore 2.0 we rebranded to Ember. And that was, what, eight years ago.

Eight years is practically, like, eighty in JavaScript framework time/scale?

We are ancient. Like the grey-haired wizard of the mountain compared to others. And it’s easy to fall into the trap of thinking, “Ember is from 2011, which is the Mesozoic era in JavaScript terms — so that must be JavaScript for a different world, things have changed so much.” But when we started, we were determined to build a framework to last a decade. Or even two. At the time this was a seemingly silly statement to make because JavaScript is such a flavor of the month environment. People use the term “JavaScript fatigue” to describe the sense that the tools we use inevitably change every year or two…even as you get the attitude from people, like, ”You’re still using grunt?”.

Ember is the antidote to JavaScript fatigue. We saw change coming and optimized for it, built in a formula for adaptability. So we can adapt to the cutting edge features as they land — while bringing the community along with us. So we are the still the only framework from that time that is still around. Ember’s codebase has never been healthier, Ember has never had less technical debt, and never been more advanced than is now.]

So now I confidently say, Ember is now a two-decade framework. Ideally, three.

LinkedIn is supporting your continued open source work on Ember while on the job?

LinkedIn is such a huge supporter of both my own work, and also working on the standards open source core team. We aren’t doing this to control it — LinkedIn does not control Ember, it just employs a few people who contributed back to the framework. It is an open process; not a big company telling us what to do, to align it with their interest. We have full control over not just the code but the decision-making process.

The term “open source” puts emphasis on code, but the code is a byproduct. The community culture and decision making, governance, is what’s truly important.

And now, Ember.js v3.0.0 is live.

Ember 3.0 is a very exciting release, and the reason it’s very exciting is because there are absolutely no new features. And we couldn’t be prouder of that.

Counter-intuitive, right? New releases are supposed to be all about the hot new features. What this means, though, is we are being consistent with our vision. We don’t need to sell you on the new, major version upgrade in order to get the latest, hot features. Instead, we took all the hot, new features that we wanted to deliver to users, and we did them all back in the 2.x series. And we spent the extra time to do it right, in a backward-compatible way.

And, along the way, a bunch of stuff we did in Ember — like classes — have increasingly landed in the language itself.

Ember 3.0 is mostly about being a garbage collection sweep and improving performance. We deprecated some features, removed features that were no longer being used. Overall we made the framework sleeker and smaller. To make the jump to Ember 3.0, you just get the last version of v2 Ember, 2.18. You make sure that it runs without any deprecation warnings, and then you just move to Ember 3.0 and there are no changes.

Which brings us to the introduction of Glimmer.js — Which some devs worried was meant to replace Ember.

Glimmer.js is our laboratory, our experimental performance space for investigating what is the absolute fastest web app that we can build if we can set aside backward compatibility at least temporarily, to embrace the cutting edge of new web technology.

Stuff like binary data, service workers, WebAssembly. If we can combine all of those ingredients, not yet worry about backward compatibility, what is the absolute maximum performance that we can get out of the web? And the experiment is working: at LinkedIn, we rebuilt the feed in Glimmer.js. And oh boy it was screaming fast.

Afterward, though, take the lessons from all the experimentation and upstream them back to Ember. So, ultimately, devs gave something that you know is going to be stable, you know it’s going to be mature, you know it’s going to be battle tested, and most important, around for the very long term.  Ember is not going anywhere.

For developers just now entering the profession, why should they embrace Ember.js?

The big reason is that building front-end web apps is really hard — A distributed computing problem, ultimately, that many new developers are kind of shocked to discover. As someone who stumbled into this line of work without a CS degree, I know first-hand how you don’t know what you don’t know.

It’s like the world’s most complicated choose your own adventure book — a combinatorial explosion of complexity that is simply unmanageable for those just starting out and even a  lot of us who have been doing it for awhile. How are people supposed to find their way? How do you do state management — Flux, or Redux, or MobX, or some hot new library that just landed? And all the other decisions that need to be made. It’s endless.

So Ember gives you a complete front-end stack. Even more importantly it comes with a community of people who believes in shared solutions, working together across corporate boundaries to say, “This is a problem we all have, so let’s solve this together.”

That said, you’re not in a straightjacket. With Ember, you have the option of doing whatever you want. The culture of the community shapes what the software ends up becoming. Ember attracts people who don’t like fiddling around with toolchains or reinventing the wheel just for kicks. People who just want to build things.

Last question: why a hamster?

The question really is, why NOT a hamster? Go has a gopher logo, and there are others with fuzzy animal mascots. So Ember has a hamster.

How it happened. Well, we were about to launch the Ember website. We had this beautiful design, but with placeholders for the logo because, well, I’m not a designer So on the Thursday before the Monday that we are set to launch, I asked Patrick Gibson to go on Dribble and find us an illustrator to get us an emblem before Monday.  He found Lindsay Wilson who just came up with three [images] for the website of one hamster running in a wheel. We never told her, please make us a hamster, but people really connected with the hamster. So a hamster it was. Also because the hamster kind of looked like me — because the glasses, at least so they tell me — the hamster got named Tomster.

And there has to be gender equity, right, so eventually, Lindsay came up with a sister for Tomster, named Zoey. And they have gone on adventures all over the world. We do a different version for EmberConf every year as a tribute to the host city. It’s fun and it’s silly and one of the billion reasons all this has just been so great.