004 JSJ Backbone.js with Jeremy Ashkenas

by woody2shoes on February 13, 2012

Panel

Discussion

Picks

Transcript

JAMISON: I’m going to pick “computers” next week.

[Laughter]

CHUCK: No, thanks.

YEHUDA: Computers are awesome.

CHUCK: [Chuckles] Yeah I use one on occasion.

AJ:  You guys are all wrong; technology is the best!

CHUCK: Hey everybody and welcome to episode 4 of the JavaScript Jabber Show. This week we have with us, Jeremy Ashkenas. Am I saying that right?

JEREMY: Yeah that’s pretty good.

CHUCK: [Chuckles] That’s pretty good. [Chuckles] I like that – err… passable. Anyway, you wanna introduce yourself real quick?

JEREMY: Sure. I’m Jeremy and I work at the Interactive News team at the New York Times these days. Right now I’m on our elections coverage but in previous lives, you may know me from documentcloud.org, which was a knight-funded news challenge that ended up releasing a lot of open source code like Backbone.js, which will be one of the topics we cover today and Underscore. I also had this fun little language called CoffeeScript that compiles into JavaScript. So my perspective is mostly working on, these days, news-oriented projects that have large, large, large JS components or mostly done on the client-side and then trying to make that easier to accomplish.

CHUCK: Sounds interesting. So you are doing programming over there in some journalistic website?

JEREMY: I’m mean yes. The interactive news is a team inside the news room that is sort of an parallel with multimedia and graphics that are also newsroom teams at the Times and so the kind of stuff that we do ranges from apps for covering news and how they are progressing through the system right now like I said before, mostly elections coverage of the republican primary. So that’s like the maps on the home page that you see the live results coming in from the ap, that sort of thing.

CHUCK: Oh, cool. All right we also have on our panel, a new panelist that’s Joachim Larsen. Do you wanna introduce yourself?

JOACHIM: Yeah. I’m just a go by developer, I think that’s how I see myself; just a developer basically. I don’t have a large GitHub profile, I just kind of work with clients and try to get their stuff running. And I’m in really good company today, with Jeremy Ashkenas; he is a really great guy. I hope we get to talk about the Ice… I saw the Ice library on GitHub recently, which I would imagine you are involved.

JEREMY: I’m not actually. That’s — thing but it’s exciting stuff so just for folks who didn’t manage to see that, Ice was sort of a track, if you’ve ever used and you have track changes so you can see from all the people that added a document; who’s acted what and who’s deleted what is a implementation of that for any content editable field so that you can use it in like a WordPress blog for example. So I’m thinking about using that for getting reporters and editors to be able to start on the web instead of starting in our CMS for working on our web stories.

CHUCK: Cool. Also on our panel, we have AJ O’Neal.

AJ: Hey! Yup, I’m here. So for those of you that haven’t heard me before, I am an employee at SpotterRF which is actually a radar company, but we do some interesting things with our browser client and some of our internal apps with JavaScript, HTML5 and Node.js and I’ve written the FUTURES library if you’ve heard of that.

CHUCK: All right cool. We also have Jamison Dance.

JAMISON: Hi, I’m Jamison Dance I work at SpotterRF with AJ. So the things that he said also and yeah that’s about it. I’m excited to be here.

CHUCK: All right. We also have Yehuda Katz.

YEHUDA: Hey, I’m Yehuda. I promise to have my audio better this week — not really sure how.

JAMISON: Is it a smaller dungeon?

YEHUDA: I’m in a smaller dungeon. I have a snowball, hopefully we’ll be good. I work on a bunch of stuff; sort of the intercept in Ruby and JavaScript. These days most of my time on open source is Ember stuff and Rails plugins that make it easier to work with the client-side libraries.

CHUCK: All right, cool. And I’m Charles Max Wood from teachmetocode.com and this week we are going to be talking about Backbone.js so I don’t know if there’s a blood for you between Backbone and Ember, but it should be interesting to talk about and I’ve actually been asking some of my friends about what they think about the two if they’ve used them both. So I’ve gotten some insight on that. I still have yet to try Ember — I’m sorry Yehuda.

YEHUDA: It’s ok. I should point out there was a couple of really good discussions that we had probably on IRC this week or last week; we should definitely put them on the show notes — and people should read them. I mean we will probably have a good discussion here, but I feel like… I don’t have to speak for Jeremy, but I felt comfortable with people reading that and understanding what my position was.

CHUCK: All right cool. Is there a good place to get that?

YEHUDA: I think Jeremy posted a gist; he can link to that in the room.

JEREMY: Yeah we can provide the links.

CHUCK: All right cool. So Jeremy, why don’t you go ahead and kind of explain what Backbone is and how it’s intended to be used and then we can kind of start picking apart what we like and don’t like about it.

JEREMY: Sure thing. So Backbone.js is a library for helping out with client side MVC, so this is… I think lots of us has experience where you start building a JavaScript web app and you are trying to do lots of things on the client-side; you are trying to do optimistic rendering and keep yourself on one page without having to use lots of page refreshes; make it feel more like an application than like a website. And there are many different ways to approach this, and that’s actually one of the exciting things about seeing all these different JavaScript client-side libraries come out of the wood work.

But one of the single things that you start to realize as you are doing this is as you get yourself into a really  big mess if you end up with pieces of state gathered all over the DOM, right? So maybe as it’s as simple as the number of people in this chat… this Skype chat that we are having or maybe it’s some fancier kind of state with text and who’s editing it — whatever you state may be. If you end up with it scattered all over the DOM, your JavaScript that’s really crazy and whenever any state change happens, whenever something happens to the system you make update, you both have to persist that change to the server, that’s your database so that it can be saved and update all the different pieces in the UI that might be looking at it.

And this gets tricky, I think, mostly because it’s so tempting with JavaScript and HTML to treat the documents and the HTML as the source of truth and sort of use… especially with jQuery, right? So jQuery is the most ubiquitous JavaScript library and it has some data manipulation facilities like mapping and filtering, but basically it’s querying against the DOM. And so because it’s good at querying against the DOM, it’s really tempting to have all your data in the DOM and just look it up. And I think one of the first things you realize when you build one of these big apps is that you need to stop doing that. You need to have a single source of data that your UI is just basically and watching and reacting to changes and rendering. And then you wanna have a rich model layer for working with that data and doing your transformations and your computations and your calculations on it.

