- Jeremy Ashkenas (twitter github blog)
- AJ O’Neal (twitter github blog)
- Charles Max Wood (twitter github Teach Me To Code Rails Summer Camp)
- Jamison Dance (twitter github blog)
- Joachim Larsen (g+ github website)
- Yehuda Katz (twitter github blog)
- IRC log of Jeremy and Yehuda’s chat
- Ice library
- Document Cloud
- client-side MVC
- server persisting
- Is backbone really MVC?
- Backbone Collections
- Convention over Configuration
- jQuery is an opinionated library
- DOM only approach
- Templates in other languages
- Benefits of templates on the server
- Core patterns
- jQuery deferreds
- When to add features to your library
- Adding onto Backbone
- Adding hooks
- Matt Might’s blog (Jamison)
- Addy Osmani Video Part 1 Part 2 (Jamison)
- uservoice.com (AJ)
- OK-go music video (AJ)
- NTT Docomo video (AJ)
- ES5.github.com (Yehuda)
- HTML5 spec author view (Yehuda)
- Chrome for Android (Yehuda)
- PhoneGap (Joachim)
- Gmail man (Chuck)
- myfitnesspal.com (Chuck)
- dailymile.com (Chuck)
- jQuery (Chuck)
- ES-discuss mailing list (Jeremy)
JAMISON: I’m going to pick “computers” next week.
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!
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?
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.
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?
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.
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—
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.
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.
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.
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.
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—
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.
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.
JEREMY: Maybe we can get more specific instead of just feels easier or what doesn’t feel easier.
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?
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.
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.
YEHUDA: The whole thing is a pipe dream to begin with.
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—
YEHUDA: So I’m willing to be convinced on the pipe dream, but I want us to be honest about where we are today.
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–
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—
JOACHIM: No, but it can. There’s no reason why it can’t do anything.
JOACHIM: No, but it won’t if you are broke.
JEREMY: People do advocate that. That’s the full-on progressive enhancement to–
YEHUDA: So, Jeremy–
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.
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—
JOACHIM: Because people… they will go somewhere else. If that take 10 seconds for a page to load—
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.
JOACHIM: It’s called an abstraction layer.
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—
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.
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—
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—
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: 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.
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?
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?
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.
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.
YEHUDA: I don’t know.