Ember interview with Tom Dale, a Robust Framework | Episode 003

Craig McKeachie: [0:00] On this episode, I interviewed Tom Dale who helped create Ember.js about how Ember differentiates itself from other frameworks with a robust router as well as what’s going on with Ember data. This is Front-End Developer Cast, Episode Three.

[0:14] [background music]

Craig: [0:24] Welcome to the Front-End Developer Cast, the podcast that helps developers be awesome at building ambitious web applications, whether you’re a JavaScript ninja or you’re just getting started. I’m your host, Craig McKeachie.

[0:35] Hi everyone. Welcome to the third episode of the podcast. I’m really excited about the great response I’ve gotten so far. If you haven’t subscribed yet, please do this in iTunes, Stitcher, or via RSS by going to frontendcast.com. The podcast is still hosted on my blog at funnyant.com, but there’s now an easier way to find the podcast. Just go to frontendcast.com.

[0:58] If you’ve already subscribed, then please leave a review in iTunes. This is the best way for other people to find out about the show.

[1:05] Personally, I’m still adjusting to not having an office job lately, and working on my book, but really enjoying being around my family more. I was just the mystery reader in my son’s second grade class today and got to walk him home on a nice spring day.

[1:18] The book I’m writing on “Choosing a Single-Page Application Framework for Your Project,” is coming along well.

[1:24] I’ve written close to 30,000 words at this point. I have just a few more chapters and lots of editing to do, but I decided to make it available for pre-sale on my site at Funnyant.com in the next couple of weeks. I’ll keep you updated.

[1:37] Let’s move on to today’s interview with Tom Dale, who helped create Ember.js, which has rapidly been gaining momentum in the ongoing JavaScript MVC debates since releasing version 1 in the fall of last year.

[1:48] For those who aren’t familiar with Ember, it’s a JavaScript MVC or model view whatever framework, similar to Angular.js, but differentiates itself with a robust router that is a full-state machine as well as supporting nested routes and templates.

[2:01] Here’s the interview.

Craig: [2:02] Hi. I’m lucky today to have Tom Dale with me, one of the creators and founders of Ember.js. Real excited to have him on the program, needs not much of an introduction here [chuckles] .

Tom Dale: [2:14] Thank you Craig, thank you very much for having me.

Craig: [2:15] I don’t hear a lot of people talk about, “What do you do for a day job?” and “How does this all tie back to this Ember.js stuff?”

Tom: [2:21] Sure, yeah. I think a lot of people think that people who go around and travel to conferences and work on open source probably have a big corporate sugar daddy, which is maybe even true.

[2:30] I think for both Yehuda and I, being independent was really important. We also didn’t want to be on the venture capital treadmill, where it’s like, raise $10 million and burn through it, and then raise another $10 million and burn through it.

[2:42] Yehuda and my other two co-founders, Lea and Carl, we founded Tilde just over two years ago, and initially we made our money doing consulting. That was a way for us to run the company without having to raise venture capital.

[2:55] Since then, we’ve been mostly focused on a product called “Skylight,” which is a tool for measuring the performance and fixing the performance of Rails applications. It’s actually been very nice because working on a product Skylight; it’s an Ember app sitting on top of Rails and a pretty sophisticated job of back-end.

[3:12] We’re very lucky in that we get to use our open source technology on a product which is really great and then, as for supplemental income, we occasionally do some training and screen-cast and stuff like that for Ember. Slowly we have been focusing more, and more on the product.

Craig McKeachie: [3:27] Is the product live and out there? Is there any product development? How does that work in terms of eating and stuff like that?

Tom: [3:36] It’s definitely tough. [laughs] We’re in private beta right now, so we have a sign up list. We launched it at last year’s Rails conf- and we’ve been on boarding people very slowly, but we do have paying customers, which is nice. More than you can say for a lot of VC companies. [laughs]

[3:53] We are hoping to open up soon, but the interesting thing about what we are doing, the computation that we are doing on the performance data we are collecting out of this Rails applications, is so much more sophisticated than what any of our competitors our doing.

[4:05] It requires a ton of number crunching and we give you much better, much more actual data because of the number crunching so we just did not want to build a system that would crash on day one. We’ve slowly ramping it up and we have got a big refactor coming out, it’s re-written using Storm and Trident.

[4:20] Very big data, real time, Java, serious business enterprise stuff. Once we roll that out, I think we will start on boarding a lot more new people.

Craig: [4:29] Sounds great. That gives me a good perspective on…That you have work with framework every day, you eat your own dog food and that sort of thing and that’s great.

