The panelists talk about design patterns in JavaScript with Addy Osmani

Special Guest: Addy Osmani.

 

All right. So, should I kick the show off? 

 

JAMISON: Let’s do it. 

ADDY: Let’s go for it then. 

CHUCK: All right. What episode number are we on? See, I got to open up the show notes. Shows you how awake I am. 

JAMISON: Twelve, I think. 

CHUCK: That sounds right to me. 

JAMISON: [Chuckles] Chuck, you sound like way more tired than you did 30 seconds… 

ADDY: I’m going to get coffee. One second. 

JAMISON: I think you are actively falling asleep right now. 

ADDY: We are roughly around episode… or something. 

CHUCK: [Chuckles] Yeah. We’ve done about a dozen. 

JAMISON: Yeah. 

ADDY: Welcome to episode… your guess is as good as ours.  

CHUCK: Hey everybody and welcome to episode 12 of the JavaScript Jabber Show. This week on our panel, we have Jamison Dance. 

JAMISON: Howdy, howdy. 

CHUCK: We also have Joachim Larsen. 

JAMISON: Hey, it’s me with the dogs. 

CHUCK: AJ O’Neal is in the chat right now, so he'll probably just tell us important and happy things in the chat and we'll voice for him. We also have a special guess, and that is Addy Osmani. 

ADDY: Hi. I have no dogs. 

CHUCK: [Chuckles] And I'm Charles Max Wood from… 

JOACHIM: You can have one of mine. CHUCK: [Chuckles] Yeah, just FedEx him. Just kidding for the animal lovers, I’m just kidding [Chuckles]. I’m Charles Max Wood from teachmetocode.com. And this week we are going to be talking about Design Patterns in JavaScript. Addy, do you wanna introduce yourself really quickly? I’m sure there’s one or two people out there that don’t know who you are. 

ADDY: Sure thing. So my name is Addy Osmani, I’m a JavaScript developer at AOL. I’ve written a few open source books like Essential JavaScript Design Patterns, Backbone.js Fundamentals; I'm on the jQuery team, I’ve contributed to open source projects like Modernizr and I do some other open source stuff on my spare time. 

CHUCK: All right. Yeah we love those projects – jQuery Modernizr. 

JOACHIM: jQuery rules! [Laughter] 

CHUCK: Yeah Joachim was telling us how much he loves jQuery. Anyway, so were having discussions before the show and I think it’s interesting to talk about before we jump in on design patterns; we were talking about TodoMVC. Is that what it’s called? 

ADDY: Yeah that’s what it’s called. 

CHUCK: You wanna just explain what that is and why you did it? 

ADDY: Sure. So a while back, I realized that as time went on, we were getting more and more MVC frameworks in the JavaScript world and sort of structural solutions to try helping developers organize their code better. And I got to a point where it was difficult for me to like go and compare each framework; not just because some of them have bad docs, but they didn’t have all examples of how to actually use the framework and it was difficult. So I thought, “Why not create a project that has the exact same solution in every single one of these frameworks?” So how does solution x try to structure models and views and controllers and what other bits and pieces it might have? And I just want to make it really easy for developers to you know, get a feel for what a framework was like before they went and explored it further. So you know, maybe you will take a look at 10 frameworks, maybe you will take a look at 5 and you will just find 2 that you really like and just go see if it’s a good fit for your project -- that’s the essence of what TodoMVC is all about. 

CHUCK: All right. Cool. And I think it was Joachim that pointed out that not all of the frameworks really compare in the same way, feature to feature and whatever. So, what's kind of your take on that because you know, you look at some and they have different capabilities than others? 

ADDY: Absolutely and that’s the challenge that we are trying to solve for the past while. I mean, in our upcoming releases, we are trying our best to sort of make each implementation as consistent as possible so that the developers has a fair view of what they can do with the framework versus how much extra effort they might have to go to get it, as good as something a little bit more mainstream for example. But we realize that it’s really, really difficult getting a baseline application to help you compare 20 or 30 different frameworks. And one way that we are going to try addressing that is by coming up with a bunch of end-to-end applications. So you know, a complete application built with Backbone or Ember or CanJS or any of the others, so the developers can get a really good feel for how all the other little parts involved in building an application are solved by that framework. And we are going to try documenting that as much as we can and then hopefully, that will give developers an even better way of making their minds up about what to use. 

JAMISON: Wait, wait, wait so you are saying that you didn’t build the TodoMVC stuff because you had a lot of to-do things? [Overlapping talks] 

ADDY: Absolutely. I woke up one day and I thought, “Well, why don’t I have an application in 20 different frameworks for each of the different aspects of my life?” I need to remind myself that. 

JAMISON: Yeah it seems like it really helps you organize. 

CHUCK: Yeah you finished reading Getting Things Done and you said… 

JAMISON: [Laughs] 

CHUCK: …”I need to do some to-do applications.” JOACHIM:

…procrastinator. [Laughter] 

CHUCK: Awesome. So a lot of people are asking that we get you on the show to talk about design patterns in JavaScript and I remember when I was a new developer, I really didn’t have a good idea what a design pattern was. Can you jump in and just explain that really quickly? Like what they are and how they are used? 