So what Backbone is, Backbone is basically the… it started out as the heart of Document Cloud. Document Cloud is the Knight Foundation project that mentioned; that’s a workspace for journalists to work with primary source documents. And so Backbone basically started out as the basic model and view layer that we had inside the Document Cloud for standard views for rendering documents, annotations, users, projects — that sort of thing – entities. So part of the deal with Document Cloud being a knight-funded project under the News channel was everything we did had to be released as open source. So during the entire process, we were trying to look at different aspects of the application and say what will be useful as the stand alone library and what can we pull out and make a standalone thing that other people can use for other news projects and other projects. And so Backbone was sort of the kernel of that structure for the application — the foundation level of the structure. So that’s its origins and that’s the kind of things that it helps you with. I think it’s pretty good intro.

CHUCK: All right. Cool. So is it really an MVC? Because I noticed that you renamed “controllers” to “routers.”

JEREMY: Yeah. There’s been a little bit of struggle about that. So you already have the Rails-Django sort of back and forth about what’s a view and what’s a template. And so if you are about it and you looking at views as reacting to changes like click events and stuff like that, then you could probably think of Backbone views as controllers instead of views. Why don’t you call them views, because they are responsible for a single piece of UI, usually they are tied very, very tightly to a DOM element and all of its contents and so in that sense, they are really view-like — but you also have templates. So if you want template views and your views controllers, feel free.

YEHUDA: So by the way Jeremy, I agree that the nomenclature is a big problem in general. I think everybody wants to call themselves MVC and not call themselves MVC and it’s become this massive pedantic thing. I think there is a space for a controller object that is responsible for multiple elements; so Backbone defines as a essentially controller like things that is responsible for controlling one element. I think often when you get to a bigger application; you want to have an object that is responsible for multiple elements. Backbone has collections for this, but that’s sort of, kind of like a special case.

JEREMY: On the UI side though I think you’d also use a view. You can also have bigger views that have multiple elements inside of them — although there isn’t different type of object for that. But yes, I agree it’s more important not to get pedantic about this; especially with MVC right? MVC is super broad category. There are many different types of systems. I think that’s fine. I think as long as you have this sort of basic distinction between the UI and the model, like that’s the heart of MVC, right?

YEHUDA: Usually there’s UI, model and then some intermediary layer, and I think in Backbone, that’s the view object, usually.

JEREMY: I think that’s right. Yeah.

YEHUDA: So I should just follow up; I agree that often… so like what Cocoa would call a view controller make sense to be a view in Backbone or Ember, but there’s definitely a case where you have… I think what Backbone uses collections for, there’s a more general case of that and basically it’s not UI its representing applications state, its representing something that is presented in multiple views, multiple presentation locations but it represents application state.

JEREMY: So that might be a little fuzzy because Backbone collections don’t have anything to do with UI, they are just collections of models and all of the data manipulation and aggregation functions that you want to do on your realistic models; so mapping, filtering, selecting — all that kind of stuff – where you are taking a list of model objects and getting subsets.

YEHUDA: Right but—

[crosstalk]

JEREMY: But I would be curious to hear more about how Ember’s controller controllers work. I know that you guys have array controllers and that sort of thing.

YEHUDA: Yeah so array controller is kind of fulfill a similar purpose… so what I meant specifically was you have this array of things and that array of things isn’t really persisted like there was a concept to what that array is often in terms of a query, but you would never like persist an entire array to the database. So the list of items that you happen to have locally is application state as are things like aggregates; so in a to-do list (which is a “hello world” example) how many items are remaining etc. those things are application state, they reference things that happen to be transient in your application but they are not view things specifically, right? They are just information that doesn’t belong in the model layer because it’s not really persistable.

[Overlapping talks]

JEREMY: I think it does belong in the model layer. I think it’s a bit of a red herring to talk about a model layer that directly is one to one with what happens on the server; that’s never ever the case in client-side code, right? Like its one of the things that you need to sort of get past when you first do this is that you are not expecting to have like a Rails like active record base model in JavaScript where you are running arbitrary query and it represents the entire table.

First of all, because it’s insecure – it’s in the client side — you are not going to allow your clients make arbitrary queries against your database. And secondly, because it’s impossible — like there is no way you can fit your entire table across the pipe and get it to JavaScript against… so your client side models represent the data and the models from the perspective of the browser and what you need to do and that includes things like the to-do list; how many are in particular session, even though that that collection may not be persisted back.

YEHUDA: So I would be comfortable I guess if you want to just stick the collection into the model layer. I think of it as a different thing. I think of it… there’s like as a bunch of objects… so in my mind the model layer maps well on to not the database tables but on to the resources that are exposed from the server. And the controller layer is basically intermediary that aggregates information from a bunch of models and exposes that information to the viewer. But I would be ok with someone saying — that thing that you are saying is controller layer — is actually part of the model layer.

JEREMY: Sure it’s all one big fuzzy, wishy washy MVC suit. You can push and pull the boundaries around for sure.

JOACHIM : I think that’s the great thing about Backbone I mean, what Backbone did was basically say, “OK, I’m going to take a small part of what I assume you guys use for much bigger projects, and so we are going to take this out and we are going to open source this and this is going to be something that people can build on,” as opposed to Backbone; it’s pretty empty, very minimal and basically people think put their own stuff on there and make them do whatever they want within the context of what they are working with, and I think that’s what kind of made Backbone like really great and that’s what inspired a lot of things such as Ember and such as so many other frameworks that are now taking Backbone inspired or MVC stuff and putting it in there.