[4:37] When do you find time to work on the project? I noticed you have a lot of contributors to the project now.

Tom: [4:42] We do, yeah, and actually that’s been really great. We actually were very lucky in the early phases of the company. Yehuda and I were both working for startup called “Strobe.”

[4:50] Strobe paid for us to work on what was then called “Sprout Corp 2,” and then when we left, re-branded to Ember. Since then, we’ve had very generous support from several different companies.

[5:01] Living social, Square, McGrawHill Education Labs. They basically paid us for our consulting time to work on Ember, which has been just really phenomenal.

[5:10] We try to make time, everyday, to work on open source whether it’s on evenings or on the weekends. We also get to get for a few hours and hack, but I’ve been so thrilled. I think we just came in and I think we set a vision for the project.

[5:26] The community around Ember, especially in the last year, has just exploded. The people doing the day to do work of managing photo requests, writing new features, it’s not Yehuda and I any more.

[5:37] We’re around to answer any questions, but by and large the bulk of the work is done by people just using Ember at their companies, which I think is really phenomenal. I think the reason for that is, if you think back to 2011, two, three years ago. 2011 if you wanted to build those really ambitious apps in the browser, you were kind of a pariah.

[5:57] If you think about that time, there was this micro library movement. Backbone was the hottest thing on the planet. You’d read comment threads on hacker news, and they would say, “Ember is this huge library. It does all this crap. Why not use Backbone? Backbone does the same thing, but it’s much more lightweight.”

[6:13] Of course, Backbone had 900 lines of code; Ember at the time had something 20,000 lines of code. They obviously didn’t do the same thing, but there was just this attitude of, “You really didn’t need these abstractions.” I think it’s because a lot of people didn’t have any experience building a real 100 percent client side app.

[6:28] I think at the time, we were really the only people who were like, “You guys are crazy. You need abstractions to help you manage a larger app. You just need abstractions. All of human progress is built on building up new abstractions.” I think that really drew people who believed in that cause; that cause of, “We’re going to build awesome tooling for the browser. It might take us a couple of years, but we’re going to do it.”

[6:53] I think that in the JavaScript community, we attracted some of the best and the brightest. That strategy, while it was initially painful, not being able to hire people but just needing to attract them in open source, initially was very painful, but I really think it paid off for us.

Craig: [7:07] That was a good sort of recap. I think we touched on it before we turned on the recording here, but can you dig a little deeper into how you viewed all the competing frameworks in this game and then you see the evolution? I’ve definitely heard other people say there’s some generations of them or this sort of thing.

Tom: [7:24] Definitely. It was very loaded question. I should make sure I don’t get myself in trouble here.

Craig: [laughs] [7:28]

Tom: [7:29] The first thing I should say is that all of the JavaScript frameworks that are at all popular are written by very smart, very capable people, for whom I have nothing but the utmost respect. I am a big believer in picking the right tool for the job. I’ll be frank; there are jobs where Ember is not the correct tool.

[7:47] If you were building a component, a third party widget that you’re embedding in some else’s site, you shouldn’t use Ember. It’s too big. It just does too much. If you’re building a page that doesn’t have to deal with URLs, if you’re just making interactive pieces of one page is traditionally server rendered, I don’t think you need Ember.

[8:02] I think that you need Ember when you are building a 100 percent JavaScript client app that talks to an API, and you have multiple pages. You have any kind of sophisticated UI. We really want to help you map your application state onto the URL. By definition, that means that you are building larger apps that have complicated state. If you can reason about it and handle it, you don’t need Ember.

[8:26] The thing that I’m glad about is that the landscape has really shaken out. There was a time where someone could piece together a 500, 600 line JavaScript library, MVC library, and post them on Hacker News. You would get people commenting very breathless. They’d go, “This is amazing, this is awesome.” I’m really glad that fetishization of micro libraries has finally passed us.

[8:52] I think what’s left obvious to me, is Backbone, Angular and Ember. I think Knockout, too. Knockout’s very popular, but there’s a little bit less buzz about it. It doesn’t seem like it’s really evolving towards anything, but it’s definitely a very solid candidate right now.

[9:07] I think you could say the same thing about Backbone. Backbone is relatively fixed. I don’t think there’s any plans from the Backbone team to try to expand it at all. Really I think what is left duking it out, is Angular and Ember. I’m hoping what happens is, in the same way [laughs] in 2011 and 2012, Backbone and Ember were really duking it out. People really thought of them as more or less doing the same thing, but no-one thinks that any more.

