031 JSJ history.js

Download MP3



01:00 - Benjamin Lupton Introduction and Background

  • history.js (twitter / github)
  • Front-end and back-end developer
  • Based in Australia
  • Works full-time open-source 03:19 - history.js
  • HTML5 History API
  • Hashbang 09:26 - URL appearances 10:32 - Maintaining states 12:23 - (Joe joins the podcast) 12:30 - Framework usage 13:42 - Overriding history.js 17:33 - JavaScript community and evolution 21:10 - Particular problems that history.js is geared toward solving 22:07 - Sites implementing history.js
  • 37signals 25:18 - Other libraries that do the same thing 26:12 - Page reloads 32:14 - Browser limitations 34:37 - Live event in jQuery 35:42 - history.js: a deep or shallow library? 37:43 - Resources for history.js



BENJAMIN: Anything important, I hear from my wife. So, I could finally have that thing where Facebook doesn’t infiltrate my mind with cat pictures anymore.  [This episode is presented to you by ComponentOne, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to wijmo.com and check them out.] [Hosting and bandwidth provided by the Blue Box Group. Check them out at bluebox.net] CHUCK: Hey everybody and welcome to episode 31 of the JavaScript Jabber show. This week on our panel, we have Jamison Dance. JAMISON: Howdy Doody! CHUCK: I'm Charles Max Wood from devchat.tv and this week, we have a special guest and that's Benjamin Lupton. BENJAMIN: Hello. CHUCK: He is the author of history.js and why don’t you introduce yourself? Because that's all I really know about you other than history.js and you are many time zones away. BENJAMIN: [laughs] Yeah. So, I have been doing JavaScript pretty much my entire life and been doing it professionally since about 2006, full time. And over the time, I've developed some open source project. One of them became quite popular and that was History.js it makes HTML5 History API that was compatible with like hashes and things like that. We’ll go into that late. Yeah, that became really popular. Now I other stuff with Node a lot as well. CHUCK: Ooh. A front end and a back end person. BENJAMIN: Only because I'm Node. JAMISON: You are basically like a unicorn. CHUCK: Yeah. JAMISON: You are a mystical creature. CHUCK: You are too well rounded. You are going to put us to shame. BENJAMIN: Well, it’s easier being with Node. CHUCK: Yeah, that's true. JAMISON: Yeah it’s true. Where do you work? BENJAMIN: I work for my own company right now. We’ve been doing JavaScript constancy for a few start-ups in Australia. And now, I'm looking at going completely full time with just the open source stuff. CHUCK: Oh, cool. How do you manage going full time open source? BENJAMIN: Right now, we’ve got premium support. I'm going with a few companies and we are looking into other options as well. CHUCK: Right. Yeah. I'm in the same boat with my podcast. I’d love to go full time podcast and less full time consulting. JAMISON: So the real question is, if I pay you enough money, will you put a gigantic ASCII art picture of my face in the History.js source code? BENJAMIN: Perhaps. JAMISON: Okay. We’ll have to talk after. CHUCK: I’m going to have to figure out how to do that. Let’s see... Image to ASCII art… BENJAMIN: In podcast. CHUCK: Yeah and then I’ll… JAMISON: Oh Chuck, you could do it so there’s face that shows up like in the waveforms on the sounds. CHUCK: [laughs] I don’t know about that. BENJAMIN: How would we know you then? JAMISON: Oh, it’s true. CHUCK: Yeah. Anyway, so why don’t we talk a little bit about History.js and I was saying in the pre-call, I was looking at it and I'm like, “Okay, this is either super simple and I totally don’t get it or there’s something I'm missing here” and I turned out that they were both true. Just reading through the GitHub explanation of what it does. But if you had a link somewhere in there to the Mozilla articleabout the HTML5 specification on window.history and it gives you the whole spiel on push state, pop state and what is it – update state? BENJAMIN: Yeah, push state and pop state. CHUCK: Yeah and replace state. That's the one I'm trying to think off. And so I read that and then it made a lot more sense. And it seems like they are a lot of powerful things you can do about it. JAMISON: Well, I was not as good as you Chuck and I have not done enough preparation for this episode. So, can you talk a little bit about what the history API gives you? Because it seems like that is kind of a percussive to why History.js is cool, right? BENJAMIN: Yeah definitely. So what happened—do you wanna know about the hashbang then? CHUCK: The hashbang? JAMISON: No. Nothing besides what it is. CHUCK: You mean in the URL? BENJAMIN: Yeah. The hash and then the exclamation mark. Twitter used it and it stopped working for a while. Everyone was just saying like, “Oh my god Twitter, why are you doing this?” And I think Lifehacker did it as well. CHUCK: Yeah there are a bunch of them out there that do that. I think some of the JavaScript frameworks use it for different things. So you can do like hash whatever, whatever for like... I don’t remember if Backbone was just the hash or if it’s hashbang but anyway, a lot of them seem to have something like that in them. BENJAMIN: Yeah. So the reason I ask that is like, as soon as you start going to like AJAX stuff, right? Probably around maybe 2006 when jQuery was in its bloom, everyone started doing AJAX and its like fitting with AJAX and then SEO died because search engines couldn’t crawl the AJAX websites. And then out of that, the other problem then was the back button died. Because if you are doing a AJAX web application, the URL does not change. So, that was a big problem. So then what people did was they put hashes in the URL. So then we could do the little anchor hack. It was like a kind of a hack. And so we changed a page, we updated a little anchor so that the hash in the URL. JAMISON: So the back button will still work with that and you can still bookmark that and stuff? Is that what you mean? BENJAMIN: Exactly. CHUCK: I remember doing that back in 1997 with geocities. BENJAMIN: Yeah. So that hack has been around for a very long time. But the problem with that is, you still lose SEO. So then, Google—there's also another problem and that is if you refresh the page, you are not actually getting the correct page initially, right? Because you get the little normal page, like the front page and then it will load in the correct page from the hash. CHUCK: Right. Is that still the case now or is it a problem that they’ve solved? BENJAMIN: Yeah. So, that is solved by the HTML5 History API. So, all these problems were solved very, very smoothly with HTML5 History API. It’s important to talk about the hashbang because they were kind of the series of steps that led off to that. So with the hashbang, they had the hashes and they are like, “Okay we need SEO”. So hashbang was created by Google. They are like, “Okay, how can we get SEO for this AJAX websites?” and they made this really complicated routing thing. So if you do the hash, the bang and like the actual URL you want, they will redirect to a proxy on your website to fetch the content of that search engine, you actually want. So, it was a lot of effort to set that up. So HTML5 History API actually allows you to change the URL directly. So, now you don’t need to use the hashes anymore and it works with the back and forth button. So it’s just like you are not actually changing the page, you can just change the URL. CHUCK: So the hashbang, if I can just summarize because I am not completely sure I follow, it treats it more like a path and less like an anchor on the page? BENJAMIN: Yeah. So they both treat them as path. They both treat them because you handle all of this. Because all you do is you put the path and whatever after it is how you handle it. That's application specific. JAMISON: It’s not like built in to browsers or anything? BENJAMIN: That's correct. That was like, there was all of us trying to think, “Okay, how can we accomplish this with the limitations we have and the options we have available to us.” So, from there, the HTML5 History API then advice you to wanna find that URL and with events and everything you need to be able to get SEO because you got the correct URL to be able to get it back and forward going. And to be able to have the correct page initially, because you are just showing the original URL. The problem then became, “Okay, How many HTML5 browsers support this?” CHUCK: Right. That would be a problem. BENJAMIN: Yes it is. So then the other option was, “Okay, we have to have hashes” Pretty much what people did then was they just used HTML5 History API then. Now, a few people do that. They use it but it’s been a problem. So, that's where History.js comes in. What it does it is it will use that HTML5 History API but if you are in a HTML4 browser, it will go back to using hashes for you. JAMISON: So, does that mean that your URLs will look different in different browsers? Like would I not be able to share a link with someone if I'm in a modern browser and they are not? BENJAMIN: Yes, so the URLs will look different. So in HTML4 browsers, you get the hash; in the HTML5 browsers, you just get the URL you expect. Now, where History.js really got popular was that, it is able to handle that very gracefully. So, if someone gives you a URL with a hash, so say someone is using Internet Explorer and they copy the URL they send it to a HTML5 browser, then that would convert automatically into the HTML5 equivalent. JAMISON: Oh okay. That makes sense. So you can upgrade but you can’t downgrade. Is that correct? BENJAMIN: Well, it downgrades because in HTML5 History API browsers you are just showing the URL. CHUCK: I looked at it and it had a little bit different format for the HTML4 only capable browsers, to the older browsers. BENJAMIN: Yeah. CHUCK: One thing that I really liked about the API is that it’s not only allowed you to put in the hash and things like that, but it also gave you JavaScript object that you can put in at the same time to maintain the state or the history overtime. BENJAMIN: Yeah. So that's the picture that was part of the normal HTML5 History API. So the other problem with maintaining states in your web application, so essentially every single page shows some state and the web has never really had states before. So, that data which you are talking about is that you can attach a certain JavaScript object towards a particular state. So that could be like, “Okay, the username and pass…“ Okay that's probably a very bad example. You don’t want your username and password in there. JAMISON: [laughs] BENJAMIN: [laughs] But just information related to that, the page to maybe which step you are in a particular form or something like that. CHUCK: right. So if there's some kind of access, details or one thing that I thought is interesting is even if you have different data that needs to be displayed in different states, then you can store in there basically in history. BENJAMIN: Yeah. CHUCK: So essentially then, like if you wanted to browse from one user’s page to another, let’s say, you can just store all the user’s data up in the state and then if they hit back or back out anywhere, then it will just load that state because you are backing up by saved state instead of by page by page. BENJAMIN: Yeah. That's correct. CHUCK: Yeah. It looks like Joe is trying to join. Let me bring him in here real quick. JAMISON: I’ll stall by thinking of questions. So, it seems like this is a thing—is this being used by any frameworks to help with their routing layer? Because it seems like, I mean lots of frameworks have URL based routing for what they show and stuff. And this would be a really easy way to find easy, compatible URLs for those. Is that something that is happening a lot? BENJAMIN: Yeah. So a few people use it with Backbone, that I know of. The frameworks tend to wanna be as lightweight as possible and they don’t want to go a particular direction because History.js does for to a particular way of doing things. And you may not always want that capabilities of History.js. So if your framework was to adopt it, a lot less people would be—you would then have a split. You would have people that will be satisfied with that decision and you will have the people that will not. But it’s very easy to just include it in any framework you use. So that is just they take the optional if you want it, just include it. It’s very easy. CHUCK: Right, so if you are using something else that does have a routing engine to it, then how do you override history.js’s version of it? Or can you? BENJAMIN: How do you use History.js with that framework? CHUCK: Yeah. So say you are using Backbone.js and History.js and you wanna use the history’s routing instead of Backbone’s or vice versa. Will one always override the other? BENJAMIN: Yeah. So they will not be compatible because Backbone provides a router inside it by default. It’s very basic. So, if you were to use History.js and that just to right your own router for that which would just use to history.js API instead. The APIs are very similar to the native APIs, but, there is a change that is a big controversion in History.js in that, when you push a state, pop state fires immediately or our state change event will fire immediately rather than pushing a state and then enough causing pop state. JAMISON: Wait. Can you explain that one more time? BENJAMIN:   Yeah so the HTML5 History API works by you do a push state that will add that state to your application’s history. And when you do the Backbone, what that would do is it will then trigger pop state “so okay, this state has now been popped. Here is the state details”. JAMISON: And that's totally separate from the URL changing right? BENJAMIN: Push state changes the URL. JAMISON: Oh, okay. BENJAMIN: Pop state will fire when that URL changes. JAMISON: Oh. Okay. That makes sense. BENJAMIN: So what History.js does is, I was like developing an AJAX application for like a long time, and I looked at that and I was like, “This is a bit odd.” because the way I have always done it is that, whenever you push a state, the router will fire immediately. So for instance, if I pushed the state, I want that to go to like my router controller immediately and then that would do the handling for my applications. So for instance, if I push this page, that’s pushed to the about me page, now that should trigger the state change and that should load the about me page. When I found that I had to do this in two separate things as the HTML5 History API  suggests, then I had to do--  I had to say, “Okay, push that state and now load in the about me page” I found I was doing the same thing with more code. So, we made it so whenever we push a state, it fires the state change event right away. JAMISON: Okay. That makes sense. Thanks for explaining that again. BENJAMIN: Yeah. So it’s different to get your head around at the start, which is why there’s a lot of articles written about it. Because it’s a very—it’s doing a lot of structure to web applications the way should people actually use them. JAMISON: So it seems like it’s not, so I mean it doesn’t seem like, it’s definitely not a framework, but it also imposes a lot of design. It decides a lot of things for about the way you are going to build an application. Would you agree with that? BENJAMIN: Yeah. So it’s definitely not a framework, its more just like there’s a --- but because of like the extent of what it’s trying to cover, there has to be some compromise with it. So, those tool with like compromise. JAMISON: Can I ask an off topic question? BENJAMIN: Sure. JAMISON: So you have been doing JavaScript, you said since 2006. That's a lot longer than a lot of people in doing JavaScript especially since the explosion of Node and there's just been lots of new people coming in to JavaScript. Do you think that there is a big difference in the way that people are solving these problems now? Like people without long years of JavaScript experience are solving similar problems. Does that make sense? BENJAMIN: Can you rephrase that? It seems like a few questions in one. JAMISON: Yeah it’s probably because it’s fuzzy in my head. It just seems like you have been around for a long time and have seen JavaScript change a lot. Both the way people use it and that kinds of people that use JavaScript. Do you do things differently because you have been doing JavaScript since 2006 or do you think that you've kind of kept up with best practices that have been evolving? BENJAMIN: Yeah so, at first it was just like a little timeframe that I see it though; the way JavaScript community has changed. I say around 2006, jQuery wasn’t that big yet. People was still writing the custom JavaScript and jQuery came out and suddenly was like, “Oh wow, you can actually accomplish things with JavaScript. I can actually use it to solve these problems. You know, just add all those text that I wanna use and do these things that without, jQuery would be hundreds of lines of codes”. So, after that, then in the last few years, web applications really took off like in the web 2.0 thing and suddenly people starting solving the more difficult problems.  And with these abilities I think with the browser and things like that, JavaScript moved from being the thing of just click handlers for forms or animations, into actually being something that people can create really amazing application, that's like entirely on the class side and things like that. That was one half of your question. That was like the timeline with whether or not people… what was the other part? JAMISON: I mean you have been doing JavaScript for a lot longer than lots of people, like I've come in to JavaScript in the last few years, the scene that I came into is much different state and I've had much different experiences with it. Do you think that you do things differently because you have been doing it longer? Or has it been kind of a consistent evolution of things getting better in JavaScript and you are keeping up with the best practices. Does that make sense? BENJAMIN: Yeah. So, I think like the thing that people coming in now, there is so much out there. I remember watching the previous episode on listening on the previous one on the JavaScript community, saying that, “Yes. Like, right now there’s so many in the JavaScript community again” And then they had the little tiny community inside the JavaScript community. And there's people who say one thing and that doing something that people say another thing.  The big difference I kind of find is the people coming in to JavaScript now; they don’t really know who to subscribe to. Sorry, it’s just like a fuzzy question. JAMISON: Yeah, it’s fuzzy in my head too. That’s okay [laughs] CHUCK: So I'm wondering. It’s there a particular application that you see for History.js? I mean, we talked about the HTML5 history state APIs and we talked about what they provide for you, but are there particular problems for History.js is specifically geared towards solving? BENJAMIN: Yeah. So whenever you want to change the page of your web application, without the entire page reload, that’s a time when you should be using at least the HTML5 History API. So History.js just kind of makes that easy. So, pretty much every time that you need a web application to change pages without causing entire page reload, then you would want to use History.js or something like it. CHUCK: Okay. I'm also curious to know if you have any sites out there on the web that are using History.js? BENJAMIN: Yes. So, the biggest one is 37Signals base camp. CHUCK: Oh, really? BENJAMIN: Yeah, they use it. CHUCK: I'm an old Rails. So I find that interesting. BENJAMIN: So, they use it in the new version of it before. They didn't use it in the old version. That's a perfect example of when you may use it because for that, there is not really a definition of a page in that application because as you go through that application, you just change that little part of the page without changing the entire page. But the URL will change with it because it has it has your --- and things like that or all of that stuff. CHUCK: So that makes me a little bit curious. So let’s say you go to a page and you use it to change the state and you changed the state to something that opens up or changes one small part of the page and then you click on something else and then it changes another small part of the page; If you go back to that same state, it’s only going to change the second part of the page not the first part of the page unless you store all of that in the state. Is there a good way to account for that or you just have to manually keep track of it? BENJAMIN: Having through different areas that can change that are independent of each other? CHUCK: Yeah. BENJAMIN: That would be something you would definitely use that state data, which we have been talking about before. So assign some data towards that state. CHUCK: right and if people hit that URL directly, so If I try and share it somebody else, obviously they don’t have the state so they will only see the one that changed. BENJAMIN: Yeah that's right. This isn’t really a limitation of the HTML5 History API; this is a limitation of web apps in general because URLs only point to one state. It only point to one page. So if you go through independent states going on, it’s not really tied to that one URL unless of course you then add, identify like the query string. So search page is a good example. It’s going to be lost going on the search page. So we just use a query string in your URL. CHUCK: So you pass along the rest of the state in the query string and tell it what other parts to change? BENJAMIN: So that's the way to do it. You would--- because it kind of depends if you want people to get access at state from showing URLs and things like that, then you would use the query string like we’ve always done. So, search page is a great example of that. If it’s something  like, “Okay, here’s a panel that is unrelated to other areas”, then yeah any part of the state that you do not want to share,  you would use the state data for that. CHUCK: Are there any other libraries that do kind of the same thing? BENJAMIN: Kind of.  They are not doing it to like the extent that History.js would do. Like for instance Backbone kind of has like a middle fall back, but they make no effort towards hamming or the different browser bots associated with like the web applications. So, the different browsers event like the HTML5 browser handles HTML5 History API in different ways. CHUCK: Does History.js account for those differences cross browser then? BENJAMIN: Yeah, so History.js aims to be the only one cross browser solution for web apps. Like we would try and fix all the different browser bugs for it. So what we actually do is we can include and then not worry about different browser bugs. JOE: Do you have some internal guidelines that you use when deciding what state changes to actually push in to the history and what kinds of state changes not to bother with? I mean, obviously if we talk about the major switches in the state of your application that you want people to be able to bookmark, that's one. But, I find myself getting down to where there’s times when like, I think like Chuck was saying. You make a small change in a small part of the page and you get tempted to push that into history. And so I was just kind of curious if you have any insight being that you are the expert here on when to do that and when not to. BENJAMIN: Yeah. For that situation, they try and think about the HTML5 history state for web applications as exactly the same as how you would do it without the stuff. So, anything that you would use a new page for, traditionally, that should get it’s URL. Anything that you find can’t justify, like a new page reload with the traditional application, should not get its own URL. JOE: I find that to be far too simplistic. Don’t ASP.net, when page reload where something you did 85 million times, then you practically animate an animation by just reloading a page over and over again. CHUCK: [laughs] that's so true. JOE: [laughs] So there's tons of times when I reloaded a page and you know I’ve done--- certainly one of the worst offenders here, tons of times I reloaded the page there are times that it just did not in any way, shape or form deserve their own state. In ASP.Net, you can really didn't get at all-- There are controls in the client side where often very difficult to get to use the ones that actually did some Ajax or did some client side rendering. And so, you’d start changing the page for anything. So that definitely at least being. I don’t know if you have ever done .NET. BENJAMIN: Yeah. So, perhaps what was trying to say is, if you would do it like a page reload, that should be then changed to the HTML5 History API, you should push a state for that. JOE: Okay, but what if you are doing a page reload just to like I don’t know, change the background color on something because of some small state that is going on. I've done that. Smaller area of the app and I changed the background color and do that then I reload just to change that background color. Back when I was too dumb to learn JavaScript. JAMISON: You know, there is a global pool of page reloads and it’s not unlimited. So you've done us a great disservice Joe, you've used up a lot of them. JOE: I have. CHUCK: [laughs] JAMISON: We are going to reach page reload and then no one will be able to refresh their browsers anymore. JOE: I have much to repent for--- I'm making up for it now. I've no more page reloads. Zero. JAMISON: Got me other way. JOE: Does that makes sense? BENJAMIN: Yeah, so I would say changing-- causing a page reload to change the background color definitely does not justify a new state as you were saying. That seems to be better handled by like a cookie or *** rather than an entire page reload. JOE: So, for people that haven’t done your more traditional web application framework where you have to do page reloads before people started learning, --not page reloads, they are not going to know. They are going to have the experiences of “Oh, yeah. I would do it this way, this way that I would reload the page. Now, it’s coming to this fresh” and there are definitely people out there who’ve never not written a single page application. JAMISON: So, how about this for a metric, if it would piss off the user, if they wanted to bookmark that state and they couldn’t, then you should use the history. You should push it on to the state. JOE: So, I like that metric that it’s just bookmarking and stuff, but what about like being able to hit the back button to go back through and be able to see state changes. Sometimes there's value in that but you hit a state but is not valuable to bookmark, but it was valuable to see if you are hitting the back button. CHUCK: that's where History.js pays off because you can store the state in the history. You have to deliberately do it but you can do it. BENJAMIN: Yeah so for that, you would just push the--- this is where the state data comes in. So you only just push the same URL you are currently on, but with the state data that says there’s been a little change here. JAMISON: Oh, so they are separate? The URLs and the states that you are pushing on? I mean you can push the same URL on different state. CHUCK: Yeah you need to go read that Mozilla explanation because it really explains it well. JAMISON: I'm just the stand in for all the listeners that didn't read it too [laughs] JOE: [laughs] CHUCK: Yeah but basically, you can push state on to the history and it will update the hash and stuff if you tell it to. And anyway, when you hit back, it backs up through the state stack instead of through the URLs. Now, one thing that I'm a little curious about when you pop state, does it remove that state from the stack? So can you go back forward again? BENJAMIN: Yeah, you can still go back and forth. It pops it in the way we you popping in array. So, it still saves it. It’s just saying the state changed. CHUCK: Oh, I see that right here. I had another  question. The other question is, on the Mozilla article that you referenced in the readme, it also points out that, there's a limitation on the size that they will allow you to put into the state on that object that you store in the state; which is the way that you store any data that you need to do access in the state. Do other browsers have limitations like that? BENJAMIN: The different browsers all have very different ways of having things. One thing people run into a lot is that, they would try and put like a jQuery element into the state data, but because that is a circular reference, then it all falls down because those data is only for stuff that can be serialized. A good practice is to just have like a global store of a data and for the state data, you just reference like a ID in part of this global store. So you can say, “Okay, let’s now push this state” and then when the state changes. You go, “Okay, now fetch the data from ‘blah’ and where I can still have it in the DOM I want”. CHUCK: So you back up, you get the old DOM then you have to reinitialize things? BENJAMIN: Say, if you have done the little JavaScript program that do like okay, store = “blah, blah, blah” so just like have a global object, call it “my data store” and then when your state changes, you will just get the data from the global data store. And you will just associate and ID into that global data store. That's the other way you would deploy it. CHUCK: Right, but what I'm saying is let’s say you are using jQuery you find an element, you out a click handler on it and things like that, you can’t store that jQuery object in the state, is what you are saying right? BENJAMIN: In the HTML5 History API state. That's correct. CHUCK: So you store the ID in there and then when you back up on the state, you have to set up that click handler all over again, right? BENJAMIN: Yes, you would probably use a lot of events in jQuery for that. CHUCK: Okay. BENJAMIN: Almost like, live events come in jQuery, they allow you to bind to the selector or any changes that happen to your page. So you can say, “Okay do this selector for jQuery element” but that element may not be able to exist yet and it will still work when that element actually comes to be. So that will be great for things that are always present in your application. For things like overriding just the particular page, yet you would just do it in that particular page handler, you can say for all JavaScript just related to that page, and yes, you would have to reinitialize on that click event for that page. CHUCK: So the other question that I have then is, when you move through state and you are using jQuery, does it call on ready every time? BENJAMIN: no. CHUCK: That's only on the initial page load? BENJAMIN: Yeah. CHUCK: Okay. Cool. Do you guys have any other questions? JOE: I do. I got like 40 of them. JAMISON: [laughs] JOE: No, no just got a couple. I'm kind of curious, would you consider History.js to be a very deep library that requires a fair amount to get it to implement or would you consider it to be more of a shallow library like you spend maybe an hour trying to figure out and you pretty much be figuring out everything that's there. BENJAMIN: History.js is like the lowest of the low level. The other thing that is more lower level will be interacting with HTML5 History API like directly and hashes. So that was like the goal is to be like, “Okay, I want to provide the most  low level alternative to that API, that can have all these cross browser things solved”. But there are things like say, work with it very appealing to people who don’t want to learn about how to use the HTML5 History API. JOE: Right. BENJAMIN: So, inside there's actually a link to like snippet of code like a gist that will make it so you can just drop in like gist. You can drop in History.js and then your entire webpage will be updated to use a HTML5 History API with like the hash fall back. So the entire website will be converted into using stateful way of doing things. So, everything through AJAX you get with different things. But that only applies to like say, simple website. You wouldn’t wanna put that on yahoo.com. JOE: Got you. What if you decided to implement History.js event though you are using a third party library that actually has its own routing, would you call that process of replacing history with routing History.js, will you call that simple or is that often a difficult that you might want to apply a reasonable time to do? BENJAMIN: I would say it will be pretty simple. JOE: Cool. And then my last question and I always ask this question I'm like for asking this question on every podcast; if I wanna learn History.js, where are the best resources for me to learn it? BENJAMIN: The History.js *** is a good resource. There's also a few articles on that wiki page what will go in to more depth, which really is where people will click with it. Because the introduction on the state web applications is a big learning curve, so you have to do the reading about it. And then there's some good resources on the wiki. JOE: Have you had to change History.js a lot as browsers have come up with new versions and or has that been pretty stable? BENJAMIN: Yeah it’s definitely needed a few changes over time. JAMISON: Okay, I've got another question. So, I’ve used Backbone a lot and the way you manage state with Backbone is you models and some stuff to do with its URLs. But it looks like History.js, if I'm understanding it right, it gives you and easy way to manage some kind of global state that can be linked pretty directly to a URL. So how does that interact with other frameworks that have other pair for keeping track of all the state in your application? BENJAMIN: Backbone… how do you store—do you *** with the model in that frame? CHUCK: Yeah that's typically what you do. You manage the data and state with your models. JAMISON: Yeah so there’s an object graph of models there. It’s all loaded into memory that you load from the server sometime and you can manipulate them and save them back. But they are kind of always in memory for this state you are in, I guess. Does that make sense? BENJAMIN: Yeah, that seems a bit out of the scope of HTML5 History API. Backbone provides a router and that's where the HTML5 History API would come in. CHUCK: Right. But what Jamison is pointing out is that, if you have multiple states and your models change over the course of those states, then as you back up, your models aren’t remaining consistent with the global state that they were in at that time. It seems like one thing you can do is, If I remember right, Backbone provides you with an attributes object that is a property of your model instance. And so you should be able to serialize that and put it into the global state. And then from there, you would just have to you’d have to do some finagling and if you look at some readme, there's a bind for state change and so, when you pull the state up, then you just reinitialize those models so that they had the old data in them. JAMISON: But is that what you would do? You would store all the state of your application in the history state, I guess? CHUCK: Only if you care about what state it was in, when that state was saved. JAMISON: Okay. That makes sense. So, it’s not like you would use it for every action the user did, but if there was some intermediate actions that you want to be able to backup or forward to or something? CHUCK: Right. JAMISON: Okay. Sweet. Sorry I'm totally the *** on this podcast but, I'm not afraid of asking stupid questions. [laughs] so you have to bear with me. BENJAMIN : The way I generally do it with the Backbone apps is, you have the router and that will control your page so your router will say, “Okay when you have this page, tell your application view to like start loading up this page and just change the view into that”. So anything relating to the actual particular page, I'm still in the view. That's one of the properties of the view. And the models are just used for things like uses, tasks and things like that. But the model should stay the same across all the different pages or at least I would think so. CHUCK: Yeah, I generally agree with you like if you are doing like a to do list or something then that makes sense because even if your state is changing the view itself, you want your data to be the consistent latest version. But if for some reason you needed some intermediary state to be saved, then you can save the relevant pieces and then pull them out if you needed them. But I can’t think of a good example of why you would wanna do that. BENJAMIN: Correct. I would agree with you there. CHUCK: Anyway, were just about the point to where we needed to do picks. Are there any questions you guys have? JAMISON: Nope. JOE: Nope. CHUCK: Alright then, let’s do the picks. Jamison, why don’t you start us off? JAMISON: Okay. So I bike to work pretty often and today I was biking to work and had a sweet crash that I ended up flipping over the handle bars and rolling around and the back on concrete and stuff. And I landed on my Retina MacBook Pro which is in my backpack. But luckily, it was inside a case and since it just saved me a few thousand dollars I figured I’d better pick it. It is the “booq Vyper case” and book is b-o-o-q or something. It’s kind of a like hard shelled neoprene fiber-ish case. I don’t know. It’s pretty tough and did a great job of saving my laptop from being crushed to death. I've had it for about two years so it’s held up pretty well. JOE :Was itstiff? JAMISON: Yeah, it’s stiff. JOE : The picture don’t make it look stiff. It looks almost like a fabric. JAMISON: They have some fabric ones and this one looks like its fabric, but it’s got material inside of it that it’s kind of like a shell, not just a sleeve I guess. Maybe I said the wrong one. But ill post the right one in the show notes. JOE : Why don’t you pick your MacBook pro for saving your back? CHUCK: [laughs] JAMISON: You know, maybe that was it. Maybe it saved my back. I like skidded across the concrete on my back, so I was really glad I had the case. JOE : On traffic? JAMISON: No, it was on the side walk. I did get laughed at though, so… CHUCK: Is your retina MacBook Pro yours or work’s? JAMISON: Its work’s, but that would have been a sad thing to have to come tell them. CHUCK: [laughs] JAMISON: It was the best possible way to getting a bike accident though because like, I didn't really get hurt that bad so I kind of like flipped around and like jumped up on my and like stared around breathing really heavily like, “Oh my gosh. I almost died.” My next pick is a man named “Jordan Santell” he is @jsantell in Twitter and he has created a thing called “dancer.js”. Its JavaScript library for doing audio visualizations. So you can like make the screen pulse to the beat of a song that is playing or something like that. It’s really cool. He's also doing some contract work for i.tv. He’s helping us do some stuff and he’s been amazing at it. So if you're interested in audio visualization or if you need help on Backbone or Node stuff, he's your man. Those are my picks. CHUCK: Awesome. JOE : Now if you need help with Backbone or Node stuff, why can’t we just go to you? JAMISON: Well, if I hadn’t been incapacitated in a bicycle accident. CHUCK: [laughs] JOE : Good point. CHUCK: Okay. Joe, what are your picks? JOE: Hi, so my first pick, since its beginning Halloween season, is the book “Red Harvest”. It’s Star wars novel set in the old republic time period and it’s like zombie novel. I just barely started it. I'm really excited to read it. I read the same author’s previous book “Death Troopers” which was set during the time period of the original series of movies, where in this one, Han Solo is actually in the book and that it’s still zombies. That one was cool, so I'm really excited for this new book to read it during this Halloween time. That's my first pick. And I also pick “Nitro Circus: The Movies” it’s not in theatres anymore unless maybe but I saw that a few weeks ago right before when it was in theaters and that was awesome. Especially the part when a dude was in a wheelchair does like a 40-foot jump with a flip and lands it. CHUCK: Oh wow. JOE: Yeah, it was pretty awesome. And all the crazy stunts that they do, that was a sweet show. And then for my last pick, since it was a new TV season time all the new TV shows out on TV, I'm going to pick an old TV show, you can pick up watch on Netflix, “Arrested Development” the best comedy to ever have been on television. Those are my picks. CHUCK: Awesome. Okay. So I'm going to go next. My first pick is “f.lux” and it’s a program that goes on your computer and basically what it does is—and David Brady give such a better explanation on Ruby Rogues but I have used it for a couple of days and I love. Anyway, so when the sun goes down, it changes the colors and the brightness on your computer, so that it’s more of an evening dusky kind of deal instead of the bright blues and regular shine on your computer. And when your eyes see the blue light and kind of the day light colors, then it causes you to be awake and when it dims it and changes the colors to kind of warmer colors, then it’s more of a signal that you can go to sleep. And so, it was really nice for a couple of reasons; one was that it dimmed my monitors just enough to make it so that I can sit in front of it and work on my computer without killing or wearing out my eyes last night. And the other thing that was nice about it was that, I didn't have that wild awake feeling that I had a lot of times when I work on my computer late and I can just go to bed and lay down and go to sleep. Anyway, that's my pick. I don’t have any other picks. I usually have at least but I just don’t this week. So, we’ll let Benjamin share his picks. BENJAMIN: So I have two picks; the first one is a server side generator for Node that I have been involved in for a long time. So, it extends express and will gives you compilation of the CoffeeScript and things like that  as well as support of a different templating engines. And you can accomplish things like blogs really well in it as well as other stuff. It’s a pretty cool static site generator/web framework for express. It’s well worth checking out if you are trying to do blogging and things like that or when you are getting into web apps with express. And that’s called “docpad”. Now, the second pick an author called “Paulo Coelho”. He’s Brazilian and he’s written things called like “The Alchemist” which is really popular. When I first found these books to just be amazing. They really kind of shed a new light on things that happen in life. As well as what could god be and things like that. It’s quite interesting. He brings it to you like in not a religious way at all and the way he presents his lesson are quite appealing. So, well worth picking up. I think it’s really cool. CHUCK: All right. Well, we’ll go ahead and wrap things up. Do you guys have any announcements that you wanna share? JOE: Nope. CHUCK: Okay. I have one really fast that I wanna share. I'm going to be doing a webinar on November 14th I believe. It’s going to be an introduction to CoffeeScript. So if you've been wanting to learn CoffeeScript then go ahead and sign up. Its at introtocoffeescript.eventbright.com and I’ll have a shorter URL sometime but, if you wanna make sure you get a spot, then go there and sign up. And I guess were done so well just wrap up the show. Thanks for listening. We’ll catch you all next week! JAMISON: Thanks for coming Benjamin.

Sign up for the Newsletter

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