ADDY: Absolutely. So design patterns provide us with like proven solutions to recurring problems and developments. So, they try to build upon the experience of developers that have been trying to solve similar problems over a number of years. And JavaScript is obviously is not the first programming language; there have been tons over the past 30 years. And design patterns just mean that we can take some of the learnings from some of those other languages and hopefully, apply them to JavaScript and apply them to the other projects that we are working on a day to day basis that could hopefully save us some time. Now pattern address a ton of things; like developers are going to go into projects and wonder, “Well, what’s the best way for me to separate concerns,” and “What’s the best way for me to offer simple APIs that are easy for people to consume, but which will still allow me to be complex behind the scenes if I need to,” or “How do I decouple my application so that each part of it doesn’t have to directly speak to another part?” And patterns help us with all of these things. 

CHUCK: Yeah. Absolutely. And were they first originated with the book The Gang of Four or is that… 

ADDY: No, no. Design patterns actually were originally defined by an architect called Christopher Alexander, a long, long time ago. But design Pattern Elements of Reusable Object-Oriented Software was one of the first sort of break through books to sort of describe how design patterns be applied to software design. And they had a really huge impact at how software engineers design patterns and how they apply them to their projects. But I guess I realized after reading the book that first design patterns aren’t really covered as much in computer science courses in most universities. And secondly, there was at least no open resource that developers can go to just learn about patterns and how they apply to JavaScript. So I figured, well, why not write one? 

CHUCK: Yeah and I just wanna back you up on that because I have a college degree in Computer Engineering. It’s not Computer Science, but I took quite few Computer Science classes. And yeah I don’t think the word “design” and “pattern” were even used in the same sentence [chuckles] together. 

JOACHIM: The closest you get is probably “algorithms” and “data models”. 

CHUCK: Yeah. That's true. 

JOACHIM: They only kind of scratches the surface, especially in terms of interactions and reusability. 

JAMISON: We did some design pattern stuff in one of our classes. I think one of the dangers with the design patterns though is that people build patterns instead of applications. Eventually, it’s like other… I don’t know cool new things that you discover in computing, like you first learned about meta-programing in Ruby or like async stuff in Node.js and you go and do horrible, awful things with it by using it where it doesn't need to be used. 

ADDY: Yeah I completely agree with that. People, don’t use design patterns if you are not using it for the right reasons. Like I've seen people that will just see a design pattern in my book or another book or they'll see some article about a design pattern… [Kid’s voice in the background.] 

a Sorry. 

ADDY: [Chuckles] That’s cool. And they'll be like, you know, “I should be using what the cool kids are using. Surely it’s on Hacker News, I should be using it.” But that’s completely the wrong reason to be using the pattern. You should be studying what patterns are available, form your own conclusions about them and try to pick out what makes the most sense for your project. 

JAMISON: Yeah I think that’s a really good way to put it. 

CHUCK: Yeah. One thing that I’ve found with design patterns that I think is interesting is that, in a lot of cases, I’ll start building something and I’ll get it mostly fleshed out and then some other developer will come and look at my deal and go, “Oh, you are using the observer pattern!” [Chuckles] and I'm like, “I am? I guess I am!” And I think that’s just… it’s also a good way of checking your homework I guess, where you can get in and have a look and go, “Okay, yes this problem actually fits this design pattern.” And that’s sort of what I intuitively wind up building. 

ADDY: Exactly. I mean, the thing I like about design patterns is that you get like this formal language that helps us to commonly share an idea. And it’s harder for us to describe syntax and semantics and things like that about what a pattern is versus just saying, “Hey, I'm using the observer pattern.” 

CHUCK: Yeah. AJ pointed out, “Patterns aren’t invented; they are discovered.” And yeah, it’s so interesting. At the same time, you know, you can also look at a problem and at the same time, realize that a particular pattern describes well what you wanna do. And then exactly what you were saying, then you can start to explain to somebody else instead of saying, “Well, we need this out here that does this and this over here that does this.” You can just look at them and go, “Well, we are going to use these pattern and we are going to tweak it a little bit this way to match our problem.” And so it does; it defines that language that then immediately provides this huge amount of context around the way that you are going to approach and solve the problem. 

JOACHIM: I think it’s also important to realize or it’s important for developers to realize that there are really nice and interesting problems to solve at higher levels of abstraction as well. Like if you listen to [unintelligible] all the time and it’s one of those things where you start from fresh or bring what you have on before because there’s no kind of building blocks in terms of that. But I'm sure Addy is working on that. 

CHUCK: So let’s jump in and talk about some of these design patterns. I was looking at essential JavaScript design patterns? 

ADDY: Yeah, Essential JavaScript Design Patterns. 

CHUCK: And you know, there were few quite interesting ones in there. One that I wanna jump on real quick that I thought was interesting where you had the dry pattern which I don’t really think of as a design pattern. 

ADDY: Whilst it’s not necessary, there is a disclaimer right above the dry pattern that says it’s not necessarily a design pattern, but it is a nice way of thinking. And sometimes, when developers try approaching problems, they sometimes forget that you don’t have to include as much repetition in your code and you don’t have to be doing things in several different ways when you can simplify them down to maybe 5 or 6 lines of code instead. And its jut one of those patterns that I guess improve readability and remove the need to include a ton of code that doesn’t have to be there, I guess. 