[9:32] I think the same thing will happen with Angular. Amber will find its niche, and Angular will find its niche. People will have a much better mental model about which problems are appropriate to solve with each tool. I would be very happy in a world where it’s like Rails and Jango. You pick the tool that makes the most sense to you. You pick the tool that happens to be a little bit better for whatever particular problem you’re solving.

[9:52] I’m just really glad it’s shaken out, because it was getting really irritating having to defend ourselves against the “flavour du jeur” on Hacker News every week.

Craig: [9:59] That’s very helpful for our listeners and very politically correct there.

Tom: [laughs] [10:02]

Craig: [10:03] Sorry about the loaded question. How are you guys trying to differentiate yourself in your framework?

Tom: [10:09] The biggest one, like I said, is rooting for big apps. I gave a talk today and one of the things I said in the talk is, people think of MVC as being an application architecture, but it’s not. MVC is a component architecture. Your app is made up of many of these little groups of MVC units. It’s not just one model, one view and one controller.

[10:30] You’re going to have many models, many views, many controllers. Sometimes, all of them are on the page. Sometimes, none of them are on the page. There’s just so much flexibility here and so much variability in what you’re building. That’s part one. MVC is a component architecture, not an application architecture.

[10:45] Second, URLs are extremely important. The web is a viral place. The notion that I can take what I’m seeing and I have this UI for taking that URL out of the address bar — I can command click to open it to floor off the process, essentially. I can share it on Twitter, I can send an email, I can bookmark it — that viral web is extremely important. That’s what makes the web, the web.

[11:12] Historically, we were very lucky by accident. It was very accidental, but in order to build server rendered web applications, you have to have URLs because if the browser can’t hit the server by definition, you don’t have an app. Then people were like, “Well, server is fine, but wow, we can build really awesome UIs, really fast, really responsive, if we do it in JavaScript”.

[11:33] They started doing that, but they completely forgot about the URL. There was like a whole generation of JavaScript apps that you would use them and the URL support was just terrible. People would notice, like, “Don’t click the black button.” You refresh the page, you just lose everything. It was terrible.

[11:49] Our goal is to build a framework where if you just follow a couple of the rules of the framework. Just follow a couple of these rules about how you architect things, we can guarantee you that you’re going to get good URL support out of the box and that ties back to what I was saying a second ago, which is we want to build a framework where you architect things in terms of these groups, these components of MVC and then those get mapped back on to the URL.

[12:15] That should be as seamless as possible. If you have to think about it as a developer, you’re going to screw it up. If the framework does it for you, if it’s automatic, then you’re just going to build apps that happen to have the URLs. You don’t have to put any extra load on it, and it’s not just a feature that you check off anymore. It’s something built-in from day one.

Craig: [12:29] Let’s take a little bit more into the router for the audience. Can you maybe elaborate on the master detail example that I’ve seen in several of your online presentations? I think that sort of helps people understand where things start to break down with some of the other frameworks of URLs.

Tom: [12:43] Absolutely, I think there’s a temptation where the notion of composing each page into these separate units. If that notion’s not built in, I think people treat the controller and the mauler. They treat it like a juncture.

[12:57] I review open-source Backbone apps, I review open-source Angular apps whenever they come out and many of them, you have one dollar scope an Angular, for example. It was just a dumping ground. Your whole app is a controller just dumping stuff in here and it’s clearly not maintainable

[13:13] The point of the demo that I gave is to show a master detail for you where you really want to be able to architect your application in such a way that you have these groups on screen. At any given time, you have, for example, the thing that you just said was the blogging example.

[13:29] You may want a UI where you have a list of all the blog posts on the left and you may want a blog post on the right, like a particular one that you want to read right now and clicking that link shouldn’t replace everything. It should just replace the particular blog post.

[13:42] Having a system that lets you very easily break that into two, so you have one template, one model, that’s a list. You have another template, another model, that’s a particular blog post, just makes working on these apps, especially on a team much nicer than let’s just turn this into a dumping ground.

Craig: [14:02] Let’s talk what the URLs look like in that scenario even though it’s difficult here on a podcast, but you know. I think it would help and people would appreciate it more. What I saw was /blogs, gives you a list of…

Tom: [14:13] That’s what we would call like an implicit model. You say /blogs, there’s no unique identifier. I think /blogs is identifying both the template and the model. In that case, if you come in to your app and say /posts and say come to /posts, that means show the post template and get all the post models that the app knows about.

Craig: [14:33] Thanks for fixing my blog posting.

Tom: [laughs] [14:34]

Craig: [14:35] I’m sure I had all the listeners quite confused there from it.

Tom: [14:38] /posts, yeah.

