Episode 145 of The SitePoint Podcast is now available! This week our regular interview host Louis Simoneau (@rssaddict) interviews Addy Osmani (@addyosmani) about his free online book about the Fundamentals Of Backbone.js and how using javascript frameworks can really help when building a front-end Web app.
Download this Episode
You can download this episode as a standalone MP3 file. Here’s the link:
SitePoint Podcast #145: Bachbone.js Fundamentals with Addy Osmani(MP3, 34:16, 32.9MB)
Episode Summary
Louis chats to Addy Osmani (@addyosmani) about backbone.js.
Browse the full list of links referenced in the show at http://delicious.com/sitepointpodcast/145.
Interview Transcript
Louis: Hello and welcome to another episode of the SitePoint Podcast. Today on the show my guest is Addy Osmani who is a JavaScript developer at AOL; he speaks at a number of conferences about JavaScript and about developing larger applications in JavaScript and is the author of a few books. Hi, Addy.
Addy: Hi, it’s nice to be on your show.
Louis: It’s great to have you. So, the reason that prompted me to reach out to you and try and get you to come on the show is you’ve recently put out sort of a free in-progress book about Backbone.js, is that right?
Addy: Yeah, that’s right.
Louis: So, before we dive into talking about the book and what prompted you to do this sort of project, I’d like to maybe give the listeners some background on Backbone. So do you want to explain a little bit about what Backbone.js is and what problem does it try and solve, and why would people want to use it.
Addy: Absolutely. So, the idea behind Backbone Fundamentals is it’s a book that teaches both beginners and advanced developers how to effectively use Backbone to build more structures to applications. Now, what does that all mean? Well, when you start building with App Stack or non-trivial or begin to grow, you learn that unless you have some sort of organization in place you’re going to end up with some problems. What kind of problems? Well, maintaining all of the code through applications, say a file, without using any architectural design patterns can mean that it ends up looking a little bit like spaghetti; it might look good from the outside, it might taste nice, but it’s a mess to clean up. So, when you’re searching for something a little bit more maintainable, a lot of developers find that applying patterns like MVC, which usually stands for Model View Controller, that means something slightly different on the front end and in JavaScript; that can help them keep their code a little bit more organized. Now, Backbone is one of those frameworks that lets you use the flavor of MVC to cleanly separate concern and organize the application. It’s mature, it’s incredibly lightweight given what you get out of it, and it’s great for single page applications and multi-view applications. Now, there are like a ton of other solutions out in the market at the moment which offer, a bit of a variation of what Backbone does. In my opinion it’s one of the more elegant solutions out there right now. Developers that might be looking at it and saying, well, is Backbone good enough to be used in my large enterprise model application? well it’s currently being used by the likes of LinkedIn, Foursquare, Sound Cloud, and a lot of other large companies that build their applications. Now, they’re not small companies and they’re not building small applications, so hopefully if it’s good enough for them it’s hopefully good enough for the rest of us.
Louis: Yeah, absolutely. We’ve recently started using Backbone at Flippa, I haven’t personally played with it a lot, I work more on the backend, but I’ve definitely heard good things from our front end guy about the experience he’s had with it. But maybe I want to step back a little bit, you were talking about MVC as it applies to JavaScript and to front end engineering, and I understand that probably a lot of listeners, or a lot of people out there who’ve done backend web development, you know, MVC makes sense for that, and I think it’s easy for most people to grasp why you’d want to use MVC for something like an application where you’re dealing with interaction with a database, which is your model, and then routing requests, which is your controller, and templating, but for something which is entirely on a front end, or the application code on the front end which is in JavaScript, where does MVC come in and how does it relate to front end development?
Addy: Well, on the front end it translates, in some ways it translates almost identically to the server side version of MVC, and others it differs quite a lot. I think view and models are quite similar on the front end as they are on the backend, but when you get to talking about controllers that’s somewhere where a lot of sort of JavaScript MVC frameworks tend to take a slightly different view of what that should be. Some frameworks, Backbone, for example, doesn’t exactly have a controller, what it has instead of the C part in MVC is it has routers instead which are used for sort of managing navigation; other frameworks consider the view the controller on the front end. And so it’s hard to give a concrete answer to that, but each framework, and each framework author’s template tend to take a slightly different take on how that should be interpreted, but I think that the MVC pattern or MVV, I tend to call MVC on the front end MVV, which means Model View Variation. And I think that that pattern still translates well to the front end and does help keep all of your code relatively well organized, even if you’re just keeping concepts sort of models and views in there and having to graft onto something else inside that pattern; it still tends to work quite well in my opinion.
Louis: Right. Maybe you can make this a little bit more concrete in my mind and the listener’s mind. What’s a simple example of sort of a front end application that could benefit from this kind of framework?
Addy: Anything that I would consider non-trivial. So let’s say we’ve got a simple photo gallery application which would be something that perhaps isn’t using a single app paradigm, you’re going to be having people refresh their page every single time they’re interacting with something. So, if I click on a thumbnail to view a larger version of a picture I might be going to a completely different page, that might mean I’m making more http requests, I’m having to have the user wait even longer for things to load up, and in a single page application paradigm, which is what frameworks like Backbone tend to help people do, it means fewer clicks to get things working, it means how snappy the interface is, but in terms of organizing your code it means that I can cleanly break apart the various components that make up that application. So, it’s clear to me, well, what is the concept of a photo in that application? Well, I can use models to model the data around that and say okay, well, a photo might have a caption, a photo might have an image source, it might have some additional meta data, okay well that’s the concept of the model. The collection, which is something we have in Backbone, probably represents a number of different models, so that means that if I have a gallery I’m going to have multiple models, i.e. multiple photos, in that particular gallery. And my views might essentially mean okay, well, what is that I’m actually rendering to the end user, am I taking them from an index page that might just say what the application does, and taking something that might actually let them traverse and browse through different image collections, for example, routing there is perhaps going to be used for actually taking them from one page to another and giving them URLs, clean URLs if you are using HTML5 PushState for just using the hashtags to actually navigate around the application without having to make them sort of refresh the page at all.
Louis: Right.
Addy: So that’s one example.
Louis: Right. So in that case you’re — sort of your photo model would be substantiated based on sort of, say, if I load a new page I get some JSON back from the server and that contains an object representation of these photos in the gallery, and rather than just sort of haphazardly iterating them over them in inline jQuery I’m cleanly bundling them up into a model object which would then be easier to use in other places in the application.
Addy: Yes.
Louis: And it behaves a bit more like a server side application, or like we’re used to developing in object oriented code.
Addy: Exactly, yes. So we were just taking a look at an example of a gallery application that could be implemented using Backbone and using MVC. Now, the idea behind MVC on the front end is that it still separates applications into sort of three main concerns. You first of all have models which manage the behavior of application data, and it doesn’t differ that much from how data is handled, how models are handled on the server side, it still represents sort of knowledge and data, they still respond to changes of state, but they tend to be a little bit more isolated from using controllers than you might find on the server side. In frameworks like Backbone, models can sometimes group things and collections, so you have the idea of a single model perhaps representing a photograph, but a collection in Backbone actually is representing multiple models or multiple photos. You might have views which are responsible for sort of rendering models into a form that’s suitable for user interaction. In a lot of cases on the front end your views are going to be considered your UI, they typically are rendered to specific user interface elements, so I might have a div on the page that I actually want to render my view to, and it can be called container or something else, and I’ll simply render that whether I’m using a templating library for this or I’m using Backbone’s own internal stuff, I’m just going to be rendering that view for a specific element. And you can have multiple views which is just for single models, so you might have models that represent photos in your applications, and you might have views which perhaps display different aspects of that model. So, if I have a photograph that has meta data saying, you know, well, this photograph was taken say in Italy, for example, this photograph was taken in the year 1990, there were Tom, Dick and Harry around; you could have one view that actually shows you the people that were around when that photograph was taken, you could have another view that represents the location where that photograph was taken and perhaps show you a map, and so on and so forth. You then have sort of controllers on the front end as well. Now, some frameworks don’t necessarily implement controllers when we’re talking about JavaScript, controllers typically sort receive input, can instruct models or views and respond accordingly, so usually sit between models and views they might perform some business logic and data manipulations, but they’re low inside MVC, it quite heavily varies. You’ll find that Backbone considers controllers quite differently; they actually replace it with the idea of a router for handling navigation. Other frameworks might maintain something called a controller, so they’re JavaScript MVC frameworks they have to do something completely different. So there are a lot of similarities between sort of MVC on the server side and on the client side, but it’s usually the controller side of things that’s where things differ from most I would say.
Louis: Right. And just to maybe expand a little bit on the idea of the view, if someone’s not familiar with JavaScript templating and how that works, I know there are probably still a lot of JavaScript developers who’ll either just create DOM nodes inline in their code or load entire chunks of HTML from the server, can you talk a little bit about templating and how that’s used in these frameworks?
Addy: Oh, absolutely. So, templating in general, even outside of JavaScript MVC frameworks it’s something very, very useful for your applications. One way that developers tend to approach this without templating is you might be constructing HTML for your page in memory using scripting catonation, and I’ve seen people do this; ten years ago people were doing this in doctrine right, now if you’re not using the best practices there are still people that are sort of concatenating ten or more lines of code and then injecting that into the page or injecting it every single time a new line is being constructed in memory, and the problem with that is that it’s not just inefficient from a performance perspective, but it’s also difficult to maintain. So, once you start to store multiple long strings that are supposed be representing sort of HTML in your page, and you start building larger applications, it can become difficult to figure out okay, well, what part of my page did I store the script in that contains those lines that need to be updated now. Something that is a little bit better and easier to manage but also more performant is using JavaScript templating. So, with JavaScript templating you take a look at what repeatable output that you have in your application, so rather than me saying okay well I have a JSON feed coming from my backend that contains a number of photographs, what I’m going to do is I’m going to move through every single one of those photographs, and I’m going to concatonate some image tags around that and some nested divs around that, and I’m going to construct myself a pseudo template that appends my page. Instead of doing that you can say okay, well, I’m basically repeating the same pattern multiple times in this loop, why don’t I simply represent the template, have something much smaller, okay, well, I might just have one single entry, the website says okay, well, my template is going to be composed of a few nested divs and an image element. Well, that’s all there is to it, I don’t have to have any performants around that, I don’t have any additional logic in there if I don’t need it, and instead we just apply templating to that feed that’s coming through. In a framework we actually represent that feed is either a model or collection, and we would then template based on that collection to render out those to the screen, which is the DOM, and it just means that I can actually maintain templates in a slightly more readable fashion, it’s a lot easier to read this stuff than going through all the different pluses and minuses that you might have inline, it’s also easier when you get to a point where you might want to sort of manage your template outside of your page. So rather than maintaining an application where you have to have sort of scripting catonation and your different templates stored inline, so in larger in applications you’ll see that there’s actually a lot of benefit to doing this outside of your model and your views. If I wanted to say have a template to represent how I actually output gallery items, I can simply just go to say, you know, item.tntl or item.txt, which might just contain the HTML markup representation for a single element on that page, a single photograph on that page, and then use that with templating to render out how every single other photograph on the page is going to look. It’s something that’s a little tricky to sort of explain without showing people examples, but, again, if you take a look at the new MVC what you’ll find is that there are actually quite a few examples of how templating can be effectively used with MVC frameworks and where it can come in useful. But, yeah, I definitely recommend checking it out.
Louis: Yeah, absolutely. It’s something that we take for granted working on the server side, but that is I guess still not a widespread practice working on the client side possibly because a lot of these frameworks haven’t enjoyed widespread use as of yet, but it’s definitely powerful and it definitely makes the code more maintainable if when you need to change your markup you’re actually changing markup rather than digging through your code to find, oh, I’m concatenating a div in here and I want to make that a span now; suddenly I have to go through and find all the instances of code that does that. Right, that sounds super useful, so, however, I guess one of the issues with Backbone is it’s fairly new, it might seem a little odd to people who aren’t used to working with JavaScript in such an ordered fashion, people are used to just sort of slapping a script like when you click this link whatever opens or just DOM manipulation.
Addy: Hmm-mm.
Louis: So it can have a bit of a learning curve to it, and I guess this is where the idea of doing this book comes in, right?
Addy: Yes, exactly. So I’ve been blogging for I guess four or five years in JavaScript now, and whilst blogs are really useful for beginners to sort of grasp new concepts and gain knowledge, they also come with some caveats which is why I decided to write this book; blogs only have like a limited amount of information you can convey in them, and I figured, well, why just show somebody how to build an application with a framework when there are going to be beginners that ask, well, where I can learn the fundamentals of this framework so that I can use this tutorial. And then you’ve got like advanced users that might say, well, this is a little too basic for me, I’d like to know how I can build something even more complex than what you’re showing me right now. And I think that a book solves this problem quite well because it means that if you’re coming from a completely fresh background and you have very little experience that’s sort of MVC on the front end, or architectural patterns with JavaScript, you can just come in and read the book and start off in the basics section and fairly quickly you’ll pick up all of these concepts. I start fairly slow off, we don’t throw people in the deep end; I think that by the end of the first chapter you do get most of the concept, and one of the things that the book’s going to be trying to do is sort of first of all teach you how to build a very simple application, and then iterate on that application as we go along through the rest of the book, so you’re going to learn to take that application more complex, learn how to integrate it with different backends; there are people that have sort of requested to learn how to integrate Backbone with say Node.js or with Sinatra or with WebSocket frameworks. And the book tries to sort of help the user on their journey, so it gives you sort of a complete look at — or I might need to redo that, but the book gives you a complete bird’s eye view from start to finish of what you need to learn how to properly use Backbone.
Louis: Right. And the other thing obviously that’s really interesting about this book, above and beyond it being a book about Backbone, is that you’ve done it sort of for free online in a sort of collaborative fashion, because it’s all on GitHub, and I assume you’re accepting contributions from different people, and it’s still very much in a development stage, it’s still incomplete, but I had a read through the Basic section, and in terms of getting you up and running it definitely has all the basics, but there’s, I assume, a lot of work to come.
Addy: Yeah, yeah, there’s a lot of work to come. So when I first released the book, I think about two weeks ago, I started a wish list that developers could go into and add requests for topics they’d like covered, so if a developer wants anything written about in the book, or they want me to consider writing a chapter about something, all they have to do is just submit an idea, I’ll talk to some other developers about it and see what they think, and if we think it’s a good idea I’ll write a chapter about it. Just going on some of the items on the wish list right now there are people that want me to sort of address using different test stacks Backbone, you know, people want to know how to unit test Backbone using solutions like Queue Unit, they want to learn how to build mobile applications with it, so there’s a lot of work still left to go, but I’m excited about it, I think we have an excellent opportunity to sort of build something that is very open, will hopefully be very authoritative and will help some people on their journey through Backbone.
Louis: Yeah, absolutely. And this kind of free online book has been maybe not a super common pattern in the industry, but it’s definitely something that’s happened before, and there have been some really great examples; I mean both of Mark Pilgrim’s books on Python and HTML5 are these huge resources that are extremely useful for those topics, and I think help those topics get a lot more interest from the community than they might otherwise have gotten.
Addy: Oh, absolutely. I think one of the reasons I wanted to release this book for free is I believe that educational material should be free and accessible where possible. I think that authors who write are totally within their rights published contents and ask for something back, people need to make a living, but when you open source your content it just means that more people are going to be able to read it, share it, spread the word about it, and, I don’t know, I think it’s a nice way to go about putting educational material out there.
Louis: Yeah, especially for something like Backbone where it’s not very mainstream at the moment, so if you were to publish a book, a conventional book, you wouldn’t expect to sell a lot of them, but having it for free can build a lot of momentum behind this because it makes it easier for people to learn it.
Addy: Certainly. And I guess one of the reasons I decided to go for this open source model is this is actually the second time I’ve released an eBook for free. The first time I got something else out there last year, this book called Essential JavaScript Design Pattern; I think I had something like 250,000 downloads in the first year, and it’s difficult to get people to read things, and I’m just happy that if I can duplicate sort of the same level of success with Backbone Fundamentals that I did with that I’ll be happy, it’ll just mean that I guess I’ve had a way to hopefully influence other developers in a positive way and help them I guess code better.
Louis: Yeah, definitely. And I think there’s probably a lot of room for JavaScript developers to take some hints from server side developers and look at this kind of structure, it’s definitely become a major topic in the last year or two, I guess, that you’ve seen all of these sort of front end frameworks bring up, and really a focus on trying to make JavaScript behave a little bit more like a structured programming language that we’re used to working with.
Addy: Hmm-mm.
Louis: Now, you say you’ve had a look at a number of different JavaScript frameworks that have come up in recent years and that you decided to go with Backbone because it was a natural fit for you. Do you want to maybe talk about some of the differences and where you feel like you like Backbone better and where some of the other ones have interesting features?
Addy: In a lot of cases I think it comes down to style. So, a while back when I was first learning about Backbone, I realized that there were a number of other frameworks that are out there at the moment that tried offering something similar. So we had — I guess a year ago we had SproutCore, we had JavaScript MVC, Spine was coming into the picture as well, and most of those frameworks are still around, SproutCore has become Ember.js, and most of the others are still around, but for developers that are still sort of on the fence and trying to decide on what frameworks to opt for, I created a project called To-Do MVC to try helping with this. What To-Do MVC is, is basically a collection of to-do applications, so everybody sort of knows what a to-do application is, it’s just a list application where you can add little reminders about things you have to do, you can cross items off the list, you can edit them in place. And so the idea with to-do MVC is that you get the same two applications in a number of different frameworks, we’ve got a Backbone.js version, we’ve got Spine.js, JavaScript MVC, Ember.js; and for developers that are still on the fence about which framework they want to commit to it just means that all you have to do is go in, take a look through the source code for any of these applications and see which one best fits the style that you might prefer using. Now, most of these implement some form of MVC, or a variation of MVC, and it’s not to say that simply reviewing the source code is going to be the defacto thing that’s going to make you decide on a framework, you should, of course, go and research a little bit more what the framework offers outside of the implementation to-do MVC offers you. But I think it’s just a way to I guess figure out what you might prefer using without having to spend six or eight months implementing something and then going, well, you know, this probably wasn’t the best decision.
Louis: Yeah, absolutely. And so did you find yourself at any point struggling to implement the same feature set across all of these different frameworks?
Addy: Oh, absolutely. I think it’s very difficult to I guess be a master of all frameworks, it’s extremely difficult because of varying feature sets and the syntax that’s involved, and so the community’s been extremely helpful here. Anytime there was an application which I didn’t feel that I could implement personally I tried reaching out on Twitter and on GitHub, and the community has been great, people have come forth and said, you know, I’m going to spend a weekend building this application and if you can help me with the style just to make sure that it’s implemented properly, I’m fine with pushing this to To-Do MVC, and that’s really helped the project sort of grow. At the moment I’m currently working some contributors to get sort of Dojo MVC’s quote in there and other applications, but it just means that whatever experience other developers have with frameworks that I don’t, we can still lend those to the project and hopefully help somebody else out there pick something that will work well for them.
Louis: Yeah, absolutely. If a JavaScript developer is sort of on the fence, they’re sitting at the point where they’ve been pretty happy doing everything they’ve done so far just using inline DOM stuff and jQuery, they do feel like sometimes they’ll look back at their code and be like, ooh, that’s a little difficult to read or understand or play with, or they’ve come to someone else’s code and had that feeling, but it feels like a big step to start moving maybe existing code over to something like Backbone. What’s a good way to sort of get your feet wet and start playing with it?
Addy: To be completely honest I’m going to give a very silly answer, it’s just looking at the basic view application that comes with Backbone. As I was saying with to-do applications, it’s just something that I’ve actually built into a complete project, it just gives you a nice simple flavor of how you can break down an application into sort of models used, controllers if the framework supports it, or routers and collections, etc. What To-Do MVC actually also had is a version of the to-do application implemented in just jQuery and just plain JavaScript, so you can actually take a look at how you can take something that’s currently in I guess what some people might call spaghetti code, which is like everything in a single file, and then see how that can actually be broken down into the different concerns using different frameworks. So I think To-Do MVC can actually help you with that too, hopefully.
Louis: Right. So that’s pretty interesting. Is it a big difference in terms of the amount of code that’s written compared to either plain JavaScript or jQuery when you’re using these various frameworks?
Addy: I think in terms of the amount of code the developer has to write themselves it’s minimal; it’s minimal, the addition is very minimal. You do of course have to include the framework that you’re opting for, so if I’m using Backbone it’s just going to be a few additional kilobytes to my project, if I’m using Spine it’s going to be the same case. But, yeah, it’s minimal in terms of the developer effort requires to turn that code into something a little more structured.
Louis: Right.
Addy: But for developers who are very new to this and who are still wondering okay, well, how do I take my standard JavaScript application and convert it or break it down into something models use in controllers, well there’s some very simple things that you can do. The first thing I would do is take a look at the data in your other applications, so what unique data is represented in your app. For photo gallery application, again, you’re going to have things like the id of pictures, you’re going to have id’s of galleries which contain multiple pictures, so that’s going to be a group or a collection. You’re then going to need to think about what the user needs to be able to see and do. Now, that comes down to your view, so we just talked about models, models are all about the unique data in your application and how you want to represent them. You even have views which basically are what the user needs to be able to see and do, it gets a little bit more complicated than that, but let’s talk about — let’s take a look at templating, right, so another thing to consider is what repeatable output do you have in your application that you want to shift to JavaScript templating to make things a little bit more performant. And then you have controllers, and the role of controllers vary, actually we’ve already sort of reviewed, and in your application if you’re talking about using perhaps Backbone, let’s say that your controllers are actually routers, and what routers are going to do are they’re going to take care of the navigation of the application. So if I have a single page application and I want to start navigating around the different galleries that might be available, when I click on a specific gallery I want the user to still be able to bookmark the path to that gallery. So even though this isn’t an application which has sort of real paths, and there are no real folders on the server which might represent the file or the view that we’re going to be rendering, we still want to give them a nice clean way to simulate this behavior. And using Backbone you can either use HTML5’s PushState or you can simply use hashbang URLs to simulate these URLs so people can still go in and say okay, well, I’ve navigated to a particular photograph in this application, I know that this isn’t an application which has real folders or which has the proper server side structure, but by copying and pasting this URL using Backbone’s routers I can still navigate the user back to the specific image very, very easily, this is one of the powerful things about these MVC frameworks; if they support routing by default it means that you don’t have to sort of natively go yourself and figure out how do I monitor hash change events, and how do I take care of all this mucky stuff to do with URLs myself.
Louis: Yeah, and does that extend to things like the browser’s history and the back button?
Addy: It does; depending on the framework it can actually have a built-in support for managing back button, but yes it does. It also means that if I navigate multiple depths down inside an application it might have multiple views, I can easily use the back button; if the application has been coded correctly I can use the back button to go back exactly to where I was.
Louis: Yep, right. And do you know under the hood if that’s using HTML’s browser history?
Addy: Again, it really does vary depending on the framework that you’re using.
Louis: Yeah, but just talking about Backbone specifically because you’d probably know a bit more about it.
Addy: So in terms of the specific question you’d probably be talking more about Backbone or HTML5 PushState, and in terms of that, yeah, Backbone does support HTML5 PushState, if you want to turn it on you can use it. And the benefit of using PushState is rather people seeing a — sort of a hash or hash fragment in the URL at all, all they’ll see is very clean, very plain URL; the end user, they won’t know that, without sort of inspecting your code, they won’t know that you’re using a single page application, it’ll look like it’s a completely server based application and that like all these paths are actually naturally existing on the server side, but they’re not, so it’s actually quite a beautiful thing because it means that they don’t need to worry about is this weird looking URL actually going to work in other browsers or anything like that. And the beauty of frameworks that do support HTML pushState, in a lot of cases they gracefully degrade back to using hash bang if pushState isn’t supported. So if I try navigating using a pushState URL which doesn’t contain any hash bang, and my application doesn’t necessarily support that, I can use hash bangs instead and still provide users with the ability to bookmark URLs.
Louis: Right. So that was a bit of a diversion of what you were talking about, which is to say that when you’re looking at breaking your application down and taking an application that you’ve written in an unstructured way and trying to make it structured using this, and you were just getting to the point of saying how do you break down the interactions into routes and that sort of thing.
Addy: Absolutely. There are a lot of applications that people use on a daily basis that are single page applications, and they may not be necessarily using Backbone, they might be using sort of homegrown solutions that were something else, but there are actually single page applications that are either using hash bangs to give people the ability to navigate around them, or they’re using HTML5 pushState. Gmail is a perfect application of this; Gmail is probably my favorite JavaScript based application, and if you take a look at the URL scheme that Gmail uses you’ll see that in some browsers it’s actually using hashbangs to help you navigate around different email. And if you copy those hashbang URLs and you paste them back, you’ll actually be able to get to exactly where you were regardless of whether we’re talking about a specific email or a specific setting that you were looking at, and I think that’s quite beautiful. Being able to cleanly manage state and help people get to exactly where they were in the application and share those locations with people just means that the validity of using JavaScript for these applications is a little bit more strong and a little bit more powerful I think.
Louis: Definitely. Alright, well, I just want to thank you so much for taking the time to come on the show and hash out all these topics, I think it’s really interesting to get your view on all this. Before we go I’d just like to provide everyone with links to the relevant material, so the book is at github.com/addyosmani/backbone-fundamentals, and do you want to give some links to your Twitter and your website for people to look you up online.
Addy: Absolutely. I’m on Twitter @addyosmani, so that’s a-d-d-y-o-s-m-a-n-i; and that’s the exact same for GitHub, so github.com/addyosmani, and if you’d like to read a little bit more about some of the screencast books and articles that I write, they’re all on addyosmani.com.
Louis: Fantastic, that’s all pretty straightforward. So, again, thanks so much for taking the time to come on the show and talk about this, and I really look forward to seeing how this book develops and how people jump in and contribute to it.
Addy: Absolutely, thank you for having me.
Louis: It’s been a pleasure, thanks.
Addy: Great, thank you.
Louis: And thanks for listening to this week’s episode of the SitePoint Podcast. I’d love to hear what you thought about today’s show, so if you have any thoughts or suggestions just go to Sitepoint.com/podcast and you can leave a comment on today’s episode, you can also get any of our previous episodes to download or subscribe to get the show automatically. You can follow SitePoint on Twitter @sitepointdotcom, that’s sitepoint d-o-t-c-o-m, and you can follow me on Twitter @rssaddict. The show this week was produced by Karn Broad and I’m Louis Simoneau, thanks for listening and bye for now.
Theme music by Mike Mella.
Thanks for listening! Feel free to let us know how we’re doing, or to continue the discussion, using the comments field below.
Louis SimoneauLouis joined SitePoint in 2009 as a technical editor, and has since moved over into a web developer role at Flippa. He enjoys hip-hop, spicy food, and all things geeky.