CHUCK: Yeah that makes a lot of sense. And you know, the first time I was exposed to it was when I was reading the Pragmatic Programmer. But yeah, it’s something that they talk a lot about when you are programing in Ruby and rails is DRY and that’s why you have MVC. And I think it’s an interesting principle that definitely applies to a lot of these because you wind up putting together these design patterns to help you avoid the repetition and avoid the problems that come out of repetition. But yeah, it’s an interesting thing and you know, I can see how it might kind of come and bump up against what a design pattern is. Anyway, that makes a lot of sense. So, one of the other design patterns that I wanted to ask about that I don’t completely get is MVVM. I understand that it is similar to MVC, but I don’t completely understand how they are related and what the differences are. 

ADDY: Oh, that’s absolutely cool. So I realize this is JavaScript Jabber, they are going to be a ton of JavaScript developers, they are very familiar with MVC on here, but for those who aren’t, I'll just go through that very, very quickly. So in MVC, we've got sort of three parts; we've got models, views and traditionally, controllers. The models manage the main specific data for an application. So if we are creating something like say Facebook, you probably have models representing users and photos and videos and stuff like that. Models might have validation rules and defaults for example. So if you upload a photo for example a model can have a default state to make sure that it is visible to everybody on your timeline. And when models change, they modify anybody that is watching the model about that. So, views for example. Now views in MVC at least are representation of models that have a filtered-down look of their current state. So looking at, say, the user model again, you could easily have multiple views for that model or you can have one that shows the movies you’ve watched on Netflix, the music that you've listened to on Spotify, etc. And views usually observe models and they are notified when models change. But they also come in two different flavors; and this is going to come back into something I'm going to talk about in MVVM. Views have two flavors; it can be passive or they can be active. 

CHUCK: Okay. 

ADDY: So views can be passive or they can be active. Now a passive view is consider relatively dumb; and that means that it’s mostly manipulated by a controller. But an active view is something that has a lot more logic in it; it might have data bindings, it might have events, it might have behaviors. And patterns like MVVM use active views. I’ll go into a little more detail about that soon. And then again at MVC, we’ve got controllers and they are supposed to be like intermediate or between models and views. And I guess they are classically responsible for few different things. You know, they update the view when the model changes and they update the model when a user changes the views. So if you are for example editing the caption on a photograph, that’s you editing a model effectively. So your controller will then update that for you and you’ve made changes to the view. But you know, we talk about MVC; but the reality is that, when it comes to JavaScript frameworks, there's not really a true sense of MVC. I can’t think off the top of my head of many frameworks that actually follow this pattern exactly. If we took Backbone.js for example, that completely omits the controller. We usually say Backbone is MVC or something like it but Backbone completely omits the controller. And it moves all the responsibility off the controller into to the view. So you have the controllers, your views, models, collections, routers -- but there is no controller logic. It’s on separate component. It’s in the view. And so, it can be challenging sometimes if developers are reading classical literature and saying, “Well okay I sort of get what MVC is but why is it that all these frameworks I'm using approach it a little bit differently?” And the reason for that is usually because the framework authors have interpreted the pattern a little bit differently or they found that you can be a little bit more flexible with it; and that’s with Backbone at least, that’s a good thing. It means that I can develop an application that maybe just has a single model and multiple views and doesn’t need a controller at all. But it can get challenging. S So I’ll talk what MVVM now. So we've talked about models using controllers. In MVVM, which stands for Model View ViewModel. The model is very, very similar to what it is in MVC. The view is mostly the same, but it has some subtle differences that are worth noting. So the view in MVVM is essentially an interactive user interface and it represents the state of another component MVVM called the ViewModel. Now the ViewModel is like the specialized controller and it acts like a data converter. So whatever information you have in your model, the ViewModel can change that information into view information. And it can also pass commands from like the view to the model. So one example for that is like your MVVM model might contain a data tribute in UNIX timestamp format, and your view model can actually go and format that into something a little bit more friendly for your view. So when it actually goes to displaying it, the view doesn’t need to convert that data itself. It could have if you wanted it to do that…. I just heard someone said I'm hypnotizing to listen to. [Laughter] 

CHUCK: Yeah that was Joachim on chat. 

ADDY: Okay. 

CHUCK: I was just thinking something along the same lines. I was like, “Man, he is a

really dynamic speaker.” Explain things very well though. 

JAMISON: You talk pretty. [Laughter] 

ADDY: When you say that, I translate that in my brain as, “He has no social life.” [Laughter] 

CHUCK: You should hear our other shows; Jamison is over there. 

ADDY: All right. So we were talking about model, ViewModel and ViewModel essentially act as a middle man between your models and your views, and they can also expose methods for helping you to maintain view state. Now going back to the view again for a moment, the MVVM view like we talked about the idea of views being both passive and active; where the passive one is dumb but the active one isn’t. The view in MVVM is actually active; meaning that it does a little bit more. MVVM strongly promotes this idea of data bindings. Now if you've explored frameworks like KnockoutJS before, you are probably aware of this idea of having data bindings in your markup which are then passed on to other parts of your application. Some developers like them, some feel bad -- it’s a little counter intuitive having sort of logic and bindings in your mark up and they could be completely separate. 