Craig: [14:40] /posts, anyway, so continue please.

Tom: [14:41] There’s that and then you have URLs like /posts/1 and that’s telling us, well, we want the posts template, but we want it to show the post with the ID of 1, for example. I think if you look at most URLs, URLs that are considered clean, the contents of MVC map on to the URLs very well.

[15:04] There’s some basic routing support. Backbone has a very basic router. Angular has the router, but I think one thing that we have been working on for the next version of Ember, that should be going out — which I think is really cool and no one else really handles is…Everything that we talked about so far has been mapping templates and model information, but there’s a big of a question about, “OK well, there’s a lot of state also in the controller that you want to capture and you want to serialize into the URL.

[15:31] Right now, in all these frameworks that’s being lost. We’ve got this future coming out member called [inaudible 15:36] and this makes it super simple, super declarative to basically annotate your controllers and say, this particular controller property should be saved into the URL. Now, that’s a little bit abstract, so let me give you a concrete example.

Craig: [15:50] Before we go there, I think we may have missed the new ones that you know, from you doing this presentation a bunch of times.

[15:55] Just to describe the page, we’ve got a list of items and then when you click on the list of items, both the list stays on the page and the detail of the post comes up, so then the URL become post/1 or 5 or whatever the case may be and the way you guys are achieving this is sort of through composability.

[16:13] In other words, that you don’t have to rewrite the list control on the left side of the page or the list template — I guess that would be a better word — on the left side of the page or you get re-used out of that in that same composable template. I think that composable story is a great story there.

Tom: [16:29] Yeah, I think it’s a good story and I think what’s also cool is that the Ember inspector makes visualizing what’s happening there, very easy. You can just take the Ember inspector, which is a Chrome or Firefox extension and you can go to any production Ember app, bustle.com, vine.co, any of these things. You log in into the production app and you can actually see how their templates and their models are composed. Visually, it just makes so much more sense than [inaudible 16:52]

Craig: [16:53] I saw you trying to hack it, one during a presentation. We’re going to try to change somebody’s name. You mentioned that this is a good way to play a practical joke on someone.

Tom: [16:59] Yeah, it is a good way of playing a practical joke. In inspector, you can open up, so you have these nested templates and each template has its own model and that maps on to the URL. You just open the inspector and you can see all those things, visually it’s laid out and so you can just click on one. It’s funny to play a joke on people because you get access to the raw underlying JavaScript model and so you can play jokes on people by changing any of the properties in that model. It’s all light bound. It’s [inaudible 17:24] . It’s pretty funny.

Craig: [laughs] [17:25] There might be a whole site dedicated to this soon.

Tom: [17:28] Emberpranks.com.

Craig: [17:30] Embervinepranks.com, something like that. Get the URL before this podcast is over. I had to track you from an important point there. You were talking about the future coming.

Tom: [17:39] Oh yeah, [inaudible 17:39] . I should say that this is available right now. Ember has a very Chrome-like release process.

[17:46] Every six weeks, we cut a new version and we also cut a beta version and we call it canary version, similar to Chrome. All of the features that we’re working on are behind feature flags. If you are interested in a feature that we’re working on but maybe we haven’t quite finalized the API yet, you can download the canary build and there’s a feature flier that you can turn on and that will allow you to play around with the feature without having to worry about…You can start playing around with it without having to wait for the official release to come out.

Craig: [18:16] You explained the release cycles, so in which one of those version is the [inaudible 18:21] right now?

Tom: [18:22] You can go online right now and download the canary release which we do a new nightly every night and you turn on the [inaudible 18:28] feature. Let’s back up and talk about what kind of stuff controllers’ store. What stake controller store? In Embers point of view anyway.

[18:36] In Embers point of view, controllers are responsible for controlling application state. There are things like filtering or sorting where that doesn’t really change the model. That’s just changing how the model is presented and that’s the kind of thing that a controller and an Ember app would be responsible for.

[18:54] What [inaudible 18:55] allow you to do is say, OK there’s a controller property called let’s say filter and it contains a string that we’re using to filter all the models that are displayed to the user.

[19:03] Literally one line of code, you say, “OK this filter property I think I want users to be able to save it from the sessions. I want that property to be shareable.” You just have one line that says, “OK this filter property is a [inaudible 19:17] ,” and that will automatically be persistent into the URL for you, and also vice versa.

[19:22] When you come into the app, we will extract that from the URL and we’ll set it on your controller for you automatically. It keeps your controllers and the URL in sync and you don’t really have to worry about it. You just mark it as, “This is the thing I care about and now boom, it’s shareable, it’ put [inaudible 19:35] et cetera.

