 A long time ago, decades ago, when I was in Kathmandu, Nepal, and I was there as a young man. I was going to go trekking in the Himalayas. And I was sitting in a bakery cafe, the German bakery cafe in Kathmandu. I was looking through my lonely planet and maybe writing some notes in my journal about what I was planning on doing and just enjoying a beautiful courtyard environment in the shade there. And suddenly something fell out of the sky and it landed with a thump next to me and bounced up onto my table and landed on my plate. And it was a grapefruit. So I ate it. I looked around. No one else had seen this happen. Backbone is your grapefruit. That's my metaphor. So backbone, backbone, what is backbone? Backbone is the simplest set of prototypes, objects basically, that you can use in JavaScript to build a single-page web application, a complicated, interactive JavaScript application. So if you've written JavaScript and you've gotten into something that's a little more complex, then click here and do this. And then this happens. We start to have multiple things happening at once. When you start to have an application where you want people to be able to drill down into records and then send a URL, capture the state of that application, backbone is your friend. It's going to really help you create that kind of code. So in this talk, I'm going to go through the basics of backbone and then I'm going to run through a few code demos, just the really simple code demos to hopefully give you guys an understanding of how backbone works at a fundamental level. We're not going to get into anything super sophisticated. But why should we use backbone? It's fast. If you've used applications like Basecamp or the Media Library and WordPress, you've experienced that kind of fluid interaction that you get with a backbone application. Trello, there's a zillion applications out there. I have a little thing in a second. But when you design something in backbone, we're talking about an application that runs in the browser. It's JavaScript. You're not dealing with that old style web interaction where you click on a submit button and then you wait for the server to respond and the page refreshes. This is a different world. This is where you drag a slider and the page updates immediately or you drill down and the page updates without a refresh. It organizes your code. So backbone comes with some fundamental objects, prototypes that I mentioned. I'm going to go into them a little bit, models, views, collections, and a great templating library. It sort of gives you a structure that you can put your application into. So when you have something in the DOM, something on the page in the browser that you want to represent, you're going to use a view. And the information in that view is going to be backed by data that you store in a model. So when you want to change something in the DOM, you're not going to just write to the page like you would with JavaScript instead. You're going to change the data in the model and the view will update the DOM to reflect that. And it's going to keep your code organized by giving you that structure. It's also very lightweight. It's a very small library. It's included in WordPress. You can just enqueue it. It's also modular. So if you just want to use, say, backbone views and you don't need a collection, you can pull that part of backbone out and just use that code. What else? Should you use backbone? Come on. I created this easy chart. Oh, it went right past it. It's supposed to say, should you use backbone? But you can't see it. There's the easy chart to figure out if you use backbone. So if you're just writing something simple, you probably don't need backbone. Backbone comes in when, like I said, when you have a state that you want to manage, when you have complicated interactions happening in multiple places. So these are the basic prototypes that backbone provides, views which represent everything that happens in the browser, both the interactions that are coming from the user and the display of new information that you're doing in your code, models which you can think of as a record or a post. It's the data that is contained in one element, and that's usually what you're going to push to the browser, to the DOM, to the view. And then collections are just a group of models. So you can think of it as a bunch of rows in a database. You can think of a model as a single row, and then you can think of a collection as a bunch of rows of data. And a collection is just gives you a great utility functions for handling groups, filtering them, searching through them, appending to the end, that kind of thing, anything you would think of doing with an array or any kind of collection of objects. Plus, some other nice helpers, events, great event handling built into all of the backbone objects. Routes, which is going to handle the URL up in your browser and route that to a specific state of your application. We'll actually see that in the demo. And then history management, so the ability to hit the back button after you've, say, drilled down to several different things, you hit the back button. It takes you back through those states that you've just been in the application, not to the previous page before you loaded the application. Now, I'm saying application. But I would say that you could use backbone in a lot of different places in your themes or plugins. You could create a widget that was driven in backbone, written in backbone. We recently did a search feature for a site, a pretty sophisticated search feature that was written in backbone. Not just a normal search box, but something that included data from multiple sources, and allowed keyboard navigation, and had some kind of fancier, responsive stuff going on. And it enabled us, multiple developers, to all work on the code at the same time. Some of us were working on the front end, some of us were working on the back end. The structure of the application was dictated, sort of, or controlled by backbone. Dictated is actually the wrong word, because one of the really nice things about backbone is that it's very flexible in how you use it. It doesn't actually dictate how you use it. It gives you these great objects, and then you sort of decide how you're going to put them together, how you're going to use them. Some people will just use backbone views, and that's all they use. They don't care about the other parts of backbone. But I'm going to show you, sort of, in the example, some basic ways of using it. So to get our data into our backbone, whatever it is, widget, application, page, theme, there's two ways. Basically, we either bootstrap that data, which means that when the page loads, the PHP code actually generates all the data that the application needs, and then passes that application to the JavaScript, using WP localized script. That's our WordPress function that we use to pass PHP data to JavaScript. And that's when you have the data available at page load. The other type of data is when someone does some action, they click on a post, and then you want to retrieve that information from the server. So that's an Ajax request that we make. We make that to the server, and then the server responds with the data that we need for application. So in my examples, I'm going to use the WP JSON REST API plug-in, which is a really handy way to get data out of your WordPress site in a JSON format, which is exactly what your backbone application wants. Backbone consumes JSON, so the REST API is a perfect match. You don't have to do it that way. You can use standard WP Ajax functions, use WP send JSON success, whatever you want, to just build your own JSON. But I'm going to use the REST API to make it really simple in the demos. So there's a zillion examples. And the backbone.js.org site is awesome, great documentation as well. But these are some sites, for example, that run on backbone. So if you view some of those sites, you're probably familiar with the kind of interactive experience that I'm talking about. I use Basecamp every day. Some of these, I use CloudApp quite a bit, Trello quite a bit, Pandora. That's also written in backbone. So if you've used those things in your browser, you've used a backbone application. Also, WordPress Core is making extensive use of backbone. So I've been involved in WordPress Core for the last couple of years. And come on, video. Oh, here we go. So I just made a little video to remind you all of the awesome things that we can do now in WordPress Core. So you drag a bunch of files onto the image uploader. They start uploading while they're uploading. You can edit the titles and the captions. You can build your galleries all while they're uploading in the background. Multiple things are all happening at once. This is backbone at its best. It's a very sophisticated implementation. And it's one that you can tap into as a developer. You can pop up a modal and have your own media uploader in your theme or plugin. Revisions, I was heavily involved in this rewrite for 3.6. So previous to this, when you went to the revision screen, it was a kind of click and compare and wait. Now we have this great slider. You slide it back and forth. You can view all your revisions. You can choose to compare any two revisions. Drag the sliders back and forth. Meanwhile, it's making AJAX requests back to the server to get the data from the PHP to show you what the difference is in your revisions. More recently, we did the themes screen, which is going to come up here in a second. So this was another rebuild. It really didn't change what you could do on the theme screen of WordPress. Just really enhance the user experience. So no more waiting, clicking preview, waiting. You could now just open up. The search is instantaneous. So as you're typing your search, you're seeing the filtered results come right in. You can click to preview a theme. And then you can hit, like, a next arrow next and back and go right through the themes. That next arrow is off the screen up there a little bit. But you get the idea. Inside of WordPress core, we're transforming features that already exist into way more user-friendly experiences by basically recoding the front end part of it in back bone. The media library, this was also new. So this is the media grid. We used to just have the list view when you went to a media library. We're in that long list. Now we have this beautiful, full page grid of images that you can scroll through, infinite scroll. And again, really nice full screen modal that comes up. You can hit next and back to go through the images. I mean, this is a great experience for users, especially if you have a lot of images that you want to edit all at once. It's really intuitive. It's really fast. There's not any refresh. So this is the kind of great experience you can build in back bone. Even if it's something much smaller than these, it can still enable you, users, to get that instant responsive feedback. So underscore. Underscore is a dependency of back bone. And it's another very important, awesome JavaScript library. So I'm not going to go into all of underscore features. But while you're out there exploring back bone, which is my goal of this talk, is to get you excited about back bone, go check out underscores. It's referenced right from the back bone site. It's got these really useful functions like filter and map and where that you can run on collections. Really great timing functions for dealing with asynchronous events. Delay is similar to set timeout. But you've got these really nice ones like debounce that will only fire an event a certain amount of milliseconds after the input has stopped. So if, let's say, a user's typing and you want to fire off an Ajax request, when they finish typing, you can use that debounce. Throttle is another one where it will only fire events at a certain rate. So if you've ever tried to build something in JavaScript and you're maybe responding to a mouseover event, and suddenly you mouse over and the whole browser slows to a crawl because you're getting 1,000 events per second and your code can't deal with it, these types of timing functions help you out with that. Really useful functions. Once you start using them, you'll miss them when you don't have underscore. Underscore is also a very small library, easy just to load up, you just need to score. It's already part of WordPress. Just some more nice utility functions. Underscorejs.org is the site. Here's one example of using underscore. So I've got a group of models called BackbonePeople. This is like a collection of models. And I'm applying the filter function. And what that does is it's going to go through all of the models and call this function for each model. And it's going to check whether the title contains this search string. And if it does, it's true. So it'll return that model. And if it doesn't, it's false. So basically what this does is it filters the list of models to those that match the search, all in one line. It's basically doing a loop and doing a comparison for each thing in the loop. Here's a debounce one that I mentioned earlier. So this is when you want to trigger a search when someone's typing. But you don't want to have every keystroke that they hit trigger another search. You just want, when they pause for a brief second, like a quarter of a second, that's when you want to fire the search. So they type 12 letters. And then the search gets fired off. Maybe they type some more letters. Another one gets fired off. But you don't want to just do it every single time because it's going to not be very performant. That's another one. So this is another example where I'm using throttle. And this will fire repeated events. But this is more like you want someone to be able to hold down the key and maybe move something left or right. But you don't want that event firing again 1,000 times a second. So another really useful helper function. So WordPress and Backbone. So WordPress, like I said, includes Backbone. It also has some really nice utility functions that make working with Backbone easier. I already mentioned the JSON REST API, which I'm going to use in my demo. It's a plugin. It's on the repo. You can install it on your site. It instantly will provide JSON feeds for your posts, any public, well, not users, any publicly accessible data. So like your posts and your post data, for sure, would immediately be available. If you're an authenticated user, then you can get more information from it. And you can also send information with the JSON REST API. So if you want to update something, your Backbone application can send an update. WP Localized Script, I mentioned that. That's the function we use to pass data when we're bootstrapping our data from PHP over to JavaScript. I will have that in my demo. The WP-AJAX filters are used to create callbacks. They're used to create AJAX callback endpoints. Because we're using the REST API, we probably won't be using those. So this is sort of replacing that. Create and Verify Nonsense. Nonsense is a security measure that prevents click hijacking type attacks. Basically ensures that the intention of the person that you're getting the AJAX action from is who you think it is. You can read more about that, but these are very important security functions, especially if you're doing anything where you're allowing someone to update records by sending AJAX requests and make any kind of change. You want to make sure that you verify that that's actually the person who you think it is. WP Remote Get allows you to make remote API requests from WordPress. So this is great if you want to call back to your server and then have it fetch data from other APIs, say the Twitter API or something like that. This is what you would use. Get and Set Transient. Also, Markzik with CLC Transient Library was mentioned. Transients are a great way to cache data. So you would probably want to cache data, especially if you're dealing with remote data. JSON, WP Send JSON, Success and Error are functions that basically send a JSON encoded data back to your request and includes an error or success and status in there. There are some really nice WordPress specific backbone helpers, including WP Template, which is an extension of the underscores templating library with some sort of WordPress specific variants. I won't get into that. And WP Backbone Views and Subviews are a way of managing views and subviews, meaning like in the media, you can think of the whole thing as a view, and then each media element as a subview. So that's just one simple example. It's a WordPress thing, views and subviews. It's not a backbone thing, but there's a very well-setup way to use it. It's a little bit complicated to understand at first. I recommend Mark Jacobs' talk from last year's WorkCamp San Francisco, where he talks exclusively about this particular thing, WP Backbone View and Subview. And I'll have a link to that at the end. So coding Backbone is fun. You can kind of see that up there. My slides are slightly cut off. It's mostly fun because of the results you get at the end. Along the way, it's just like any other coding. But in the end, what you wind up with is this amazing experience for people that's fluid, responsive, fast, all those things. So that's why it's fun. So it's also fun. There's also great documentation and awesome annotated source code on the backbone site. I already mentioned this stuff. It's clean. It's simple. It's also meant to be extended. So it's very easy to build on and extend existing backbone objects. You'll see that a lot. You'll see that in some of the demo code. It's got great templating, which basically means that we're and I'm going to show you this, but you're going to have an HTML template. And that template is what's going to do the rendering on the page. You're going to drive the HTML that's rendered on the page. And the data from your models is going to get injected into that template as it's rendered by the view. Couple of considerations when building a backbone application that you might not think about. One is accessibility, meaning is it accessible to users who can't use a mouse, for example? That's one small part of accessibility. If you can't navigate your application using only your keyboard, it's not accessible. That much, I can tell you. It's definitely a consideration when you're building something purely in JavaScript. You also need to think about when you have Ajax events. So you click on a button and say you delete. They've got a list of widgets. And you click a little X and it deletes the widget and your backbone application updates. It removes the widget. So if you're a blind user and you're using that and you're using a screen reader, how do you know that that's happened? There's no alert that comes up that your screen reader can read. So in WordPress 4.2, there's a new helper function called WPSpeak. And what this does is it embeds a hidden tag inside the DOM that you can update with messages that you want to send to screen readers. So when someone deletes a widget, you can send a message, widget deleted. And in fact, that happens right now. In the widget screen, if you move widgets up and down, previously the screen reader would do nothing. Now it actually announces widget moved up, widget moved down. You actually understand what's happened. Because these are, we like drag and drop. And as visual users, it's very easy to understand. But if you're using a screen reader and you get to a widget and you hit the up arrow and it moves up and there's nothing that tells you that it didn't, you have no idea what's happened. No JS. What if people don't have JavaScript on? So for some people, that's not a problem. Like, okay, you can't use my application if you want to turn off JavaScript. I'm sorry, bye. You're 2000. But for WordPress Core, I work a lot in WordPress Core. We can't really, if it's something critical, like edit your posts, you can't just say, well, you have to have JavaScript enabled. There's whole parts of the world where people don't have JavaScript enabled. There are different reasons that people will have JavaScript disabled in their browsers, not just because they don't want ads or because whatever. Internationalization basically means can you translate all your strings? So in WordPress, we have great translations functionality. WordPress is available in 86 languages, all over the world. When you build something in JavaScript, if you just put your words, your strings, your language inside your JavaScript, it's not translatable. We do not have translation functions in JavaScript currently. So the way you do that is you translate your strings in PHP, and then you use WP localized script to pass those strings to your JavaScript. So all the strings, all the language that you're gonna use in your application has to be put into PHP inside translation functions. And then you can pass it through to your JavaScript. Without that, you will not be able to translate your application. So I did a couple of little demos. This is the first one. Any questions? Anyone wanna stop me for questions before I get into the code? I promise it will be very simple. Yeah. Do we have data binding? Does Backbone do that at all? Not directly, no. Yeah. Templating, do we use things like Timber or not ever? Can you watch some examples? You can use other templating libraries. I don't really have experience with that. I mostly just use WP template, but apparently, yes, it's flexible about what you use for templating. And you'll see how I do the templating and maybe if you are familiar with those other libraries, you'd be able to understand how you would do that. So this is a very simple demo. We're just gonna display a single post, the first sample post that comes with any WordPress install. And we're gonna use a view, a model and a template to do that. The view will do represent the display on the DOM, the model will represent the data of the post and the template will be the actual HTML where that data gets inserted. You're about to see that. And we're gonna get the post data from the REST API. So I've installed the REST API on my site. Oh, it's a little crap, but this is the template. So this is the very first thing you're gonna see. It's just simple HTML so far. This little script wrapper tag is very special and because it's this type text HTML, basically the browser will ignore it, but Backbone knows how to find it. So Backbone's gonna look for something after with an idea of temple slash Backbone demo dash post, which we'll see in a second. And then here's sort of the inner part of the container. This part is the templated data, right? So inside this H2 tag, we're gonna have whatever the data.title is. That's what's gonna get rendered in that spot in the HTML. And then similarly down here for the content, data.content. So those are our two data points, the post title and the post content. So we're gonna bootstrap a little bit of data, but not much. All we really need to bootstrap is the URL of the JSON API because our JavaScript application needs to know where to hit the JSON REST API to get its data back about the post. And I don't wanna just hard code that in there. I wanna get the actual value. This was helpful since they just recently updated the REST API and changed the endpoint. This continued to work because they updated the function to return the new endpoint. But if I had hard coded the endpoint in the old way, it wouldn't have worked anymore. So this is a way to get the correct endpoint and then I'm passing that data with WP localized script right here to the application. So this is the name of the script that I include. This is the name of the variable that I wanna pass that data to in JavaScript. And then this is the data that I'm passing. This is the model. So again, this is the model is what contains the data. So it's a post model. I'm representing a post. I'm just gonna extend backbone model. This extend is part of underscore. So backbone leverages a lot of underscore functionality. And basically all I'm doing in this model, it's just the default model. All I'm doing is I'm changing its sync method. I'm overriding its sync method. The sync method is the method that a model or a collection uses to retrieve data from the server when it wants to update its data. So you tell the model, update yourself and it goes to the server and gets its new data. And all I'm doing here is I am giving it the URL of the endpoint that I just localized. That was what I just did. The data demo data dot API URL, that was from the localized. And I'm appending posts slash one, which will give me the first posts. And that's it. That's all the model has to know. All it has to know is how does it get its data? By the way, this is what the data looks like when the JSON request goes out. So when that model does make its JSON request, all this data back from the REST API and most importantly, title and content. Those are the two data points that I'm mostly concerned about. I actually don't care about the rest of the data. Here's the view. This is the part that's going to render the data into the template onto the DOM. Ties it all together, okay? So the class name, this is basically the class that it's going to insert itself into, which is already on the DOM. This is that script tag that we saw before on the template. So this is basically building a template using the WP template function. And it's gonna grab this identified div. That's that script tag that we saw before, right? So this is telling it which template to use. And then, oops, down here, what it does is when it initializes, we're gonna pass a model through, which is gonna be the model that we're gonna create, the data, the post model. And all it's gonna do is it's gonna set the model, this.model equals the past model. And then it's gonna tell the model to fetch. So it's basically saying, here's the model, now do your fetch operation, which is gonna be where it goes to the server to get its data. And then, when that completes, it's going to, oh, I'm sorry, when that completes, it's gonna call the render function, self.render, which is down here. And this is what's gonna put it on the DOM, right? So this dollar EL is a special element of a view. And it's setting the HTML to the templatized version of the model and that's the data. So basically, this function there takes the data that's in the model and inserts it into that template that we created in the first step. So this is the final slide of this demo. So I know you guys can ask me questions. So this is just the initialization. When we initialize it, we just create a new view. That's the post view object. Oh, we create a new model, right? Post model equals new, post model, then a view equals new, post view, we pass the post model through and remember that it's gonna fetch as soon as it does that and then we basically append that view to the DOM. That's it, that's the whole thing. Now all it does is this, right? All it does is display one data. So it's a lot of code for one really simple thing. But what I'm trying to show you is how these different pieces fit together and in the next demo, I'm gonna show you how it gets a little more sophisticated and then we can talk about how it gets even a little more sophisticated. Any questions so far? I don't, no. It was basically like similar. We had created a structure for an HTML thing and then you would contact it whenever you get your data back and there's just a pair of items in an AJAX column and use that as a format for an HTML. Yep. Would this be like a extremely relevant like replacement for that? This is like a replacement for that, I think. Yeah, so this is. Since it's not maintained anymore, I've got a developer who loves to go back and use it, I can ask them not to. I mean, that's essentially what this is doing, right? Okay, so now we're gonna go on to a second demo. This one's gonna be a little bit more sophisticated. It's gonna build on the first one. So instead of displaying one post, we're gonna display a list of posts. So it's gonna be a list of all the post titles. When you click on a post title, it's gonna load the content of that post. So when you click on it, it's gonna go back to that first demo. It's gonna be the exact same post view model we're gonna load up. But first we need a list of models and that's gonna be a collection. And what we're gonna do is we're gonna actually bootstrap that list. So we're gonna pass through the list of the post titles to our application from the PHP. So we don't have to request that. That's just gonna be there when the page loads. Then when you click on each of those post titles, it'll make an age act request to get the data for that particular post. So you can click through to any post that's in the list. And we're gonna load those in via the REST API. Oh, and we're gonna use the router and history to handle routing. So what this is gonna do is if you click on several of the posts and then you hit the back button, it'll take you back through those posts. Or if you hit the refresh button, it'll take you back to the post you are on. Or if you were to copy the URL and send it to a friend in an email and they were to open that same URL, it would take them back to that same post. So we're gonna manipulate the URL up in the top of the browser to reflect the state that we're in in our application. Here's the template for the list. I'm not gonna show you the template for the individual posts because it's exactly the same as the previous demo. But this is the template for the list. So it's gonna be a list of items. So this template's gonna be repeated over and over again. But this is basically a single item. And it just has one data point. Oh, it has two data points, I'm sorry. It has an AHRF and it's gonna link to pound post ID. And then it's gonna have the type. So it's gonna be just a hyperlinked title going to pound post and then the ID of the post. Here's the bootstrapping of the data. So in this case, I'm actually just gonna get all the posts while I'm gonna get the first 10 posts and I'm going to pass that data through with my WP localized script. So I'm still passing the JSON URL but I'm also passing the post data as posts which is again just all the data I get from get posts. Okay, and WP localized script converts that into a JavaScript object. So when the JavaScript loads, that will be available, that list of posts. And I'll show you how we're gonna use that. Here's the collection. There's nothing to the collection. It's just a default collection. There's no code in the collection. Here's the collection view. So this is the view that represents the list of posts, titles, right? So it has a little more sophistication. It's got its template, which we just looked at and it has its collection which we're gonna pass through uninitialized. We'll see that at the end when we see our initialization. But just know that it has a collection that it stores internally. And then the render function. What it's gonna do for the render function is it's gonna go through all, it's gonna go through each, this is like a underscore for loop. It's gonna go through all the collection models and for each one of those models, it's gonna call this function and basically it's going to take that model's attributes, templatize it and append it to the dollar L which again is the special element that's attached to each view. It's a JavaScript, a jQuery object. Does that make sense? Everyone understand? So we've got the, so now let's see the router. So this is going to handle the routes. So this is, if you go up at the top in the browser and you type pound post 17, it's gonna load post 17. And the way it does that is through this little magic. The pound is assumed, that's unless you change it, that's sort of the default that Backbone uses. This is just the word post. And then this thing, colon post ID actually represents a variable. So it could be anything that you wanna pass there. And that's gonna get passed through to this post route function, right? Here's post route and we're passing through the ID. So the router will take that ID out of the last part of the URL, pass it through to this function. All this function does is it creates a new post view and it says refresh that post view with this ID, right? Which we already saw, I did slightly modify it. All I modified is it in the sync method. It's that always hitting number one, it hits whatever ID you pass to it. But basically it's exactly the same. Here's our initialization. For our post collection, when we initialize it, we're gonna pass the posts. That's the localized data that we bootstrap from our PHP, that's the list of the first 10 posts. Then we set up the view and we pass the collection in into that initialization function where we saw before. And then we set up our router and we start the back loan history object. And then we append the view to the DOM. That's it. So here's the result. This is a little sort of video, so this is the page loaded. Now when I click on each of those, unfortunately you can't see the top. Darn it. Okay, well, at the top. I don't know how I could make that smaller. I don't know how to change it. Anyway, at the top, if you were able to see the URL bar, you would see that each time I clicked on one of these, the URL was changing to reflect that. I also hit refresh a couple of times and hit back a couple of times so you can see that I'm navigating through different states of the application. So the router is keeping track when you click on that link and it changes the URL, right? Cause it's just a hash link. So it doesn't change the page. It just changes the URL. Then the router responds to that event by calling and refreshing the post view. Any questions? Yeah. When would you bootstrap your data versus your HX call? So bootstrapping, you wanna give the application basically all the data that it needs to show its initial state. So for example, one that I'm most familiar with is the revision screen. So you go to the revision screen, let's say there's 100 revisions that you're gonna be able to scroll through. What we bootstrap is the metadata about those 100 revisions. So their IDs, the authors, the date. So that you have just the basic information. Then we also load the first diff that you're gonna see, whichever diff, whichever particular one that you're looking at. That's also part of the bootstrap data. That's all you need to display the initial application because as soon as you've got that, you can display a slider, you know how many spots you've got, you know what's gonna happen. Then when you start to slide, actually what we do is as soon as the page loads, we make an HX request for the rest of the data. But when you go in the two-handled mode where you've got an infinite number of possible combinations, those are all HX requests. Every time you move a handle, it does an HX request for all the other possible comparisons. So basically the shorter answer is the minimum amount of data that you need to load your application initially. It could be more, you know, it just depends. I mean if you could load all the data once without a performance that you might choose to do that. Yep? I didn't say the URL, but did that URL you were using have a hash in there? Yeah, it had the hash. That's not required. So back then now it does support just a question mark like typical query bar type URLs. You'll see that actually in the revision screen. We had to sort of hack it to make that work at the time because Backbone went through some revisions where they weren't supporting that. Now it's actually very easy to do that. You can just put that right in your report. Does the hash mark require or can we just? I think so because otherwise, I think if you. If you want a page refresh, it would clear your browser state. Right. If you add, yes. So if you click the link and you had like a full URL in there, the browser would just go to that URL. Or we sent it to a friend. If Backbone wouldn't know to get it because it's actually going to try to look for that folder. That folder. Or that resource, which doesn't exist. You could like post slash one. Yes. But after you had like a question mark or a hash, that sort of breaks the question mark or the hash is what sort of tells it this is the page and then this is the data that I'm passing to the page. Just like query bars do. What you can just do slash you might very well be right. I've never done it that way. It's possible that you can. I'm not sure how they would achieve that, but I don't know the solid answer to that. You can do it in Backbone, but I don't think it's not an answer before. Yeah, so you'd have to realize that if you're using it in WordPress, it's going to be a special consideration. The URL might get intercepted before Backbone ever sees it. Which would be my guess. So I did have a more sophisticated demo that I created that I'm not going to go through. But it is on my GitHub.com plus Adam Silverstein. This demo one and demo two are both there. I encourage you to look at the code. One thing that I did want to mention that happens when you start to build applications is you start to have multiple views and you start to try to figure out how to communicate between those views. And Backbone doesn't tell you how to do it. There's a lot of different ways that you can do it. Like one good example is the search box example that I was using before. So you start typing into the search box and you're filtering what's in the collection. So the search box is a view, the collection's over here. How are those two connected? Well, you can insert the collection into every view. So there's always a reference to the collection. You can have views reference each other, but it gets kind of messy. So what we do a lot in Core is we use what's called a frame state model. And the frame state model is like a Core model that represents the state of your application. And it's used to communicate between different parts of the application. So the frame state model is created when the application is initialized. And then every view or collection has a handle to that frame state model. And you can communicate between views by using triggers and listen to. So the search box can trigger a search event that the collection is listening for, both on the frame state model that they're both connected to. So this is one approach to communications between different objects and large applications. It's what's used extensively in WordPress Core, but it's not the only way to do things. Backbone is flexible about how you choose to do those things. So just to reiterate, I want you guys to go out and just explore using backbone. That's my main goal, to get you interested and excited about it. And just to show you that it's really, even though it seems like a lot of code, the basic concepts are very simple. And as you start to build larger applications, you will benefit from that structure that's built in. It's fast, it's lightweight. I think I made that point really clear. It's easy to extend and it's part of WordPress Core. So you just enqueue it and it's there. Got a page of resources for you. It's all on my slideshow. It's on tunedin.net, which is my website. You can go through all these. There's some great demos. This book is a free open source book that you can read. There's that talk from Mark Jakewiff on the backbone views and sub-views, TLC transients, which I mentioned before. All that stuff is linked there. This is me. I work for a company called TenUp. We're a premier WordPress agency. We're always hiring. So if you guys are interested, come see me afterwards. I'm a core contributor. And I'm open for questions. I'll be around, too. Yeah? I assume that I can also do this push data out to the next round of APIs and then put it in. Yeah, I'll make an example of Google questions. You can. You will run into, if your browser's trying to contact other remote sites, you'll run into cross-origin request issues. So there's sort of a caveat to that. Yes, you can, but you have to do it in a very certain way. Otherwise, you'll run into permissions issues in your browser. But there's an optimization piece in the way you do it. Yeah, most browsers restrict JavaScript from making connections out to multiple other websites, except in certain ways, right? So you can include a script, and there's a really common technique called JSON key, which basically a script that calls a callback function. But other than that, you're pretty much limited to hitting your own site. If you want to do cross-resource sharing, if the server itself handles it, it can send a header back that says, for example, if mysite.com wants to talk to tenup.com, it's allowed and set it up so there's a change, and we can give each other permission. Yeah, you can get around that. I'm just saying, just the caveat is, you can't always do that easily. On top of the first-hand-go spreadsheet, for example, you can set it up. Exactly. Instead of client on your WordPress back end, they're not individually requesting that resource, but you're requesting that resource, patching it, and then serving it to them. Right. And it's much more performant. Yeah, that's the general approach. Exactly right. In general, with remote APIs, the most common approach is, you actually sort of use WordPress as your proxy. So your JavaScript application requests the data from WordPress. WordPress uses a remote get to get the data from the API endpoint, caches it, hopefully. And gives it back to your application. And the next application that requests it, the data's already there. I have not used AngularJS. And so I can't speak to compare the two. Everyone wants to compare different frameworks. I've read articles about them. I have extensive experience with Backbone. I know that other, from what I've heard, other libraries are more robust. They provide more things like two-way data binding, maybe, that Backbone doesn't. Backbone is the thing. The reason I've chosen to use it is because it's part of WordPress. And because it's very lightweight and modular. Like how you would load them up. Yeah, I mean, so that's gonna vary by what you're building, if it's a plugin, or if it's a theme, where you're doing it. But basically, you would render those onto the DOM in the same way that you would render any HTML. So if it was a plugin, you would just, instead of your normal, or wherever your normal HTML that you're rendering into the DOM, you would include that script. As long as that script's in the DOM, Backbone will be able to find it. Could be on a footer hook, yep. Yep, could be in a meta box. Could be, you know, if it's on the admin side. It could be anywhere on the page, really. It doesn't have to go in one specific spot. Yep. Yeah, I was thinking the same thing. So basically, for your demo template, that was post.php. Yeah, so what I did for my demo, just to explain is I created a theme. And on my index.php, I look at the URL, and depending on the URL, I include certain HTML. Just kind of clunky, but I wanted to keep it as simple as possible. If you look at the code, it's like, it's very, very simple. You'll understand it by looking at it. Yeah. Yeah, I'm gonna use the JSON API, that's a plugin, I'm not familiar with that at all. The JSON REST API? No, there's actually another one. Yeah, that old one, I haven't used it now. It's much older and not currently being developed, so I'm not sure why you would choose that one over the more modern one that's gonna be part of WordPress 4.3. Uh-huh. I'm just taking a base. Yep. I mean, I guess one advantage is that the modern JSON REST API, that the new one is in a lot of flux right now, so you will have to deal with changing your code if you use that one. If you use this older one, maybe that's not an issue, because it's not being changed right now. Yeah, so that's one really big advantage of using the JSON REST API, the one that I referenced, is that it is progressing towards becoming part of WordPress Core. So at a certain point, you won't even need to install this plugin. So if you build, right now, if you build something that depends on this, you'll have to have people install that plugin to use it, but in the future, they'll just have to have WordPress, and then they'll have that REST API built in. Yes? How do you set your permalinks? Does that mess with your? The routing? Do you route it? No, because the routing is happening all after a hash or a question mark. Okay. As far as I know. Yes? For press JSON API, for my single, we have to create our own function to simply reach out to the table that we want and put the data back into that table after you are accepted on that. So you can create custom endpoints where you load specific data, but by default, the REST API provides endpoints for things like your posts. So you automatically, once you install the REST API, get an endpoint where you can get a list of all posts, and you get an endpoint where you can get the data about a single post. You're there and where? Yeah. So could I just create my own functions and just hook them? Yes. You can. You can create your own endpoints and put whatever data you want in them. Do you have a custom post type for... You can also extend the default endpoint. So if you have a post type where you have a bunch of metadata that you want to attach to it in your JSON response, you can do that. There's filters in the REST API that allow you to hook in and modify the existing ones as well. I'll be around. I'm going to be at the Genius Bar or to a happiness room tomorrow. So, and I'm around, so feel free to hit me up for questions. Yeah. Cool. Thanks, you guys.