CHUCK: That sounds like Mustache to me where they try and strip all the logic out and it’s just dumb data. 

ADDY: Yeah but it can also contain events and behaviors and stuff like that. But I guess the framework that most people know MVVM for or probably will know MVVM for is Knockout at the moment or I guess Kendo MVVM which is another variation by another company. But in Knockout, your views effectively just a HTML document with the markup in it, declarative bindings and those link to your ViewModel. It took me a long time to really appreciate why someone would want to use data bindings in their markup, but the reason why I guess MVVM is of interest to some people is that you might have a team where you have I guess UI developers and UI designers that wanna be working on your view. And you wanna be able to allow the rest of the developers working on your project to focus on the ViewModel and the model, so things that contain more of the business logic and behavior. And so, pattern can help you with that because those designers can be focusing on the view, they could be including sort of data bindings in the mark up without having to go writing logic themselves. And it can be useful in that sense. 

JOACHIM: From the performance aspect though, if you need to like refresh only one aspect of the UI, then it becomes a valuable thing to be able to do. 

ADDY: Definitely. 

JOACHIM: I mean sometimes like you are really big UIs with thousands of elements then if you are refreshing the whole thing or you know, yeah. 

ADDY: I mean it has some interesting pros and some interesting cons. I mean, most of the cons are what I guess the majority of JavaScript developers used to keeping their logic outside of the markup will feel like. I personally probably wouldn’t be writing a project that uses data bindings. I just feel somewhat counter intuitive, as a JavaScript developer, to be to keep all that logic in there. But you know, like I said, if you are in a team where you find yourself needing to keep that separation where some people are able focus on the view and other people focusing on the other logic, MVVM can be immensely useful to you. I guess I also wanted to mention that -- and this is something that I

covered in Essential JavaScript Design Patterns but also in a recent article on MVVM -- you don’t have to keep all your data bindings in your markup. There are actually ways with Knockout.js so you keep all your data bindings in a binding object completely separate to your markup, and you can use data classes instead just to refer back to that logic back to those bindings. So the amount of, I guess logical hooks or declarative bindings in your markup can be as minimal as you want. But I then get to a point where I think, well if you are going to do that, maybe it makes more sense to be using something else. It’s interesting. It’s definitely interesting. 

CHUCK: So I'm a little curious then after everything that you’ve done with TodoMVC and you know, looking at these different design patterns and stuff, which of the MVC or MVVM or MVP -- which we didn’t talk about Model View Presenter, which of all these libraries do usually prefer on your projects? 

JAMISON: And you can’t say, “It depends on the project!” 

ADDY: I'm somewhat glad Yehuda isn’t on this call. [Laughter] So, I mentioned earlier that I'm writing a book about Backbone.js and so, it’s probably not a huge surprise that the one that I currently prefer the most is Backbone. The reason for that in addition to some of the sort of reasons enterprisey reasons like there's a huge community around it, lots and lots of ways to extend it and tons and tons of large companies actually investing in building apps with Backbone, I find that it’s extremely flexible. And something that you’ll find even people who are like committing codes of Backbone.js will tell you is that, once you really understand how Backbone works, even if it doesn’t completely support MVC in its classical form, it’s flexible enough that you can use it in a way that works best for your project without subscribing to just one way of doing things. As I mentioned before, I'm currently working on a rather large application with AOL where we effectively have an extremely small number of views and models in the application event though it’s quite large. And I'm making use of a huge amount of component reuse in there, but this is something that I personally find Backbone really useful for because it’s flexible enough for me to do whatever I want with it. If I wanted to introduce additional parts in there, if I wanted to say, I don’t know, spin off some other layer that further breaks down concerns in a way that Backbone doesn’t do at the moment, it’s not that difficult for me to do that. And I don’t know that I could say that about all of the other frameworks that are out there. Having said that, I will say that I'm excited about some of the other frameworks that are out there – just so that that they don’t gang up and beat me. I really, really, like Ember, I think that once they have a lot of documentation and some more solid examples down –which I know that Yehuda and Tom are working on at the moment -- that's going to be phenomenally interesting to see. CanJS by Justin Meyer and what used to be Jupiter Consulting, but it’s Bitovi where the guys that worked on JavaScript MVC. CanJS is really, really cool. It’s sort of been built in the way where it’s extremely light weight. So it’s in some ways it’s supposed to be a competitor to Backbone. But it’s got some really, really neat things in there. I'm going to quickly sort of look this up and just point out one or two of them. Justin Meyer was like showing me this right before they released it but it’s got everything from sort of live binding to some other magic that… 

CHUCK: I have to say while you are looking that up, I'm really disappointed we are not going to have like you and Jeremy tag teaming on Yehuda -- the Backbone versus Ember Round 2. 

ADDY: I'm more than happy to let Jeremy and Yehuda do that themselves and just sit back in the audience. 