Craig: [19:36] Great. I’ve heard the router being described as more of a close to a full state machine.

Tom: [19:42] It’s actually…I think we do a good job of putting a lot of syntactic sugar around it. It’s under the hood and extremely powerful state machine. We’ve done some really novel work in state machine in terms of making it asynchronous.

[19:55] I think that’s really the part that our competitors are going to have a hard time catching up with. This is like a state machine where from the ground up we thought, “OK, what does state machine look like. If you have transition that can be deferred, aborted or even if they just take a few seconds to happen for an animation for example.”

[20:13] Let me give you an example where this is useful. Imagine that you’re building a form that the user can edit; editing their user profile or something. They’ve entered in some information, but they haven’t yet clicked the save button, and then they click a link or they click a button that’s going to take them out of that state, off that page.

[20:28] To deal with this key, you obviously want to probably be like, “Hey, you’re about to lose data.” You don’t want to do that, but they just click the button to do the transition, so what do you do?

[20:36] Well, you can put in these hooks that are called the four transition happens or after transition happens, and in that hook you can actually pause the transition and you get a transition object that you can hold onto and you can replay that transition at any point in the future.

[20:51] Basically what you do is you say, the user clicks away, you pause the transition, you pop up some UI. It’s like, “Whoa, are you sure you want…You’re going to lose this data if you transition out.” Then based on what they clicked, you can either say transition got replayed or transition got cancelled and everything else continues to work as before.

Craig: [21:07] When they click save, they might navigate to the place where they’re originally trying to go?

Tom: [21:11] Yes correct. You just say transition that continue…I forget the exact API. It’s “transition.continue” or something like that and then it will just continue on as though they had clicked whatever they had clicked without the interruption.

Craig: [21:23] That’s a great feature. Yes, I like that. I noticed in the presentation, our code match I didn’t mention that before. Tom just did a presentation on URL driven web apps I think it’s available online. Go check it out. A very good introduction to Ember. The router versus the route, I even heard you say in the presentation, “That’s the router. It’s kind of like a controller.”

Tom: [21:44] The router. It’s like…I think that…

Craig: [21:47] What about the naming though? I’m sure you did that intentionally, so…

Tom: [21:50] Yeah definitely.

Craig: [21:51] …I’m curious to try to clarify that.

Tom: [21:52] Sure totally. The router is really just an object that defines all of the routes in your system, all of the URLs in your app. The router, the only interaction that a user is going to have with the router is that we have a DSL for defining all the routes.

[22:06] Say this .resource post, this .resource post et cetera. That’s about it as far as what you need to understand as an member developer about the router. I’ll talk about routes now, route objects.

Craig: [22:17] I’m sorry. I’m sure you said routes?

Tom: [22:19] Yeah, so there’s route objects and these are kind of novel object that we introduced into the architecture for the traditional MVC architecture. If you’ve ever read a book on Cocoa or ever done EMAC or iOS programming, in Cocoa you have the notion of a coordinating controller…an intermediate controller I think is the name for it.

[22:41] These are two roles that the controllers serve. The coordinating controller is responsible for doing all the setup of other objects responsible for rendering views; it’s responsible for gathering data. Then there’s the other type of controller which basically serves an intermediary between the view and the model.

[22:58] It does more transforming of data. It basically gets the model ready to be prepared for the view. It gets the model ready to be in whatever format the viewer is expecting.

[23:07] I think for us, routes take the role of coordinating controllers. There are essentially controllers that setup the state of the application, but we call them routes because everything that they are doing is driven by the URL.

[23:23] It’s essentially an object whose responsibility is to translate the URL into application state and then similarly if application state changes, transform that back into a serialized form and put it into the address bar. I don’t think of them as controllers per se, not in the classic sense of a Backbone or an Angular, but if I think about the architecture of the application, I think it fits into MVC, that kind of layering, and I think the route objects fit into kind of the C layer.

Craig: [23:53] I’ve always wondered about that when I see the framework. I know this was intentional, but yeah. Just to rehash that to make sure I’ve got it, so the router is the object where you’re doing what people traditionally think you’re doing a route which is map URLs to pass and…

Tom: [24:12] Like the rails router.

Craig: [24:12] Rails router.

Tom: [24:13] Yeah rail router.

Craig: [24:14] The route object is most easy for people who are familiar with service item C frame works to think of it as a controller, but there was some reasoning behind that which you’re interested in?