JEREMY: So the funny thing about this is that I think that this type of thing that we are talking about and that you guys talked about last week is the kind of thing that anyone who is done a big app in JavaScript has written before; it’s not new at all. And a lot of ideas in Backbone I’ve seen you know, in earlier jobs that I’ve worked for and  for people who have been doing this kind of thing from the early days of the HTML, like some of the first webmail clients and stuff like that. You end up with the same sort of concepts of models and UI and you have to wrestle with that. And so I think that a lot of JavaScript developers have been doing it for a while have done this before you know, for one off projects. And it’s been really fun to see explosion of libraries came out of the wood work because everyone was like, “Oh when I did it, I did it this way and now I like it better that way, so I’m going to make my own version that works a little bit differently,” and I think that’s great.

CHUCK: That’s one thing that I really like about the variety that’s out there too is that you have something like Ember that is very opinionated; that you know, it’s you do it this way and you know, because its opinionated, kind of the convention over configuration that you get with Rails is that you expect it to work in a certain way you know, all the time every time. And it seems like Backbone gives you a lot more options if you want to customize, configure whatever — it just gives you the kind of the bare bones and then you can work up from there to whatever you want.

And so I think it really depends on the coding style is to which one you choose and so people who are more used to the opinionated way of doing things that you get from something like Ember would probably be more comfortable that way but I have a few friends that don’t like some of the conventions that Ember puts in, and so they are like, “Yeah if you can do something like Ember but give me these other options over here that are kind of natively built in and then I’d be happy with that framework,” and I think that’s where you see a lot of these coming up.

And I think it’s also very encouraging that you have all these options, so you can say, “I want something that yeah that just kind of handles everything for me and as long as I do it the Ember way, then I’m happy,” and in other cases, it’s like, “You know what, I just need a minimal model to handle this. I’m going to customize these couple of things I’m really going to think about it this way,” and you pull Backbone in, you hook it up, it gets it up and going really quickly, it’s a relatively small library compared to some other ones and you know, you are often running.

YEHUDA: I wanna clarify one point which is just basically… so I’d been doing conventional over configuration for a long time. I also considered jQuery to also be a conventional over configuration type of library. One thing that I learned starting with — and then I’ve pretty much taken with me the entire way is that it’s fine to have conventional over configuration but it is bad to build the core library as conventional over configuration.

In other words, the conventional over configuration ideally a light default layer on top, it has a very, very big impact on how people use the library. But I think the idea that conventional over configuration also means that it’s impossible to drop down into something different is basically like Rails 1.0 or 2.0 era, there are ways to strategically build a library that is very flexible under the hood, so if you actually want to go do stuff, its fine but ultimately, most people use the defaults.

And I should be clear; I definitely think that if people are going to want to be [inaudible] all the time, a conventional over configuration library isn’t for you. But the idea that you hit a wall and then you just stopped because Ember or Rails didn’t think of something is pretty much not how it works anymore.

CHUCK: Yeah that’s fair enough.

[Overlapping talks]

JEREMY: And I also wanna add to that I don’t think that it’s just black and white — either you are conventional over configuration or configuration over convention, I think that there’s definitely strong opinions; it’s not just that Ember is opinionated and Backbone doesn’t have opinions – I think both have opinions and both have opinions about ways that other libraries do things that they disagree with or that they do agree with.

YEHUDA: Although Backbone definitely is of the opinion in many more cases that you should not have opinions.

JEREMY: Yes. It does try to be flexible to many different patterns and uses. That is correct.

[Crosstalk]

YEHUDA: So Ember totally under the hood supports for instance alternate template engines, but the public API, the way you are supposed to use Ember is you should just use Handlebars. If you wanted something else, fine, here’s how you do it probably where Backbone is we think that we should not make this decision for you at all.

JEREMY: Exactly. Backbone thinks you should be able to use any template library that you—

[Crosstalk]

YEHUDA: Just to quibble; Ember also thinks you should be able to use any template language you like, but we think that there is a win in saying, “Here is the one that we support well that has a lot of integration; if you use it, you get additional if you don’t want to, that’s fine but you lose all the extra web.”

JEREMY: You use all the extra stuff and you are also not using a large part of what Ember gives you, right? You are probably be ignoring 50% of the code base of Ember that you are including on the page if you didn’t use handlebars, right?

YEHUDA: So you would probably, in that case, rip out… so again, this is definitely I think in terms of how people use it, this is not what we tell people, but you could rip out the Ember Handlebars library, which is bundled but ship everything else and then roll your own templating layer and that would, from the perspective of all the modules that come with Ember, that will be fine. The view layer doesn’t care about handlebars at all; the view layer just cares about an object that’s a function that takes a context and returns a string.

CHUCK: Right.

JOACHIM: I’ve been involved in a fair few discussions regarding refactoring of you might call it “legacy” applications to be more responsive you will  use responsive UIs and what I found is that people is a little bit more define Backbone by itself, easy to reason about because that it is that flexible. So the thing is that you can take this piece and start from there and start to kind of — existing code into that and see what happens after that whereas Ember or whatever it’s a little bit like it’s more of a feel like a whole hog on this and so the Ember people have to be a little bit on board and there’s a lot more that had to be read and kind of be reasoned about to be able to integrate that.

YEHUDA: I would quibble with that but I..

JOACHIM: Sure. I mean.

[Overlapping talks]

JEREMY: Maybe we can get more specific instead of just feels easier or what doesn’t feel easier.

[Overlapping talks]

JOACHIM: I mean the thing about JavaScript is that it is so flexible, right? I mean we can go in and write anything and make anything do whatever you want; it doesn’t matter if it’s Ember or something else, I mean of course you can, but its JavaScript.

[Crosstalk]

YEHUDA: So I would go beyond… I mean obviously that’s true about like if you wanna go use jQuery and like drop in a different strategy for doing document fragments, no you cannot; whereas Ember is actually built the idea of like there’s the core runtime, there’s the mix in system, there’s view layer, there’s Handlebars, there’s a state library, there’s data and those all things build on each other, so I think it’s a different thing than saying JavaScript is a flexible language and of course you could do anything from saying Ember specifically has parts of the system that do not care about the template layer; and that is an intentional part of public API.