CHUCK: [Laughs] I have to say though that it wasn’t… I was very grateful that it wasn’t this huge bash fest and at the same time… I mean, it was so interesting because you know, they are talking about these tradeoffs and some of it was in a really high level, design level and some of it was you know, they really got down into the nitty gritty of how their frameworks work. And I think it turned out to be more informative than it really turned out to be hostile. If you haven’t listened to it, I highly recommend you go back and give it a good listen because it was really informative about how these people think about the problems that they are trying to solve, and especially since they are trying to solve general problems, using these particular design patterns as opposed to you know, a very specific problem for a very specific website. 

JOACHIM: Can I just quickly ask you Addy, what do you think about YUI3? 

ADDY: To be completely honest, I haven’t used it extensively myself, another member of our team built a YUI example on the TodoMVC but you know, I'm sure I can take another look at it one of these days. 

JOACHIM: It strikes me because we see all these smaller startups starting up frameworks and they all seem to basically be recapitulating the functionality that’s in YUI3 already. And with a lot of these different things, now we need EnyoJS for loading, we need all these other things for dynamic binding. And these are the things that already… in YUI I'm just wondering if it’s a Yahoo name and the purple color that are [24:21 unintelligible] 

ADDY: I think that you made a really interesting statement that YUI already has most of these things sorted out. I think a few years ago, we had the Dojo camp for example saying something very, very similar. And I love Dojo. I'm not saying anything bad about Dojo, but I think that we've come to a point where we understand that you know, developers are diverse enough that they are not always going to want to do things in a single subscribed way, you know, a framework might give it out of the box. And we do currently have I guess enough tools that it’s not that difficult for us to put together our own toolkit if we need to. There are situations where it’s going to take a lot more time to and you have to make sure you’ve got built processes that work and take care of unit testing -- all those things on your own -but I guess it works for some developers and some prefer something a little bit more packaged. 

CHUCK: All right. Did you find what you were looking for on Can.js? 

ADDY: Yeah it’s got a ton of useful things; one of the nice things I found about Can is that it’s also built in a way where all the individual components of it… I’ll read these off very, very quickly. You’ve got can.model and can.ejs and routers and observers and all sorts of things. But all of these different parts can actually function outside of this library. So you can actually take bits and pieces of it and start using them separately, which I thought was actually quite interesting. But Can.js is also… we've got the team over at Bitovi were kind enough to build us to-do apps for TodoMVC. And Can was built in a way where it’s not just saying, “You can use jQuery with this.” They’ve actually the effort of creating special builds of their library, where you can be using it with jQuery or Zepto, Dojo or YUI or Moo Tools and it will use whatever functionality those libraries already have to avoid sort of duplicating it on top. So if you go on the Can.js website which is like canjs.us, what you see is they actually have different kind file sizes for the variations of Can that works with different libraries. So for the jQuery version for example, if you wanted to use jQuery with it, they’ve got a version that's like a 8.5K but the version that just uses Vanilla JavaScript for example is going to be a lot smaller. And you've got things like live binding and magic tabs and all sorts of other wonderful things. But I suggest people you know, check it out. It’s just come out over the past couple of weeks,  so it might not be completely ready for primetime just yet, but I certainly found it interesting. 

CHUCK: And you can’t even find it on Google. 

JAMISON: That’s a really cool feature. I know that one of the things that bothers me about Backbone is its dependence on jQuery. And I know if you can kind of rip it out, but I just wished that more people went through the effort of making their libraries kind of selector library and AJAX library agnostic. So that’s really cool. 

JOACHIM: Wasn’t that the other way around? Because I mean there's functionality in Underscore which is more of a tighter bound dependency which duplicates functionality in jQuery. 

ADDY: In some cases, that’s true. And I've heard some people say… there are cases where you might only need 10% of what Underscore has and yet most people will still include the whole thing. I think it’s an amazing project but at the same time, I think that the idea of building your library in a way where you are using the best parts of whatever else someone else is going to be including on the page is a really interesting take on it. And I would love to see more frameworks trying that out. I think it’s an interesting idea. 

CHUCK: Cool. Well, let’s get back to design patterns for a minute. Does anyone have another design pattern they wanna talk about? I mean, I have a whole bunch but… 

JAMISON: I think it will be cool to talk more about MVP. You mentioned it briefly but we didn’t really define what it is and how it differs. 

ADDY: Sure. 

CHUCK: That would be me. 

ADDY: [Laughs] Was it because you didn’t wanna know what MVP was? [Laughter] 

CHUCK: No, I'm the MVP “Most Valuable Player”. 

JAMISON: Got it. 

ADDY: I should probably also mention that this whole class of architectural patterns is known as MV* I think Yehuda actually mentioned to me on Twitter a few days ago that he is going to start calling this MV*. So its MV*. Anyway, back to MVP. So MVP is quite similar to MVC and some people would even say that Backbone is a little bit more MVP than it is MVC. But the idea is if you want to reuse as much presentation logic as possible in your application, MVP is what you are going to probably end up using. And I should probably say MVP is Model View Presenter. So let’s say you’ve got applications where you might have complex views and a lot of user interaction that you might find MVC isn’t the best fit for because you are probably going to require a huge number of controllers for it, for example. I say “controllers”, but fit that in to whatever it is that the frameworks are using, consider a controller. In MVP all that complex logic can usually be encapsulated into a much smaller number of presenters, like you can use a single presenter for it if you wanted. And that can greatly simplify maintenance in some cases. So like, MVP views are usually defined through an interface. This is slightly different to the way MVC and MVVM works. So when you’re defining MVC, MVP view is defined current interface and that interface is technically the only point of contact that you have between the system and your view. And MVP also less developers like their presentation logic without having to wait on designers to produce the layouts and the graphics for the application and stuff like that. So in that light, it’s a little bit like MVVM, without the data bindings. 