Tom: [24:27] Yeah. Instead of just mashing everything together, instead of saying there’s one conflicting controller, the controller acts as an intermediary between the templates and the model and it also sets the application state. We broke those two concepts in two. I think it’s a little bit easier to reason about once you understand what’s the…

Craig: [24:43] Let’s talk about Ember data a little bit.

Tom: [24:45] Sure.

Craig: [24:45] I wrote a post on funnyad.com. It was very popular. It got hundreds of comments and not to promote it, but one of the comments I got that was probably one of the most insightful was, “Gosh, do you know that discourse doesn’t even use the Ember Data and…This framework is unfinished this sort of thing.” I’m not sure that’s a fair comment, but I wanted to hear your response to that.

Tom: [25:05] Well, I think that’s an extremely short sighted comment to be frank with you, because I don’t perceive it as a problem that discourse isn’t using Ember Data. Ember Data is a separate project and its goals I’d say are just as ambitious as Ember proper. It’s going to take as a little while to get there, but we’re very close releasing a 1.0 version of Ember Data.

[25:25] The reason that I think that particular comment is either disingenuous or intellectually dishonest is, neither Backbone nor Angular actually have any data libraries that come even close to doing what Ember data is doing.

[25:41] If you write a Backbone app or you write an Angular app you’re going to need to somehow marshal model data into that application anyway. The tools that…For example Angular gives you, it gives you like dollar HTP. We don’t need dollar HTP because just use jQuery. We don’t want you to make you [inaudible 25:56] tool. Just use jQquery, so you can use jQuery or they give you dollar resource which is like a very small implementation on top of dollar HTP and frankly it’s completely panned by the Angular community.

[26:08] If you ask any serious Angular developer, they’ll tell you not to use dollar resource. I find that particular argument completely disingenuous. It’s not hard to write a model library. You don’t have to use Ember models. Just go grab a Jason pay load using Ajax, using jQuery, whatever library you want to use, give it to use in the model hook and we’ll put it in the template for you and it work just fine.

[26:29] Ember without Ember Data works no different than Angular or Backbone, so why are we getting nailed for that? I’m still not sure. I think people just have a bad understanding about what’s happening.

Craig: [26:38] What discourse is doing right now is jQuery isn’t [inaudible 26:41] of your library, so they’re simply using the built in things that everybody is familiar with HTP object. In Angular, for example, the HTP use the [inaudible 26:49] .

Tom: [26:50] Well, jQuery doesn’t work with the digest process, the dirty checking. You need dollar HTP to know when to apply digest changes.

Craig: [26:57] That’s the reason they wrapped it. They’re not adding a whole lot there…

Tom: [26:59] Correct right yes.

Craig: [27:02] People could argue that in the resource area, there are people I’ve seen who are OK with the resource model, but it’s not a ton on top of it let’s put it that way. It’s not doing a lot for you.

Tom: [27:09] It’s not doing a lot for you that true.

Craig: [27:10] Let’s talk about what are Ember Data’s more ambitious goals? As a community, a lot of people aren’t familiar with what’s coming. What is so cool about Ember Data? What’s so much better than just make an Ajax calls?

Tom: [27:23] First only talk about the concept of an identity map, because I think an identity map is very important. For any listeners who are not familiar, an identity map is simply an object in memory that if you ask it for a model particular ID, it will always return let’s say in model back.

[27:42] This is really important because what it means is that, if you have an application and your user is moving around the application, you are only fetching data that you haven’t previously fetched over the wire before.

[27:57] If you think about a server rendered application, and if I click to a link to a certain blog post, it’s going to load an entire HTML representation of that whole app over the wire. If I click on a link to another blog post and I click back to that original one, it’s transferring a ton of HTML every time. You can reduce that pay load by using a JavaScript framework, but if you don’t have an identity map you’re still having to load at least the JSON representation of that resource every time the page changes.

[28:21] What identity map does, it basically says, “Let’s keep in memory all the model data that we have loaded.” If we move around the application, if we’ve already loaded that over the network, we’ll just immediately hand you back the model that we had previously loaded.

[28:36] This is also important because it means that any changes that happened to that model in different parts of your application, you don’t have to think about, “Is this model the same?” If you ask your database, your data library for a particular model, if it gives you back a different instance of that model each time, then two separate parts of your application making changes to it, they’re going to quickly go completely out of sync.

Craig: [28:56] Right, and cause a lot headaches?

Tom: [28:58] A lot of headaches, a lot of chaos, yeah. We do that and then, I think what we do is pretty cool is we just have…Ember Data has actually — in scope — gotten a little bit smaller in the sense that it is purely a wrapper around a asynchronous network request or not even network request.

