002 JSJ The Right Way to Build Web Applications

Download MP3





YEHUDA: I now have to make a thing that's probably going to live with me forever. CHUCK: Disclaimer, this is Yehuda’s opinion and only Yehuda’s opinion. So, if you don’t follow it, you are stupid. CHUCK: Hi everybody and welcome to the JavaScript Jabber podcast! This is Episode 2 and this week on our panel we have Yehuda Katz. YEHUDA: Hello, great to be here again. CHUCK: We also have Jamison Dance. JAMISON: Howdy! Nice to be here too. CHUCK: We also have AJ O’Neal. AJ:   It's Wednesday and we're so excited! CHUCK: And I'm Charles Max Wood from teachmetocode.com and this week we're going to be talking about How To Do Web Apps Right (or something like that). YEAHUDA:   Yeah, it’s hard. CHUCK: Yes it is hard. JAMISON: [crosstalk] – some PHP right? YEHUDA: Things are good. CHUCK: Absolutely. Well you kind of bring up a good point there, is that everybody kind of has their own way of wanting to do this. I mean, some people, they just kind of throw out layout together and they do a big JavaScript front-end. Other people tend to use something like Ruby on Rails or PHP or something to build an API, that then the JavaScript front-end can use. And then there are other people that just do it all with like page refreshes and hairy AJAX calls. YEHUDA: Yeah I believe 37Signals does the AJAX calls and page refreshes based on what--- CHUCK: So I think there are a lot of different ways like you pointed out to do it. But what is your preference? Or what are you guy’s preference? AJ: My preference is to actually build the API first. It seems like a lot of sites have API as an afterthought. So if you're going to build it anyway, why not build the API and then use your API in your app, so your API is tested because you're the one using it as well. YEHUDA: Yeah I think as more people are building other front-end, so if you are building iOS or an Android app, you're going to need an API anyway. I think treating your web front-end as the equivalent of an Android or iPhone app, --- to say, but if you can do something like that, that that's a big one I think, along the lines of what you just said. CHUCK: Right so when we talking about APIs, are we talking about something like JSON APIs since this is a JavaScript show or XML API or does it matter? AJ: JSON. YEHUDA: Not an XML API. [Laughter] No, so I am not going to be controversial by saying I prefer JSON APIs, but part of the reason why I prefer JSON API is that, I actually like to have my front and my back end—(let me back up)... So a lot of people who build API do like handcraft APIs where every resource that they build, they are like, “Okay what things should I expose? What should I name everything? Where should I attach my associations? And what should happen with these errors.”  I like to build applications where the answer to all those questions for every resource is always the same. So I built “Serializer Gem” that enforces that. But basically, if that is the case, if everything is the same, if the answer for associations is a long side and the answer for errors is an error sash and if your frond-end is JavaScript, it’s really nice to be able to just basically just say, “The way I handle taking a response and converting it into an object that I want to use in a client side is basically just taking that data action, making it available to the model on the client side.” And again that is very consistent, if your JSON API is always the same; if you ask a POST, you get back a hash that contains a POST key, for instance, then it is very easy to do that. AJ: The thing that I like about JSON is, well, first I'd like to say I think that JSON is a misnomer because it is not a JavaScript object notation; it's a generic object notation. Python has it, Ruby has it, plenty of other languages implemented it either on accident, because it just made sense or on purpose to comply with the JSON standard. But the idea that you are transmitting objects in JSON, you can specify what’s an object or a map and you could specify what's an array, whereas you can't really do that in XML without some sort of external document and schema etc. JSON just really simple -- it is what it is. CHUCK: Right, that's definitely something that I like about it too, where sometimes you get big blobs of JSON that are hard to read, but with a little bit of work, or if it's a relatively small object, it's really easy to see what's going on. Whereas with some of the other protocols out there, you can’t always follow what’s there and what’s provided because it's either not consistent, and that's the issue that I have with XML, is that you have the tags, but then you have attributes on the tags or you can have sub tags. And neither of those, really, you can't just pick up what’s there where you can with the JSON and the other thing is just its really concise, you have the key in value and very little syntax around it to describe what's going on there. JAMISON: Yeah, there's not a lot of noise at all. I mean, I don't think they are very many people using binary protocols for their APIs besides like the huge places like Google and stuff. But I think being human readable is a huge plus for it. There's a lot to be said. [inaudible] YEHUDA: I actually don't care about human readable so much, but I do care that it is… so basically, if you get a huge array of objects back (which is like pretty common), I would like to show the customers, so give me customers back. It’s actually important that it be efficient for browsers that are used to actually getting access to that information and not have to do a ton of processing to get it. So I think ultimately, buyer protocols will be good in new browsers, but may be then it would be worth revisiting stuff like BSON or something like that. But until then… basically the fact that you get back with JSON and then it’s just a hash you’ll have access to in your JavaScript code is helpful. CHUCK: Yeah, the other nice thing about that is that, regardless of whether you're using JavaScript or Ruby or anything else, not only do they have translation protocols or drivers or whatever for the JSON, that will translate it into some fundamental data type, but most languages have a data type that is a key value hash dictionary object, or what have you. So it translates very nicely to most languages you’re going to use on the frond-end or the back-end. JAMISON: Yeah, so we are talking about the right way to build web applications and Yehuda kind of has a horse in the game, right? So maybe we should talk about --- CHUCK: A horse or two in the game. YEHUDA:   Yeah two horses. JAMISON: [Chuckles] But should we talk about the whole frond-end framework stuff? Like Ember.js? CHUCK: Yeah, absolutely. YEHUDA: Sure. So first I wanna say a bit about Rails which is, I think it’s like hipster popular right now, to say, “Well I look at Rails back in the day and most of my app was like a bunch of use, these days I just make JSON and I think it will be cool. I just use like Nodes and spin out a bunch of JSON and like, and Rails seems too heavy.” And as a person who has both worked on a lot of Rails apps and worked on Rails, I want to put out there that I do not agree with this position. I think, that both two big issues; security and HTTP semantics mean that even for just doing JSON, as long as your app is mostly request response style app (which is still mostly the case), having something that I know is invulnerable to timing attacks, does the white thing with cookies before using those… there's a big list I could make.  I'm not worried that there are like common Web attacks that I'm vulnerable to. And I also know that HTTP does the right thing and I’ll have to like, install middle wares to get common functionality. I use Rails for everything basically -- all back-ends of all apps that I build. That said, I totally agree that a Rails app is becoming more and more dumb terminal kind of-- or sorry, dumb server kind of thing where, like I said earlier, where you are essentially creating a bunch of JSON objects that are extremely consistent. But that I think the world where you don't have to write authentication object or the world in which you don't have to do custom queries or things like that is not here yet. So I would like to use Rails. So that's one. In terms of front-end, I believe strongly now in some kind of data binding solution. People would use data binding solutions for other purposes where they like it. So there are a few options out there. I think Ember which is what I work on, is the most robust data binding option and I would say that, that the fact that is a feature of Ember is one of the reasons that I advocate it. JAMISON: Do you wanna explain what data binding is maybe to some people that don't know? YEHUDA: Sure. So the easiest way to explain it is in terms of something like Backbone. So obviously a simple “Hello World” JavaScript app doesn’t use anything, it’s like everything is in the view. And if you wonder like, how many checkboxes are checked off? You go get collect all the check boxes and count them and then you know how many there are. So, that is what we call “Truth in DOM” right? The truth about what is happening is in the DOM. JAMISON: Your data is the DOM basically. CHUCK: Right. YEHUDA: And think that works well, that’s like how a lot of people build apps today. But that type of application, everybody who builds anything that's not extremely simple or mostly retrieving HTML snippets from the server, hits the point where you are like, I can’t --- this well. The same data is represented in multiple places in DOM. Which one is canonical? If I change it here, how do I make sure I change it everywhere? So people immediately hits this issue where they realize that storing truth in DOM, your DOM as data, I'm sure Lisp will like that. So storing your DOM as data rapidly gets to a point where people realize it’s not acceptable. And when you realize that, you immediately start moving towards some kind of inventive system. So I have been advocating, like way before I worked on Ember, basically decouple your low level events like clicks and drags and things like that from high level events like, “I have competed his task.” And Backbone is basically a model that says, “Okay there some common patterns here. You’re basically dealing with that a lot. When you set a proper, you should see an event if you want one.” So that's useful, that is a step up and stops you from storing a bunch of stuff to the DOM and gets you a good pattern. CHUCK: I have to say, having been using Backbone for a little while that, like you just said, I mean like, going from the model of, “Some of it is in the DOM, I might have a few objects that I’ve got in memory and of the browser somewhere,” to something like Backbone where it manages a lot of the data, it manages a lot of the events, I mean it really is a breath of fresh air. And I'm not saying that it's the best solution, but I mean it is a step up from-- YEHUDA: So, I totally agree I think basically, Backbone goes from VVV, your jQuery VVV pattern to… I think Backbone is basically an MC or MMV framework, right? There isn't really controller per se in Backbone, but it decouples your model and your view, and that's actually a pretty big deal. So if you look at the Backbone site they tell you that is not MVC, so I think MVC is like sufficiently hot, but the fact that people want things to be MVCs, actually defeats the fact that Jeremy doesn’t wanna call the Backbone MVC. But anyway, Backbone is basically giving you place to put things, decouple model from view and creates a general pattern. Like whenever you change an object, if you wanna know about it, you can find to that and then you can do things. Basically, the data binding philosophy is, “Okay, so now that you have done that, it turns out, a lot of the time you are using that, to shuttle data from place to place.” So there are two critiques of Backbone that something like Ember but also Knockout or other frameworks has a Backbone. So number one, like I said, a lot of the things that you are actually doing with events, are basically just saying this thing should be the same as this thing. When you change this thing, reflect that same thing here. And that’s especially true about arrays and things. The collection of things, a large number of the time, what you want to do is, say if you add something to this array, I just want the thing that represents the array in the DOM to receive a new rendered copy of the same thing, right? So if I have ten items, I have ten new things. In Backbone those common patterns which every app has them, Backbone basically says, “Okay here is the code, copy and paste.” And the second critique of Backbone is that because Backbone so heavily requires that you write your own event handling, it actually kind of limits you to a couple of layers. So, because Backbone basically says, “You need to write your own event listeners and then decide what to do with them,” it actually discourages you from breaking your app up into more than like two layers. So you obviously could create more layers to handle more levels of abstraction, but it’s not comfortable because you have to make sure you don’t make mistakes and how your… if you have intermediate things that you are not the model or the view, you have to make sure that you are listening for events in the right direction and passing along with other directions and that gets complicated. So, data binding basically says, “Okay, so there are going to be things that basically sit in the middle.” So in Ember, those are usually controllers. There are going to be things that sit in the middle, but we are not going to actually make you say, “Listen to this and pass it on to that.” We basically use data binding to glue it all together. So data binding essentially makes it a lot easier to break itself into conceptually separate objects that have small responsibilities because you don’t have to worry about making the mistake of, “Okay, now I accidentally observed this but I forgot to pass it along,” and then things go haywire. And obviously, good developers don’t make those mistakes but, I think I write good code and if I have to write the same code over and over again, occasionally I’ll make mistakes and that’s annoying. CHUCK: I kind of get then that there are some data binding layer that you have in Ember.js that manages all of the different things that are going on. How exactly does it do that then? YEHUDA: So basically the first thing that Ember does is it says, “We are going to need some kind of object model that is data binding aware.” So, in Backbone basically, the core concept is events. So you mix in your event module in to your object event, events work. The Ember is an object model that is binding aware. So the first thing is (and you could use this in Node if you want or whatever) the first thing is you could say this property, this object is bound to this property of the other object. And whenever you set a property on object A, it basically tells the binding object which exists and say, “Hey, later on when you get a chance, go reflect those change to the other object.” CHUCK: Right. YEHUDA: And then basically the way it works internally is that, every time the user clicks on something or types something or something like that, their browsers hands off to JavaScript like, “Please handle this event.” And what we do is we basically handle all events.  And as soon as we start receiving an event, we basically create essentially a new transaction. Then you start running your handlers, you register some handlers with us, we call your handlers and then if you basically make some changes during those handlers, we remember it like, “Oh you made some changes we need to do propagate that.” And as soon as all your code is done, all your handler code is finished running, then we say, “Okay there is a bunch of things we need to do,” and we go and we propagate those changes.  And the reason that we do it like this is instead of doing it immediately is that, often there is a lot intermediate states, so you are setting properties, but imagine that you had some calculation that is based on three properties. If it was event, like it is backbone, every single time you change any one of those three properties, whatever you have to do on the flip side has to be done immediately because there are no notion of deferment. But, if you defer it, you could change all three of those properties and you don’t have to make any changes immediately, but later on it’s like, oh that computation that you want to do, even though it depends on three properties, we only have to do it one time. This is especially important with large arrays of things, so you have aggregates, where it’s like, “Tell me how many things are in this array,” right? And you add 50 items or you delete 50 items, obviously you do not want to re-calculate that 50 times and update the DOM. So basically, the way binding works is whenever you say something, what we do is called “invalidating” the properties. So we invalidate anybody who cares about you and then later on once all of your code is done running, before we hand control back to the browser for basic configure of that loop, we say, “Okay let’s go do all of those things, “(and that may obviously trigger more things), but we do it in waves instead of like, instantaneously as you do things. CHUCK: Okay that is interesting, that's really interesting. I'm curious if there are any other frameworks out there that you guys have heard of that do the same sort of thing. I’ve heard of Backbone, I’ve heard of Spine. I just wanna throw some options out there so people know what is there. I'm going to have to go try out Ember now. YEHUDA: Yes, so Knockout is quite similar. Backbone and Spine are similar to each other in that they are trying to be relatively minimal and aren’t really trying to add a lot of features above the basic event layer. Knockout, Angular, Batman.js are all try to do bindings but, (I shouldn't say but) they try to do bindings, they have these binding layers, Ember’s binding layer is definitely I would say the most sophisticated among all of them, I think probably in general. Like if they will argue against that, they will just probably say it is unnecessary or something. But yeah I think if you are looking for, “I am a jQuery developer, I would like to have a little structure,” then Backbone and Spine are good options. If you are looking for data bindings, then like I said a lot of people use Ember, a lot of people use Knockout, Angular, Batman. Batman is a CoffeeScript-only framework, which basically means you need to read CoffeeScript in order to read the source of it, which is fine for other people. I personally would never write a framework from JavaScript even though I use it for work often. CHUCK: So then, moving on to the back-end, we’ve talked about Ruby on Rails and you’ve mentioned that it gives you a lot of security and things like that. What you need to be doing to make it consisted in the way that you want it to, to get that API to where you need it to be? Do you just use built-in JSON stuff that comes in the generators or-- YEHUDA: Definitely not. I should just reiterate, I'm actually interested other thoughts on this question but, I should clarify what exactly that means. So when you make JSON, obviously if all you are doing is rendering like, an object with 5 properties, it’s obvious what you should do, right? But there’s questions of how like how you deal with associations? So for instance, let’s say you had a POST which has many comments, which has many tag. It is not ideal to nest the tags inside the comments, inside the code, because if you do that, there may be the same tag like 50 times and now you have 50 different copies of it. And further, now basically as you are extracting information, you are dig in to the JSON object, pull out the things that you need and then like if you are using Ember, your JavaScript is basically like, I'm a model, a POST model, a common model, I have a tag model and you would like some code to automatically settle that. You don’t wanna have to be responsible for manually going to the JSON saying like, “Oh here’s my comments, let me go put that in to all these stuff,” right? What I mean when I say “consistent”, is that the rule is, it’s only nesting one level deep; associations are always arrays on single IDs and then associations are provided alongside of the top-level index by ID. So that way if you have 50 comments, which each have an author and many other authors, they are pointing at the same author object at the top level. And obviously it’s not always necessary, but I personally inconsistencies so even its only necessary half the time, the fact that half the time you’d have to write the code to do it, means you may as well have to do it all the time. CHUCK: So, one thing that I wanna clarify here then is what you’re saying is on the frond-end, it makes more sense to have one master or authoritative copy of the data for particular object. YEHUDA: I think that that's very important. Once you get into data binding, it’s extremely important. Because let’s say I have 50 tags, and I have little tag editing interface and I go and edit one of the tags, obviously you would like all of the location where the tag is located to be updated. CHUCK: Right. AJ: We actually got into that problem recently with one of our apps. YEHUDA: So, basically with Ember data, which is not part of Ember but which is like I think most people use it when they have more data to work with, one of the many reasons that exists is as identity map, so when you give us a tag, it’s inserted into the store once and if you ever try to get that same tag again, you get the same Ember object back out of it. And that way, if you edit one copy of it, all the other places where it is DOM will always have the right— CHUCK: I’m having these newsflashes (I guess) in my head, [chuckles] where it occurs to me, you know, so if you need that object; it just pulls it out of collection of objects. And if it needs to, then it can go and check and see if something has changed on the server side if it has to and then it can update everything the way that you are talking about it before. YEHUDA: Exactly. CHUCK: It maintain consistency that way and you can have it update more quickly because it’s already there in memory. YEHUDA: Yeah and updating from the server is also like having one canonical copy on the client is important. Otherwise you would have to go like, “Oh! Newsflash: the server has decided to change the tag name of this. Now, I need to go figure out all the places where I have to dial that tag.” So basically if the associations in JSON are always pointing at IDs and then you basically get the canonical copy alongside, you don't have this problem. You only have one canonical copy of it. Obviously it will be crazy, like it is of course possible and really bad if you have nested the copies and you have different things in all the nested copies, that probably would not happen though. So, the problem isn't that you might get different copies in the JSON; it's just which one of them is the canonical one. And then how do you store that and how do you make sure that they are all pointing in the right one. So basically, not just getting into that problem in the place I think right and no, obviously the render JSON in Rails does not solve that problem. Render JSON in Rails does, by default, everything is embedded and it basically asks you to do all the work by building up a hash yourself and then passing it to JSON. CHUCK: So yeah I've gotten pretty familiar with that hash. [Laughs] JAMISON: Yehuda, the way you are talking about it almost sounds like a relational database type of thing. I mean, it's like a table that has IDs basically, right? YEHUDA: Yes. So it's basically, it's conceptually relational. It's not as heavy weight as a relational database, doesn’t mean you have queries or anything like that. It’s more like just a way in JSON to represent object identity. So, in memory structure, you can say all these things point at the same object but if you're in JSON, you cannot say that. So the way you say that is by essentially serializing objects base into a JSON structure and then using IDs to point at it. JAMISON: So, like you said, they are the poor man’s pointers, (kind of). YEHUDA: It’s definitely relational, but I would say it's more about preserving identity than it is about the relational nature of it. CHUCK: All right. So, I have another question about the kind of consistency end of things and this is something I'm trying to steer clear of Rails jargon because, I mean, people use all kinds of stuff to build their back-ends. I guess my question, is sometimes let’s say I’m just loading up like my main page on my blog and all I really have there is the title, the author and a short description. So I don't really even need to care about the comments, or the tags, or the categories, or anything else related to those POSTs. All I need is the basic data and an author object that I can refer to. So in that case, do you pass an object that has references to the comments and tags and categories or do you not worry about that until you're actually updating it to a state where you need that information? YEHUDA: So there are basically two ways to do that; the easy way that would retain consistency is that you would include the references, but you would not include the actual thing that is being referred to. So you would have a tag thing and it will have a list of all IDs but you would lazily get those IDs later. But in more advanced thing will be in your system to have a notion of partial updates, so that you could load in a few fields and then later on when you want to load more things, load more things. The reason why I’m saying it’s more complicated is because like I said before, you still definitely want to have a sense of identity. If you're adding tags to a blog [inaudible], you want to add the tags to the original thing that is representing the blog post; you don’t want to be creating a whole new one. So basically, that means that you system needs to have a notion of being able to be updated with a few fields, but that's not very hard. And I should say the first approach of just like including references to things that you don’t have access to yet is fine (for most cases). It makes you not have to worry too much about essentially loading in partial data. CHUCK: Right. Which approach Ember.js take? I’m asking because you are here. YEHUDA: So Ember data by default, takes the approach of expecting that you have at least the references. We’ve run into a few cases where partial updates would be a good idea. Ember.js has two layers; it has like, how does the store work? And the store doesn’t really care. Your store is basically like, “Give me a hash for this ID and later on if you go get the same ID again, we’ll give you an object back by the same hash (or the same object back by the same hash).” So you can obviously go and update that hash and by definition it will all work. There is another layer which is the adaptor, which is the code that actually talks to your server. And we actually have a default one which for dealing with this styles that I’m talking right now and that expects that you give it the data lazily, that you give it the data such that lazy update will be possible. So if you have a case where you have like, a million tags and you don't want load that until you actually need it then like we are probably add something like this but we haven’t got the issue yet. CHUCK: Alright cool. YEHUDA: Actually I should say a million tags such that loading even the IDs will be expected. CHUCK: Yeah, it fascinating to me, again, how many approaches there are, but just thinking about the ways that we can solve these problems and make it consistent. Just talking about it, it seems relatively simple. So as you update things, is there some way that you should be circling back to your API server in getting the data? Or do you perhaps get it when you update something or things like that? Does it matter? YEHUDA: Part of the consistency question is also like, what happens when you make an update. And so basically the way we think about it general is when you make an update, either the server can give you back nothing, which basically means mark this thing as updated it is no longer dirty or waiting to be saved, but all the properties are the same. And then you get optional return like a hash back that says – actually, for instance a comment that will be updated after change, (because now you have actually updated it). Here’s the hash go update the backing hash and again in our case, if you update the backing hash, the object that points to that hash does the right thing. I definitely think that the way you actually go about updating things, like we support bulk updates, like updating ten at a time and then the rule was you have to return back the hashes in some order that they were submitted. I think Rails did a good job early on in saying a lot of things are common. We should not make you like constantly rethink things. There is a resource helper and that generates like ten URLs for you. And I think part of where we need to go as a both frond-end or back end community is just decide what consistency looks like for more than just like, REST -- which is a very vague thing which basically means, there’s a resource representation, go for it.  What is the resource representation? What should server speed sending back? How should server represent associations? Should servers include roots? Should they not include roots? What should happen when we save things? How do you do bulk? So REST is like actually pretty bad at bulk in that it does not specify at all. It’s not obvious how you do it, but saving ten things at once seems like a good idea. So how does that work? We’re just basically Ad Hoc picking an answer and then writing an adapter that supports that. But I think a bigger discussion about that would be a good idea. (Probably.) CHUCK: Yeah. So the other question that I have is, when you are updating, do you generally send just a diff? In other words, if the key on the object isn’t there then it’s not updated? Or, if the key is not there in the object is it deleted? YEHUDA: So we basically follow the normal Rails convention here, which is put request but your update should include everything. So, there is like a proposal for patch request, which has the ability to have a diff, but that’s definitely still an on-going discussion. Not in Ember, like in HTTP, there is a patch proposal. CHUCK: So at this point you send back the all of the attributes regardless of whether they’ve changed? YEHUDA: Yes, correct. So we know which attributes changed but making the server deal with that is actually-- it basically seemed better for us to take the hash, that is the backing hash and say here is the new backing hash, which basically the semantics of PUT in HTTP. I think it will probably be worth revisiting if it turned out that there are application that ---. CHUCK: That makes sense. So one other question I have for you is that, we had a long discussion in Ruby Rogues with Steven Klabnik and he went off on how Rails Rest is not REST REST. Where do you sit with that? YEHUDA: I now have to make a thing that is probably going to live with me forever. CHUCK: Disclaimer, This is Yehuda’s opinion and only Yehuda’s opinion, so if you don’t follow it, you are stupid. YEHUDA: I think that's true what he said, but largely irrelevant. So, specifically what I mean is that, I think that consistency in this stuff is far more important than… essentially I’m not an HTTP originalist. I’m not the Scully of HTTP. I don’t wanna go figure out what the REST people originally meant about something and then tried to extract it. So for instance, batch updates is really a thing that HTTP doesn’t describe how to do at all. What URL should you POST to, or PUT to or patch to, what exactly does that mean. Obviously like posting to a collection which simplify creating a new item, spec creating under a new collection, putting to collection, replacing the collection you're not doing either of those of two and things. So, where do you send the request to in the first place? These are questions that exist in the real world that needs to be solved and I think it's okay to try to, like say, what's the best RESTful paradigm but there’s bigger problems that you are actually implementing some feature that doesn't have a good semantic explanation of it in REST. CHUCK: Right. YEHUDA: So, when people say it doesn't do the right thing, they don't like the fact POST is used. They don't like the fact that a lot of people want POST and PUT to both work. There is shortlist of things that are, like, here is why you are violating REST. I think of that the way of Rail saying, here is what these things mean actually is more important than the few cases where Rails may have gotten it wrong. AJ: So can we define real quick, what we mean by “REST”. What does it as a general idea where talking about? To me, that means that I have /object. So let’s say we’ve got a contact list like contacts.ruby.com or something. The REST API for that will be like ‘/contacts’ will give you a list of all the keys with minimal meta-data about the contacts and then ‘/contacts/ID’ will give you back all of the data about that object, right? YEHUDA: Yeah, I think when people who are very pedantic (so what you just said seems good. I’m cool with that) When people are very pedantic talking about REST, they usually mean that the HTTP Spec and the original dissertation had some semantics around things and you should follow them. So for instance, a POST request is a request that inserts an entity nested under the entity that you are submitting the POST request to. A PUT request says, take whatever is at the location that I am putting to and replace it with the body of the request that I am making. So there are semantics around this stuff and basically— AJ: Well, that seems like CRUD, I mean you have create is POST, update is PUT, destroy is delete, get is read. YEHUDA: I think people don’t like the prominence of the concept of collections. I honestly can’t speak for other people. I’ve occasionally run into people who are like, very angry about Rails is REST implementation. And I'm happy pedantic people exist in the world, but I have work to do. [Laughter] I should be clear, I’m not bashing people, like I had good conversation with people and I am not… I don't think that they are doing anything wrong per se. It's just hard for me to make myself care that may be Rails got some verb wrong. Like, at this point basically it’s like Rails style REST right? Which basically whatever Rails decided around Rails 1.2 and we could have Rails style REST 2.0 but that would mean breaking a lot of apps and so the question is, is the case that you are saying we are doing the wrong thing, is that making it correct more important than the cost of breaking apps? It’s just hard for me to care about, like, there are few cases where it’s clearly wrong and it’s hard for me say, “Yes we should break everyone's app.” AJ: Can you give an example of layer, something we need to change? Because I mean like as I understand it, I’ve read through the  HTTP spec and I'm not like hard-core HTTPist, but Put and POST , they kind of blur the lines, the paragraphs and those two aren’t extremely clear, so I kind of see how somebody might think its ok to do one versus the other or say, “I don't care.” I think that update is kind of silly anyway. You can just have delete the old and create a new or something. YEHUDA : That kind of suck though. AJ: But what is the case where an API would break REST. You can use a Rails example. YEHUDA: I think there are people who have more compelling arguments than I will personally remember at this point, but one example would be a PUT request is basically like, take whatever the contents of this body is and replace what there is there now. And the Rails semantics are, update the existing resource at that location by updating just the field there in the body. So that’s wrong. Basically people say that Put in Rails should really be PATCH. AJ: Oh, because it is not a full replacement? YEHUDA: To that point, you might but you don't always fully replace it. Certainly, there often are internal properties that are not exposed to REST, so you may be making a PUT request that does not contain fields are just technically should just wipe out. AJ: I think that some of those arguments might me a little outdated considering that we are now in the age of HTML5 and the HTTP Spec was created long, long ago. I mean, you got to admit they had some ideas right. There’s the Coffee Pot Protocol. But I mean, they had the idea that there would be other devices big online on the Internet, even if it was just joking. But for the most part, I would think that the people who designed it wouldn’t have quite imagined the kind of HTML5 interactive full-on applications that are built around modern browsers. YEHUDA: I think they actually did a remarkably good job. And I think honestly, a lot of the cases where people complain are toss ups. Like, maybe Rails did it wrong and maybe the HTTP Spec is smart. Anyway, proceed. CHUCK: So one other thing that I wanted to bring up and that is that I don’t know how many of the modern browsers support PUT and DELETE. YEHUDA: No. So PUT and DELETE are supported in all AJAX requests and never on forms. And I reopened a thread like a month or so ago, it’s like say, “Hey, can we have this back?” And the reason why it’s not in forms actually turns out to be pretty complicated. When Rails supports PUT and DELETE, it basically says, the semantics of PUT and DELETE are the same as POST, because we are hijacking a POST but route it inside of Rails into a PUT request. CHUCK: Right. YEHUDA: Where, if the browser wants to implement PUT, like wants to look at a PUT HTTP Spec and actually do the right thing and that turns out like getting the correct answer there. There is like a pretty long thread about this and there’s a pretty long bug ticket about this. I personally didn’t have the time to even fully answer it. They are like, what should we do in this case? In this case? In this case? It’s like hard to know. AJ: Isn’t it up to the browser anyway? I mean like, if I put POST in a form versus put in a form, I mean, the server. The server is going to get that data and it’s going to decide what to do with it. Why would the browser be concerned? Just curious there. YEHUDA: So it’s like what happens if the server returns a 201? What happens if the server returns a 204? What happens if the server returns a 404? AJ: Then you do the same thing with all of them. YEHUDA: Yeah. So the difference is that, so right now there is no spec for POST but everyone does the same thing because they base the copy value right? CHUCK: Right. YEHUDA: But if we say it's up to the user agent with PUT, the actual semantics will be different. People will do different things and that will not be good for the web. AJ: So one of the nice thing about HTTP implementations as is, is they are generally write your implementation to output data strictly, but it accepts data loosely. So there’s like a lot of web server issues that /n instead of /r and /n still works just fine, things like that. So, it seems like the server returns a 201 instead of a 202 or 200 then that was just being smart. YEHUDA: So, that’s true. That is totally true, but the answer to what the browser should do when they are smart if it turns out to be different things is clearly not a good thing. AJ: Okay. YEHUDA: So basically, the argument that there are a lot of existing servers that has semantics around stuff, largely Rails apps has semantics around these things and right now the current things that [inaudible] I think people are weary about saying it’s basically POST but it’s not, right? So one approach would be to say, basically in the browser, the browser would do the same thing as POST even if it's not. And I think people don’t that. People basically say, you don't have PUT and DELETE right now, so we can actually take the time to get it right. CHUCK: So I was just going to ask, outside of the concerns over consistency and semantics are there any other implications in the fact that the browsers don't give you the option of submitting a form through PUT or DELETE? YEHUDA: So one possible implication could be that right now, so this turned out to be a wrong assumption, but a lot of people made the assumption including Rails and Django etc. that there is blacklist of headers that can come from browsers. So if you receive a POST request that has these headers, these are browser headers, and if you receive headers that are any headers other than these, it definitely does not come from a form. And because it is only affected by form submission, a lot of servers assume that it will be safe, for instance if you had a content type of JSON as an example, content type of JSON can come from a form. Now it turned out (and Rails we have to do a lot of work to fix this) it turned out that there is not a file reception because of some weird flash stuff. So flash can do weird shit. Not not obvious like you could just – for me but there is some combination of redirection and other stuff that causes this assumption to turn out to be invalid. But it's actually kind of tricky to do it, but basically if the browser added new features and said like, “Oh from now on we are going to send JSON as a thing.” You can say form content ID = JSON then now a lot of servers that had not been updated to recognize the new reality which is actually is a lot of web frameworks, now it’s very easy to make them vulnerable. You don’t have to have a weird flash thing. You just have a form that puts or deletes and it has a JSON. CHUCK: Alright, I am going to go ahead and start to wrap this up. We need your picks and then we can call it an episode. Jamison, do you want to go first with the picks? JAMISON: Yes. I have two picks I think. The first one is Mike Birbiglia; he's a comedian-storyteller guy. He’s been on This American Life a couple of times and some other radio shows and stuff. But he’s great he tells amazing stories that also happen to be a hilarious. He’s not just like, here's my list of jokes that I'm going to tell. I'll post a link because his name is really hard to spell but he’s great. Then the other one is it's a band called “Inu” (I-N-U). They are like beautiful poppy-electronicy-rocky music. It’s pretty mellow I feel like it wouldn’t just like turn anyone off but it's great. It's really relaxing and they are good. So those are my picks. CHUCK: All right. AJ, what are your picks? AJ: So I was listening to a song recently (it’s probably really popular on the radio right now but I don't think it was at the time that it first started just a couple of weeks ago), by a band called “Plug-In Stereo”  it's called “Oh Darling” and it’s just got a pretty interesting mellow sound to it. I really enjoyed it. CHUCK: Cool. Any others or is that it? AJ: That’s it. CHUCK: Okay. JAMISON: It’s musical week. CHUCK: Yehuda what are your picks? AJ: Actually no, I’ve got another one. CHUCK: Okay. AJ: Sorry. “Parse.com/docs/android_guide” very cool layout on the documentation looks very nice, actually trying to build something to replicate it. CHUCK:   Cool. Sounds good. Yehuda what are your picks? YEHUDA: Okay. So I have two; number one is a book called “The Yellow Lighted Bookshop.” It is memoir from a guy, who is a bookseller, grew up working as a stock boy basically in a bookstore then and became some high-op in some bookstore. And he basically walks through in parallel, sort of the history of bookselling in general and his own personal experience. I thought it was good. I enjoyed it a lot as a person who likes books and bookstores, I enjoyed it quite a bit. The second pick is a piece of software called “Mou” (M-O-U). It's really simple markdown editor. So, you type in markdown left and the right size of preview and it lets you pick CSS, so it has like the GitHub style CSS for markdown or other things. It's under development. He’s been pretty responsive to feedback. I use it a lot now just because the problem of I have some markdowns typed in and I want to see what it’s actually going to come at the other end as I type, plates me a lot and this solves  it. It’s free now but he accepts donations and I think will charge for money once he releases it publicly. JAMISON: Does this support the GitHub style markdown where it does like the syntax highlighting and stuff? YEHUDA: No, but it will in the next release. So, 071 which is the next release, he is going to add like the code fencing support. CHUCK: Alright, cool. So I have a whole bunch of picks. I’m just excited about a bunch of stuff. The first one is Mountain West Ruby Conference. I know it's a Ruby conference but there's going to be a lot of web discussion there. Yehuda is actually going to be speaking about moving toward JavaScript front-ends and stuff like that. (I don't remember exactly. He could probably tell us better). I’m really excited to see where that goes. I'm also an alternate speaker, so if somebody drops out I’ll probably wind up speaking there as well. Another book that I’ve been reading recently is called “Outliers” it's by Malcolm Gladwell and I'm on few chapters in but he talks about kind of the way that certain people excel in the areas that they are in. And then he finds these the reasons why they would excel in that way. So the first chapter he brings up hockey players and it turns out that the kids with January birthdays, it turns out that they tend to be the people who are leading the hockey field in Canada. And the reason is, is because January first cut-off in the younger leagues and the funny thing about it is that they're the bigger kids on those teams, so they tend to get more coaching, they go to more of the away games because they are on the  travel teams. The younger kids are smaller so they don't do as well. They are not as well coordinated so they don’t. And it’s really fascinating. The second chapter was the “1000 Hour Rule” which you may or may not have heard of. It actually goes into how people like Bill Gates and Steve Jobs and (I forgot the other guy’s name. He was the son founder Bill something, Bill Joy…) anyway, he talks about them and how they kind of had this unique circumstances that allowed them to spend a ton of time in their younger adult years learning to program and spending time programming. So they got in their 10,000 hours that made them world class people in their field and that's what got them to where they could succeed in the ways that they did. My last two picks (I’m sorry this is like pick heaven for me) but I got a lot of people asking me what set up I use with my programming both in Ruby and JavaScript and what I use is, I use MacVim. It’s just a Vim variant that opens up in its own window and stuff so you don’t have to use it from the command line. Then I use a set up that Yehuda contributed to and it’s called “Janus”. It really easy to get set up and then you have all your syntax highlighting. You can do fuzzy searches for files and a whole bunch of other stuff. Just a bunch of Vim plug-ins that they pulled together and really make it work really well. Those are my picks. JAMISON: Janus is great. CHUCK: It really is. JAMISON: I used it when I was first starting out. I don’t anymore. But it’s really good if you wanna get a really good set up quickly. CHUCK: Yeah so I’m still using training wheels Jamison. JAMISON: [Chuckles] No. It’s not just training wheels. CHUCK: So anyway, we are still in iTunes so if you are listening to the podcast and you are enjoying it then go to iTunes look up “JavaScript Jabber” and leave us a review. Let us know what you thought. Also if you have any suggestions we are going to get the link up so that you can post suggestions, topic ideas for us to talk about on the podcast and help you kind of level up with your JavaScript. So with that I just wanna thank you for listening and we'll catch you 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.