JAMISON: I was going to say this sounds a lot like MVVM. 

ADDY: Yeah. It’s a little bit like MVVM without the data bindings. So, one can almost say that MVP is essentially MVC with a slightly more designer friendly way of doing things. It’s not massively different. I'll put it that way. 

JAMISON: So I have a broader question about all these stuff. These all seem similar. I mean does it really matter whether you choose MVVM or MVP or MVC or whatever? 

CHUCK: It does matter. How else are you going to know who’s right? 

JAMISON: [Laughs] That’s true. But there's this little bit of like paralysis of choice; like you have 30 different frameworks that it seems like the effort you would spend to evaluate them all carefully might be wasted if you would just pick one and do it, you know. 

ADDY: That is true in one sense. But the way that I usually approach this is my knowledge of these patterns means that when I do pick a framework, understanding how they were classically defined -- so understanding how MVC was classically defined for example -means that I have a better idea of perhaps how I could go about using a framework. So, with Backbone for example, knowing that it perhaps has a lot more controller logic in the view means that if I wanted to, I could be a little bit more classic and separate that out further if I wanted to -- if found out that easier. It just means that you know, if I'm using Knockout’s MVVM, perhaps taking on some learning’s that other people have had when they were using MVVM for things like, you know, Flex development or Windows presentation foundation, it really does hurt me saying these things… 

JAMISON: [Laughs] 

ADDY: But people were using those things, [chuckles] taking on the learning’s they had can be useful to you. And I would say you know, don’t go learning these patterns thinking that that’s going to be the be-all and end-all of how you actually go using a framework or how you go out picking out a framework; it’s not. In a lot of cases, frameworks are going to be using something completely different; they might be saying their own variation of MV* or M** even. 

JAMISON: So it sounds like you are saying that knowing these patterns helps you understand how to best use the strengths and weaknesses of different frameworks? So, kind of like working with the framework instead of fighting against it? 

ADDY: Exactly. 

JAMISON: Okay. That makes sense. 

CHUCK: Yeah. It will also help you in a lot of cases. For example, even if it’s not strictly MVVM or MVC, if it’s somewhat, you know, if it’s close enough to be lumped in with the other ones that are also following MVC. Then in a lot of cases, you can make the distinctions and make the right decisions in the first place as to which frameworks you want to use because your problem set and the way that you are going to approach this particular application matches up better with MVP over MVC. 

ADDY: Exactly. 

CHUCK: And so, you know, it works both ways; both in the decision on which one to use and then later on in how you use it and how you can possible take advantage of some of the features that it has or doesn’t have based on that design or the design pattern. 

ADDY: Exactly. 

CHUCK: So one other pattern that I think we see a lot in JavaScript that I don’t know that many people really even think a lot about is the Observer Pattern. And so the Observer Pattern from what I understand is basically you have something that’s publishing events or you know, events is fine and then you have something else that kind of captures those events and then reacts to it in some way. 

ADDY: Essentially, yeah you are right. The Observer Pattern is all about sort of having subscribers that watch other objects we call publishers and we provide a means for subscribers and publishers to have this relationship where whenever something interesting happens in your application, your subscribers can go and react based on that. And the reason you do any of these stuff is to try decoupling your application further. So one problem that developers regularly have these days is they’ll build things in a way where every part of their application is speaking directly to another part. So you might have multiple modules that are responsible for a variety of different things. And so you’ll say, “Okay I'm going to have the module response for you know, I guess composing how a shopping cart is going to look. How a shopping basket is going to look on the screen,” is being directly tied to a module that perhaps deals with currency or something like that. That’s a really, really bad example but let’s imagine two modules directly communicating with each other. The problem there is that when I go and I want to start building parallel applications, I'm going to perhaps run into an issue where I'm building the exact same logic multiple times over rather than reusing the work that I’ve previously done. And instead of you building things in a way, where you know, every single module is speaking to another module directly, using the observer pattern, can be really, really useful because it just means that you’re broadcasting out events of interest and other parts of your page or application is going to react to that. And this is also useful because you can build your application in ways using the observer, so that it could be even I guess fail safe or fail proof because other parts of your application might not necessarily I guess crash if you know, someone isn’t directly touching them. I guess an example of that is… let me think… so let’s say we have a mail application and you are going to have a few different views of this; you are going to have composer view, you are going to have inbox, you are going to have contacts and so on and so forth. Using the Observer Pattern can mean that even if one part of your application crashes, let’s say that you know, something that controls pulling in the messages crashes, because I'm just going to be broadcasting events saying, “Okay there are new messages that are now available. Someone has triggered an action to create a new composition window or there's a new notification for new message having arrived.” I can actually build my system to be reactive so that none of the other code responsible for stuff even gets touched if that part falls over. I don't know if I'm explaining that as well as I could be. 

