An Interview with Tom Dale of Ember.js

I recently had the pleasure of interviewing Tom Dale, a member of the Ember.js core team who has been with the project since the very beginning. In our talk, we discuss how he got started as a programmer, a bit of JavaScript history, as well as what to expect from this year's EmberConf, among other topics.

There's a lot of wisdom from Tom in what follows...

Tom Dale: Nice to meet you, John.

John Hannah: Yeah it's nice meeting you, and thanks for taking the time to answer some questions for me.

Tom Dale: Thank you for covering it.

John Hannah: You bet. So I want to start with a part of Ember that fascinates me — it’s the Ember history. Can you talk a little bit about the origins of the Ember project? How you got involved...and I’ve read something about SproutCore, and a company called Strobe. I mean, how did that all begin? The genesis of Ember.js?

TD: Oh geez. You know, I could talk your ear off. I love this stuff. I actually really love the history of all these things and I actually do think that part of the reason Ember has lasted so long is I think we are very aware of history. I think that helps us avoid going into trends that are not long term trends, they're kind of like a fad. People tend to chase fads but I think because we do take a long view of history, that kind of helps us avoid that.

So SproutCore was a very interesting project. So this was an open source project that ported Cocoa, the Apple Objective C framework for building Mac apps. It ported it to JavaScript. I think SproutCore was really, it was revolutionary. I don't think it gets enough credit for just how revolutionary it was.

So this was back in 2007, I think, was when Charles Jolley created the SproutCore open source project and I think 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. Even though we take that for granted today, my goodness, that was a controversial idea in 2007.

JH: Yeah.

TD: I think most people learned about SproutCore because Apple built the MobileMe websites, like the web applications, in SproutCore. That was my first real programming job, working on that team at MobileMe where I met Charles and the rest of the SproutCore team. And I really got thrown in on the deep end. I had no idea what I was doing. It was my first job. I did not have a computer science degree, and I kind of like picked up programming on my own, got hired into the job, and next thing I know ... How did I do that?

JH: How did you land that job? That's an awesome first job.

TD: It is an awesome first job. I agree and it was career defining. Like I don't think I'm particularly smart or skilled in any way. Honestly, I think I was just in the right place at the right time. I was hired into that team to work on the JavaScript framework before JavaScript frameworks were considered a good idea. In fact, they were widely considered a bad idea.

So long story short of how I got that job, is that I was working at the Apple store in the Genius Bar, and I had a friend who had a job at Apple corporate and he had kind of heard that I knew how to program, I kinda taught myself. I learned Rails so I could build a website for my World of WarCraft skills. (laughter) …this is like my very early 20's and he said, "Hey, we got this project that we want to build, but we don't actually have the budget so we can't hire real software developers." What they did was they kind of did this rogue operation where they pulled I think it was like five of us from retail employees. I think I was making like 12 bucks an hour.

They pulled us up to work on this web development project and they wanted to do it in Rails and SproutCore and everyone knew Rails. No one really knew JavaScript but 2007, JavaScript was considered a poor language. So we built the Rails API in two weeks and then the SproutCore app, I don't think we even started up. (laughter) So they were like, okay, you have to learn JavaScript. You have to learn SproutCore.

So here I am making 12 bucks an hour, learning JavaScript in 2008 and through that process of, "Oh my God I'm going to get fired because I don't know what the heck I'm doing”. We went over to Charles and the rest of the MobileMe team and we said, "Please help! Anything…oh my god, we’re dying!" That's how I met him, and I guess they didn't think I was a complete idiot, and hired me.

JH: Wow. That's a great story. At some point, the transition from SproutCore to Ember, how did that happen? Was that something that happened internally at Apple? Or was that afterwards?

TD: That was after Apple. So I was working on SproutCore at Apple. We were working on the transition from MobileMe to iCloud. Charles left Apple to start a company called Strobe, the one you mentioned, and Yehuda joined Strobe as a co-founder, which is Yehuda Katz, it's how I met Yehuda. That was kind of the start of what has been a very fruitful collaboration and career for both of us. Although of course, Yehuda's reputation precedes him. He had quite a good career before I came along. He worked on Rails and jQuery and all sorts of stuff.

But for me, it was amazing. I think I was like 22, maybe 23. I left Apple, joined this start up with Charles and Yehuda and I think ... I remember walking into that office day one, and Yehuda handed me a keyboard and mouse and said, okay we're going to be pair programming. The next five years of my life, there was basically not a day where I didn't pair program with Yehuda.

JH: Wow!

