013 JSJ Knockout.js with Steven Sanderson

Download MP3





YEHUDA: See, if you caught it off right at the simple case, then the simple frameworks are going to look really awesome because they don’t do anything and there is nothing going on, right? CHUCK: [Laughs] CHUCK: Hey everybody and welcome to Episode 13 of the JavaScript Jabber Podcast. This week on our panel, we have Jamison Dance. JAMISON: Hi! I'm Jamison Dance. I work as a software developer in ITV in Utah and we are hiring JavaScript developers. CHUCK: Awesome. We also have AJ O’Neal. AJ: Hello there. I work at SpotterRF and we are ALSO hiring JavaScript developers. JAMISON: (Oooh, now it’s a battle.) CHUCK: Did you have somebody leave recently? AJ: Yeah Jamison leave room for us. CHUCK: We also have Yehuda Katz. YEHUDA: Hey it’s Yehuda. I work on JavaScript at Tilde and I am back! CHUCK: I am Charles Max Wood from teachmetocode.com and this week we have a special guest and that is Steven Sanderson from the KnockoutJS team. STEVEN: Hey. Yes I am Steve. I am a developer. I’ve lived and worked in the UK and currently I'm working for Microsoft. And I don’t work in recruitment but obviously the others are hiring. I work in the team that produces lots of different web technologies and various things like that. CHUCK: So I'm the only one that is not hiring? I guess Yehuda didn't say that they were hiring either. YEHUDA: We are not hiring unfortunately at the moment. We are a very small company with limited resources. CHUCK: Great. Yeah, I can definitely identify with that. I am trying to get hired more. Anyway, this week we are going to be talking about KnockoutJS. We actually have quite a few people asking us to talk about it and we figured who better to bring to the show than somebody who actually works on it on a day to day basis. So Steven, do you want to kind of explain the basic concepts that make KnockoutJS work and then we can start talking about what we like and what we don’t? STEVEN: Well, to set scene, Knockout is one of the Model-View type libraries for JavaScript. So it’s a library for building very rich, dynamic user interfaces with a clean architecture behind of it. And in Knockout’s case, the recommended pattern is Model-View-ViewModel, and that’s a little different from Model-View-Controller or Model-View-Presenter which more people are probably more familiar with. (I can describe what the difference is if you are interested). Knockout, also on top of the MVVM stuff, brings some additional features of its own to where the object and declarative bindings and there are things like “automatic dependency tracking” that I can get into, what they are and how they work if you are interested. CHUCK: So, Model-View-ViewModel, (if I remember right from our discussion with Addy) is basically, it felt to me kind of like Model-View-Presenter, where you have a View-Model that holds all the data and behaviour for the view? STEVEN: Yeah, there is some similarity there. So, probably the easier way to understand this (and I'm going to completely steal this description from a friend of mine called Rob Eisenberg) is to imagine a scale, like a spectrum. So at one extreme end, would be Model-View-Controller and that would be the stateless end. So when I talk about MVC right now, I'm talking about the kind of web flavour that are from things like Rails and in that kind of model, the controller is something that's processing request, doing some stuff and then emitting some view mark up. And itself is not actually holding any state. So, that state is some model somewhere. And then in the middle of the spectrum, would be a Model-View-Presenter (that you just mentioned) and on the far right or far left, whatever would be “MVVM” which is the most statefull of these kind of patterns. (Firstly, there is no difference between the model view part of any of these. You can sort of forget that.) So the difference that you need to think about is between Controller, Presenter and the View-Model. So Controller, like I just said, the way we think of it on most about web technologies are stateless and the View-Model, is fully statefull. So the ViewModel represents what’s happening in the user interface. It represents both the data that’s in there and also the behaviours that might be on it. So if you got a button, let’s say does something. Then the logic for what that button does will be in the view model back and that's holding all its data. It’s completely independent from the view; it doesn’t even have a reference to the view. And it just gives you a sort of clean model to write code about what happens in the UI And then the Presenter, would be similar in between these two. So a Presenter probably holds a bit of state itself to do what is going on in the view. But most of the state there would be actually kept within the view. So if you’ve got some sort of rich UI widgeting type system and your Presenter is just kind of tweaking on controls then that would be MVP, (as distinguished from MVVM) where it’s not really about rich widgets and controls, it’s more about ViewModel holding a module of what is going on and then having some kind of framework where you are binding that onto the view. I know that’s not stunningly clear, but this is subject to difference really along that scale. YEHUDA: Would you say that the ViewModel is similar to the View object itself in Cocoa? STEVEN: I would love to give you a good answer to that question, but I have never developed in Cocoa. I can just take a guess based on a UI technology that I have worked with. If in Cocoa, you’ve got widgets that hold some data like, so you got a list control the host data for what are to be shown on that list. In that case, that would be in MVVM terms of a view and you’d separately form that have a ViewModel which represents the fact that there is a list of some data. And then you have framework component that binds that ViewModel onto that list control. So therefore as a developer, you primary write operations against the ViewModel and don’t have to think about any of the Cocoa widgets because you just know that the framework will update them automatically. Does that make sense? YEHUDA: Yeah, I think that is probably more like a View-Controller in Cocoa, yeah. STEVEN: Okay. CHUCK: So one of the things that you talked about was the data binding. You said that its declarative data binding? What do you mean by that? STEVEN: Yeah. So if you think about how HTML looks, obviously you’ve got some sort of tags, angled brackets and stuff like that. And then let’s say you have a textbox. So you’ve got input= “whatever” and things like that. The way Knockout does declarative bindings is that it uses a custom attribute called “data-bind”. So that’s the data namespace from it. And the value inside the data-bind attribute is a piece of JavaScript object literal, but without the curly braces on both ends. And that’s something that Knockout can evaluate in order to find what stuff you want to bind on to that DOM element. So let’s say you got “data-bind=text: (some value for my ViewModel)” then Knockout will evaluate that and it will find out if that you want to bind a particular value from that ViewModel to that textbox and it will do so in a bidirectional way. So if you change the value on the ViewModel, then the textbox will update and vice versa. So that is probably the most simple and obvious kind of binding but most sophisticated than that, I think it is like “control flow bindings”. Where you can have something like an “if” binding or “for each” binding and that would cause part of your mark-up to appear or disappear depending on the value in the ViewModel or it will cause repetition in the case of for each. So you can set up something that is very much like templating that will give you the same powers as normal templating but just purely expressed in terms of your DOM. CHUCK: Okay. I know that some of the other panellists had a reaction to the way that the binding is declared in the HTML. JAMISON: [Chuckles] I don’t know, I think it’s just from being trained for so long to not put logic in the view and then it kind of feels like “logic in the view”. But I played with the tutorial a little bit last night and I actually really liked it. It almost feels like more of a tooling problem than a design problem, because I mean in the GUI architectures like Cocoa, you have the same type of binding sort of and you can do them declaratively. But you also have interface builder that takes care of all of it behind the scenes. Have you guys done anything with tooling to kind of help you declare your bindings automatically? STEVEN: That's a very interesting point. So, there are two aspects of that; one is, is this a good to be doing and what are the pros and cons and the other is what can we do in tooling for that?  In terms of tooling, Knockout doesn’t try to force you down any particular route in terms of items, or text editors or server-side technologies or anything like that. So that does provide unfortunately a bit limitation on what could be offered. So I'm not entirely sure of what is the best way of providing that kind of tooling is. Now there is some talk inside Microsoft, they are doing some stuff in Visual Studio that can help. But I know that is certainly going to help certain percentage of developers of web development because Visual Studio is quite dominating web development at the moment. So there's an open question about that and the answer is we don’t have a particular plan, so that is something that the community could contribute with. There is a strong need for it. My personal experience with that, I don’t really feel the loss of tooling because I tend to feel very clear-minded of my ViewModel and ---  but what I can do at that time is quite natural to me to know what stuff I can bind to other stuff but obviously I appreciate that slightly unusual position of having what worked with us a couple of years now but of not being alone out there. JAMISON: So what is Microsoft’s relation to Knockout? I mean, do the people that work on Knockout also work at Microsoft or it sponsored or what? STEVEN: Yeah good question. I'm the only person at Microsoft that has got any sort of personal relation with Knockout. But it is a purely open source project. I created it before I started at Microsoft and it hasn’t been sort of acquired or anything like that. It is still a community project. It’s agnostic to your server side technology. It’s equally applicable to Rails or anything else as it is for Microsoft technologies. As for Microsoft’s interest in that, it does fit very well with MVC and so MVC team at Microsoft decided that they want to ship it as part of MVC. That wasn’t my decision but I’m completely happy with that. So that's something that happens now. But Microsoft doesn’t own it or control what is going to happen there. But yeah it’s just good to have a bit of support for the developing that and exposure to a whole set of developers-- [Crosstalk] JAMISON: There you get kind of built-in user base. That's cool. CHUCK: I wanna jump in here real quick because I am looking at the example on the website that has the ticket class and I have to say, one thing I do like about the data bindings is that it’s pretty clear (to me at least), that you can look at it and you can see it binds this and it does these kinds of things. I have this kind of deep down reaction looking at the configuration sort of set up there. It looks sort of like a JavaScript object, STEVEN: (It is.) CHUCK: But at the same time, part of me is going, “They must be evaling that.” And that kind of makes me cringe, even though I'm sure you guys are being careful about that. It’s just kind of… I have a reaction to that. But I do really like that it is explicitly stated on the DOM elements what you are binding it to and what they are going to be looking at. I think that is really kind of neat because then all you have to do is look at the HTML code and you know what you are getting. STEVEN: That is precisely the thing. So the experience that lead to this design was building a fairly large single-page application using a technology called “Reactive Extensions for JavaScript” which is a kind of event-based programming model. And I was spending a ton of my time setting up the sort of mappings between different parts of this reactive model and the user interface. And the requirements for the software continue evolving; it just forms a continuous burden to keep these two things up-to-date and in-sync. And it’s by switching to a declarative model that the information about what a given DOM element does it exists in exactly one place. You never have to go off to some other place to try and figure out what's going to happen. And if you want to refactor UI some way by moving some elements from one place to another, you don’t have to think like, “Is this CSS selectors still going to work?” or “what selectors are trying to reference this element?” or anything like that. There is no consideration like that in your head. You just literally move the mark up in DOM. Some people do prefer having a separate system for defining bindings and that's fine. But there is extensibility in Knockout to that. I don’t personally recommend it but very often, people who are new to Knockout will come along and say, “Hey, I think we should switch to this other way of doing stuff” and we always say, “Well, great. Go and reduce the extensibility mechanism.” But you know, it’s not become particularly popular within the community.  CHUCK: So what are the trade-offs then between maybe declaratively putting it in the DOM versus using some other method of binding DOM elements to your view model? STEVEN: I suppose probably the biggest advantage of not doing the declarative binding but rather doing it procedurally, is that you don’t have this thing about not wanting to put logic in your view. And you mentioned that before and I completely agree with you but you do wanna keep a clear separation of concerns; there are stuff that’s like procedural logic inside your HTML because that's just really confusing-- So with Knockout, the way we do that is to define properties and properties or functions in your view model and encapsulate whatever logic is it that you want and then you can bind that into your view. But sometimes people don’t do that and they slightly abuse the binding system and just put all kinds of junk directly into the bindings. That's not really something that you want. And so I suppose the advantage of doing it procedurally is that you don’t have to make that differentiation, you can just put whatever logic you want into your bindings because it’s not really from the view. YEHUDA: I think probably part of the reason why that happened was that the old Knockout documentation. So right now the Knockout documentation is actually a lot better and doesn’t do crazy stuff but the old Knockout documentation would do stuff like click: and like the inline function. So, I'm sure some people look at that and copied it. STEVEN: Yeah that's a fact. I am to blame for that. JAMISON: We should talk about the documentation though. It’s amazing. They have all kinds of interactive tutorials and I was really impressed by the docs. YEHUDA: Yeah I'm actually jealous of it. [Laughter] AJ: Yeah, I'm actually looking at the tutorial right now. I'm pretty impressed. JAMISON: I mean, I haven’t gotten very far, so I don’t know in depth it gets but at least for a brief introduction it’s great. STEVEN: Cool. Thank you. CHUCK: So how do you find people to do that? STEVEN: To do what?  To write the documentation? CHUCK: Yeah. STEVEN: Well, until probably a year ago, it was just me and then there was a very prolific participant in the mailing list called Ryan, who was just outrageously helpful to everybody and incredibly nice and patient and always giving the right answer to everything, which is just like a dream for someone who creates an open source projects. So I quickly brought him as a co-contributor and now he is involved in particularly the sort of education side of the project; helping people in the mailing list and writing docs and things like that. We do have another co-contributor who came on recently as well but he is more of the code wizard kind of guy. He did write some docs just yesterday but that’s not his focus. And then occasionally when people send us pull requests with an incredibly good pull request, they will come with updates to the doc as well; so that’s always nice when it happens. JAMISON: So did you make a dedicated decision to say, “We are going to have interactive docs.” or did that just kind of evolved because I think that is really cool. STEVEN: That kind of happened because early last year, I spoke in an event with… Well, we didn't mark it off because it was reasonably high profile, so it was quite a cool thing for me to get to connect with all these other people and some other well-known speakers. And so I spend a fair amount of time before that preparing some really snappy demos that would be very impressive. And after I've done all that, I felt, “Oh I got these great demos now but I've got no way of like using them again after I have done this talk. How can I somehow put that on the web? Can I just put video of me doing these demos? Yeah I could, that would be kind of cool, but what would even be cooler would be if people could do the demos themselves and they can step through bit like that and have the same experience.” And so from that, I’ve always had this idea of having interactive programing examples. It only took a couple of weeks to build the site. Obviously it’s built with Knockout and it’s was quite a nice experience to me actually because although I’ve created Knockout, I did not have any active projects at that time that we are using it because you know, it’s just working on some other stuff. So it was quite nice to be writing some real code that was using that. JAMISON: It turned out great. STEVEN: Thank you. CHUCK: Yeah it looks really nice, the interactive tutorial. YEHUDA: Yeah, Ember tried to copy it. STEVEN: [Chuckles] YEHUDA: I guess we were going to do a few things differently, but it actually turns out to be pretty tricky to do well. There's just a lot of little details to me. I think we will probably eventually have something good but I would agree that it will probably take a few weeks of dedicated work to get it done and we just never have that. But it’s really awesome. JAMISON: Maybe you could use Knockout to power your Ember docs. [Laughter] YEHUDA: I don’t think that is our problem, but— [Laughter] STEVEN: One benefit that these particular examples have is that they don’t really involve server but they are very, very superficial work and that makes it so much easier to code something like this. CHUCK: What back end technologies are you aware that people are using behind Knockout to provide it with data? STEVEN: Well there's certainly a bias towards the Microsoft stacks because of my background and the fact that I've got a lot of involvement in the Microsoft communities, and so within the MVC which dominate in quite a long way. But besides that, I'm aware of people using pretty much everything else I have heard of. Certainly things like Rails is quite common and popular. I'm aware that increasing people having Node back-ends with kind of Restful services and  then they’ve got that client side code that’s just effectively static file served by the server talking to the REST services that's getting quite popular. And also interestingly, probably the most interesting thing at the moment is the back-end as a service type thing. So you know things like parse and stackmob that are providing the Restful backend that’s just about rich enough that you can then write pure JavaScript and HTML that will talk to this backend and produce a very nice rich app without having to get into sort of database management stuff. So that's really cool. But also, anything else you have heard of. There's probably enough people using it now; somebody out there is doing that. A couple that I will point out actually, this plug-in that a guy in the community created called “Knockout Live” and that allows you to connect Knockout view models with models that exist within a Node server and it uses web sockets or some other transport to continually synchronize what’s happening in the client with what is happening in the server. So you can have multiple clients connected to the same server that are collaboratively editing some data and you can see that as one browser window is making some edits on a data that continually showing up in the other browser window and vice versa; so that is very nice. I just got some email the other day from someone that created Knockout support for the Meteor Web Development Framework. So that is sort of potential next generation kind of framework that doesn’t differentiate between server and the client. So, you write the same code and it sort of migrates between the server and the client, which is really interesting. JAMISON: There are all kinds of weird puns you can get into with “Knockout Meteor.” STEVEN: [Chuckles] Definitely. CHUCK: [Laughs] So I'm a little curious (and I'm sure that Yehuda has some input on this too)  because we were talking about it before the show actually with the TodoMVC and how interesting it was that ToDo has kind of become the default for demonstrating these frameworks. And-- [Crosstalk] JAMISON: People have lots to-do, Chuck. Come on. [Laughter] CHUCK: Yeah, somebody should write “Yet another Todo App” or something. Anyway, so I'm a little curious -- because it seemed like both of you said that it wasn’t the best way to show off your particular frameworks -- what sort of application would you put up to show off what Knockout can really do? STEVEN: Okay, good question. Well, it’s a difficult trade off isn’t it? When you are doing something educational between accessibility and just awesomeness. As opposed to write examples specifically chosen to be accessible and there isn’t a sophisticated demand that you have to understand, it’s just literally editing a list of stuff that’s barely even in validation. I don’t even know if it has validation. So you know, that’s got its benefits. If you wanted to have the most awe-inspiring app that is built on Knockout, I suppose you will build something… I don’t know, suppose something like Gmail would be quite a good example because you know, it has lots of different lists that you can navigate around that’s got all kinds of search support and ability, stuff like config screens that you can navigate between tabs and you can build all the sort of different requirements with validations and asynchronous operations that are going on in the background and so on. So I think a mail client would be a pretty good example. In fact there's a sort of very, very basic email client example on the interactive tutorials, but that’s just navigating between a few lists. But yeah, that would be a cool one. CHUCK: We’ll have Jamison code that up and get it to you next week. [Laughter] YEHUDA: For me, I just wanna say why I think the Todo example is not so good. Todo example was designed basically as a demo of Backbone and it’s a really good fit for Backbone because Backbone is relatively simple in terms of the facility they provide and the demo is simple. And then you go and you take that example and you take something like Ember or Knockout and in fact, there is less code in Ember or Knockout obviously or we will not be doing our job, but it also it is the case that it’s not really showing off any functionality that either of those frameworks has above Backbone because the demo itself was designed for Backbone. So that’s why I think it’s a poor… It’s a really good demo for simple frameworks that don’t provide a lot of facilities and it’s a poor demo for showing why frameworks that provide a lot of extra facilities are better. STEVEN: Yeah, great. It’s also a good demo for frameworks that are specifically designed for doing that demo. [Laughter] CHUCK: Isn’t that always true though? You provide a set of benchmarks and then everybody designs toward those benchmarks? STEVEN: [Chuckles] Yeah. YEHUDA: I mean honestly, we spent some time looking at what things about Ember made that demo not great and I think at some point we were just like, “Okay, so we have optimized our..” So there were things like for example, like the ability to have computer properties that know about lot of… arrays basically… and this is useful and it provides value, but at some point, like you run out of obvious wins and you can keep optimizing it or you can move into like actual real apps that people are building. CHUCK: Yeah, I think one thing that I can say for the To-do MVC is that if you look at it, you can at least kind of get an idea of how the frameworks work (at least at a basic level) and some of the APIs that are provided by the frameworks. But yeah, it doesn’t fully showcase what it is capable of and what other instances it might be a better fit to use one of these more powerful frameworks. YEHUDA: I think in particular, the fact that… so Backbone has a very simple data model; it has basically models and views and if you have more things than that, you end up in the situation with the Todo demo or where it is very hard to actually showcase the extra things because there is no place to put them. And if you did use them, it will be like, “Oh look, their over engineering creates this stuff.” CHUCK: Mh-hm. One other thing that I wanted to bring up is that in the demo and stuff that I’ve looked at so far, I didn't see anything that took me back to a persistence layer at all. How does that work? Is there just a built-in mechanism that I missed? STEVEN: No, you didn't miss anything. Knockout is targeting a specific segment of web developing you have to do and that particular segment is not including data persistence in Knockout’s case. So, the idea is to be agnostic to what we are doing now. And the reason behind that is that, the focus to the project has always been since it was originally created on building extremely rich UIs basically. So my own personal background is that I’ve worked on a bunch of projects that were consumer facing as opposed to your sort of internet type admin apps. Typically, the sort of demand in that is to make things really, really shiny. So if it needs to move around with the right kind of animations and things need to appear and disappear and have all kinds of nesting and things like that. So, that kind of like, deep richness in the UI has been the focus and the actual data access aspect of it, we decided to keep as a separate thing. So there are various different plugins for Knockout that will provide different kinds of data access mechanisms. Or if you don’t wanna use any of those, you can just fall back to something truly basic like $.ajax. But examples of things you can use are Knockout mapping plugin, which knows how to take all the data that you might get on the server and sort of upgrade it to the Knockout ViewModel or do the reverse. There’s the Knockout Live plugin that I’ve mentioned before which synchronizes Knockout data with the stuff that is going on in memory in the Node server. There’s Knockout Meteor I mentioned as well, that’s extremely nice. One interesting one that I very much doubt that everybody has heard of yet, is actually from Microsoft a library called “Upshot.js”, which is a sort of standalone data access mechanism for JavaScript. It knows how to talk to arbitrary Rest end points to fetch entities on demand and it caches those entities in memory so it didn't have to keep going to the server even more often that it should. It understands relations in a very deep way. It comes out of the team that has got a background in SQL server, so obviously there is immensely rich kind of relational data modelling type support. It knows exactly how to deal with like if you move stuff from one collection and move in into other collection and what the server needs to know to update all, and things like that. So its stuff like validation and then it just change tracking. So as you Knockout UIs, or any other type of UI modifies that data, it is keeping track of the changes you have made then you can either revert or synchronize those to the server. And it has a protocol for with dealing with validation errors that might come back from the server, so you can then then reflect those up in your UI. But yeah very few people have heard of Upshot.js yet. But yeah, that’s just one kind of layering that you can use. CHUCK: Okay. (I'm trying to make someone else ask a question.) STEVE: [Chuckles] JAMISON: I wanna ask a question. (We kind of talked about this already, but I think it will be important to go to). So I mentioned how it feels weird to put stuff that feels like logic in the view and Yehuda in the chat was saying that for front-end interactive apps, that’s not actually as bad of an idea as it is for server-side stuff. So I’d like to hear your guys’ thoughts on that. Why is it not applied as much? STEVEN: Well I would have to give a balanced answer to that which would be, I still wouldn’t recommend putting a ton of logic in the view. So, even though Knockout has a dynamic binding mechanism that will allow arbitrary logic, like there is nothing to stop you, it’s still going to get potentially overwhelming and repetitious if you have bits of business logic inside your views that you don’t copy and paste within different views with no reasonable kind of reviews. I still wouldn’t really recommend that, just because of the loss of separation of concerns. But to some extent, simple logic like let’s say, I want to display something if there are more than four items in the list. Well maybe the number four is something that you really need to factor out into like a constant or something like that. But simply having the logic of “show this if it’s more than that number” is probably completely reasonable to put inside your view because it is a view concern. It’s part of the view logic code should be shown if this particular condition is met, so I think that is okay. But it’s still remains up for the developer to choose what level of logic that they are comfortable with. And if a developer says, “I don’t want to have the effects as greater than logic in my view,” then of the Knockout solution to that would be to have a computer property that is Boolean property and it returns true or false based on whether or not a given thing should be showing based on that comparison and then you bind that up to your view instead of the comparison. YEHUDA: I think it’s important to remember that before unobstrusive JavaScript, there was that on onClick=function() and that was it. People were evangelising unobtrusive JavaScript, they were doing that because they were like, “This is craziness. You have a giant HTML file that just has only has logic in it. Please get this logic out.” And in addition to that, you had cases where for example you had ad bar with had like ten links in it and people are doing things like “onClick=” on each link. And it was like, “This is clearly wrong. You should move this logic out.” But I think when you are looking at a JavaScript MVC framework, there is a more position because you have a lot more tools for factoring out logic. So, in Ember for example, we actually just made the decision for you. You cannot put arbitrary snippets of JavaScript. You have to move the Boolean into the view object, but it’s still is sensible to be able to say in your mark up like “Hey, only show this section if this Boolean is true.” And you still get the benefit of, if that’s part of a larger usable component, you still get the benefit of having that Boolean be factored out. But basically, (for me anyway) the idea that it has to be 100% you have to take all of your logic and go, “Let me find this thing by selector and say that if it is here, you do this. Let me bind to this thing and then go show it or hide it”, when you can actually have it be declarative -- for me feels like overkill. CHUCK: Yeah that makes sense. I do like the idea that you are pointing out to where, don’t use the anonymous functions if you can obstruct the logic somewhere else. Does Knockout actually allow you to put anonymous functions in your “data-bind”? STEVEN: It’s not going to stop you but, everybody would just sort of let you if they saw you doing that. CHUCK: Kittens will die. Is that what you’re saying? STEVEN: Yeah, I mean it’s a sort of all programming systems have got things you can do that you don’t want to really do. And it’s just the case of these bindings can be arbitrary and so we let them be arbitrary because it’s up to the developer to be mature. I know in the end Yehuda has explained there's a system to stopping that from happening, that’s a completely reasonable perspective too. In Knockout, we just happen to make with the --- we’ll leave it out the developer. But really, the best result is that you shouldn't be putting in line of function that is ---. YEHUDA: To be honest, I don’t actually care. I just cared before that it was in the documentation. STEVEN: Yeah I think there were a handful of case in the Knockout doc’s in version one where we did have them in line --- just because it would reduce the amount of code by three lines or something like that. And for people who this is the first five minutes that they’ve ever looked on Knockout would be trying to reduce it the absolute minimum number of concepts and that was the way it went in version one. But yeah, so much feedback that that is the wrong words and we totally changed that. CHUCK: Right. [Overlapping talk] -- be careful how you use it. AJ: I'm a little confused. So originally, (I think it was Jamison who said something about something here is supposed to be analogous to an onClick handler, right?). I don’t see anything here that looks analogous to onClick handler to me. You use data-bind and looks like you parse the value that you put out of there but that doesn’t look too terrible to me. It looks clean. It’s not like you got onClick=”function()” and then a 50-line function in there or anything. [Chuckles] STEVEN: No. It’s just setting up the logic. If you use a click handler that said, “data-bind=click: function()” (some function that’s from the View Model) and that’s it. That's the full extent of what we have done. And conceptually, you have just associated at that DOM element with some functionality in the View Model. That’s all it is. It is supposed to be a binding; it’s binding two things together as opposed to being a place where your logic goes. CHUCK: So one other thing that I see here that is a little bit concerning with data-bind is that you could conceivably have several options that you are defining in data-bind. How do you keep that neatly organized? I mean, I can see here that you kind of put a new line between each of the options. Is that generally a good way to go or I mean, what if you have like fifteen or sixteen different options on there? Are you doing something wrong? STEVEN: [Chuckles] You probably are. I’ve never seen a situation where someone’s had fifteen different bindings on a single DOM element. Even the example on the homepage that you mentioned, which is called one binding has four separate components to it. That’s pretty much an extreme case and it’s kind of a weird quirk that’s ended upon the homepage. I've probably have never seen a case with more than something like four bindings on a single DOM element because the bindings are pretty high level thing you know, like the options binding; pretty much is doing a lot in saying, “I want to keep the contents of this element in sync with this other array.” It’s doing a lot of things in just a few characters there, so having to combine a lot of them together would be extremely abnormal. CHUCK: Another question I have looking at this example, (for those of you who are trying to follow along, if you go to KnockoutJS.com I'm looking at the source code in the example). The other thing I noticed is that you do have “options:tickets” and that binds it then to the tickets array in the tickets view model that you've bound to this element up here. I guess the question is then why don’t you go ahead and initialize the options inside of the “select” tag? STEVEN : I'm not sure I quite follow that. What do you mean by initialize? CHUCK: So why don’t you just have option tags inside of the select tag? YEHUDA: You will typically not have that information. Like you will typically be getting that information from the server or something like that. CHUCK: Okay. That makes sense. STEVEN: A different way you could do this, (I'm not sure if this is what we are getting at) is that you could have a select tag that doesn’t have any options binding on it and then inside that, you could have a for each binding and inside that, you can have options tag.   YEHUDA: I think what he was getting at is he was thinking about the progressive -- approach. He is thinking, “Why does the server just not put the options in there as the starting data?” STEVEN: Oh, is that the case? CHUCK: Yeah. STEVEN: Alright. So typically, with a single page application you are probably just serving something like HTML that’s not really been processed in any significant way by the server and which is fantastic performance because you know, just service straight out of engine x or whatever would basically know server code when you are around it. It’s fully cacheable; it goes on to cdns without any sort of considerations to use a specific state or anything like that. So the phenomenal speed of getting the stuff into the browser and then from there, the browser is going to do all the hard work by taking the raw data and binding all that on to the DOM and producing that kind of running application. CHUCK: So, basically what you are saying is that you provide sort of a lay out that you are binding your data to and then because of all of that, the only assets that are dynamic are the ones where you are going to the server and retrieving the data; otherwise, you are serving static assets which is really, really fast. STEVEN: Yeah. That's not the only way to do it but it’s very beneficial one. It’s really nice. It’s all conceptual, simplicity of it. You probably got some design that you are working. Got some designers who are producing this static HTML files and then all the developer is having to do is sprinkle a little bit data-bind attributes on that and then you’ve got some separate backend developers who are producing super performant Restful services and then all the stuff sort of composes together nicely into a finished application. CHUCK: That makes a lot of sense. I really like that approach. Well, we are getting pretty close to picks. Does anyone else have any questions or thoughts or comments? STEVEN: Can I just point out a few of the things that I think are probably distinctive about Knockout as compared with other compiler things? So this is not sort of attempt to argue that you need to use Knockout as opposed to other things. But just in case people are interested in what this is as compared with everything else. The things that I think are distinctive about it are the DOM-based templating approach. So, although you can use string-based template engines with Knockout, that is not the default and most people will just literally use the DOM as it is with control flow bindings to define the structure of UI. It’s got pros and cons but it’s distinctive and that's all I am trying to say about it. And the other thing about it is the extremely opinionated approach to observability that we have in Knockout, where observables are kind of the first class thing themselves. It’s not just thinking about entities, like whose properties are observable; it’s that the properties themselves are things that are observable. So you can compose an arbitrarily shaped data out of observability. You can nest observables, so you can have an observable that returns a set of things which are themselves are observable, which themselves have got observable sub-components and so on. And so, if you’ve got that bound to a UI then, whichever part of that object graph changes will always update exactly the right part of the UI. You never have to render any part of the UI that wasn’t affected by the change. In terms of the inferring the relations among the object graph, this is all fully automatic. So you don’t have to say, “I've got this computer property that is composed out of these little pieces data.” That’s just pick it out of the runtime automatically. So you might have set on dynamic web-- that uses… you got to compose one property out of set of others maybe situation to go to some structure and then depending on the number of values, going off to some of the data, and depending on those values, going off to some other data or whatever; and Knockout will figure out what the structure dependency is among your graph. So again, when changes just the minimal set of consequence are and then the minimal set of change happen to your view. CHUCK: Oh, that's kind of cool. STEVEN: Yeah, it is. When this sort of first came together, I was very excited about the sort of mathematicality to that. But it does some drawbacks as well to be fair, which is that, when new comers are not familiar with what’s happening, they sometimes don’t quite appreciate that sort of power of that system and try to do things another way and then they can get confused because they are sort of manually trying to track dependencies, which is just something that framework should be doing. But yeah, it does work out very nicely. CHUCK: Anything else anyone wants to add? Alright, we’ll go ahead and get into the picks. I don’t know if I actually warned you about picks. Did I? STEVEN: I’ve heard this podcast before; I'm familiar with the pick. CHUCK: Okay, good deal. So we’ll go ahead and get started. We’ll have Jamison go first. JAMISON: All right. My mic is not muted this week. My first pick is a Twitter account called “wwwtxt” and it’s this guy’s art project where he takes text from the early internet from the 80’s to the mid-90’s and just post it up on Twitter. And it’s really interesting just to see how different people’s attitudes are towards the internet and also kind of how similar they are. It’s really cool, little historical nuggets. I like it a lot. My other pick is a book called “Wool”. It’s by this… (I don’t know that he is like a famous author, so he just publishes it himself as eBooks), but it’s really great post-apocalyptic sci-fi which is one of my favorite genres. “Wool,” so W-O-O-L. I don’t say L’s very well. [Chuckles] CHUCK: We’re from Utah. JAMISON: [Chuckles] Yeah. So there are five of them. He sells them altogether for like $5 as an eBook, they are full length books so there’s a lot of contents and it’s really good. So those are my picks, just two. CHUCK: AJ, what are your picks? AJ: My microphone was muted. JAMISON: Oh, man. AJ: Utah Open Source Conference. I was there this week, all three days. There was a lot of good talks, interesting stuff to learn, great networking with people, making some new friends. And also, if you look at “UTOSC 2012” on YouTube, there’s about 20 videos that are already uploaded for it. JAMISON: You can see AJ, I and Chuck, we all presented there. CHUCK: Yeah. [Chuckles] AJ: That is true. And actually, Jamison I think he is on here and I think Chuck yours is on here. JAMISON: You posted the link to it. I saw it. AJ: Oh, your name is just not showing up when I did the “CTRL+F” to find it, because the text was too long. That’s why. And then talk I did on ARM is on here but the other one, it wasn’t actually on here. CHUCK: That's too bad. Any other picks? STEVEN: Sure, yeah. I have a couple. (Just one that is slightly pretentious, anyway…) JAMISON: Are you going to pick yourself? [Laughter] STEVEN: The first one is actually a cooking book, a recipe book. It’s just fantastic. It’s called “The New Best Recipe Cookbook” and the thing I love about it is that, for every single recipe in the book, they have tried about 30 or 40 other recipes; like 30 different ways of making Triple Chocolate Cookies or something. And then they’ve scientifically done taste tests on all of them and produced what they think is the best possible recipe. And when you read it and they tell you, “If you want the cookies to be slightly softer, you need to use a little more oil because this will cause the protein to expand well” or something like that. They give you all the chemistry. JAMISON: Oh so it’s like for engineers. STEVEN: Yeah exactly. [Chuckles] It’s cooking for really obsessive engineers. AJ: There is actually a talk at Utah Open Source Conference-- STEVEN: Oh fantastic. I got another one, a book called “The Conscious Mind” which is a philosophical book which is really influential. It’s written in the mid 90’s and this guy called David Chalmers who described what he calls “The hard problem of the mind” which is how physical things can be treated conscious. And he describes a system and he is not saying it’s true but it is something that has moved a lot of philosophers on from kind of a physics-based understanding of reality to various different kinds of realistic understandings with the last 15 years. And so I find that interesting. CHUCK: Cool. Yehuda, do you have some picks? YEHUDA: Just one. I think that it’s possible that I was already reading this when I was on last but I don’t know. I’m reading a book called “The Better Angels of Our Nature: Why Violence Has Declined” by Steven Pinker and it’s basically evidence that while we all think violence is going up, up, up, it’s actually been going rather rapidly down. All kinds of violence, wars, torture etc. It’s a pretty long book with a lot of numbers and anthropological information, but I found it interesting just because its seems unassailable in terms of the fact that it seems very contrary to the common perception of the-- CHUCK: So we are just more hyper sensitive or hyper aware of the violence that is occurring? YEHUDA: Yeah. The idea behind the book is that he actually goes through many, many pages just talking about like describing torture and he says, “You see how you are squeamish about that?” It turns out that like 500 years ago, people did that in the public square so you have just gotten more sensitive to it. And in particular, we are less tolerant of violence; therefore the little amount of violence that remains makes us a lot more uncomfortable, therefore we pay more attention to it and think it’s a big deal. CHUCK: Well, I've got a couple of picks. Jamison neglected his duty to give us something to listen to and when I was Rails Conf, David Brady turned on some music and it’s called “Picking On” and it’s actually bluegrass music. But before your turn off the podcast, [chuckles] they actually do covers of famous rock music. So they have a Picking On: U2 which is stupendous. It’s amazing. I also got Picking On: 3 Doors Down, because people kept asking me if the intro to Ruby Rogues was “Kryptonite” by 3 Doors Down -- and it’s not. Anyway, I just totally love what I got so far. So, I may wind up picking up more music off of iTunes. But anyway, they are great albums; really, really, enjoy them. I think that's all I've got this week. Oh, I’ve been reading “Getting Things Done” but I think I picked it before. So, that's it. We’ll go ahead and wrap the show up. Thanks for coming again Steven. STEVEN: Thank you. It’s been fun. I really enjoyed it a lot. I’m looking forward to listening to more episodes of this podcast in the coming weeks or months. CHUCK: Cool. If you are wondering where the episode from the last week was, we had a little bit of a recording snafu and so it is not available. We are going to be rerecording it next week. So, just keep an ear out for that. And we will catch you all next week!

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.