JOACHIM: Another example could that if you are dynamically loading in widgets. So you are loading in widgets later on that might be showing a different kind of interface to the basic models that you have. So you can basically load in all kinds of widgets later on independently to each other. 

ADDY: Yup. Exactly. But the whole idea with the Observer Pattern is really just to make sure that your system is as free from, I guess, coupled connections as possible. 

CHUCK: Now, I have a question about this with regards to JavaScript. Because it seems like most of the JavaScript engines in browsers and in Node.js and others like it already have an event loop that behaves somewhat like an Observer Pattern. Or kind of a backward observer pattern I guess where they throw an event out and then anything’s that’s… well, no its observer pattern because anything that’s subscribed to that event will then fire off. So is this something that’s inherent to the language or am I kind of misunderstanding and missing the point? 

ADDY: I don’t think it’s something that’s inherent to the language, but you will find in most environments that there is some need to have a

decoupled way of communicating and broadcasting. It’s not necessarily always referred to implicitly as you know, the observer pattern or the publish-subscribe pattern. But you know, if we took jQuery for example, I know that not everybody on the call likes jQuery… 

JAMISON: [Laughs] You can just say, “Joachim”. 

ADDY: [Chuckles] So quite a few versions ago, we actually had this concept of having custom events in jQuery where you could have sort of you could bind something and you could trigger actions etc. and whilst we didn’t explicitly say that that was the observer pattern or that was a publish-subscribe implementation, it effectively could have been used for that. And Ben Alman who’s a really, really popular plugin writer in the jQuery community actually just created a nice wrapper around that. Because even though that particular library didn’t say, you know, we have we support pubsub, it’s possible to use existing event systems in many cases to either simulate that behavior or do something very, very similar to it. 

CHUCK: Yeah that makes sense. All right. Well we are running out of time. We did get a question on Twitter. It looks like it was from Chris Smith. Is that the one that you were going to read, Jamison? JAMISON: Yeah that was the one that I was thinking about. 

CHUCK: It’s not related to design patterns but we’ll ask. 

JAMISON: Yeah he is asking why do you favor AMD Require.js? Is it just real world needs or just the belief that it makes sense? It sounds like it is like because it’s just practically the best thing after right now or because you think it’s the best thing overall. 

ADDY: So let me flip backwards. Is he trying to say why do I prefer AMD over common.js for example or why do I use AMD at all? 

JAMISON: Over common.js because I think you have to use some kind of script like dependency resolution thing. I just hate the require everything in global scope and figure out… 

ADDY: Absolutely. I mean, my modern module formats, even though you know, some people would say that their interim standards really do help us a lot and I love that they get rid of the global issues and the name spacing issues and dependency and stuff like that. So the reason why I love AMD is A. dependency management; it’s really, really useful for that, even if you are just talking about sort of on page load or you are talking about dynamic dependency resolution. I think someone mentioned the idea of dynamically pouring in content when a user needs it, which a number of large applications do these days. And it makes it extremely trivial to handle things that way. It handles the synchronous loading really, really well. It’s used by a number of major libraries like Dojo, jQuery, Moo tools, runs well on the browser, has plugin support, you can sort of export AMD, exports of AMD can be of any format. You can have like objects, you can have JSON functions, numbers, anything you want. And I like that it’s somewhat compatible with ECMAScript next to ECMAScript Harmony using translation tools. I like AMD for all those reasons and more. Common.js is a nice alternative to other people like you don’t have the same define wrapper to worry about. But I sometimes feel that the Common.js works better on the server than it does in the browser and you know, although both of them do translate to Harmony, I just prefer AMD. 

CHUCK: All right. Cool. We are out of time, so let’s go ahead and get into the picks. Did we warn you about the picks, Addy? 

ADDY: No. no you didn’t. 

JAMISON: Surprise! [Laughter] 

CHUCK: So I'm really trying to get better about that. But anyway, so basically, the idea is we just pick things that we like or enjoy. I mean, we’ve had people pick music, or books or TV shows or movies. We also tend to pick things that help us in programming; so you know, we’ve picked tools and IDEs and what have you. So feel free to just think about those kinds of things. And we'll make Jamison start off so you can kind of get an idea of how this works. 

JAMISON: All right. So my first pick is Prismatic. It’s as app that does a bunch of like social network analysis, machine learning and natural language processing to basically recommend interesting articles to you. And I think there’s been some other stuff like this before but Prismatic has been far the best tool I’ve ever seen as far as signal to noise ratio and actually getting things that I’m interested in. I think it’s in beta, which means you might need an invite, but I just like signed up for it and got in. So maybe it’s more open now. My other pick is a Vim plugin called Vim-coffee-script. Starting to do a lot of CoffeeScript development and one of my complaints with CoffeeScript was that you are debugging in a different language than you are writing in, but it kind of helps alleviate that problem because you can highlight a section of CoffeeScript code and with a command, just compile it in to the JavaScript that it creates, so that you can kind of debug stuff. And it has a bunch of other nice features for that as well. And I’ll do one more. It’s an eBook called Coders at Work. It’s a bunch of interviews with great minds in software development and Computer Science. And it’s kind of leaned a little bit more towards the old guard kind of people from the 80s and 90s and earlier. And it’s just really cool. There were a lot of people in it that I had never heard of, but it turns out they are incredibly influential in things that I use day to day. It’s just a really good read about people solving technical problem and doing interesting stuff. One more pick -- Udacity. It’s one of these online course thing that was started up by Stanford. I got my sister and my dad to sign up for the CS101 class, which is awesome. I’m trying to turn them into nerds. 