TD: Which is quite a learning experience. So that was life changing. So what ended up happening was that SproutCore was a port, like I said, of Cocoa to the web. That meant that it tried to extract over things like the DOM and CSS and tried to make building a web application much more like building a native app, like a Mac app or iOS app. I think a lot of people liked that. There was also Cappuccino, which was another kind of take on decisions.

But I think what we underestimated was people really like ... web developers really like the tools in the browser. They're very powerful. HTML, CSS, those are the tools they feel comfortable with. Those are the tools the browser has optimized for. Those are the tools that there is a wealth of resources available for. So what happened was, we said people don't want to build apps like this because it involves a lot of manual DOM operations if you want to do anything custom.

So Yehuda had just written handlebars and he said, "Why don't we add this templating language to SproutCore for people who do want to write HTML, there's a nice app for that and it's not just kind of like painful customization process." But that caused a little bit of tension in the community because they're kind of polar opposites. One has a vision for the web as an app development environment where it's like you're building an app and this vision was more like, let's go back towards HTML and CSS.

So ultimately what happened was we were working on SproutCore 2 and I think that caused a lot of branding confusion so ultimately we rebranded SproutCore 2.0 to Ember.

JH: So one of the things that I've read is one of the big early contributions that Ember made, really to all JavaScript frameworks, is the router. Can you talk a little about that and the significance of it? How big of an achievement that actually was and how it has that legacy today?

TD: Oh boy. Absolutely. You know, it's so interesting because almost every framework has a routing story now. It's just table stakes if you want to be competitive. But before Ember, JavaScript applications, single page apps, the apps where you do all the rendering in the browser, they had a very bad reputation. A very bad reputation.

Every time someone would post a link to a JavaScript framework or a library on Hacker News, or anytime someone posted on Hacker News and said, "Look at this app that I built", people would come out the woodwork and say, "I hate JavaScript apps. They're so terrible. I can't command click on things. The back button's broken. If I reload the page, I lose the state." It's just broken, right? And what had happened is that, I think, people had taken the architecture of native applications too literally. When you build an iOS app, or a Mac app, there's no URL bar, there's no address bar.

JH: Right.

TD: So, you don't really have to think about that. Applications, they kind of just happen in this ad hoc fashion. And a lot of people were treating it like JavaScript intrinsically was a problem, that we will not do JavaScript, this is just, these are the problems and they're insurmountable. But after we had noodled on it, I think we came to realize that the URL is really just a serialization of the current state of the app right now. It's a serialization of a combination of what views or components are on screen, and what is the data backing those views. And it was, in retrospect, it's so obvious.

But at the time, it really wasn't. And our initial attempt at this was, we kind of went to the academic literature. We looked at a paper about state charts by David Horrell, Dr. David Harel, I guess. He has his PhD. And so we imported this concept of state charts quite literally. And the API was just very unpleasant to use, so this is one of the reasons people didn't like Ember at the time, was just that we were very rigorous about the routing, and it produced good applications that helped get the views, but the process of writing them was awful.

So the key insight that we had that I think solved this is that we decoupled ... It had two responsibilities throughout, right? One responsibility is when you were running the possible URL in your app. And then the other responsibility is then taking them, and then going and fetching the right data. It was like this data fetching responsibility.

JH: Right.

TD: And we had coupled those into a single object, so I think if you look at the Ember router API today, it's very similar to other routers. The key insight that we had, that was not at all obvious at the time was to decouple these things. Have one file that says, "Here's all the URLs," and then have other objects that are responsible for doing the data fetching. And once we did that decoupling it felt so good. We knew we really had something special there.

JH: So Ember has been around for a long time, like 7 or ... Yeah, it's like 7 years now, right?

TD: I wanna say 8.

JH: 8 so ...

TD: If you count SproutCore 2 ...

JH: Yeah. So, been around for a long time, but just a few weeks ago 3.0 was released. What's new in 3.0 for Ember?

TD: Well Ember 3.0 is a very exciting release, and the reason it's very exciting is because there are absolutely no new features.

JH: No new features?

TD: There are no new features. And we are very proud of that fact. So, I think our model is a little bit different than ... You know, most people think of major releases as ... Usually there's some hot, new feature that it's supposed to entice people to operate.

JH: Yeah.

TD: And you do the big press tour, you know, telling everyone about this cool, new feature.

JH: Yeah.

TD: But I think it actually says a lot about Ember's…like the thing that we value. Because rather than saying, "Hey, you need to upgrade to this new, major version in order to get the latest, hot feature," what we did is we took all the hot, new features that we wanted to deliver to users, and we did them in the 2.x series. We spent the extra time to do it in a backwards-compatible way.