[29:14] It’s very easy to write and adapt to an Ember Data that will wrap things like index DB for example so you can have like a right through cash so that the app [snaps fingers] puts up like that without having to do a network request. Then because you have this identity map, it’s super easy to plug it into a socket.

[29:29] You plug it into a socket [inaudible 29:30] for changes on the server or hosted server like fire base for example, and as those changes stream, because everywhere in your application from the web socket to the model in your templates, because they’re all pointing at the same instance of that object, because of the identity map, any changes made anywhere are reflected across the entire system.

[29:49] That’s the important bit, that’s basically the core concept. There are a couple other libraries in different frame works ecosystems that are attempting to do the same thing, but the thing that they don’t do is relationships. It turns out doing the thing that I described is…

Craig: [30:01] Media I’m sure you’re really referring to right?

Tom: [30:04] Yeah. Well, media I think is kind of a no go because it ties you into Mongo and no one is seriously using Mongo in production. More importantly, doing the thing I described is…You can hack something out like a month, let’s say. Like a really robust thing that doesn’t [inaudible 30:18] anyone could do it probably in like a month or so. Adding relationships, oh my gosh, the complexity just explodes, but you need it.

[30:26] In Computer Science, we need to model tricky relationships between objects and taking those tricky graph relationships and keeping them in sync across the network, you have a distributing computing problem now and that’s a really hard thing. That’s what’s taken us a really long time to figure out. Is, how do we solve that problem, how do we make an API that’s nice to use that you can adapt for JSON API’s that are totally not normalized, and then also sockets and xDB?

[30:53] I think we’re very close.

Craig: [30:54] That’s a lot of problems to solve.

Tom: [30:56] There’s a lot of problems to solve. I think that we have a history of tackling really ambitious problems.

[31:00] Sometimes it takes us longer to get there than we think we will, but in the end, I think that we’re committed to doing it in a quality way. Not just packing something out as soon as we can. Anyway, it should be pretty soon. We just have one last major refactor in terms of how our relationships are handled, which I’m hoping to land in the next couple of months.

[31:15] After that, we’re going to try to keep Ember and Ember Data in blockstep, so that we basically synchronize their releases, and they’re guaranteed to work compatibly with each other.

Craig: [31:24] Great. I’m excited to see what you guys come out with. One thing you mentioned in the presentation that I thought would be helpful for people to hear was, there’s string templates and there’s DOM-based templates, and you talked about some of the pros and cons.

[31:36] I personally was having a hard time, besides the performance argument, ever really warming up to string templates, but you made some very good points. Can you talk about some of the things you guys think about and why you chose…?

Tom: [31:46] Sure. Absolutely. Probably one of the most important ones is that you don’t need a DOM with string-based templates.

[31:53] For example, if you want to take Handlebars templates and render them on the server, you can just do that, because the parser is just dealing with strings. String input for the template, string output which is all your HTML.

[32:05] You compare that to both Knockout and Angular, they lean very heavily on the HTML parser in the browser to convert HTML into DOM, and then they rely on that DOM-API existing so you can traverse the DOM.

[32:20] You need some kind of somewhat heavyweight solution on the server, whether it’s jsdom or spinning up a phantom JS. Instance for example is extremely memory heavy. It’s hard to do a lot of those in parallel without burning a lot of RAM.

[32:33] There’s that aspect of it, where you just have a lot more freedom.

Craig: [32:36] I hope people understand why you would need to render templates on the server and why people think about that.

Tom: [32:42] I think the most important thing is SEO, obviously. At this point, there’s a lot of search engines. Google is doing limited JavaScript execution but they haven’t really been public about it, so it’s hard to reason about.

[32:51] What Discourse does, for example, is they just render simplified templates on the server that they feed to Google. They have an API that you can do this so it’s not like shady, dark hard SEO stuff. Google realizes this a problem, they give you an API that you can use.

[33:07] There’s that, and I think also, eventually all of the JavaScript framework is going to have to support some kind of system for sending down an initial render in HTML. Just because waiting for the entire Joust payload to load before you see anything is a little bit painful, especially on mobile devices. I think we’ll see that relatively soon.

[33:25] I think also, we’re relying on the browser’s HTML parser, which you don’t have a lot of visibility into. For example, if you have a table in Angular, and you have two tr’s that you want to repeat for the model. If you watched the cage match with [inaudible 33:45] , this is one of the things that gets him. Because you want to repeat two tr’s for each item.

[33:50] The way that you would normally do that, is you would have some kind of wrapping div or wrapping span, but the browser HTML parser’s going to just totally eat it. It’s not even going to show up in the DOM. It’s just going to discard it, because it’s an invalid note.