JEREMY: So speaking of the templating layer, (since we are starting there) I wanted to ask Yehuda how he finds folks reacting to the pattern of basically encoding some logic… so Handlebars is somewhat logicless templates; it takes inspiration from Mustache. But in conjunction with Ember especially, you end up putting basically logic into your attribute tags in a very codified ways that Ember can understand what the particular piece of DOM represents in terms of the JavaScript model. So as opposed to having HTML that knows nothing about… basically knows nothing about what your JavaScript model is, right? Inside your Ember views, you sort of expose it and you can see what hooks up to what. How do you find folks reacting to that?

YEHUDA: So first of all, Handlebars is absolutely a compromise; it’s a compromise between arbitrary code and no code. But the basic idea is that the codes, the parts of logic that are in there are designed to be very declarative. So the only things that you are supposed to be putting into a Handlebars template in Ember (and we do a decent job of enforcing this in terms of what expose by default) are declarative things. So an example is we have computer properties, and so if you wanna say like a conditional, you never say, if foo and bar or baz, you always say, if a single property and then the logic for what that property means goes into your JavaScript code. So I think it’s useful and people find it useful to be able to have conditionals that automatically update, loops that automatically update; but to limit what is in that code to things that are declarative and that we can observe and analyze and say, “OK here’s how we need to get this on the script  and update it later.”

AJ: So this is something that I’ve got feelings about too, like the templating, I really don’t get the whole Handlebars thing other than that people are coming from PHP so they want some sort of tag identifier. Like my argument is why not use what the DOM provides? So you’ve got class names in there that you could use semantically, so why not use those instead of putting in some Handlebars brackets that then have to get parsed and then turned into a span tag has that class name anyway?

JEREMY: That’s a great question. And I’ve actually worked with some libraries in the past where everything was DOM-based right? So basically, I mean you do from JavaScript, right? So you’d be working your JavaScript view, you will be building up what the HTML looks like, but every single call that you made will basically be a document that create element call and it was all done in terms of the DOM; and so that’s interesting approach. One of the big problems you run in to first off is the slowest way you can possibly render UI in JavaScript is to do it all with the DOM and that for better or for worse, generating strings of HTML and then evaluating them all at once is about the fastest way that you can do UI in JavaScript. And so if you are doing anything performance intensive and again, this is just partly with all the browsers because you can do pretty crazy things in Chrome and FireFox these days, but if you have to be working IE8 or IE7, you are going to run into limits if you try to use a DOM-only approach and if you try to render a thousand elements and update it quickly. That’s one of the main things.

YEHUDA: I think there’s another point which is if you actually go look at… so there are other libraries that make the exact argument that you are making and the end result looks exactly like Handlebars except way more verbose because you have all the XML, right? So you have things that are loops, you have UL; UL is a loop and the UL inside of it essentially has exactly the same thing as what Handlebars add s except as Jeremy points out, you now have to go find it in the DOM and manually do DOM work, and it looks… there’s data for each; instead of being able to say #each, you have to say UL data for each. So you end up with the conceptually, abstraction-wise exactly the same thing, except it’s a lot more verbose.

CHUCK: Right.

JOACHIM: What I really like about Handlebars is that it’s so similar to Mustache; so you can also use its server-side. Mustache is implementing almost all server languages, so you can have server-side templating and use the same templates in the client as well. With Node.js, that becomes a non-issue.

JEREMY: That ends up becoming, maybe I don’t know if Yehuda will let me say this, but a Handlebars’ dirty secret, right which is that if you are doing anything interesting in a Handlebars template, you are going to have your own helper functions and your helper functions are both sophisticated and implemented in a particular language — which is going to be JavaScript in this case.

[Overlapping talks]

YEHUDA: The whole thing is a pipe dream to begin with.

JEREMY: So if you have a nice (and we have this actually here at the times), if you have a nice big Handlebars application, you probably cannot render it in a different language; you probably have to run JavaScript on the server if you wanna render it without—

[Crosstalk]

YEHUDA: So there is one window, so I could imagine the fact that the helpers are separate, means that you could still use the same templates and re-implement the helpers in Ruby or whatever. Again, I think the entire, “Node is awesome because do you know if you write in JavaScript, you write the same code in the client and server and if you use Mustache you use the same template…” I think the entire thing is a pipe dream; people are missing the context of what client side apps and server side app is and thinking about it very superficially, so the end result is you imagine that something is cool, by now shouldn’t Node have done something cool? Shouldn’t there be a demo of something really awesome happening? I think the fact is that there’s just a totally different context for what you are doing on the server and the client.

[Overlapping talks]

JOACHIM: If you look at some of the UE3 demo for example, right? UE3 they have some heavy JavaScript widgets, right? Because UE3 can run in the Node.js server, it can render those Node.js widgets on the server and send them HTML for example mobile browsers or otherwise less powerful interface and you can then load the JS on the client behind the scenes.

YEHUDA: So I think I would echo Jeremy’s dirty secret; I think in practice, I think it probably done as well but I would easily imagine that trying to do practice will result in a… like having to have mega constraints  that are not obvious, right? So you actually can’t run any code that would be carrying client side state at all.

CHUCK: All right. I’m going to—

[Crosstalk]

JEREMY: For the record, I’m still believer in this pipe dream and I don’t think that Node is necessarily there yet in terms of library support for doing everything that you need it to do on the server side, but I do think that there is; specially for JavaScript web applications value and being able to have the same code run on the client and the server, even if we haven’t really reached that point yet. And I think this happens even on daily basis. So this afternoon, I’m trying to get together a little widget that’s going to show the current state of their republican primary and who’s got delegates for a section front on NY Times. So we wanted to be able to update the client side because we want it to be live and want to always be able to pull from the JavaScript API, the latest state of race, but we also wanna be able to bake it into the page on the server side, fit in the CMS and have all the links and that thing be indexed by Google. So then I have this kind of funky, hybrid template right now where half of the UI and that the pieces that are links and that we wanna be indexed by Google are being done in an ERb template and it’s also a client side template to make the API call it an updated client side bit and it’s a little bit two feet; one foot on each world — and it doesn’t need to be.

YEHUDA: So I’m willing to be convinced on the pipe dream, but I want us to be honest about where we are today.

CHUCK: Right.