CHUCK: [Laughs] Nerd converter huh? All right, Joachim what are your picks? 

JOACHIM: I’m going to pick Plos1. It’s now the largest scientific journal. And it’s open access; this basically means that people can go in and read stuff and I've been spending more time than I should on that and that’s why it’s my only pick. 

JAMISON: [Laughs] 

CHUCK: All right. I'll go ahead and jump in and go next. So I’m going to do a couple of picks basically just right off of my browser here. The first one is I have an Amazon Wish list. 

JAMISON: Oh you can’t pick your wish list, Chuck. 

CHUCK: No, I'm just saying I have this plug in, okay? And it makes it nice for me to add stuff for my wish list, but the thing that I really love about Amazon is Amazon Prime. Basically what you get out of that, I haven’t tried getting the free access to the videos, but I guess you get free access to several videos. You also get access to the lending library for certain eBooks, but the big thing is that you get your shipping for free. And I’ll tell you, I have already earned back what I spent on Amazon Prime with the free shipping; just ordering equipment for producing the audio shows and things like that, along with a whole bunch of other junks that I didn’t need to buy. So Amazon Prime is definitely a pick. One other one that I have here is a Color Picker. It’s an eye dropper tool. I'll actually put a link on the show notes, but basically if you click on it, then you can click anywhere else in your browser and it will give you back the hex number for the color. So I’ll just put that in here as well. The other one that I have that I really like is LastPass. I know a lot of people use One Password and used that one a while ago and I don’t know why but it just didn’t work for me the way that I wanted it to but LastPass really does. It’s nice too because I can actually share my passwords with my virtual assistant and then he can go ahead and do things like post podcast episodes. And you know, log in to the websites and things like that that I got up. So it really pays off that way and I really, really dig it. So those are my picks. Addy, do you have any? 

ADDY: Yeah. So I've got a few picks. The first one is something that might have been shared on the show before, I’m not sure. It’s Idiomatic.js by Rick Waldron. It’s essentially an up-to-date JavaScript style guide if you want to write sort of consistent idiomatic sensible JavaScript. And I recommend everybody check it out. It’s something that I’m trying to sort of update all of my current projects to follow. It’s really, really is useful. My next pick is… 

JAMISON: What can you say about semi-colon? 

ADDY: Don’t start. [Laughter] 

CHUCK: Comma first, right? 

JAMISON: Yeah, it’s great. 

ADDY: We’ve had enough about semi colons today. The next one is a project called Pulley. My friend Sindre Sorhus and John Resig sort of been updating this project. And the idea behind Pulley is that it’s a really easy to use GitHub pull request lander, and it makes it easy to avoid sort of messing up pull requests and ending up in like a messy commit stream, where you’ve got ticket trackers that don’t automatically close tickets and all that stuff. But it can squash all of the code for a pull request into a single commit, which can just make it a little bit easier to read, but they’ve just released a brand new version like I think an hour ago. So it’s useful to put that out there. My last recommendation is a project Code Painter. And the idea behind Code Painter is that it can help you define like a JavaScript style guide that you then force or sort of use to lint a piece of code. So if you write a style guide and you wanna make sure that whatever code you are committing to a project is following that style guide, Code Painter can be useful for that. It’s an idea, like the whole idea of code Linting is something like JavaScript style linting is something that a few different people are looking that up in the moment. Anton Kovalyov (sorry I can never pronounce his last name) but he’s the guy behind JSHint and he is currently looking at ways of implementing this idea in the next version of JSHint, so that should be pretty interesting. And there are few other people that are looking at ways of making a concept of JavaScript a little easier including ---- So yeah that’s it for my recommendation. 

CHUCK: All right. Cool. It looks like AJ had a few picks too. He’s picking Steve Jobs: One Last Thing and Pirates of the Silicon Valley. And anyway, it looks like you can watch them for free if you have Amazon Prime or on YouTube. So, anyway, with that, we'll go ahead and wrap up. And just wanna thank you again Addy for coming on the show. 

JAMISON: Thank you. This was awesome. 

CHUCK: We are talking about doing a Book Club, so keep an ear out for that and over the next few weeks… let me pull up my list here, one person that -- if you are interested in MVVM -- that we are going to be talking to in a few weeks is Steven Sanderson from Knockout.js. So if you want to hear more about that, then we are going to be talking to him on the 8th of May. We are also going to be talking to Chris from ComponentOne. They have a tool called Wijmo and its using the SVG libraries for JavaScript. And so, we are going to be talking to him on the 1st. Next week it doesn’t look like we are going to be doing an episode. I’m going to be out of town, Yehuda is going to be out of town. And we just have lined up a good way to get this recorded so, you know, we are going to skip next week and we'll catch you the week after that. So, anyway thanks for listening and we'll look forward to talking with you again.