056

056 JSJ Marionette.js with Derick Bailey


Use this link and code JAVAJAB to get 20% off your registration for FluentConf 2013!

Panel

Discussion

01:03 – Derick Bailey Introduction

02:11 – Marionette.js

06:57 – How backbone.js helps with large-scale applications

  • Scalability

08:42 – High-level application architecture path with Marionette.js

13:02 – Breaking down Marionette.js

16:02 – The value of using Marionette.js

  • Tree views
  • Table rendering

18:23 – Application Structure

20:17 – backbone.wreqr

26:20 – Memory Management

  • Single-page applications
  • Simplicity & maintainability

34:23 – Routing

41:40 – Compatibility Issues

48:57 – Layouts, region managers, and regions

Picks

Next Week

Functional Programming with Zach Kessin

This episode is sponsored by

comments powered by Disqus

TRANSCRIPT

MERRICK:  Tim, is there anything that you don’t follow up with, “I actually wrote that a few years ago?” [Laughter] TIM:  Yeah. AJ:  I was wondering the same thing. [Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.] [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.] CHUCKHey everybody, and welcome to Episode 56 of the JavaScript Jabber Show. This week on our panel, we have AJ O’Neal. AJ:  Yep, I’m here. CHUCK:  Tim Caswell. TIM:  Howdy? CHUCK:  Joe Eames. JOE:  Hey, everybody. CHUCK:  Merrick Christensen. MERRICK:  What’s up? CHUCK:  And we have a special guest, Derick Bailey. DERICK:  Hey, how’s it going? CHUCK:  I guess, I should say I’m on here too. I’m Charles Max Wood from Devchat.tv. Derick, do you want to introduce your self really quickly? DERICK:  Sure. Derick Bailey, obviously. I work for Kendo UI at the moment. We build HTML 5 and JavaScript controls for the web and global and all kinds of fun stuff. I’ve been working in JavaScript off and on for, let’s see, it was released in ’94. So, about 19 years, I guess. I got into it right when it was first out in Netscape 2.0 and it was a love/hate relationship for a long, long time until I finally found that I really do love it in the last couple of years and started working with it full time. I’m just enjoying the heck out of it at the moment with all of this server side stuff we can do in Node.js and all the big apps we can build with Backbone and Ember and Angular and everything else. CHUCK:  Nice. JOE:  That was a lot of enthusiasm, I liked it. MERRICK:  Yeah. CHUCK:  Yeah. It’s like JavaScript’s cool again or something. DERICK:  Yeah, it’s crazy. Everything old is new again. MERRICK:  Why can’t I be that happy? [Laughter] TIM:  You’re just doing it wrong, that’s all. DERICK:  It’s a choice you make. You just have to do it. JOE:  Bingo! MERRICK:  Cool. So, you want to talk a little bit about Marionette.js, Derick? DERICK:  Yeah. For those that are listening, if you’re not familiar with Marionette, head out to Marionette.js.com. That’s the home page for it. So a couple of years ago, I started working, a year and a half, not quite two years ago, I started working with Backbone a lot in my applications because my co-worker and I wanted to stop sucking at JavaScript and stop writing horrible jQuery soup and all that stuff. So, he spent the week evaluating different things and he came back with, “Hey, let’s use Backbone.” And I almost immediately fell in love with Backbone because I saw the potential for all of these patterns and practices that I’d been using in WinForms and C# development for a number of years. I was like, “Hey this is awesome! I can actually do this stuff in JavaScript and have a model and a view and have what I consider a presenter in the mix in there and do all this amazing work with good structure in my JavaScript.” And so, I really started digging into it. And after a couple of weeks, I started seeing a lot of repetition and a lot of boilerplate code inside of my Backbone apps. And it started getting pretty frustrating having to copy and paste all of this code over and over and over between all of my different Backbone views especially. I started extracting that and I went through a number of different experiments and different ideas. Eventually, when I moved on from that client to the next client, I finally got to the point where I knew enough about Backbone to create a good abstraction on top of Backbone view and provide a default rendering mechanism. Then from there, I saw the need for, “Okay, I’ve got these view abstractions created now but I also need a way to manage what content is in the screen in a given element.” So, placing a Backbone view into the DOM, basically. And so, Marionette’s idea of a region was born from there which is heavily influenced by my WinForms development work again with the Microsoft Prism Framework and all of the composite application stuff that I was doing ten years ago, six or eight years ago, I guess. And so, from there, it just started getting larger and larger and larger as I saw more and more patterns emerging in the applications I was writing. So, Marionette was really born out of my own needs, and my own frustrations, and my own desire to have an easier way to build scalable and large-scale JavaScript applications with Backbone. I think that’s one of the real benefits that a lot of people have mentioned when they’re talking to me about what they do and don’t like about Marionette is they see the value almost immediately because they know it’s been extracted from the same problems that they’re running into. CHUCK:  Yeah. I wanted to get in and just say that it looks like it solved some of the issues that I was having and those specifically with the views, just keeping track of everything that’s going on the screen and I’ve got six or seven different things going on. Or if I have a collection and I’ve rendered views for each object in the collection, or each model in the collection, then I’ve got a whole bunch of views that I have to keep track of. And sometimes, I get the binding just slightly wrong and then it’s a mess and I have to figure out, “Okay, how do I work around it?” Or, “What did I do wrong?” It looks like this solves a lot of those issues for you. DERICK:  Yeah, it really does. That’s kind of one of the big goals of Marionette is automating the clean up and the handling of a lot of that stuff because one of the biggest problems people have with Backbone views and models when you combine them with the events is you often end up with these Zombie Views hanging out in the background. You think they’re dead and then you go to do something else with that model and suddenly that view is popping its head up out of the grave and tearing your face off and doing all kinds of horrible things to your application. [Laughter] DERICK:  So Marionette really tries to solve that and it does that through a number of different things. And actually with Backbone 0.99 and higher, a lot of the code that I had originally written into Marionette to handle that was moved into Backbone with the ‘listenTo’ and ‘stopListening’ methods. So, I was really, really happy when Backbone 0.99 came out, I got to get rid of like 150/200 lines of code. AJ:  Yeah. Can you talk about how Backbone helps with large-scale applications? Some say when Backbone apps starts to get large, they start to break down, they don’t get much better than jQuery soup when you have views just grabbing and creating elements, and not knowing which entry points are coming into which views, et cetera. Can you talk about what Marionette does to ease that pain? DERICK:  Yeah. So, like I said, when you start getting Backbone beyond a certain point, it does start turning into its own form of soup and mess. That’s not to say that Backbone is a problem or has problem, it’s just showing the limitations of what Backbone provides. It’s not a full framework. It’s just an MVC/MVP/MV* frontend view framework with models in the mix as well. It doesn’t really address the scalability and application infrastructure problems that we have with JavaScript. Let me stop there for a second and address the word ‘scalability’ because a question I’ve heard a lot recently is, what do I mean by scalability in JavaScript? Isn’t it just a single user running in a browser? And yeah, that’s true. So, what I mean by scalability in this case is not the number of users running the code at any given time. It’s the number of features in the system, how those features interact, and how you can start up and shut down and do all these things with these different features so that your application can grow in size, grow in features, and grow in capabilities. So, those are some of the problems that Marionette tries to address. AJ:  What in particular? I mean, I know there’s a Marionette application. I know you can register modules into that application. How do you kind of picture high level application architecture with Marionette? Because you offer a bunch of tools that you can kind of pick and choose, but what would you say is sort of the happy path or the blessed Marionette path is for writing a scalable app? DERICK:  There’s a couple of different opinions on that and the differences in the opinions are very subtle. At a high level, the happy path for Marionette’s application growth pattern or path is a very top down organization. If you look at the Marionette application object, it is the entry point to the system that you’re building, the JavaScript system really which is composed of multiple smaller applications. So, that’s where you start. That’s how you get the whole system up and running. It provides initializers so that you can initialize all of the different sub-applications or modules throughout the rest of your system as needed. AJ:  Just real quick, when you say smaller applications, are you talking about more Marionette.application objects or Marionette.module objects? DERICK:  Marionette.module. And this is a point of contention with my self. I named things very poorly early on and I never corrected them. So, that’s something that I want to fix in Marionette Version 2 is to get things named properly. So, when I say sub-application or smaller application, I’m really talking about, from a syntax perspective, Marionette.module. Alright, where was I going before that question? AJ:  You were going on about how the — I’m sorry. I didn’t mean to cut you off, about how the application is top down. You have an entry point which is the application, and then smaller Marionette modules. DERICK:  Right. So, in terms of sub-applications or smaller applications within the Marionette application or system as a whole, think about Gmail, that’s the canonical example that I keep using. In Gmail, you have a number of different applications, you have the mail application, and you have the contact application, and you have the task application. And you can switch between any of these three applications using that little dropdown at the top of the Gmail screen. When you first load it up, Gmail though, you don’t get all three of those applications running all at once. It starts up with Gmail, the mail application, and when you switch to the contacts or the task list, it loads up that application and starts it at that point. I don’t know if it shuts down the mail application or not, but that would be potentially one way to save on memory usage, resource usage, and everything else involved in having such a large complex application up and running in your browser. So, Marionette provides the same kind of features and capabilities through its module system right now. And the module system is really comprised of three separate things, honestly. It’s name spacing, it’s encapsulation through closures and the JavaScript module pattern without being AMD modules. And it’s also the idea of being able to start and stop individual pieces of an application or a sub-application as I like to call it. So, there’s those three things that modules really encapsulate. I’ve built a sample app that honestly I’m not super happy with the implementation, but it does illustrate the points that I’m trying to make. And the sample app is called BBCloneMail. If you search for that, BBCloneMail, just like it sounds, you’ll come up with it from Google pretty quickly. And if you look at the code and the way it works, I have a mail application and a contact application and a little drop down list on the top left, just like Gmail does. And when you switch between the contact list and the mail application, it does start and stop each of those sub-applications within the overall system. AJ:  Very cool, very cool. CHUCK:  So, I have a question really quickly. It seems like Backbone.js, it really is kind of a simple way of organizing your code. And a lot of people kind of embrace that philosophy where, ‘It’s just what you need, no more no less’. Do you feel like Marionette might be going a little bit far in providing some of this stuff? Yeah, I’m just wondering if you feel like it’s in keeping with the way that people approach or think about Backbone itself. DERICK:  I’m teetering on that line and it crosses the line in a few places but I like to think that I’m sticking to that core Backbone philosophy. At the very least, even if you do have to bring in all of these different pieces that Marionette provides right now, you don’t have to use all of them. You can pick and choose, “Okay, I just want to use the Item View because it solves my immediate need. And over here, I just wanted to use the Collection View because it solves my immediate need, and I’m done, that’s it. That’s all I need from Marionette.” You don’t have to buy-in all or nothing with Marionette. And that’s actually something, again, that I wanted fixed in the next version. I really want to separate the infrastructure, the application, and the modules, and everything else away from the view implementations that we have because most people find the immediate value with the views and then, “Oh! By the way, you have to drag along all of this other stuff. So maybe, we should think about using it but I don’t know.” And if we separate out the views from the application infrastructure, I think a lot more people will get a lot more benefit immediately but still have the ability to bring in all of it when they want all of it. AJ:  Yeah. It’s hard to know right now what the application infrastructure versus what reusable little library pieces there are. DERICK:  So, if you look at the Marionette.js Organization on Github, we’ve already started down that path of extracting reusable pieces. So, there’s backbone.babysitter and backbone.wreqr as examples. So, backbone.babysitter is a way to manage a collection of Backbone views. And Marionette makes heavy use of Babysitter for its Collection view and Composite view, and other things. But the actual Babysitter library was extracted out of Marionette so that other people can use it. And I do know at least a handful of people that are using Babysitter specifically in their Backbone apps without using Marionette. So, we really want to go down that path further with a lot of the other things that we’re building. I think Ember.js takes this approach a lot. They build a lot of really useful utilities as libraries on their own and then Ember brings it all together into something much more powerful and meaningful. TIM:  So, the first time I heard about Marionette, I was trying to build the app that I’m always trying to build, an IDE in the browser. DERICK:  Awesome. TIM:  And I wanted to use Backbone because I worked on Backbone years ago for like a week and thought it was cool. So, I needed a Tree view, and I was asking around the forums and they were like, “Go use Marionette’s composite thing.” Because in a TreeView, you have nodes that are inside nodes, that are inside nodes, and they’re nested and that doesn’t really work well with Backbone out of the box. I couldn’t figure out how to do it. So, you’re saying that the main value is in the application structure? Or is there a lot of value in the things like the composite library as well? DERICK:  There is a tremendous amount of value all over Marionette, I think personally. I’m kind of biased, of course. But I think there is a lot of value in the application structure and equally as much value in just the view abstractions. So, your tree view for example, Marionette’s composite view is exactly directly suited for that. I built it specifically to handle tree views and other similar situations that don’t necessarily have grandchildren but at least lists of things that are wrapped in templates. So, the Composite view, by default — let me back up a second. The reason I called it a Composite view is not because it allows you to compose your views, but because it follows the Composite design pattern which is all about leaves and nodes in a tree. So, it by default is a nested hierarchy of itself. Whenever you define a Composite view in your application, by default, it will render a list of itself for every item that it comes across in your collection. TIM:  Okay. So, it’s basically a TreeView type thing. DERICK:  Yeah, exactly. You can use it for a lot more than just tree views though. I use it to render tables all the time, because what it does is it allows you to render a template around a collection. So, the regular Collection view in Marionette just allows you to render a collection of Item views. And each Item view, of course, has its own template. But the Collection view itself does not have a template to render. The Composite view, on the other hand, does allow you to render a template around your list of items. TIM:  Very nice. The other place I always get stuck with building apps is, suppose I’m making a game. One of the games I started was Lords of Conquest port. And you’ve got your main game where you have the board but then you have these modes where you’re changing the settings, or you’re taking turns. I guess, that’s where the application structure would come in handy, where you have these different modes? DERICK:  Well, what do you mean by mode in this case? TIM:  They’re like full screen dialogues or mobile dialogues, where the app interface changes. For example, the generic one in a game is you’re at the title menu, and then, you’re in the game and then you’re at the options menu. In games, these tend to be full screen. DERICK:  Yeah. TIM:  Like if you wanted to implement that using Marionette, would it be a good fit using, what were they called, sub-modules or something? DERICK:  Yeah. Okay, I see where you’re coming from now. Right and I think the answer is yes. Let’s say we are building a game, like you just said, and we have the title screen and then we have the actual game play and then we have the options menu. Each one of those things is a discreet area of functionality. It may change the way the other parts work, like the options screen is going to change how the actual game plays and whatever the options are. But the process of setting up those options and the view structure, and the validation and the inputs and everything else is going to be functionally separate from the actual game play. It’s just going to modify some data that the game engine uses. So, I definitely would say that the game play and the options screen or editing process and the title screen, and other areas of the system like that are going to be separate Marionette modules but I would call those sub-applications in a more generic term. TIM:  Cool. MERRICK:  I know you talked about Babysitter a little bit as something that managed child views. Do you want to talk about backbone.wreqr for a little bit and how it is another dependency? DERICK:  Sure. So, wreqr came from a lot of different patterns that I was building in my large-scale distributed WinForms applications. I was building a system that had to work offline as well as online in a Windows environment. This was a maintenance system where people were taking portable computers, rugged computers out into the middle of nowhere, looking at the vehicle that was logging all of the damage into the system, and then taking that system back to the maintenance bay. Once the system was back in the maintenance bay, the system would reconnect to the network automatically and upload all of the data to the maintenance bay so that the people could have everything ready when they finally got the vehicle back to the maintenance bay. And so the way we did all of that, remember this is C# WinForms, about six or seven years ago now, but the way we did all of that was through Enterprise Integration Patterns and a message bus, and an enterprise service bus, using web [inaudible] at the time. And so, I learned all of these amazing patterns for communication across these message buses, and how to break up messages into appropriately sized chunks, and what the different types of messages were and all of these different patterns for working across an enterprise service bus like that. And so, when I started getting into the larger application design with Backbone and Marionette, I saw the same kinds of needs playing out. I didn’t have a strict message bus necessarily, but I had the same needs in terms of capabilities of communicating across different applications. Sometimes, the applications are running at the same time, sometimes they aren’t. You have the mailbox with your list of mailboxes on the left, and then you have the actual inbox with a list of Email on the right and your canonical mail applications. Well, those might be individual modules within the mail application. So, how do we make those things communicate? Well, we can either have the modules directly coupled to each other, which is a really bad idea because you end up with another giant spaghetti nest, or we can have a giant communication layer in between them, and that’s where backbone.wreqr comes into play. It takes a lot of the enterprise integration patterns that I had learned and used in Windows for so long, and it brings them into a really simple, in-memory, object-based implementation for Backbone applications. It provides an event aggregator which allows you to decouple the event source from the event handlers. It provides a command pattern which allows you to say, “Go do something,” and don’t care whether or not it actually happens. You don’t care if there’s even something there to handle the command to go do it. If you register a command handler and configure that command later, then the command handler will pick up the command at that point in time. It also provides a request response system which does require an immediate handling of the request. So, you say, “Give me something,” or, “Go get something for me.” And some other module somewhere else will respond with whatever you requested. MERRICK:  Very cool. So, it seems like there’s some of that application communication stuff built into the application object, the module object? When would you use something like the wreqr stuff versus the other stuff that Marionette offers? DERICK:  So, everything that is built into the application object comes from wreqr. MERRICK:  Oh, great. DERICK:  Wreqr is imported into Marionette and the Marionette application just provides a default instance of the event aggregator, the command handlers, and the request response process. But wreqr itself can be used entirely independently of Marionette. You can use it in any Backbone application that you want and you can also create your own instances of a command infrastructure or a request response infrastructure. I typically do that when I get down to the sub-applications. So, the way that I look at this, and one of my friends, a guy named Brian Mann out in Atlanta, he has some really good diagrams and screen casts on setting up structures like this. But the way that I approach this, in the top-down organization of code is when I have my application at the very top and then the mail application and the contact application, and the task application at the next level down, I typically create instances of my commands and my request response and my event aggregator at each one of those sub-applications. And then, within those sub-applications, the various pieces of my mail application that need to talk to each other, they will go through the mail applications commands and the mail applications request response instead of reaching all the way back out to the application. The reason I do that is just to keep the messages within the individual application. So, there’s no chance that my mail application is accidentally going to go tell my contact application to do something. It just localizes and encapsulates everything within those individual sub-apps. MERRICK:  That’s awesome. That kind of resolves the global event bus being really just global event’s problem. DERICK:  Exactly. MERRICK:  [Chuckles] Very cool. CHUCK:  So, I have a couple of questions here. I’ve been looking over the Marionette.js page and I’m really excited to actually play with this. I didn’t have that much time because my wife’s been sick the last few days and I’ve been chasing kids. But one thing that I want to get into here is, you talked about the memory management and how it kind of kills Zombie Views and stuff. And I guess the question I have is that we do have some memory limitations depending on the browser and things like that. I remember when I was working for a company out here that did online back up. When they were displaying the list of files that you could restore on the web page, if some people had backed up millions and millions and millions of files, which meant that they were trying to load millions and millions and millions of objects into memory and eventually, as they tried to add those to the DOM, it would just hang because it didn’t have enough memory to manage all of that stuff. So, would Marionette help with that kind of thing as well as its memory management stuff? DERICK:  No. CHUCK:  Or are there some tricks you kind of have to pay in order to make it do that? DERICK:  Yeah. Those are tricks that you have to step out of the JavaScript world to solve. You really don’t want to load up that much data into your browser, period. Whether or not you’re doing it in a JavaScript app or just rendering it all on the server as plain HTML and sending it down. That’s almost a guaranteed way to kill a browser just loading up that much data. So, what you want to do in those cases is create something more like an infinite scroll pattern where you just keep scrolling down and it keeps loading data from the server. Or a paging system where you’re doing server side paging. And when you click on the next page, it loads up the next set of data from the server. But the key here is keep loading data from the server as more data is requested; otherwise, you are going to kill the browser. The Marionette can handle a large number of items. I’ve rendered 15,000 items in Marionette before on a modern browser, on a modern machine and it handles it just fine. Now, if you’re talking about mobile devices, of course, you’ve got a whole different set of problems to deal with and a lot less memory to deal with. But it’s all good. There are a lot of different patterns and a lot of different tricks that you really need to be familiar with in order to handle all of these different scenarios. One of the things that I keep coming back to when I’m talking to people about large-scale apps is, don’t forget that you’re building a web application and you have a server on the backend. It doesn’t always make sense to do it in the browser. There are some really good reasons to go back to the server and get more data or even do a complete page refresh, wiping everything out in the browser and standing up a new HTML page from the server. You have the full server there and you should really take advantage of it when it makes sense. AJ:  Absolutely. CHUCK:  I like that perspective too because it seems like we hear a lot of people advocating either the one page application, single page application, or the refresh and they don’t really accept that in between approach. DERICK:  Yeah. And I think that Backbone excels at that in between approach, even just plain Backbone by itself. That’s really where I got started with it. I was building a simple system for a client and we needed to input medications that this person was taking. And so, it was really, really simple. Here’s the fields, you type them in, you hit save, and it immediately shows up in the grid down below. Well, that was my very first Backbone project, was that simple page. All it did was add, edit, and remove things from a list on the screen. It wasn’t a full single-page app. And I really don’t think I would need Marionette in order to build that application. Of course, I probably would use Marionette because I’m kind of biased and that’s my default but it’s not 100% necessary. You don’t have to do the full scale, large systems to use something like Backbone or even Marionette. JOE:  I think you’re dead right that Marionette and Backbone, et cetera, really do excel in that, right? Like the fact that you can give it an element to play with rather than having it only construct its own element makes it a really nice candidate for the hybrid approach. DERICK:  Right. And there’s a lot of cases where I just flat out say, “Do not do single-page applications,” as well. And a login screen is the biggest example of that. In all of the clients that I’ve had in the last couple of years, they’ve all asked me, “Hey, I’m having this problem. I’m trying to get my login screen to give me the current user information back from the server and redo all of this stuff on the screen without refreshing everything.” My answer every single time is, “Don’t do that.” MERRICK:  Yeah, of course. DERICK:  Just go back to the server. Let the server authenticate you and send back a complete new page with all of the new stuff that you need on the page because the user that they’re logging in as, is going to have a completely different set of permissions, and options, and features and everything else. And trying to get the server to send down the difference between what’s on the screen now and what they need to see is nearly impossible. Just forget about that entirely and make a full page request back to the server, re-render the entire page layout on the server, and send down everything that they need. It’s going to simplify your life tremendously. MERRICK:  Yeah. CHUCK:  Yeah. The other thing I’ve seen with that approach is if you have major layout changes, then a lot of times, it’s much easier to just do a full page request instead of trying to do Ajax to request all the information and rearrange everything. DERICK:  Exactly. CHUCK:  And so then, it just knows, “Okay, this particular…” because it’s basically a different Backbone application. I mean, you’re sharing models but your controllers or routes and your views might be a little different. Yeah. And then, it just knows where to put things. DERICK:  Right, right, right. An administrative screen is the perfect example of that. I’ve got a friend that built a large system, had a frontend and a backend and he, for the longest time, tried to have it all in one Backbone application, one Marionette application. I finally convinced him to separate the two. When you switch over to the administrative side, if you have permissions, refresh from the server, get a different Marionette application instance, get a different set of views. Maybe share the same model but most likely, there’s going to be enough differences between the user model on the admin side and the user model on the frontend side that you’re going to want to actually separate those as well. So now, we start getting into all of these system design patterns like domain driven design and all of these other high level architecture patters and bounded context. And all these kinds of fun stuff where you really start seeing good software development principles and patterns and practices from all of these other worlds, other than JavaScript coming into play. CHUCK:  Yeah. But the thing I really like is that most of what we’ve talked about, for the last minute or so, really boils down to just simplicity and maintainability. DERICK:  Yeah, definitely. CHUCK:  You save yourself a ton of headaches, a ton of time, a ton of your developer’s time just by rolling out something new that is better at what you’re trying to do than your current single-page app. DERICK:  Right. I’m all for ‘Bang your head against the wall in order to learn where the limitations are’. Quite frankly, that’s how I learn is I take my new toy and I smash it with a hammer to see what I can put back together. But there comes a point when you need to recognize the limitations and do the simple thing that works and gets on with your life so that you can actually build functionality instead of trying to build infrastructure to do something really complex and you should have done something simple. CHUCK:  So, one other thing I want to talk about here that is mentioned, I think, on the Github page and the docs is that it said that it reduces the routers down to just simple configuration? So, what exactly do you mean by that? I didn’t have a chance to dig into it. DERICK:  If you look at Backbone’s router, Backbone’s router contains the route definition and the route handler functions. So, you have this hash at the top of the router definition, typically at the top and it says, “Okay, for this route /users/:ID call this function show user.” And then, you’ll have that show user function in the same object. That drives me crazy. I don’t like seeing a lot of code in my routers. I want my router to be more like a Rails router, quite frankly. I just want it to be a list of routes. And then, okay. In this case, I need to specify a function to handle the route but I don’t want the actual function in the same object. I moved it out into, what I call, a controller. It’s kind of, sort of like a Rails controller or other MVC controller but kind of sort of not. It’s a mess. So, what I’d really like to see is an object that is separate from the router, handling the actual route as it calls the route handler function. The reason that I like that, the big reason that I want that separation is because it gives me the opportunity to reuse code and to have a single point of entry for the application’s functionality. So, if I have a menu system and you’d click on the list of products in that menu system, I can create this router that has all the code to stand up all the products and get everything on the screen. And then, I could have another part of the application where you can click a button to get to all a product list and have it go and do all of the same code. Or that button can go back through the router in order to get into the same code. But that gets kind of messy in itself because if you already had everything on the screen that you need except for that product list, I don’t really want to go back through the entire router in order to re-render the entire screen. I just want to update what’s on the screen because I have most of it already. So, if I separate my route handlers from my router, I can use that route handler from anywhere in the application. I can use that from the router. I can use that from a button click. I can use it from a socket IO communication event. I can use it from some mobile phone device input with geolocation or whatever else. I have a single point of entry for the functionality in the application and I don’t require a router in order to get to it. That’s really where app router came from. MERRICK:  And the beauty is that you can also test it that way easier. DERICK:  Yeah, it’s a lot easier to test it. MERRICK:  It’s not swallowed by the router, right? DERICK:  Exactly. You don’t have to test the router. You can test the handlers and then, by the way, the router happens to use them. CHUCK:  Well, I think this is a really good example of the single responsibility principle. DERICK:  Definitely. CHUCK:  Where the writers in Backbone, their job is to translate the hash or whatever you call that in the URL into a path. And then, its job is also to handle it. And in the case of — and I guess you could argue that then its responsibility is just to handle hash changes. But breaking it apart then it’s just — one’s responsibility is simply delegation and the other one’s responsibility is handling. DERICK:  Exactly. One’s responsibility is to handle route, that’s what a router does. And the other one has a responsibility of controlling the application, that’s what a controller does. CHUCK:  Yeah. And it makes it easier to separate, at least for my approaching or for my thinking. But if you like it the other way, then by all means, just use the Backbone router. DERICK:  Yeah, sure. And I actually do that a lot, still. There’s a problem with Marionette’s app router right now. There’s another Backbone plug-in called backbone.routefilter. I love that plug-in. It gives you all kinds of really cool features in Backbone’s routers. But the way I build Marionette’s app router is incompatible with routefilter right now and I want to fix that. But until I do, you have to make a choice between app router and Backbone router. So, I often drop back to Backbone routers so that I can use the backbone.routefilter. And when I do that, I do everything that I can to keep my Backbone router to an absolute minimum, just the bare minimum amount of code to call out to my Marionette controller object, basically. That way, I can keep going with the way that I like to do things. I just have one or two lines of code in my router in order to facilitate that. JOE:  So, this backbone.routefilter, does it let you do asynchronous before and after? DERICK:  I don’t know about that. Honestly, I’ve never tried to do an Async before and after with it. You’d have to look at the docs for it. JOE:  Cool. CHUCK:  Yeah. That’s one thing that I really like about a lot of these, you know, what we’ve talked about here like this route filter, for example. I mean, I’m very familiar with Ruby on Rails, teaching a course on Ruby on Rails. But to see some of these features come in and be used across different frameworks, and I’m sure Rails has stolen plenty of ideas from other frameworks. These great ideas being passed around and added to people’s applications, I just think, is tremendous. And I can only imagine how much work you’ve put into Marionette. It looks like there’s a ton there, and a ton of work that’s gone into this that really is awesome. DERICK:  Thanks. You’re absolutely right about ideas from other systems. That’s what Marionette is. It’s just a bunch of ideas from other systems. And it’s a lot more than just me, thankfully. There’s a pretty good group of guys that I have as a core team of contributors and they do a pretty amazing job of answering questions and slapping me across the face when I’m doing something stupid or coming up with really good ideas for implementations and new features and all kinds of stuff. So, there’s a tremendously amazing pool of talent of people working on Marionette. And then, all of the contributors, everybody that’s contributed to Marionette is doing some phenomenal work with it, whether it’s just documentation changes or bug fixes and bug reports and everything else. There’s all of these different ideas from hundreds and thousands of different systems out there being poured into Marionette in order to make it what it is. CHUCK:  So, one other question that this leads me to, you mentioned that Marionette and routefilter aren’t necessarily compatible and you’re working on that. Do you run into compatibility with other plug-ins for Backbone? And if so, how do you decide whether or not it’s going to be too much trouble or if the philosophies don’t line up between the two plug-ins and you just tell people, “Too bad.” DERICK:  Yeah, that’s always the tough call. Fortunately, there are relatively few Backbone plug-ins that it’s just not compatible with. Of course, there are other Backbone frameworks like Thorax, and Layout Manager, and Chaplin, and some of these actually do work together. You can mix Marionette and Chaplin into the same application, for example. But Marionette and Layout Manager don’t play well together because Layout Manager tends to be a lot more opinionated about how you should do things. It’s a lot more framework-like, while Marionette is a lot more library-like. I’m not saying either one of those is the right way to do it. It’s just a difference of opinions. A lot of the incompatibility that we run into is solved by creating additional points of flexibility within Marionette, but also by solving some of the inherent problems in how we build objects in JavaScript. So, what I mean by that nebulous kind of iffy statement there, one of the incompatibilities I ran into awhile back was with the backbone.stickit. I ran into a compatibility problem with backbone.stickit, which backbone.stickit is a great way for you to do automatic updates of your DOM whenever the model changes, basically. There was a problem in the way Marionette was configuring a certain piece of information with a collection of I don’t remember what. Marionette was using _.extend in order to bring this other object into backbone.view. And when you use _.extend, you bring everything from the source object into the target, it just copies and pastes all of the methods and attributes. There was an incompatibility between Marionette view and backbone.stickit because of the same variable name. We were both using _config as an attribute name on our object, basically. And so, that caused some compatibility issues for a while. And the way that I solved that was by changing how I mix my dependencies into my Marionette objects. Nearly everything out there has an _config attribute on it, it’s just the default name everyone uses. So, what I did is I took the approach of, rather than using _.extend to bring all of the methods and attributes from a source object into a target, I created a bridge or a facade between the target and the source. So this bridge, what it does is it maintains a reference to the source object, the backbone.stickit, or the Backbone event aggregator or whatever from record and it holds a reference to that object and it provides a function that forwards the call to that target object but then gives you — rather than copying the execute function from wreqr’s command object directly into Marionette’s application object, Marionette’s application object has an execute function of its own and it makes a call to this .command.execute. So, it just forwards the call back to the real object that does the real work. And that allowed me to not have to do _.extend in order to bring the commands into the application object. So, I’m doing that all over the place, in Marionette’s view and Marionette’s application and I solved a lot of compatibility problems with that. And that allowed me to say, “Hey look, Marionette’s views now work with backbone.stickit because I’m using this technique instead of using _.extend.” I’m forwarding calls back to the original object instead of directly applying the original objects methods to the current object that you’re trying to use. MERRICK:  I’m just wondering how that resolves compatibility issues in terms of like a shared variable? Are you keeping the state that you otherwise would have overwritten inside of the Marionette application? DERICK:  No, I’m moving that state back to the original object that held the state. So, a backbone.view is a common place for people to put mix-ins and one of the mix-ins that I had used an _variable, an _config variable, or attribute on the view. So, you had the view._config and Marionette used that for something. And then, backbone.stickit came along and it also used view._config to store its own information. MERRICK:  Sure. DERICK:  So, that’s incompatible right there. Last one in wins and you’re going to cause problems. So, what I did to fix Marionette is instead of mixing in that source object and taking the original object, my object that had the _config attribute. Instead of applying that to my Marionette view, I have my Marionette view call the original object as basically forwarded. So, you call view. — I can’t think of the exact example here. So, I’m going to have to switch back to the Marionette application. If you look at the way the Marionette application works, when you call application.execute, that execute method does nothing more than forward the call to an instance of backbone.wreqr.commands. So, instead of mixing in the state from the commands object into the application, the application holds it reference to the commands, and the commands manages its own state. So, I’m not allowing anyone else to have direct access to that state and I’m not providing any opportunity for anyone else to override the state of the commands. It’s completely separate… JOE:  And you aren’t overriding the state of the view either. DERICK:  Exactly, I’m not overriding. The commands object is not overriding the state of the application or the view or whatever else. The state is being maintained separately and we just have these methods that forward the calls back and forth whenever we need them. CHUCK:  So basically, what it boils down to is Composition versus Inheritance. DERICK:  Yes, very much so. JOE:  So, I’ve got one more question. Like you said, there was a little bit of ambiguity for me between applications and modules and sub-applications. I have a similar ambiguity problem with layouts, region managers, and regions. Can you touch on how you envision those to be used? DERICK:  Yeah. So, a layout is, first of all, an Item view. It renders a single item on to the view template. A layout also contains regions. So, you can have, in the canonical mail application example, you have the inbox with a list of mail, you have the list of mailboxes and then, you have the header and the footer, and things like that. So, you could actually render a layout for this entire screen. On the left hand side, where you have the list of mailboxes for your mail app, that could be a region inside of a layout. The right hand side where you have the list of mail would be another region. You’d have the navigation within a main region or something like that inside of your layout. So, the idea of a layout is that it allows you to provide a structure to your page and then, take individual views and place them into the structure where they need to go without the individual view having to know where to put itself on the screen. It provides nested view capabilities and you can infinitely nest these things. You can put Composite views inside of a region that is owned by a layout, and that Composite view could render a list of layouts. And then, each of those layouts can render Item views and Collection views and anything else. You can just infinitely nest these things. MERRICK:  So, do you think your application as having one layout and then giving different sub-applications a piece of that layout? DERICK:  Yes. MERRICK:  Making furthermore so, you have an app layout, then each Marionette module has their own layouts and so forth? DERICK:  Yeah, at the highest level of Marionette modules, that’s pretty much how I do it, my mail application. So then, the Marionette application object itself has the raw HTML that the server sent down. That is the ultimate page layout that the application object owns. And the application object can have regions attached to directly to it just by calling addRegions. So, within one of those regions, the main region or the content region that my sub-application, my mails application, will have a layout that goes into that application.mainregion. And the mail application layout will provide its own HTML structure to get the left hand navigation and the right hand list of Email and everything else. And then, the layout will have its own set of regions that it uses in order to populate that information into the screen. MERRICK:  Sure. Cool. Thank you. CHUCK:  Alright. Well, I think we’re pretty much out of time. Do we have any last minute questions or should we just go to the picks? DERICK:  There was one other question that I missed, the difference between a region manager and a region. So, that’s kind of the same difference between a Collection view and backbone.babysitter which is a collection of views. So, a region is individual DOM element that is an object that manages an individual DOM element and populates that DOM element with Backbone views. A region manager is an object that manages a group of related regions. So, a region manager isn’t meant to be used on its own. It’s meant to be composed into other objects like the application object or the layout. MERRICK:  Very cool. JOE:  So, I don’t have a question but I do have sort of an observation I noticed. As you were speaking at the beginning about your history, one of the things that impressed me was you said you didn’t feel like you were by any means a real expert. Then, you started working with Backbone and you saw all these common problems and you started solving and you developed Marionette. So, correct me if I’m wrong but it kind of seems to me like you went out there and started solving problems regardless of feeling like, “Oh, I’m an expert in this particular area,” which I think is really admirable. A lot of people might see problems and decide, “I’m not the right person to solve these problems because I’m not the person that invented this.” So, I think that was really cool that you tackled Backbone and said, “I’m going to solve some problems I see in Backbone and create Marionette.” Regardless of feeling like, “Oh, I’m the expert in Backbone. And so, if I’m not that, then I can’t be solving problems and contributing to the community.” DERICK:  Right, right. MERRICK:  So, does Layout offer region manager? Is it mixed in region manager? DERICK:  Yeah. A Marionette Layout has a region manager built into it in order to manage all of the regions within that layout. MERRICK:  Okay, cool. Awesome! Thank you so much, Derick. You were awesome. CHUCK:  I have to ask you, does it have an assistant to the regional manager? [Laughter] DERICK:  Yeah. I actually have an object called Dwight in there, funny you should say that. [Laughter] JOE:  That was awesome. CHUCK:  Couldn’t help it. Alright, well let’s go ahead and wrap up the show, do some picks. Tim, do you want to start us off with the picks this week? TIM:  Sure. So, I’ve been [inaudible] at work for a while but one interesting thing is Raynos has posted a new spec to something I’ve been working on for years called continuable which is my middle ground between promises and callbacks which has been a fun debate on the Internet last few weeks. I’m just going to post the link to that spec. It’s really simple. It’s basically a function that takes a callback. It’s like the lightest weight promise imaginable. CHUCK:  Kind of like a [inaudible]. TIM:  Yeah. We call it continuable because yeah, you give it a continuation and then keeps it going. CHUCK:  Awesome. TIM:  I don’t know. That’s what I got. CHUCK:  Alright. Joe, what are your picks? JOE:  Alright. I’m going to pick two things. The first one is, I’m going to pick asm.js. It’s been making a lot of waves recently. The ability to write, I guess, write really, really, really fast JavaScript by first writing it in C and then compiling it into JavaScript. They’ve got the unreal engine ported to JavaScript and other game engines, just amazing. I’m going to pick asm.js. And then, the other thing that I’m going to pick is Arrested Development. This next month, Arrested Development is launching a fourth season. It’s been like 10 years since they had their last season. They had three seasons. By far, the funniest show to ever have been on Television and they’re launching a fourth season on Netflix. They’re launching every episode simultaneously. And apparently, the way that it works is each episode is about one character but they’re all running essentially simultaneous. So, if you’re watching one episode and you see a character interact with another character, you can pause, go watch the other character’s episode and watch up to that point where they’re having that interaction as part of that character’s episode and go on. So, it’s not necessarily meant to be viewed linearly, but instead to be viewed almost randomly which I think is really cool and very innovative. So, those are my picks. CHUCK:  Alright. Merrick, what are your picks? MERRICK:  Sure. So last episode, we talked about what it takes to be a web developer. And I mentioned that I think people need to understand CSS because if they don’t, they’re naturally going to be putting too much into JavaScript. So, my first pick is a website called LearnLayout.com, and they touch on all the different approaches for CSS layouts, like floats, position, display, things like that. Then my second pick… JOE:  Hey, Merrick. Wasn’t the exact phrase that you used is that if you can’t replicate a Photoshop in CSS, that you’re a waste of space? Isn’t that…? [Laughter] MERRICK:  Actually close. I would say you’re human garbage. No, I’m kidding. DERICK:  Well, it’s a good thing I spent a good chunk of my life doing exactly that, just [inaudible]. [Laughter] MERRICK:  Then the second thing that I wanted to pick was this website called GapMinder.org/Data. They have all sorts of interesting data sets about the world in general, like the age, unemployment rate, or adults with HIV, or age of first marriage across the world. It’s really interesting if you want to get into data visualization, you can download these data sets and get some interesting insights on real world problems. So, that’s GapMinder.org, it’s a non-profit. CHUCK:  Awesome. AJ, what are your picks? AJ:  There’s this YouTube video, it’s a little bit old but it’s pretty awesome. It’s the BYU Easter Prank is what it’s titled if you Google it. But a friend of mine, until I met him, I didn’t even know about this video even though it’s got millions of views. But he went into his friend’s apartment, a couple of the guys did, into this girl’s apartment, put down sod and chicks and had a guy dressed up as the Easter Bunny, and just totally re-did their living room as an indoor/outdoors… CHUCK:  Farmland. AJ:  Yeah. CHUCK:  I’ve seen it, it’s pretty funny. AJ:  Okay. Yeah. So, I’m going to pick that because I just found out about it. Also on the subject of YouTube videos, my friend, when he got married like a year ago, had this really cool engagement story video done and a pretty neat wedding day video. So, if anybody out there is considering videography and what kind of cool stuff you could have as a token of memory, I’m just going to put links to both of those videos so you can kind of see a cool thing. CHUCK:  Nice. Alright, I’ll go next. One thing — I think I’ve picked this on the show before but I was just looking at it a little while ago and I just want to pick them again. The first one is Libsyn, that’s Libysn.com. That’s what we use to host the files that you download for the podcast. It gives you a whole bunch of statistics and stuff and it’s really, really nice for that sort of thing. The other one that I’m going to pick is GetClicky.com. And I’ll put an affiliate link in the show notes and that way, you can go check it out, and I get a little bit of a kickback on that. But it’s what I use instead of Google Analytics. Google Analytics seems a little bit just too much for me, most of the time. And Clicky just has a really simple interface and gives me the information that I need and then I can drill in to what I care about. So, I’ll put links to those in the show notes, and we’ll toss it over to Derick. Derick, what are your picks? DERICK:  Alright. I’ve got a couple of them here and all geeky, mostly techie stuff. My first pick is Arduino, I am just loving the heck out of the Arduino set up that I have right now. We talked about this before the show but I’m building a network-powered, network-enabled Arduino Barbeque Thermometer and it’s going to send me text messages when my meat is done and it’s awesome. Along with that, the Johnny-Five, MPM package for writing JavaScript to run your Arduino. It is, again, pretty dang awesome. I had to type a lot of stuff with that before I finally broke down and actually had to write some C code to really run the production version of this little meat thermometer. Third one, I mentioned earlier, Brian Mann and his screen casts, definitely a pick. If you really want to get down into the guts and the details and the structure of writing good Marionette applications, you need to be watching Brian Mann’s screen casts at BackboneRails.com. Then lastly, board games. My wife and I have been playing the crap out of some awesome board games recently. Mostly Settler’s of Catan, Ticket To Ride, and Carcassonne. All three are just awesome games and I highly recommend all of them. CHUCK:  Can we get links to those in the chat and we’ll put them in the show notes? DERICK:  Yeah. I’ll send you links to those and then also, I’ll give you some links to some of my favorite JavaScript writings as well. CHUCK:  Awesome. Well, thanks for coming, Derick. It’s been really fun. DERICK:  Yeah, thanks for having me. I’ve really enjoyed being here and talking with you guys.

x