JAMISON: I was going to ask, so the benefits of doing it on the server instead of just doing all of the templating on the client forever are–

YEHUDA: Google is the most obvious.

JAMISON: Yeah, I was going to say it was mostly from Chrome and then like–

[Overlapping talks]

JOACHIM: It’s basically the initial load, right? Because if you have a heavy JS web app and you have empty cache situation and all of a sudden you have to load whatever half a meg of JavaScript before you see something, whereas in this other way you can load a very thin HTML representation of that and then start loading the half Meg—

[Crosstalk]

YEHUDA: But it can’t do anything. So in most cases, the fact that that HTML can’t actually do anything is makes it not—

[Crosstalk]

JOACHIM: No, but it can. There’s no reason why it can’t do anything.

[Overlapping talks]

AJ: — your JavaScript yet.

JOACHIM: No, so it loads first, right? Then what it does is it hooks up in a plain old get, so basically you click on something and you send the get request and you get a new page until the JavaScript comes in and hooks up those buttons to the AJAX-powered interface.

YEHUDA: So let’s say you are on a mobile device and you go to a page and that page goes and downloads whatever you wanna look at and it takes 10 seconds or 15 seconds to download the 500K of JavaScript that it would actually need to power the page. There is an argument that the fact that you can’t actually… like the fact that the page will appear broken during that time, maybe—

[Crosstalk]

JOACHIM: No, but it won’t if you are broke.

YEHUDA: It will, because you will try to do things that you are normally allowed to do on the page and they won’t work because you have no JavaScript.

JOACHIM: No but it will work because it will have interfaces that aren’t JavaScript reliant.

YEHUDA: Oh ok. So I guess if your entire app is built as though it was a regular non-JavaScript controlled app, perhaps that could work. I would love to see someone actually advocate that in detail because in my mind, that pretty crazy. You are basically saying that people do—

[Overlapping talks]

JEREMY: People do advocate that. That’s the full-on progressive enhancement to–

[Overlapping talks]

YEHUDA: So, Jeremy–

JEREMY: The kind of JavaScript apps that we are talking about here don’t really work that way. Like it’s not realistic.

YEHUDA: Jeremy, that’s my point; it’s not the people don’t advocate the abstract. My point is that most people, who build single page apps that are serious, already have a band in this pipe dream.

JEREMY: Absolutely.

[Overlapping talks]

AJ: Well I don’t understand; just like the user take ten seconds to download at first time. I mean what’s the big deal?

YEHUDA: So I think—

[Crosstalk]

JOACHIM: Because people… they will go somewhere else. If that take 10 seconds for a page to load—

[Crosstalk]

YEHUDA: Yeah, but they will also like go somewhere if they download something and you have to wait 15 seconds and the page is broken.

JOACHIM: No but listen, listen; imagine though what we were talking about before, right? We have Ember.js in the client and it has the controller model view and all that shit, right? Then also imagine that you have Node.js in the background and you have a layer that translate these things in AJAX to normal post and get interfaces; and that’s what it renders one the server side, it serves that and once they serve it in the client and that JS stuff goes in and changes those links to be fully AJAX powered.

YEHUDA: That means that you basically need to a full HTML none… like you need to basically go back to progressive enhancement. Every single UI state that you want has to be able to render on the server at HTML and the server to know what the state is.

[Overlapping talks]

JOACHIM: It’s called an abstraction layer.

JEREMY: Exactly.  This is one of the reasons why everyone is pursuing their own style of client side application framework because it will be great to have someone who takes that idea to the extreme and creates a library where sort of all the things that you can express, you are only allowed to express things that can be done on both and can be expressed in terms of get post… basically just get and post the forms as well as the JavaScript enhanced equivalence and then see how well that works out.

YEHUDA: I think something like c side would probably necessary to make it work well. So Jeremy, correct me if wrong but I will articulate that I personally would not want to build this app and—

JEREMY: I would concur with you. Yes.

YEHUDA: This is like—

[Crosstalk]

CHUCK: OK. I’m going to turn the bus here a little bit. We did bring Jeremy on to talk about Backbone and we’ve kind of gone off of a tangent, of a tangent of a tangent. And it’s really interesting to see where this is going and that’s why I’m happy to listen, but at the same time, I do want our listeners to kind of get an idea of what Backbone is about; and we’ve talked about some of it. I’m a little curious as to what you see is the strengths of Backbone, Jeremy.

JEREMY: What do I see as the strengths? Basically if readers are curious and we wanna talk about strengths, I think the one thing that constantly inspires and amazes me all the time is that basically, Backbone has only been out there for a little bit over a year. I think it was October ‘10 that we launched it and in that incredibly shot amount of time, if you go to Backbonejs.org and scroll down to the examples, there had been a ridiculous amount of amazing apps in all different context that have been built with it. Most of them I don’t know anything about until they launch or weeks and months after. And people are using it for sort of native/web hybrid experiences on phones, if you are linked in or sound cloud, people use it for large sophisticated desktop style web apps. People use it for web page galleries. People are using it for payment process or management systems. It’s an in-game browser inside of a 3D shoot ‘em up. It’s being used in a desktop app that’s being powered by Node.js for building maps. It’s sort of found all these really fascinating nooks and crannies and all these people using it in different ways; some of which way are actually pursuing the pipe dream of using Backbone models — the same model code on the server side in Node and the client side in the browser. So I think that’s strength number one through ten, at least.

CHUCK: OK. So I have one question for you and this is just something that I’ve noticed in using Backbone myself and that is let’s say that I have a website and I have kind of the main content and then I have a side bar content; and so, let’s say that I clicked something on the main content that has a list of… I don’t know… posts, let’s say it’s a twitter app; so let’s say there are twitter post or a tweets and so I clicked something else because I have a menu over there and it loads a different set of tweets over on the right side, and I have the option to change something on the right side – those are two different collections the way that I have it implemented — and so when I change something on the right side, it doesn’t reflect on the left side. Is there a good way of handling that or is that something that isn’t just, it’s not made to handle?

