Software is Changing the World. QCon empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.
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.
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.
5. You talked a little bit about the URL being essential in Ember. I am assuming that will be what you think it is its biggest strength. What do you think would be maybe its weakness or what apps we should not build with Ember?
6. Speaking of frameworks in general, you kind of touched on this before, I think, since I started interviewing you to now probably three to four new library frameworks have come out. So, I want to get a sense of what your feeling is on that. Is this a constant re-inventing of the wheel or do you think it is a sign of innovation in the community?
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.
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.
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.
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-
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.
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.
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.
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.