To subscribe to the podcast, please use the links below:
Craig McKeachie: [0:00] On this episode I interview Derick Bailey, backbone J S expert and author of the popular “Marionette Plug in for Backbone.” This is Front-End Developer Cast Episode One.
[0:30] Hi everyone. Welcome to the first episode of the podcast. Before we get started with the interview, I wanted to try to quickly describe why I created this podcast, who it’s for and hopefully what you’ll get out of it.
[0:43] So why. I think front-end development is a historically undervalued skill. Front-end developers often get the “they just make it pretty” label. Mostly I’ve seen this mind set out of back-end developers, honestly, myself at times in the past and the designers who hand off their designs and just have them translated to HTML and CSS. I think this mindset is rapidly changing though.
[1:07] There’s a lot of demand for positions with the title, front-end developer and full stack developer, which that term full stack implies the whole stack is important, including the front-end that we’re focused on. Why is this happening? One of the major factors is, there’s a shake up in the way web applications are being built.
[2:12] For those who want to be part of this future of web applications, front-end developers as well as, people who consider themselves full stack developers, but value those front-end skills. I think we’ll get a lot of this podcast.
[2:25] What specifically am I hoping you’ll get. With the pace of change and the amount of stuff you’ve got to keep up with nowadays, there is a need to learn more and more.
[2:37] I’m going to try and keep you up-to-date with the latest stuff on this podcast by interviewing framework authors, people using the libraries already ahead of you on the learning curve, and trying to give some education around that.
[3:24] I thought this would be a great topic for the first podcast. For at least the first 10 episodes or so, I’ll be interviewing people either using these frameworks in the real world or framework authors themselves. My interview today is with Derick Bailey who was one of the earliest adopters of backbone and has written several prominent plug-ins.
[3:42] I caught up with Derick at CodeMash, a great regional development conference, CodeMash.org. Check it out. Without further ado, let’s jump into the recorded interview.
[3:51] Hi. Today I’m lucky enough to have Derick Bailey with me.
Derick Bailey: [3:55] Hi, everyone.
Craig: [3:56] Derick is famous, I’ll say, in the space where I’m starting this podcast…
Derick: [4:00] Mildly Internet famous.
Craig: [4:02] Internet famous for the tons of experience with Backbone which is the MVC framework that’s probably the most mature out of all the frameworks or the most used in the real world. Even heard recently, it’s included in WordPress and the Core right now.
Derick: [4:19] Yeah. It is. That was a recent addition to WordPress.
Craig: [4:21] Derick has the dubious distinction of being the author of Marionette which is a great framework that adds the piece, at least in my opinion, to Backbone that makes it a lot more of a framework and less of a library.
Derick: [4:37] Yeah. Backbone itself really was built and intended to be a library, a way to organize your JQuery code. I found it and started building things with it and wanted a scalable application framework on top of Backbone because I really liked Backbone.
[4:53] Marionette came out of my work on client projects and the abstractions that I was repeating on those projects and built that framework on top of Backbone to create scalability in Backbone applications.
Craig: [5:05] Definitely check out WatchMeCode.net. There’s some great…if you made a decision on Backbone after listening to all my podcasts or, however you’ve gone about your decision-making process, or you’re just trying to make that decision, there’s some great tutorials at WatchMeCode.net on Backbone that Derick’s done.
[5:27] Let’s get started. I would like to approach this more from take me back in time to when you were first working with Backbone, or your first big applications with Backbone and what your experience was like.
[5:41] I’m going to treat you like every other guest on the show at first. We’ll go through your Backbone experiences. Then we’ll segue into the framework stuff and go deep into what Marionette does and what was missing from Backbone when you were first working with it. Can you think of a project or two at a high level of functionality?
[6:01] Tell me about the first applications you built with Backbone and what they did.
Derick: [6:05] The very first project I used Backbone was a Ruby on Rails project. It was for a client, and there was one other contractor on the project. He brought me into the project. We were both writing a high level of interactivity in our pages using just plain jQuery. It was getting nightmarish in terms of the code quality.
Craig: [7:00] Tell me more about the mess. I think it’s a hard thing to describe on a podcast.
Derick: [7:04] It is!
Craig: [7:05] Until you experience it, you don’t really know it. Can you try to describe what happens to jQuery code? I had this experience where I was writing a lot of jQuery code. I actually thought it was good, until I realized it wasn’t. You know what I mean?
Derick: [7:23] I know exactly what you mean. That’s exactly what happened to us. The problems when you’re writing with just plain jQuery, and you look at simple jQuery tutorials, everybody just does nested callbacks all the time. “Select this element. Then add the click function callback. Then inside of there, you can manipulate more dom elements. Inside of the handlers for when animation is finished, you can add more handlers.”
[7:50] You just end up with this big giant nasty mess of selecting dom elements all over the place and manipulating dom elements within dom element manipulations. There is no real flow control or logic.
[8:04] Everything is a big giant jumbled mess of dom selectives, manipulations, nested callbacks, and throwing data all over the dom in order to have a place to find it and get it back out when you need it.
[8:20] Not having any real central organization for you data, for your logic, for the dom manipulation and for the application flow overall, it all gets crammed together into a big mess that over time becomes very difficult to maintain.
[8:37] I actually ended up in a situation where I could not complete the feature that I needed. I could not add new functionality. The structure that I had put in place was so terrible, it was almost literally impossible for me to understand the code. If I can’t understand the code, there’s no way I’m going to be able to change it and put in the features that I need.
Craig: [8:58] Thanks. I think that was a great description of the nested callbacks and the dom manipulation. Thinking about the fact that all those dom selectors are really…
[9:10] At that point you are just really talking to global variables when you are pulling things off the dom. Everything is global. When that occurred to me, that’s when I particularly got uncomfortable with what I was doing on that page.
[9:24] Do you remember which version of Backbone you started with and ended with? You probably worked with them all.
Derick: [9:31] I started with version 0.3. That was the first version that my co-worker brought back to us. That’s what was available at the time. I almost immediately fell in love with what I saw from the sample code that he produced. There’s a little secret here. I never actually chose Backbone. My co-worker chose Backbone on his own decisions with no input from me.
Craig: [10:21] That’s so funny. I think I’ve got an exclusive here, folks…
Derick: [laughs] [10:25]
Derick: [10:34] That is exactly what it was.
Craig: [10:35] That is [crosstalk] . I think we’re all in about the same boat there. Do you remember what the key things he saw in the framework that led him to it that you guys talked about later, or is that just like you said — it was his decision?
Derick: [10:51] The things that he liked and the things that I liked, other than seeing some of the same patterns from my C# days was the overall simplicity of it.
[11:02] It wasn’t a heavyweight framework. It wasn’t until a long time later that I started hearing Jeremy Ashkenas talk about it being a library, but that’s really what it is.
[11:14] The key distinction there being, a library is code that you call in order to get something done, and a framework is code that calls your code when the framework needs your code to get something done.
[11:29] That’s the distinction that I’ve kept in my mind after hearing Jeremy Ashkenas say something similar. I think that’s really what attracted both of us to Backbone when we first brought it in. We saw the ability to organize jQuery code without having to completely rebuild our knowledge base and start from the ground up with a large framework.
Craig: [11:50] What other dependencies did you have back in these projects? Were you using jQuery UI? Were you using third-party controls?
Derick: [12:00] None of that at the time. We were just writing plain jQuery on top of Ruby on Rails that was spitting out HTML.
Craig: [12:08] Talk about testing. How much testing did you do on these first projects and if so, how did you test with Backbone? What’s that experience like?
[13:19] Because at the time, we weren’t doing single-page apps. We were doing interactive pages. The one page that I worked on the most with Backbone was…it was a medical application and the person was entering drugs that they were currently taking.
[13:34] You had a form where you would input the name of the drug and how much you were taking and when, and you would hit Add and it would show up in the list down below right away. So a simple, interactive page where you just keep adding more drugs that you’re currently taking. When you were done, you hit Save and it sent it all back to the server.
[13:53] But that sending it back to the server was a complete page refresh at that point in time. It wasn’t a single-page app. So in doing acceptance testing with Cucumber, I didn’t have to worry about logging in to a single-page app. I didn’t have to worry about all those concerns that single-page apps bring up in testing.
[14:12] It was, go to this page, fill out these fields, click a button, wait for the response, check the response. So typical Cucumber-type testing.
Craig: [14:20] OK. Can we talk a little bit about a project you might have done later where it was more like a single-page application and your experiences with that?
Derick: [14:31] Sadly, the majority of the work that I did after that, my clients did not want me to spend time writing acceptance tests and unit tests for my code. They spent a lot of time manually testing the applications. Every time we would deliver — me and whoever the team I was working with — we would deliver features and they would have their set of testers that would run through the process.
[14:57] Of course, we as developers were continuously running the application to make sure things worked. But it was never as efficient and well-oiled as that first project, where we actually did have test automation on the application level.
Craig: [15:11] How did it go during development? Were there any surprises when you started using really the framework in production? You talked about your process for choosing and what your initial impressions were, but what did you like the most about using Backbone JS, for example?
Derick: [15:32] What I liked the most initially was the Backbone view. That, to this day, is where I tend to start people out. Most people are already writing jQuery, and the Backbone view, the whole focus of the Backbone view is organizing the DOM manipulation jQuery code.
[15:56] It gives you an easy way to structure all of your DOM events into the events hash in the Backbone view, and then you write separate methods to actually handle those events.
[16:08] It helped me organize all of my previously mashed-together events for all of my DOM elements and it helped me put a structure in place for those. The thing that surprised me the most was the Backbone model. I didn’t really think it was a bad idea to store data in the DOM at the time. I just used data attributes and put data in those, because that’s what they’re for, right?
[16:35] It wasn’t until probably the second or third iteration on this drug entry screen that I realized I was doing far more work than was necessary to get data in and out of the DOM, especially when it came to formatting things.
[16:51] I had a whole lot of “Format it and put it in the DOM. Take it out of the DOM and strip out the formatting. Because I was reading the formatted data out of the DOM in order to get the data I needed in the Backbone view.
Craig: [17:31] Gives us a good feeling. What did you find confusing or problematic when you were first working with Backbone JS?
Derick: [17:38] Understanding that I was working in a stateful application. Because your typical web development process is page request to the server, server stands up stuff, processes it, sends a response back, server shuts down. Then it just repeats that cycle over and over and over again. It’s stateless development.
[18:06] Even in that, it’s still stateless, because the server has to read that cookie or read the URL parameters in order to recreate the state that the user was previously in, to process the new thing that they want. Getting from a stateless process to a stateful process, where I create an object and it lives in memory for as long as that page is alive.
[18:30] Having the ability to set something in an object, set something in a variable, an attribute, whatever it is, and have that thing always available to me without having to recreate it constantly, that was challenging at first. I was so used to working in a web environment, which was stateless.
Craig: [19:04] Right. One paradigm that I think about a lot is, you go back to anyone who’s done classic rich client applications of any kind, whether it be Flex or Silverlight or back to Windows Forms applications, where you don’t have to worry about state during it.
[20:07] Those are memory leaks, or just memory that you’re consuming and not releasing. If you’re seeing a browser application that’s taking up a ton of memory, it’s that application’s fault. It’s not the browser’s fault, these days.
Craig: [20:22] That’s one of the great features with Marionette, right? The ability to clean up the dom for you, to make you fall in the pit of success with that.
Derick: [20:33] Right.
Craig: [20:33] Can you describe that, and maybe talk about how you first discovered that pit, to want to write that part of Marionette?
Derick: [20:41] The first time I was even made aware of that, I had been writing Backbone for, I don’t know, six months at this point. There was a book written by Thought Bot. They wrote a book on Backbone.
Craig: [inaudible 21:12] [21:12] collective, right?
Derick: [21:14] Yeah, exactly. I thought about it for days or weeks or however long it was, and then I started wondering how much memory were my applications using? I started looking at the system monitor on my computer, and watching the browser memory constantly increasing and increasing and never going down.
[21:39] Then, on top of that, I started running into problems where I would have multiple instances of a Backbone view and I would trigger an event somewhere in the app, and I would get multiple responses to that event.
[21:57] I had zombie views, which is what I like to call views that I thought were closed and long dead, and then when some event triggers off somewhere else in the application that’s supposed to work with the current instance of that view, I get every previous instance of that view reaching out from the grave and grabbing me and having multiple things running. It really bogged down my applications and caused all kinds of problems.
Craig: [22:27] I totally get what you’re saying about having the zombie views. What might be helpful to our listeners is to know, what’s a common scenario where you get yourself into the point where you’ve orphaned a view, basically?
Derick: [22:41] Event handlers. That is the number one cause of zombies.
Craig: [22:46] What does the UI look like that you’re building that you wire up that event handler and get into a bad situation?
Craig: [23:23] A change event on the property?
Derick: [23:25] Right, a change event on the property. That model now has a direct reference to the view instance. That event handler is wired so that, when the event fires, the model, holding the reference to the view, calls the method on the view that you specified as the event handler.
[23:46] It’s typically an in-line callback, which is where you get closures and all that kind of stuff. It’s really the model holding a reference to the view, so that it can reference the event handler function that causes the memory leak there.
[24:01] If you close down that view and you keep that model alive, but you do not clean out the event handler from the view, that’s an instant memory leak right there. That’s a zombie view definition right there. The next time that model triggers that same event, it’s going to have all the references to all the previous view instances, and it’s going to call that callback function on those views. You thought they were dead.
Craig: [24:30] The solution, my understanding is, is to clean up those event handlers in the view.
Derick: [24:35] Yes.
Craig: [24:36] What is Backbone’s solution to that?
Derick: [24:39] Backbone’s solution, I’m happy to say, is the solution that I and a couple of other Backbone developers popularized. It’s the idea of inverting the relationship between the event triggerer and the event handler. In Backbone, zero-nine and later, you not only have an “object.on” to add in event handler, but you have an “object.listen to,” which is the inversion of the relationship.
[25:07] Quite honestly, there’s a lot of detail to the idea of inverting the relationship that I don’t remember offhand, but I do have a blog post about this on my DerickBailey.lostechies.com blog.
[25:20] If you look for “Managing Events As Relationships.” Just Google “Derick Bailey Managing Events As Relationships.” You’ll come up with this blog post which walks through a very detailed description with examples of how these relationships are formed, how they’re managed by Backbone’s objects, and when and why you would want to use “listen to” versus “on.”
Craig: [25:44] OK. Thanks. That’s really helpful. Let’s move deeper into Marionette. What other problems were you seeing in your day to day Backbone? I don’t want to say problems, but what was missing that you wanted to fill in the gap on, that was most glaring?
[26:03] I know there are tons of features in Marionette. If you’d boil it down to what the most useful or popular things are in there, what would you talk about?
Derick: [26:13] Marionette started out with me recognizing that Backbone requires a lot of boiler plate code. Anybody that’s been working with Backbone for more than a few weeks and has built anything more than trivial to do list applications will understand that you’re copying and pasting a lot of code from one view to another, from one model to another, from one whatever to another, in order to get the same behaviors.
[26:39] Those are the behaviors that your application needs in every view. It’s the common things. It’s the things that are the same for your view instances in your application.
[26:51] I found, through building a lot of different client applications, that I was writing the same code over and over and over again. I wanted to find a way to create reusable abstractions that I could just call whenever I needed them, instead of having to copy and paste the code all the time.
[27:10] That was really the birth of Marionette, recognizing the copy and paste code and the boiler plate code that I was putting into my client applications.
[27:20] Every time I found that I was doing something over and over again, I would look at Marionette and see, is this something that Marionette could benefit from for the rest of the Backbone community, or is this really specific to this application? It’s something that I can abstract for this application for this client.
Craig: [27:39] I would say to our listeners, if you go with Backbone and after you’ve written that template code, that common pattern code, repeating that code, you will quickly see this. It doesn’t take long to see this repeated code.
[27:55] I remember the first time I looked in Marionette, when I was looking at it, I read the description, and I was like, “I hope that he eliminated all that code.” When I saw it, I almost jumped out of my chair. I was like, “Thank you! I don’t have to do this myself!” It was exactly what I needed.
[28:16] If you don’t use Marionette, if you don’t use all the modularity features, if you don’t use everything in it, that’s worth the price of admission alone. Just do that. Of course, the memory leak stuff, as we discussed previously, is really helpful.
Derick: [28:31] I was really happy to see Backbone include that memory management stuff. I got to delete 300 lines of code from Marionette.
Craig: [28:40] Elaborate on that. We’ve missed that.
Derick: [28:42] With Backbone zero-nine and the listen to method, that was the crux of my memory management, the listen to method. I called it an event manager at the time. It was essentially the same thing, functionally the same thing as the Backbone “listen to” and “stop listening” methods. I don’t remember what I called them at this point, because that was more than a year ago that I got to delete them.
[29:10] Once Backbone introduced those “listen to” and “stop listening” methods, that created the same functionality that I had built into my event manager. I got to get rid of the event manager from Marionette, because all of it was already built into Backbone. That was a very happy day for me.
Craig: [29:30] Just to be clear, even though that functionality is in Backbone, there’s still some automatic calling functionality that happens with Marionette that doesn’t happen with Backbone, correct?
Derick: [29:42] Yes. Even some of that is getting into Backbone these days. The second thing that I did for memory management was, Marionette provides a lot of view types. Item views, collection views, layouts.
[29:53] Every one of those view types has a closed method on it. I called it “closed,” and the closed method manages unbinding the event handlers, and doing a few other things to make sure you’re cleaning up your memory and your references.
[30:06] Along with Backbone zero-nine something or other, or version one, I can’t remember which, they added a “remove method” on their views. The remove method handles cleaning up all of the event references the same way that my closed method did.
[30:23] I haven’t yet taken out the closed method on Marionette’s views, because I do a few extra things in there still, specific to Marionette. Marionette has a few objects, like the Marionette region, that understand Marionette views versus Backbone views, and will appropriately call Marionette’s closed method or Backbone’s removed method, depending on the type of view that you pass into it.
[30:55] I’m super happy, again, that Backbone took some of those patterns that the rest of the community… because it wasn’t just me. There are certainly other people involved in this as well, or more so, in convincing the Backbone developers that it was necessary in Backbone. I was hands off about all of that. I was like, “All right. Whatever. I’ll just do Marionette.”
[31:15] There was a lot of good community effort in getting the “listen to” and “stop listening” methods, and then getting the “remove” method built into Backbone view as well. Every time Backbone assumes some of that responsibility, that’s more code that I get to delete from Marionette.
Craig: [31:32] Right. That’s great. You mentioned it was a rails application?
Derick: [31:38] Right.
Craig: [31:39] Did you have a clean slate where you could create a nice, restful API there, or did you have to override sync in your Backbone applications? It doesn’t have to be the first one we talked about.
Derick: [31:54] With that first app, we got pretty lucky in that we could just build an API. We didn’t have an API at the time, so we built one on top of that rails app. Backbone’s default sync matches really well to rails opinions of a restful API anyway. There wasn’t a lot of effort in getting that done.
[32:13] In other applications, like I built the first version of the front end for RavenHQ.com, which, they host online versions of RavenDB, which is a dot net based document database.
[32:27] In that system, we used the beta versions of the Microsoft Web API. It was a CQRS system — command query responsibility separation, or CQRS, on the back end, which was not a restful interface. It was not a resource oriented interface. It was a command based interface.
[32:55] Instead of using Backbone.sync all the time and the typical save method on the Backbone model, I wrote a very simple, very thin command wrapper around jQuery’s ajax method. I could have a command object, and then I would execute the command, and it would make the ajax call back to the server to the appropriate end point on the server.
[33:18] From that point forward — that was around two and a half years ago — that was one of the first applications I did where I got away from Backbone.sync. I use Backbone.sync probably 20 percent of the time when I build Backbone apps, but I typically do more command-oriented APIs at this point. It fits the way I think a little better than restful APIs do.
Craig: [33:46] OK. That’s really helpful information. Was it hard to override sync, or is it pretty straightforward?
Derick: [33:52] I didn’t override it at all, I just ignored it.
Craig: [33:54] You just ignored it?
Derick: [33:55] Yeah. That was really the easiest option.
Craig: [33:59] Excuse my level of knowledge here, but when you call save, does it automatically…?
Derick: [34:04] I didn’t call save. I had my own data access optics. I would say, “OK, my model is ready to be saved,” I would call service.save and patch the model into that web.
Craig: [34:15] The service or repository that you just passed the model into.
Derick: [34:18] Exactly.
Craig: [34:19] Which is a very common pattern in itself. Makes sense. I think we’re wrapping up here. In Marionette, there’s a ton of features, from what I’ve seen, but what’s the dark horse, or your personal favorite feature that people don’t really appreciate, but should, or utilize as much? How about that?
Derick: [34:40] That would be the Marionette.controller, which is the absolute worst name for an object ever, because there are 5,000 different definitions for “controller,” and Marionette fits my idea of an old school small talk controller, or a component based, component level controller.
[35:02] There are far too many things that it does, far too many things that it can do. It’s such a simple object. I probably should’ve called it Marionette.object, quite honestly.
Craig: [laughs] [35:15]
Derick: [35:16] The thing that I love about the Marionette controller is its simplicity. All it really does is bring the patterns from Backbone’s models and views and other objects into an object that doesn’t have a specific focus. It gives you the ability to call an extend method. It gives you the ability to add an initialized method. It gives you a closed method. It gives you the automatic memory management.
[35:45] It gives you all these things that Backbone model and Backbone view and Backbone router all have built into them, but it does it in an object that is not specifically focused on a certain area of functionality. I use that as my basis to create modules and to create controllers for larger components, or even smaller components.
[36:08] I use those individual components with that controller object that has the API in order to compose my applications out of smaller, individual pieces, which is really where the idea of a composite application framework is heading. Things like AngularJS with web components. That really is the future of web development, in my opinion. I was heading in that same direction with Marionette.
[36:33] I actually got to do real, solid component driven development in the last client project that I did before I joined Telerik. That code never made it into Marionette in an abstraction, but I proved the idea of Marionette’s controller object in that code, and really showed the value that it could provide.
Craig: [36:54] You mentioned you’re now a Telerik developer advocate, right?
Derick: [37:00] Yup.
Craig: [37:00] I know we’ve got to wrap up here soon, but I think it’d be worth talking about Kendo UI, because it crosses the commercial version of some of this stuff. I heard someone today say it’s just another jQuery UI, it’s just widgets. From my brief conversations with you and what I’ve looked at, it’s more than that, right?
Derick: [37:25] It’s very much more than that. It does have that. If you’re looking at jQuery UI, it has a jQuery UI pattern. That’s our Kendo UI web controls. We provide grids and drop down lists and previews and all the same kinds of things that jQuery UI does, but we also have a data visualization suite, which uses SVG and Canvas and even VML for older IE browsers, in order to render charts and graphs and things.
[38:17] We have some additional single page app components, that being a view, a layout, and a router that allow you to take interactive pages built with our MVVM stuff — well, primarily built with our MVVM stuff — and add single page app features. You can have a router that responds to hash changes in the URL. You’ll be able to update the URL based on calling methods on the router.
[38:47] There’s actually a lot of influence in the view, layout, and router. There’s a lot of influence in Kendo UI’s components from Backbone. You’ll see a mix of KnockoutJS and BackboneJS and, of course, our own flavoring of the ideas that come from above those.
Craig: [39:06] You mentioning the view there, just going back to Backbone, that was one of the things I found most confusing when I started working with Backbone. View object.
Derick: [39:15] It doesn’t fit into MVC or MVVM or anything like that. It really is its own beast. I think it’s a mistake when people try to call it some specific letter from any of the MV Star systems out there.
Craig: [39:29] Right. Just for the listeners, it’s not a template. It’s not markup. It controls your markup, but…
Derick: [39:37] It’s not a controller, either. It does view manipulation.
Craig: [39:41] I sometimes like to think of it as a controller, but you’re saying no?
Derick: [39:47] Yeah, it’s not your currently known controller, like with ASP.NET MVC or Ruby on Rails controllers.
Craig: [39:57] Right. The server side.
Derick: [39:58] Right. It’s not that kind of controller. I tend to think of it, in the model of the presenter pattern, as the presenter. It’s the thing that coordinates between the actual view of the HTML and the DOM, and then the back-end services, the models and the other services that you have in place.
Craig: [40:16] For you dot net developers out there, it’s the code behind the file.
Derick: [40:19] Yeah. Exactly.
Craig: [40:22] Just to wrap up, I keep saying it’s going to be the last question, but I’ll ask you one more. You’re building an app today, Greenfield. Would you use Backbone with Marionette, or would you choose to try Angular? Would you use Emperor? Would you use Kendo UI? I know that probably depends.
Derick: [40:46] Yeah, “it depends” is always a good answer.
Craig: [40:48] I’m curious, how would you rectify that in your mind?
Derick: [40:51] If I were standing up something that I needed to get done fast and I need to be comfortable quickly, of course it would be Backbone and Marionette. I don’t use Backbone without Marionette anymore. There are so many things that I’ve built into it for the way that I think. It doesn’t really make sense for me to not use Marionette.
[41:11] I, honestly, don’t think Marionette and Backbone are right for everyone, though. Everybody has a different way that they think, a different way that they view the world of development, and different patterns that they do and don’t like. I don’t think there’s going to be a clear winner in the competition for single page app frameworks. It’s going to come down to which one best fits you and your team and your needs.
[41:36] If I were going to recommend something to people, sure, I would recommend looking at Backbone, but I would also recommend looking at at least Angular and probably Knockout or Kendo UI to get three different perspectives on different types of MV Star frameworks for the web.
Craig: [41:54] OK. Fair answer, definitely. I also think, one thing for the listeners, Backbone definitely has a shorter learning curve than some other things. It feels like a smaller leap. If you’re real hesitant, your jQuery code is becoming a mess and you’re hesitant to bring a framework in, that’s a smaller step to go to the Backbone and just see if you like the way it feels.
Derick: [42:19] Yeah. Shameless self plug here, if you’re interested in learning how to clean up your jQuery code with Backbone, but you know you’re not going to be doing a full single page app, check out an article I wrote for “CODE Magazine” in the last couple of months. It’s all about building Backbone apps from the perspective of “I’m just trying to organize my jQuery code.” That’s at Code-Magazine.com.
Craig: [42:46] Thanks for being a guest. This is really informative for the listeners out there. I appreciate having you on.
Derick: [42:54] Thanks for having me.
Craig: [42:55] Take care.
Craig: [43:08] Thanks for listening to the Front-End Developer podcast. Please subscribe to the podcast by going to the iTunes Store on your phone or desktop and searching for “Front End,” or via RSS by going to http://www.funnyant.com/feed/podcast/, where you’ll also find show notes and a full transcript of each episode. We’ll see you next time.