JEREMY: No, there’s definitely good ways of handling that. So, ideally if… the idea with modeling something, right? Whether it’s in database, relationally or client-side in terms of objects is that you have one place to go look at the model and one source of state for that model, right? You’d have two different rows in your database, one of which is one looked at through a certain lens and the other one is looked at through a different lines; because then if you change one, then the other one doesn’t get updated. It’s really the same principle on the client side.

So ideally, if you have two different tweets, but it’s the same tweet, that should be one model. And when we change the model and be in both collections and both collections will have that change event and both views will re-render off of those collections. So maybe instead of just collections, one for each; for the left and for the right, you end up with three, right? And the first one is where the canonical source of all of your tweets are and then the two just look into that and pull tweets out and maybe share them sometimes.

CHUCK: OK. So that makes sense. So does anyone else have questions about Backbone? We have a few minutes before we have to get to the picks.

JEREMY: Maybe Yehuda’s got some questions.

CHUCK: [Chuckles]

JAMISON: [Chuckles]

YEHUDA: I don’t really have any—so I guess my main… so the main thing that I think that is different between something like Backbone or Sinatra in Ruby and something like Ember or Rails is what you do when patterns become conventional. And I think Sinatra and Backbone take the approach of “that is the communities’ job. Please feel free to write plug-ins, write extensions, write blog posts, put up Backbonepatterns.com, but we are basically done. We have scoped out the problem and if there is obvious things that a lot of people are doing, go to town, but is not in scope.” Where Rails and Ember say, “OK, overtime people are adding different patterns, people are using these patterns; let’s try to make it so that you don’t have to personally find it on your own.” And I guess.. first of all am I  characterizing it correctly or would you—

[Crosstalk]

JEREMY: No, I don’t think you need to draw that parallel, right? Sinatra and Backbone are not the same thing in Rails and Ember is not the same thing they are four different projects and they approach things differently. And I’d be glad to describe what I think the Backbone approach would be to filling in patterns and plug-ins, which would be that if it something that is useful for 80% or 90% of the apps out there, then we should absolutely be doing it.

So that’s true both in terms of basic utility functions on collections. You now, like, not everyone is going to use… I don’t even know what these things are… not everyone is going to use sum and shuffle and sort it index and group by and sort by and every and reject and include, all those kinds of convenience array functions — not all apps are going to need that. But they are going to be handy for most people so we include them because it’s easy to do and they are also small and lightweight and so that’s why it’s something  that we think is a good idea for Backbone. But I don’t think… yes but if it’s something that might be useful for 30% of apps, but it’s a big heavy change, then yes that shouldn’t be—

[Crosstalk]

YEHUDA: So a good parallel will be REST and Rails. So there’s actually is a third thing here; elephant in the room — which is sometimes you discover patterns and if you make them a poor thing, they become a thing that everyone uses. So, jQuery deferreds under this idea, “This is a good pattern. We think this is a good idea. If we put it in, it will be the canonical choice for 80% or 90% of people.”

JEREMY: So yes that is the elephant in the room and I think that has much less to do with engineering than it does with personal taste, right? It may or may not be a good pattern and it may or may not be good for some group of people, but that’s sort of you can’t really answer that question, right?

YEHUDA: So I agree that—I mean Rails has everything to do with DHH’s personal taste, but at the end of the day what you name your actions in a controller doesn’t matter enough to not have a default, right? Giving people an answer so you don’t have to think about it is a bigger whim than saying, “You might  not agree with DHH, so feel free to name it whatever you want.”

CHUCK: Right.

JEREMY: OK.

CHUCK: So one other thing that I wanted to do before we got into the picks was we did get an email a little bit ago. And that was from Jonathan Mahoney and it looks like he’s got a .eu address, so he’s over in New York somewhere. He said, “You mentioned Backbone several times, which is my MV framework of choice in building web apps. However, there are two projects I think deserve mention in discussing Backbone; there’s Backbone.ModelBinding and Backbone.Marionette, both by Derick Bailey. The first adds Knockout.js style data bindings and the second adds a really nice abstraction layer for forming composite applications. And this kind of lead me into another question; have you seen a lot of people adding things to Backbone sort of outside of the main tree, I guess?”

JEREMY: Yes absolutely and that’s how it’s supposed to work. So the idea is if you are doing a large app built on Backbone, you will probably start with Backbone; you may end up making your own base class that adds special functionality that you need for your app. Maybe that’s local storage like sort of right through local storage caching, maybe that’s a web socket back end instead of the default jQuery AJAX rest back-end maybe that’s sophisticated nested views, maybe that’s a client server thing. So yes, I think that there’s lots of people doing that inside of their own applications. There’s also been people who have been generous enough to share their extras with the community by doing extensions.

CHUCK: All right.

JEREMY: If you are asking about those extensions specifically, we can dig in to that too.

CHUCK: Have you used them?

JEREMY: I haven’t used them for projects, but the whole data binding topic is an interesting one because  that is one of the main distinguishing points in philosophy between Backbone and Ember — about how bindings should be treated.

CHUCK: All right. Jamison, were you going to say something?

JAMISON: I was just going to ask if there was like a defined architecture for writing add-ons to Backbone or do people kind of roll however they want.

JEREMY: It’s a pretty small… there’s not really anything… so the entire source is annotated with the explicit idea that you should be feeling free if something is not working to dig in and figure out how it works and also to dig in and overwrite things if you find the need. So there really isn’t much in the source and in the API that’s not public. There’s I think we’ve actually got a few more private methods. I think the case that 95% of the methods inside all Backbone classes are public and thus suitable for overwriting if you need different behavior. So basically, the whole thing is a public API.

YEHUDA: Yeah I should mention that is essentially true about Ember, except that fewer people do it. I think the general idea of like build your entire library in a way that APIs that are exposed are thought through well enough so that if someone wants to overwrite them clear paths of doing so, is clearly a good idea.

