Yes, sure. Thank you, Brian. My name is Tom. I guess that the thing that I am most well know for is working on a JavaScript framework called Ember.js which is an open-source MIT licensed JavaScript MVC framework, one of the 14 million JavaScript frameworks that are out there. I started a company as you mentioned – Tilde - with three other co-founders: Yehuda Katz, Leah Silber, Carl Lerche. The product that we are working right now is called Skylight which is a performance monitoring tool for Ruby on rails Apps. We tried to use the money that we made from that and doing consulting and funnel it into our open-source and standards body work.
Sure, yes. Definitely. I think that in terms of the JavaScript MVC frameworks, in a lot of ways Ember is the most ambitious in the sense that I think that what most people are doing is that they are trying to figure out what the ideal MVC architecture is and they are trying to come up with an API that feels natural, that feels good in the browser, it feels good with JavaScripts. A lot of times that means doing things like data bindings. Backbone was probably one of the most popular first light-weight MVC frameworks and people used it and they loved it, but they realized that writing all that code, all that imperative code manually, wire up, listening for model changes and then reflecting those in the DOM – that kind of sucks. Then we have things like Knockout, we have things like Angular that are really good at data binding which is a more declarative way of modeling the same thing like before and something like Backbone where you would be writing a lot of imperative code for. I think, in that sense, Ember does all of those things, but Ember is trying to do a little bit more than just the things that Backbone, Angular and Knockout do in the sense that what we want to do is say, we want JavaScript applications that are 100% or web applications that are 100% JavaScript. So you need multipage, you need URLs, you need the ability to move around. We want everything to be in JavaScript and so far none of these tools really give you a way of taking MVC, which is not an application architecture, it is actually a component architecture. Your application is made up of many different little groups of MVCs and so Ember is about how do we take those groups of MVCs and how do we put them into the URLs so your JavaScript web applications are shareable and how you can build them in a team without stomping all over each other.
No, all of them. I think it differentiates us from Angular, Knockout, Backbone. I do not think any of them are really tackling the problem in a holistic way. I think they often say it is up to you and every team. If you look at even open-source Angular, Backbone Apps, the architectures are quite different. If you look at them there is not really a strong sense of what idiomatic code is versus and Ember App, for example.
4. You recently reached 1.0, right?
We did, yes, which was a big relief. It felt like being pregnant for two years.
Brian: One of the things you showed in your presentation – I actually hadn’t seen it before – but the debugging tool. Early on, I remember talking to a colleague who was doing, trying to work on a sample app for a presentation that was in all three – Angular, Backbone and Ember – but Ember was much earlier at its development at that time and one of the things she said to me was it was so hard to debug Ember. I am assuming that has changed now with this debugger.
Yes. I have to give props to this guy Teddy Ziginy. He lives in Lebanon, I think. This guy is a machine. He has just been pouring so much effort into the inspector which, I think, is one of the benefits of open source. Once you have a vibrant community, it tends to compound itself. This is really exciting for us because we do a lot of stuff to make the development experience very, very nice because the browser really gives you a lot of primitives, but does not really tell how to put all those primitives together and unfortunately the tools that we have right now in the browser are “what are these primitives doing?” So when you try to build higher level stuff, a lot of times the debugging tool for the primitive stuff just does not really scale up, it does not give you a higher level view on what your application is doing. So the fact that we were able to figure out how to hook into the Chrome developer tools and we just released a version for Firefox as well, once you boot up and it is so cool for me. It has been so amazing to go to all of these production member apps, to open up the console and you can kind of see the MVC structure they have got, you can see all their controllers, you can see the models, you can see all the different routes they have in there. It is really, really cool and I think it just helps you get a sense of what is going on and it helps you understand all of the stuff that Ember is doing for you.
Sure, yes. I think that there is, by definition, going to be a little bit of complexity. Not complexity, per say, but you are going to have to learn new concepts. You are going to have to learn new things. I think Backbone, I think Angular are really awesome if you have been using Jif query for a while, if you are working on a shopping cart checker, you got a single page, you do not need to worry about the templates changing in and out, you do not need to worry about the models changing in and out, you do not maybe even have a URL. Maybe you are just taking a Ruby on rails application or a Jengle application and you are just adding a little bit of JavaScript sprinkles on top. I think a lighter weight framework that does not require you to learn some new architecture. In a lot of ways, the Ember architecture comes from things like Cocoa and things like Smalltalk. If you do not need any of that architecture, if your needs are not – if it is not a multi-page JavaScript application - I think you will be much better served by one of the smaller frameworks.
No, I think it is shaken out. I think that people kind of - Any time that you do not have a good understanding of a problem, of a problem space, of course when you come into it, it seems trivial. Things like MVC architecture, things like bindings. Binding seems trivial, but I have now put my name on two different binding systems and I can tell you that bindings are not trivial. You have things like cycles, you have performance problems. But, of course, if I describe what a binding is to you – it is like you have two objects, they both share a property and when one changes, update the other one. That seems easy. It seems really easy. So, I think what happened is, people came in and they heard the term MVC, maybe they watched the Ember demo or they watched the Backbone demo and thought: “You know what? That is pretty cool. But I think I can do a little bit better.” And so what everyone did was they tried to spike out their own and now we have an army of developers that have tried and failed to do their own thing and now they can appreciate it.
I think that is important in open-source projects. You should not be using something if you do not understand what is giving you. That is why I personally thought that the popularity of Backbone was really, really great for us because if you recall in my 2011, the big battle was between Ember and Backbone and Backbone is 900 lines of code and Ember was something like 20,000 lines of code at the time. People were like: “I do not understand why you would use Ember. It seems like Backbone is good enough”. If you can look at a problem, if the problem that you have can be solved just as easily by 900 lines of code than the 20,000 lines of code library, of course you should be using the smaller one. It just makes sense. So people did that. People used Backbone and they started understanding what the limitations were. Once they understood the limitations then they could really appreciate what we were really giving them in Ember. I think that we are seeing a kind of similar thing to that now, where people are graduating to Knockout or graduating to Angular and they are still in a honeymoon phase and I think that once they start butting up against some of the architectural limitations, then we will be ready and willing to embrace them with open arms and then they will better understand what Ember has been doing the whole time.
Brian: One of the things in Backbone that I have noticed is that in part of its evolution has been that now you are not just using plain Backbone. You are actually layering on top of Backbone other things that add in some of the features that are in some of the other frameworks. So it is definitely evolving.
Yes. It is interesting. I think that there is an interesting alternate history. What would have happened if Backbone had kept evolving towards Ember? But instead, what ended up happening is that the project solidified and I think that has brought a lot of benefit in the sense that it has been incredibly stable, although I think there have been some breaking changes at one point. But, anyway.
Brian: Yeah, it was one dot one dot one – some minor update.
Yes. I definitely saw some ranting on Twitter about that. But by enlarge, it has been a pretty stable system especially compared to something like Ember which has seen a lot of changes in the last two years. But at the same time there has been this urge: what do we do next? What do we do next? So it is basically fragmented. There are all these different warring groups, there are all these war lords of Backbone and they are all tribalistic isn’t it? So there is not one answer and I think that it is important. I think it was DHH that said that it is important that both beginners and the advanced users of a framework climb the mountain together. It is important that if I am a professional user from a power user, for the most part, I should be using the same tools as someone new to the framework. I think that there is tremendous value in that. That is actually why we built an opinionated framework because developers love to argue. There is so much stupid crap to argue about like what do we name it and all this stuff. You should really be consolidating all those arguments into the really important stuff. Whatever the thing that you are building is, like whatever makes that unique, that is the thing you should be arguing and spending your time worrying about, not all these conventions and architectures of an MVC app that has been solved. We think having a strong opinionated framework, in a lot of ways that constraint is very liberating in that it liberates you to focus on the actual hard pits.
7. [...] How do you deal with this and what do you think we can do to improve the overall environment?
Brian's full question: Speaking of strong opinions, you touched some of this in the post on your blog about when you work on open-source, especially. in particular, I guess, when you are working on frameworks and maybe even particularly when you are in the JavaScript community, I do not know if it is more or less opinionated than other communities, but I have my own opinions on that, obviously. Sometimes it is a bit hard to deal with the bitterness and the ranting and so on that you can get when you put yourself out there with a framework like that and it has even dissuaded some people from continuing to work out in the open like that. How do you deal with this and what do you think we can do to improve the overall environment?
Uh, it is tough. I think that the thing that you have to realize and remind yourself and I think that the thing that conferences are good at is that - I think twitter is probably one of the biggest problems because it really incentivizes, really glib, mocking tweets. If you go look at the tweets that have been most popular that I sent out, they are just the meanest, stupidest stuff. But that is what gets rewarded and there is this whole feedback cycle. That is what you want: you want to get those read tweets, you want to get those favorites. So you are incentivized to trash the people’s work because everyone likes to play and laugh. I think that is awful, but I am certainly guilty of it. I think the thing that helps is to just go in person, go to regional conferences, go meet the people whose software you are using or not using, as the case may be, and realize that they are human beings. The blog post that you are talking about, I put a tweet from Paolo Fragomeni. He had made fun of Ember and some stuff and this is the kind of example I was talking about. It was so funny because – this a 100% true story – a couple of weeks ago I was just sitting and having a cup of coffee in San Francisco and who walks by but Paolo. “Paolo, what’s up?” and we got to talking and my feelings were hurt and I think his feelings were hurt as well. Just talking, it was totally fine. We were just two human beings and none of us had any beef with the other one. We were just – everyone gets up in the morning and does the best that they can. I think that is the thing that we have to realize. Just remember that there is a human on the other side. I know it is glib, but -
Brian: Yes, I know. As someone who works for a big company that is often in the news even, you have to learn to develop a little bit of a thick skin, let it kind of flow.
It is not about you. It is pretty humbling to think that the software you wrote is literally the most frustrating thing that happened to that person today.
Brian: True. That is a little bit of a difference to when I work for a company. Obviously, this is not my creation. In many senses you are much more vulnerable when you are working in open-source because you literally put yourself out there and your code.
Yes, it is your “baby”. A big part of your ego is invested in it and obviously you are doing it because you think that you have good ideas and you think that if other people use those ideas then the world will be a better place hopefully so, trying to detach your ego from that is important, but very hard.
8. [...] Can you explain a little bit about you meant there?
Brian's full question: Right. And another topic coming from you blog: you recently wrote a post pondering the end of progressive advancement. There was no shortages of opinions on this. You even referred to the browser as “the world’s most advanced widely distributed application runtime”. Obviously, there were some strong, not so positive opinions at times I think on that, but I found it really interesting. Can you explain a little bit about you meant there?
Sure. Actually, I think that of all the things that I said in that blog post I think that bit of it was actually the least controversial. I think what is really incredible, the thing that I think is completely amazing about the browser that is transformative and we have not realized it yet and I think that as a human race we have realized that, but I think that the fact that I can go download and run arbitrary code at the drop of a hat, I can type an URL, I can download this payload of arbitrary code and I can run it safely on my computer and it runs in native speeds, I think that is as transformative as the web itself, as the Gutenberg press even, perhaps. I think this is a monumental shift in how computers work because when you think about even ten years ago, twenty years ago, if you wanted to run some software you had to drive down to the CompUSA and you would get 20 floppy disks with your computational software, you would come home and you would load it in one at a time and if there was a virus on that floppy disk now your entire computer was infected, right? You had to be cautious. Remember how careful you had to be about opening an e-mail because it might have some malware attached to it? I cannot remember the last time I really thought about it or worried about it.
If you think about what is happening every time you go to a web site. You are in JavaScript and now Mozilla has been pioneering ASM.js, you can literally take Unreal Tournament and not go through an install process - download and run – and it is running with all the same guarantees as the security model that the browser has been built on since day one. That is hugely, hugely transformative. So I think the browser will end up fulfilling the promise of what Java was supposed to be and never ended up being. People would always make fun of Java: “Oh, right. Write once, run everywhere. Ha Ha Ha. That is what we are doing as web developers, that is what we do every day. Maybe we have to test some different browsers and maybe there are a few quirks here and there, but by enlarge, by God, billions of dollars of the economies built on the idea “Write once, run everywhere”. You can buy a refrigerator’s running web kit now.
Brian: I guess it is a bit of a mental shift from people’s – I think a lot people still think in a way of-
Document viewer.
Brian: Yes. And even a request-response kind of a quick…when you are talking about downloading the application code, it is more like your Ember app. The entire application is basically sitting in that page with some scripts and stuff like that.
And there is so much infrastructure around that, there is so much infrastructure around the request for spots cycle. Google indexes and does SEO using that, people depend on things like Curl. There is still a lot of catching up with that the rest of the world is going to need to do and it is going to be painful. I think that was the primary objection that people had to the blog post. They said: “Well, if I just want to read an article in the newspaper, I should not have to download your ball of JavaScript to do that”. Frankly, I think that is how all websites are going to be but even the Ember.js web site is not an Ember app. We specifically designed it to be server-rendered sole-static HTML content because we want to be indexed by Google, we want you to have an offline copy of it, we analyzed the constraints around JavaScript apps and I think the point of that blog post was to tell people that progressive enhancement is not a mandatory thing. Depending on what you are doing, writing in 100% Java Script is a totally valid option and I think it is just so easy for people to grab onto these mantras that progressive enhancement must be server-rendered, must have an HTML during the first payload. I just do not think that is true and I think that, hopefully, the effect of that was for people to question it and if they decided “I still want to do server-rendered stuff. I do not think that the java Script eco-system, the tooling is mature” – which is not – “It is not mature enough yet for me to invest and build my apps that way”, then fine. But at least we make that a decision that you are making and not Jeffrey Zeldman in 2004 making for you.
Brian: Right. On that topic, I think it is interesting. I have seen people moving towards more complex JavaScript apps, but also a rise again a little bit of these static pages. You did not used to be that you did anything in static any more, right? Most everything was served up by the server, but now you build the app using some thing that maybe semi-dynamic, it compiles on your locally and then you push up the static files but that has become where there are these two models. There is not so much in the middle, I think. There is the complex JavaScript app or the static.
People realize that you still need the document. Maybe you can run apps and I think the line is certainly blurring, but sometimes you just want the good old document and the browser – that is the really incredible thing – the browser is somehow two beasts at one time. It is a terrific document viewer and you can get documents offered in 1992 and you can view them in your browser, but you can also download Unreal Tournament and run it in native speeds. How is this possible? I do not know. These people are wizards.
Oh, we have a lot of stuff planned. We moved the framework to a release model similar to Chrome where we cut new releases every six weeks. So, there is this release cycle, this release train. We put new features in behind the feature flag and they either migrate their way into the beta channel or not. We have decided to time releases. Releases are now dictated by the passage of time rather than by what features get in them so it makes it a little bit difficult to talk about what releases get what features. But there are a couple of things that we are really excited about. The first one is modules are coming to ES6, Ecmascript 6 – we are really excited about that and we want to embrace that but it is not everywhere yet so we have been building a lot of tooling around the project out of square called the ES6 module transpiler that will take the future JavaScript syntax from the modules and compile it down into AMD modules for you. Last week we just ported our app that I work on. We ported that using ACME script modules and we think that is going to be really, really exciting because basically every framework has its own hack-together module system or some use AMDs, some use MPM.
I think this is going to give us a standard, a lingua franca of modules for the browser and hopefully for NODE. Hopefully the NODE comes around using the ES6 modules. So that will be very nice. I think that the other thing that we are really focused on now is a project called Ember Data which is basically a library for helping you get your model data into an Ember app and I think the important thing for us is that we really do not want to dictate where that data comes from. So maybe you have an existing Rails app that serves up a Json API, maybe you have a .net so an API that serves an XML or maybe you are building something totally new from scratch that supports web sockets. I think the point is we do not want to tie you down heavily, we do not want to say you need to use a particular backing technology. We just want to give you a thin wrapper that you can use to wrap whatever it is you want to consume. I think that is where we are focused right now and yes, stability, bug fixes and ease of use documentation. I mean those are things that I think a lot of open-source projects fall down on and we want to be the best.
Brian: Great. I even gave a presentation a while back that was like “Stop writing new JavaScript libraries and start documenting the ones that are out there.”
Yes. I have to say a big “Thank you”. The Ember community has been really, really awesome about coming together over documentations. It is all in Markdown, it is all on GitHub and we have a little button you can click to add it and cement pool request. It has been awesome. People have done cementing of a lot of really great feedback.
Brian: Awesome. I wish you luck on the future of Ember and thanks for doing the interview and taking the time to come out here today.
Thank you for having me, Brian.