So what Ember 3.0 is about, is it's really just a garbage collection sweep where we already gave you the hot, new features. We deprecated some features. So in order to make the jump to Ember 3.0, you just get the last version of Ember, 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. Other than we have made the framework smaller, slimmer, more svelte.

JH: That kind of leads into another question I had for you. I was reading an article that you wrote, I think it was last year, in 2017, The State of Ember. I think you wrote it right before EmberConf, or perhaps right afterwards. And you talked a little bit about performance there, and I saw that you had a code repo that asks, "Is Ember fast yet?" Or something to that effect. So one of the concerns that developers sometimes have about Ember is performance. So how do you answer that? What do you say to developers who might think that Ember is too large, or not fast enough?

TD: Sure. So I think that Ember does come from a world where, it does predate the mobile revolution. There's no question about that. I think, in terms of performance, we have been doing a lot of work over the last few years to kind of remove features that are no longer being used, pulling things down, improving performance, so there's been a dramatic improvement there. So I think on desktop applications, if we're talking about if we consume broadband, desktop applications…basically the Western market, I don't think that there are any noticeable performance problems with Ember.

People like to take Ember as a build which includes a lot of functionality that most apps have been kind of needing. And they compare it to a library that is just the V in MVC, and those things are just apples and oranges. And what I have noticed is a lot of the times, people put these small little benchmarks. Oh, this is much faster. But actually when you build a full production application, and you have to bring in things like the router, and you can bring in things like a data library, and you can bring in all these additional helpers to build the production application, they end up being comparable.

So if you look at the final size of the Ember app, compared to the final size of the JavaScript payload built for an app using other libraries, they end up being about the same. On average, this is of course a different thing. But you can do this experiment. Go to a website. Look at the size of the JavaScript. It's always between 500K and a megabyte. It just always is.

So that being said, I think there really is an opportunity to build something that is even more optimized. Particularly, one thing that I've been focusing a lot in the last year or so is we can use audiences that are in emerging markets where the devices are not quite as high powered as what we might expect in the US where network connectivity is both slow, and often times very spotty.

JH: Yeah.

TD: And I think what's great about focusing on that use case is that if you make that fast, it's going to be screaming fast in developed markets. Screaming fast. And so that's what the GlimmerJS project has been about. GlimmerJS is our laboratory, our experimental laboratory for conducting experiments of what is the absolute fastest web app that we can build if we can put aside the backwards compatibility for a moment, embrace cutting edge, new web technology.

Stuff like binary data, service workers, WebAssembly. If we can combine all of those ingredients, not yet worry about backwards compatibility, what is the absolute maximum performance that we can get out of the web? And I think what's been so great is that we have done that. We did that experiment at LinkedIn. We rebuilt the feed in GlimmerJS. And it was super, super fast.

JH: Oh, wow.

TD: I think what's awesome about the Ember model is that Glimmer's the laboratory for experimentation, but we have a way of taking that experimentation, taking the learning from that, and up streaming them to Ember in a way 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, we know it's around for the long term. It's not going anywhere.

And so that kind of tick-tock cycle of experimentation in Glimmer, up streaming ... Ember, despite being as old as it is, has never been more technically advanced than it is now. Glimmer and Ember share the same Glimmer VM rendering engine, so a lot of the improvements that we do when we're targeting these emerging markets kind of up streams to Ember automatically.

JH: Sounds like a lot of energy and time has been put into that. That's cool. So EmberConf is coming up next week, and you're giving the keynote. What should attendees expect from this year's event? Not necessarily your talk. I know you probably don't want to give anything away, but, what about the event? What should they be looking forward to?

TD: Well, so here's the interesting thing about Ember is that we are ... I work for LinkedIn, but Ember is a community project. The members of the core team, we work for many different companies, big and small, from LinkedIn all the way to 1 or 2 person consulting shops. So the thing that's interesting is there is nothing that we're going to talk about in the keynote that is not on GitHub right now.

JH: That's cool.

TD: And I think that makes us a very special framework. We do literally everything in the open. We do everything for the RFC process. All the code is pushed to get out the second it gets written. And that is very important to me. I think that's how to do open source right.

So there's no worries about giving anything away. I think there are really two themes in the upcoming EmberConf. The first is ... Our vision for the series for 3.0 series is about simplifying Ember. We really want to keep distilling it down to just a few core concepts. What is the minimum we need for robust routing? What is the minimum you need to know for a robust data layer? Simplifying the component model.

And then I think the other thing is looking at the landscape, because there are so many cool, new features that are now landing in browsers... features that we can start taking advantage of…classes, decorators, async functions. We want to take advantage of those, but I think there's a tendency to rush in and say, "Oh, this new feature's available. Let's start using it right away."

For us, because we are used in so many real world production applications, it's very important for us to adopt those new features in a productive way. You can't adopt new features, but regress from productivity. So I think what you're going to see at conference this year is a way of making the developer ergonomics that Ember is known for in a way that can break into all these cool, new technologies.

JH: So this might be a little bit of a weird question, but what's it like to be part of a project like Ember that blows up the way that it has? So you were telling the story you're at Apple, and you're a new developer, self-taught, and then you're part of this project that just blows up and developers all over the world start using it. Big companies start adopting it. And now it's got, for many years now, it's own conference. What's that like?

TD: It is very cool. It's not a weird question at all. It is a fantastic question, because I consider myself to be one of the luckiest people in the world. I absolutely love my job. I have friends from all over the world. I think I have friends now on every continent because of the incredible gift and the honor of being invited to speak at conferences all over the world. It is so humbling, and it is so rewarding. The code is not really ... code is code. But for me, the Ember community is such a fantastic, welcoming, hard working community. So friendly, and I think dedicated to a higher purpose.

But even outside of the Ember community, open source is such a shift in the way that we work. And it has allowed me to work with the smartest people, the kindest people from around the world even though we don't work at the same company. And that is so liberating. For me, I know there's often times talk of burn out and open source's sustainability. I think those are really important conversations to have, but open source has completely changed my life for the better, and I am ... Sometimes I wake up in the morning and I am just sick with gratitude.

JH: That's great. My last question that is about open source and what advice you have for new developers who, they feel like they want to start contributing to open source, but it's intimidating, they don't know how to go about it. What would you say to a new developer who wants to do it, but is nervous about getting into an open source project?

TD: That's a great question. I think that a lot of times, the impression of open source is that you have to contribute code, and you have to contribute features, and that is what open source is. But there is tremendous value ... I'll say this as a maintainer. Having people who hang out on GitHub issues and just try to help triage ... If someone posts a problem that they're having. If someone comes along and says, "I have reproduced this. Here is the reproduction." Or, "It looks like you are just using the API wrong, here’s a link to StackOverflow. This can be closed." Stuff like that is such a time saver. Just hanging out wherever the community hangs out in chat rooms, and just helping people. Those are contributions. They matter.

And whatever your skills are. Whether it's ... If you can write well and contribute documentation, write blog posts. Design is important. Infrastructure is important. There are a lot of people who got their start with Ember, they didn't even particularly know JavaScript that well. Maybe they had a Ruby background, but they were able to help us out by working on our release infrastructure or provisioning AWS S3 buckets for us. Those are all valuable contributions. So I think there's a lot of resources that cover those things and say that. That's not really fairly a novel insight.

There is one thing that I think I contribute that's novel, which is ... Or something I haven't heard other people say, which is that for me, as a maintainer, your consistency is actually more important than your raw skills. Because raw skills can be improved over time, but as an open source maintainer, there's thousands of people in the community. A lot of people mean really well. They say that they want to help. But, for me, I have the same 24 hours in the day as everyone else does. And I like to sleep, so far less than 24 hours. And you gotta figure out how to spend that time. And even if someone is really skilled, if they show up and I don't have confidence that they're going to cross the finish line on it, then it doesn't make sense for me to invest the time.

So I think the biggest thing, if people want to get involved. The biggest thing that they could do is show up, take on the task, and if you are going to ... If you say you're going to do the task, actually follow through and do it. For me, it is more valuable to have someone who has four hours to spend every week on open source work, than someone who can dedicate two weeks to some big project, and then I'm never going to hear from them again. Because now I have to maintain that. Because now their problem is my problem.

So consistency, even in small amounts, I think ends up compounding in a way that just big blocks of time don't. So if you optimize for that, I think it makes the process a lot easier. It certainly makes the maintainer's life a lot easier.

JH: That's great advice. And I really appreciate you answering my questions and spending time with me today, Tom.

TD: It was great talking to you. These were fantastic questions. I am extremely impressed.

JH: Thank you. Thank you very much.

And Finally...

Huge thanks to Tom for talking with me. It was a fascinating conversation and I particularly loved the parts about JavaScript history and how he fell into programming. There's a good lesson there for new devs, I think.

If you’ve enjoyed this post, sign up for my weekly newsletter. I curate the best JavaScript writing from around the web and deliver it to readers every Thursday. The sign up form is below.

Until next time, happy coding…