JEREMY: And that it won’t break anything else, right? And also that there’s hooks. So like, in terms of Backbone, one of the ways that happens is to sync. So people has… so in terms of persisting your data to the server, people have really interesting requirements, right? Like maybe you have the ability to control what the server tells you, but maybe you don’t. So Backbone gives you hooks so that you have out of parse methods so that whenever you got server side data, you have an opportunity to translate it before it gets turned into model objects. You have the ability to override the sync function, which is what gets the single function that gets called every time you try to make it save the change to the server, both at the model, the individual model level and the collection level. So you can say, “All of my collections are backed by my main Rails app except for this one that goes over the Twitter API and this other one that goes over to my credit card processor.” And so those two collections, I’m going to change the sync function to go to a different place and to behave in different way. So there are a lot of hooks in there; and people are actually adding more all the time.

YEHUDA: And I definitely agree that if you think things through that way in the first place, you end up with it’s a lot easier for people who come up with an unexpected thing to do what they need to do. I do not consider that a distinction between Backbone and Ember, I think it’s just good architecture.

CHUCK: All right well, let’s go ahead and get into the picks, let’s start with Jamison.

JAMISON: So my first pick is Matt Might’s blog. I think he is a professor at the University of Utah. He teaches programming languages, but his blog posts are amazing. Some of them get very academic if you don’t care about the in-depth topic of programming languages, then you might wanna skip some of them but he some great ones about just like Unix patterns, different shell utilities, his blog is great. That’s my first pick.

My second pick is Addy Osmani (is that how you say his name? I don’t know…) He’s a JavaScript guy at AOL and he did a series of videos called “Scaling JavaScript Applications”. It just got put up on Vimeo a couple of weeks ago and he talks a lot about different paradigms of organizing your JavaScript code beyond just the store everything in DOM, like Jeremy talked about. So it’s about an hour long, his three videos he talks a lot about the different frameworks and a lot about the underlying principles as well. It’s not just like how to use Backbone but its how kind of what are the ideas that went into Backbone and other frameworks as well. So I’ll link to those but those are great. They are well worth an hour of your time to watch.

CHUCK: All right. Cool. AJ what are your picks?

AJ: So first off, the site that we used are feedback, uservoice.com I was really pleased with them when I asked them if our Utah JS user group could have a full account and they have a promo code for all people that are doing non-profit type stuff. So I thought that was really cool and they got a nice service, so I wanna get a shout out to them for that.

And also, apparently there was a music video that went on around the time of the Super Bowl by OK Go and it was very reminiscent of this video I saw before for a film commercial. And they are both very interesting because they used unconventional methods to make music and so I got that YouTube link that I’ll share but the commercial for the phone is called NTT Docomo, it’s the wooden phone and they have a ball that rolls through the force, like a mile long on different blocks that make different sounds as it rolls down this hill.

JAMISON: That’s sweet. So it’s like a Rube Goldberg type thing.

AJ: Yeah it’s like Rube Goldberg with music. And then OK Go had one too, but I didn’t think it was as original because other people have been doing stuff since that one.

CHUCK: All right. Yehuda, what are your picks?

YEHUDA: So I have two picks; two and a half picks. First of all, es5.github.com, it’s the annotated ECMAscript 51 spec and I think people in general should probably read specs more than they do. Obviously is not like a noob thing, but I think people wait far too late in their development leveling up to go read specs. So those are my two picks es5.github.com is annotated ECMAscript spec with a lot of interesting annotations. And I would recommend like reading front to back one day.

And the other one is HTML5 spec author view that’s the sky and that’s basically a version of the spec without the algorithms. So there’s like what a web browser needs to do in order to implement the cache for instance. And that’s interesting; perhaps to be a useful thing to read but most of the time, you just want a good, clear description if you what the feature is and I think what the algorithms out, it’s easier to read the whole HTML5 spec front to back. So I do this on a regular basis and I would recommend people do.

And in the HTML5 spec, you can actually subscribe to changes for specific parts, so if you are really interested in canvas, you can do subscription to changes in canvas. I think that’s one of the sections and that’s cool if you are just like trying to become notified if there are changes. And then not a pick but — goes to Google for releasing Chrome for Android; that actually excites me a lot.

CHUCK: All right. Joachim, what are your picks?

JOACHIM: Well, I know if picked this before, but one of the things I’ve been spending on a lot of time on the last few weeks is PhoneGap, which is kind of interesting. And PhoneGap is… I’m pretty sure many of you not know it, but it’s basically an abstraction layer that gives you native functionality from JavaScript HTML apps that you run within iPhone or Android phones or whatever. And it’s pretty interesting. So the company behind it just purchased by Adobe and Adobe and IBM and Microsoft and other companies are putting a lot of resources into getting it more stable. So there’s a lot of interesting stuff going on there.

CHUCK: Yeah PhoneGap I think was also accepted into the Apache Foundation.

JOACHIM: That’s right. There’s a lot of work going on there, they renamed it Callback and then renamed it to Cordova and so there’s a lot of bureaucracy going on right now. But hopefully, it will get stable in the next few weeks or months.

AJ: Yeah I know.

CHUCK: It depends. I went to Apache Con this fall and yeah, the incubator is kind of an interesting program because they basically have to go in and make sure that it will wind up with the Apache licenses, so that’s why you see them changing names and doing all these other stuff because they were trying to avoid any collisions with copyrights, trademarks and any proprietary or whatever software, so.

JOACHIM: I mean I love the idea of it, you know, I think we are world class, our stuff runs everywhere and now it can run a few more places as well and get better access to native components.

CHUCK: All right. Well, I’ll go ahead and put up a couple of picks. The first one is I was listening to a podcast, it was the South Geek Ramble and Review and anyway the first like 3 minutes were a sound from a video that I actually found on YouTube and the video was “Gmail Man” and it’s actually a Microsoft commercial, but it was pretty funny, and so I’ll go ahead and share that because I was laughing for a while about that one.

And then one other thing I’ve been working out and counting my calories so that I can get my diabetes under control and I’ve been using a system, it’s called My Fitness Pal, and it really is just that it’s a calorie counter and you can also track your work outs on it. And so I’ve been putting them in there and I also been putting them up on the dailymile.com and so I’ve really been enjoying those.

As far as technical picks go, I’m going to pick one that everybody uses, but you know, every time I use it I’m just impressed with everything that goes into it and its jQuery. So I’m just going to give them a plug because I think they are really cool.