[34:01] Now you have to put in all these hacks, you need “ng repeat start,” “ng repeat end,” put in a comment note or whatever, but now the parser in your brain has to know about all the edge cases.

[34:12] If you are the one whose code is doing the parsing, you don’t have to worry about that. In Handlebars, you just have the pound each helper, and you can wrap that anywhere.

Craig: [34:23] It’s outside of their bound, basically. It’s not in an element, right?

Tom: [34:26] Right, we analyze that and we see it before the browser generates any DOM. We have complete control and we don’t have to basically use the semantics of the browser, which is very nice.

[34:35] I think the last thing for me is, when I’m writing Angular apps, looking at a template, and quickly determining what parts are dynamic and which parts are static is quite tricky. If you have an HTML element that starts having a lot of different attributes in it, looking for the “ng-“, it just blends in. Having the double-curlies, whenever you have dynamic content, to me visually it just sticks out a lot better. It’s much easier for me to track down what’s dynamic and what’s not in an Ember template.

Craig: [35:01] I think to wrap up, let’s talk about, after that cage match I heard you say, “Gosh, if there’s one thing we admire…” You each had to say something you admire in the other framework.

[35:12] You mentioned the testability story, so you often get questions on the testability story, both unit and functional integration tests. How is that story developing?

Tom: [35:21] Really well. We have a package now, since the cage match, called “Ember Testing.”

[35:26] I think the trickiest part about testing JavaScript apps is dealing with asynchrony. The second you have to start testing asynchronous behavior, the reasoning about testing it essentially falls apart, in all of these libraries.

[35:38] What we did, is we wrote a testing package that includes a bunch of helpers, and the whole API is promise driven. For us internally, using promises for dealing with asynchronous behavior has made it so much simpler to reason about what’s happening.

[35:52] We expose these testing helpers that you say, “Visit this page, click on this button, fill in this form, wait for this value to become true,” and you just chain them all because they’re all just promises.

[36:02] It also integrates with any other testing library that uses promises because you just chain the promises. That’s really nice. I think that the next step now that we have that in place, is to make it just really easy to use.

[36:15] Unfortunately, right now, the landscape for build tools around building JavaScript apps is extremely fragmented. You have Brunch, you have Yeoman, some people are using Rails Asset Pipeline, some people are using Browserify, it’s so complicated.

[36:32] We can’t just tell people that are Ember developers, “OK, use this one particular tool and boom, you just get testing for free.” What we’re working on for the next few months is we are working on a set of note-based build tools, and once we have that in place, it does a bunch of cool stuff. It lets you use ES6 modules. It’s very nice, but built into that will be testing infrastructure.

[36:54] Once we have that, we can tell everyone who’s going onto our app, “Just use our build tools, and you’ll get testing for free.” Then using the new testing like that will just be extremely simple.

Craig: [37:03] Does that encompass the unit testing side or is it more of a [inaudible 37:06] ?

Tom: [37:07] Yeah, it does both. There’s the more integration testing, where you say, “Let’s verify that the app, all these pieces work together.”

[37:13] I think because the architecture in Ember is rather strictly enforced, it’s hard to break through the layering, the firewalls that we put between each of these layers.

[37:24] Unit testing is very simple. If you want a unit test a controller, you just instantiate it, you set some properties on it, and you see if whatever you’re expecting to happen happens. Similarly, with templates, you say, “OK, here’s my template, I’m going to give it this model. Do I get the HTML that I expected?” We have helpers to deal with all of those.

[37:43] I think it’s really nice, and at that point you can use whatever mocking or stubbing library that you want. The framework — both Ember and Ember Data — are completely unit tested and integration tested internally. We use QUnit for that, but I know a lot of people who use Jasmine, I know a lot of people who use Mocha.

[38:02] Like I said, the only problem is a lot of this testing infrastructure. In JavaScript in general, you have to set up by hand, and a lot of people just don’t do it. Hopefully we can fix that.

Craig: [38:11] Well, thanks for coming on the show today. It was a really good conversation, I think we got some good information out there to people, and I wish you guys luck.

Tom: [38:18] All right, thanks a lot, Craig. Thank you for having me.

[38:20] [music]

[38:23] Thanks for listening to the front-end developer podcast.

[38:25] Please subscribe to the podcast by going to the iTunes store on your phone or desktop, then searching for “front-end,” or via RSS by going to frontendcast.com, where you’ll also find show notes and a full transcript of each episode.

[38:38] We’ll see you next time.