JAMISON: I’m going to pick “computers” next week.

CHUCK: [Chuckles] No, thanks.

YEHUDA: Computers are awesome.

CHUCK: [Chuckles] Yeah, I use one on occasion.

AJ: You guys are all wrong; technology is the best!

CHUCK: [Chuckles] All right. Jeremy, what are your picks?

JEREMY: It’s the first I’m hearing of it so I will pick one to match Yehuda’s which is the ES-discuss mailing list on mail.mozilla.org is a woefully under read mailing list where all the folks who are working on the next version of JavaScript talk about basically what it’s going to be and why it should be certain ways and the things that they don’t like that they are trying to fix. So if you are doing any kind of JavaScript work at all and you are interested in where the language is heading, it’s a must read, or at least to catch up on a couple of times a month and scan through the new topics.

JAMISON: I have a question about that; what if you are not a programing language expert or you feel intimidated by all the academia that goes on, is there are more… either good introduction to those topics or a more digestible summary?

JEREMY: No, although that will be good for someone to write. It’s pretty much the nitty gritty of what they are working on. So usually that means you don’t need to be an expert; they are not talking about super arcane stuff, it’s like everyone has trouble with function statements versus main function expressions and although maybe that sounds a little bit intimidating, but you know, like a function statement is and when you sign a function to a variable. And so they are talking about like when that one breaks and when it works well and that kind of thing.

JAMISON: OK.

JOACHIM: And some of the way they are doing is that like every kind of proposal has to have a working script or like a code sample of how it’s going to work in real life. So it is kind of not accessible, you can kind of see like, “OK this is what I want to be working with in the future if it is goes forward.” I definitely agree that more people should be reading it and chiming in.

YEHUDA: I also say a lot of people complain a lot about, “I don’t know what’s going on. These guys are just doing stuff behind smoke-filled rooms.” And actually as far as I can tell, they aren’t a lot of smoke-filled rooms. There are definitely some decisions that get made out of the public eye, but there’s a ton of opportunity for people to provide feedback. And I think —- really want that like I spend a bunch of time contributing and people were excited about that. So for people out there who have time and interested in participating the future of the web, there is a way to do that and you should do it.

CHUCK: Besides, you only get smoke-filled rooms when something is on fire, so.

YEHUDA: This is a good point.

CHUCK: All right.

YEHUDA: All right. Awesome.

CHUCK: So we’ll wrap this up. Real quick, couple of business items first. If you go javascriptjabber.uservoice.com… or is it jsjabber?

YEHUDA: I don’t know.

AJ: Jsjabber.

CHUCK: Jsjabber.uservoice.com you can suggest topics for us. That’s something that we really appreciate then we know what you wanna hear about. One other thing is that we are in iTunes, so if you go on iTunes, you can subscribe there you can also leave us a review. If you do subscribe and you do leave us a review, that really helps us out because it kind of helps bring us to the top of the list when people are looking for JavaScript stuff. So go ahead and do that. If you are listening on some other device, I do have a subscribe link up there and so go ahead and subscribe on just off of the RSS feed and outside of that, we’ll catch you next week!

10 comments
Scott Blue
Scott Blue

oh man, this could have been such a great podcast if it wasn't ruined by one of panelists who kept interrupting with his heavily opinionated rants and yelling over top of everyone. I couldn't imagine working with a guy like this

simbo1905
simbo1905

About 10 minutes in there is a debate about what is a view and what is a controller. I was surprised that no-one in the panel said "mvvm" or "presentation model" to describe conversational state of the user with the application that is not the server-side / database model.

Deerantler
Deerantler

Hi,royston,i want also want to use backbone.

Ryan
Ryan

Yehuda = typical Rubyist = douchebag

Jason
Jason

I'm in the same boat as everyone else. I was looking forward to hearing Jeremy speak about Backbone, but after forcing myself past the 15 minute mark I just couldn't stand Yehuda's constant interruptions.

Royston
Royston

Completely agree with Justin + Alex. I gave up listening after 17 minutes as I was sick of hearing the whiny defensive ember-obsessed centre-of-the-universe noise interrupting everybody. I still don't know whether I want to use backbone, but I know I _don't_ want to use ember. Not surprised the framework is opinionated... Can anybody recommend another webcast on backbone that isn't hijacked in this way?

Alex
Alex

I came here for information about backbone.js and got a podcast with someone, that tried to highjack the topic to advertise ember. Maybe the title of the podcast should become changed to ember vs. the rest of the world ;)

Justin
Justin

I've worked with sooooo many pedantic, annoying, argumentative, pompous and arrogant programmers over the past 15 years... I can only hope to never again be forced to listen to one echoing around in a tin can during a podcast. This individual nullifies all of the greatness that JSJabber would otherwise have to offer.

Mathias
Mathias

Nice topic. You need to have more "radio" discipline - please... would make it much more pleasant to listen to.

Andy
Andy

I think Ember should have been written as a configuration layer on top of Backbone.

Trackbacks

  1. [...] background-position: 50% 0px; background-color:#222222; background-repeat : no-repeat; } javascriptjabber.com – Today, 7:43 [...]

  2. [...] JSJ Backbone.js with Jeremy Ashkenas englischsprachiger Podcast [...]

  3. [...] I remember right, Jeremy said that this comparison is incorrect. I don’t remember exactly why off-hand, but I can’t help but make this comparison [...]

  4. [...] and goes into detail about the pros and cons of using the technology.  Recent episodes include Backbone.js (Jeremy Ashkenas) and co-hosted by Yehuda Katz (ember.js) and include some lively discussion between the two about Backbone.js vs. Ember.js and some design [...]

  5. [...] Backbone.js with Jeremy Ashkenas by JavaScript Jabber [...]

  6. [...] a rotating cast of notables from the JavaScript world. My favorite episode was pretty much a debate between Yehuda Katz (Ember.js, Rails, jQuery) and Jeremy Ashkenas (Backbone,js, underscore.js…. Other regular guests are guys like Tim Caswell, who is a big deal in the node community. This [...]

Previous post:

Next post: