 Yeah, hello everyone. Kind of as Luca said, my name is Jack Lennox and I work as a design engineer at Automatic, the company behind WordPress.com. I'm on the theme division, so we work on all sorts of things across building themes themselves to approving premium themes and building all sorts of things around the theme experience, so getting themes set up and making them look good for our users. Rest API, what's the big deal? So, I like to start this now with a bit of a demo of where this talk is going, so I'm going to skip ahead a bit and show some examples of websites that are built with the new WordPress Rest API. Don't worry, I will come back to what the Rest API actually is, but let's get started with some examples. I'm going to make this bigger. So, this was a project. There was a competition in the UK in October last year, and this is a, it was called Build The News and a group of teams were tasked with coming up with innovative ways of conveying news to people. Now, this was a site that was built using the WordPress Rest API and an Angular front-end, AngularJS. To show off the kind of thing it can do, I can navigate this with the keys. We can move from page to page. Hang on, I've gone to the, ah, right, minute. Let's go to the logged in example. Yeah, so you can move around. There's different types of content that are getting pulled in. And as you can see, there are actually post formats. We've got these little icons in the top right of each window. You can see it's really nice and quick. It's obviously very fast. There's no loading time at all. It's really nice. It's not necessarily the most well-designed thing I've ever seen, but it's certainly good in terms of performance and engagement. Another example, on WordPress.com, we have a company called Quartz, a news website. It's QZ.com. They actually use the WordPress.com Rest API, and I'll explain the difference in this talk. But just to give an idea again of the kind of thing they've done with this, if I get onto a news story, and I click on one, you can see it loads really quickly. And obviously the internet here is pretty fast, but it's seriously fast because the page isn't actually reloading, as you can see when I go back to the homepage. Now, what I made earlier, in February of this year, my team, AdAutomatic, wanted to work on building a test theme that uses the WordPress Rest API. So we worked on something called Picard. It's called back because it's to do with being the next generation of themes. So this is Picard. So I'll show off just quickly what this does. So if I click on, say, the nav here, and we go into the about page, you can see it's instant. There was no load time at all. And if we go to, again, this page, instant, and the content changes, if I close the menu down, go back to the homepage, here's where things get really nice. If we go into a story, again, it's instant. It loads, we get the full screen image, and if we scroll down, we get a normal post. And if we click on that left arrow for the previous post, you can see it just slides in, and we get some new content. And we can also do this with the keys. So I can go left, and we get another post. And each time the post is changing, it's just like Star Trek Ipsum, but it's cool. It's changing. And it's quite nice. And if I go back to the, well, actually, I can go to you. I want to see what's on this. So if I scroll down here, we've got comments as well. I'm going to move that out slightly. This wasn't actually Matt. We put those in. But just to show you an example, if I just type, oops. No. Lifetyping never works. This isn't real, but anyway, we can type something in here. Again, typing badly, I'm just going to leave it. That's what it is now. And if we post, it goes straight in. You can see that kind of experience is really nice. I'll explain how this all works in a little bit. But yeah, it's a really nice way. There's no page reload. It's like a real new way of building websites. It's really nice. So hopefully that gives you some idea of what's called about the REST API, but now to explain what it actually is. So there are going to be three main aspects to this talk. The first one being what is the REST API and how does it work? The second being how can you build things with the REST API? And the third, building themes with the REST API. So kind of wrapping up with the title and getting onto the nitty-gritty. So chapter one, what is the REST API? That's what it stands for. That probably doesn't help a lot of you. But yeah, representational state transfer application programming interface. There's a whole theory around what a REST API is. I won't go into any detail about that, but you can Google it and have a look if you're interested. But I have kind of put it into layman's terms that I understand. So a REST API provides a way to retrieve pure data, and it's usually in JSON or XML format over HTTP. And I've got, in the middle bullet point there, no loops necessary. And what I mean by that is that for most of us here, if we build websites with WordPress or we build themes or anything else, we would normally use PHP and we would create a loop and we would use things like the underscore title, bracket, closed bracket, and that kind of thing. And that's how we get our content out. Now, what the REST API does is it allows you to get content from your WordPress website, but without having to do any of that kind of stuff, you can just type in a URL and you get raw data straight back from the REST API. And I'll show you how that looks. And for this reason, it's very good for mobile apps, for example. If you take something like the BBC in the UK, their mobile app is going to want to get the same data as their website. And therefore, a way that they can do that is through something like a REST API. So rather than having to load a mobile version of the web or anything like that, they can just get the data. And if they were working on iOS, they can render that data in iOS' native view elements and they don't have to load up web views and that kind of thing. But it's great because if a journalist adds a new website via something like WordPress, the BBC don't use WordPress, I wish they did. But if someone did add a new story, it would automatically come through on the app. And that's the really nice thing. It's all linked together. And there's no maintenance needed. So how does this relate to WordPress? Well, the good news is there's a REST API and it's coming to core. Now, there's a short history of REST APIs. It's not all that new as such. I mean, it's going to be new in core. But WordPress.com actually introduced a REST API in 2012. Some of you may have used it. It's accessible if you use Jetpack. And the Jetpack guys are outside. They can tell you all about that. So you can get it for your self-hosted sites and you can also use it on any WordPress.com site. The core plugin, which is known as WPApi, is a project that I think began in earnest in 2013 as part of the Google Summer of Code. I think it was 2013. And so it's been running for quite a while now. It's available as a plugin. And I'll have links at the end. You can just install it and then you get a REST API. One of the first REST API plugins that I used, at least, was called JSON API. And that was added to the repository in 2009. It's still on... Is that a hand up? Oh, no, sorry. It's still in the WordPress repository. And, yeah, you can check it out. It's been around for a while. It was actually built as part of a project for the Museum of Modern Art in New York. They wanted to have a Ruby front end and a WordPress backend. I don't know why. That was something they wanted to do. In the examples I was showing you, if you want to develop a front end in Ruby, you're not going to be able to get data straight from a WordPress website very easily. One way of doing it is to have a REST API so you can get your data that way and not have to worry about loads of other custom stuff. So, yeah, that was one of the first ones I was aware of. There's lots of other third-party ones floating around now. So what does it look like? I've got an image of one, but I've actually... I've loaded some earlier. So I don't know how clear that's going to be. I'll zoom in a bit. So this is a response from the REST API. This is for that example site that I showed you, Picard. So I'm using Chrome. The top half of... Don't like panic because this is not... Don't worry about it. You don't need to understand this. But the top part is just the pure JSON response in one big string. In Chrome, you can get this quite nice readout at the bottom and it breaks it onto separate lines and it orders it alphabetically and that kind of thing. So this is the REST API. So if you just go to any WordPress website that has the current core plug-in and you go to the URL WPJSON, which is visible at the top, but it's probably incredibly small. So WP-JSON, like WP-Admin, you will get this. And that's the title of your site and, yeah, bit of other information. And then if you go a level deeper, so I've now gone to WP-JSON slash posts. Now what this will get, and it's the same site that I showed you at the start, is your sort of default loop. So it will get the 10 most recent posts on a default set up of WordPress ordered by date. And you can see the nice thing about Chrome here is it gives me this little readout and I can expand each post. And as you can see, if I scroll through here, I've got all the things that you would expect to see when you're building a WordPress theme. You get the featured image, you get content. If we keep scrolling down, you'll see things like the title. There's the title. Make it so. So this is how you get your, obviously things like status slug. I think you get category intags and all that kind of thing. And you can even get, so this is obviously showing you a stream of posts, but we can even query just for one post by its ID. So you can see here we've got post 17. If I go on one more, this is now just post 17. So all we get, and again, all I'm going to now is wp-json slash post slash 17. And then you get your readout here. So that's just one post. Same thing. So back to this. This was a, in case it didn't work, I had an image backup, which is showing that. So why are we talking about this now? As I've said, there were plugins in the repository back in 2009. WordPress.com has had a REST API since 2012. And suddenly we're now getting a REST API in WordPress core. What's the big deal? I think there's a few reasons why. Obviously, as I've said, it does help with things like mobile apps, but I think one of the biggest things that's been happening in the last few years is JavaScript, which has kind of changed quite a bit since I first started building websites. I remember when JavaScript was a bit of a joke, and you would use things like dynamic drive to find little crazy animated things that you want to drop into your website. And 10 years ago, it was largely frowned upon. People didn't think it was the kind of thing to rely on with a website. Some browsers didn't support it in the same way as other browsers, and it caused all sorts of problems for your users and problems in Internet Explorer and everything else. But recently, I say recently, it's been getting on for quite a long time now, probably the better part of the last decade, things have been changing. And JavaScript is certainly putting more and more power in the hands of web developers. If you don't know what I'm talking about, I've got some examples. Oh, sorry, I've skipped the head slightly. So, yeah, the great, a lot of the new frameworks that have come about for JavaScript are designed for working with REST APIs. And I think that's a big reason why there's now this big desire to get a REST API in WordPress. So some of the examples that I was going to show you, you've obviously got the big server-side JavaScript implementation of Node, which has been huge and has sort of led to the Node package manager, NPM, which some of you may have dealt with, and it's a way of getting bits of JavaScript that you'd have packaged up in different ways. There's obviously things like Backbone, Angular, Ember, React. Something I found interesting when I was first looking into doing this talk is that Backbone, Angular, in fact, everything on this board either didn't exist or had only just come into existence in 2009. So when that first REST API went into core, there pretty much weren't any JavaScript frameworks for working with REST API. Or if they did, they were very small and they were very niche, and they weren't seeing the kind of wide level of use that we have today. And as I said, like Backbone, for example, is pretty much exclusively designed for working with REST API. That's what it's for. And the others, in their own ways, are very much set up for working with JSON and REST APIs. Except Node, I don't know if you can see, because that's the server thing. But I'll zoom out slightly. I found this really good quote, which I quite like. Some of you might be wondering, you know, how this all ties together. And this is Trek Noowski, who's on the core team of Ember. And I'll read it, because it's quite nice. He said, since the start of the web, for every interaction, there have been two supercomputers involved, the supercomputer sitting in front of you and the supercomputer in a data center somewhere. We've barely begun to take advantage of that supercomputer sitting in front of you. And it's a really good point. When you look at some of the things that browsers can do now, and you look at what happens when you use an app on your phone and what native applications can do, we're really not doing anything with browsers now. There are some things that are pushing the boundaries with them, but the vast majority of websites today are still the standard, you know, page loads, you click a link, page goes away, another page loads, you click a link, page goes away, and you lose your internet connection, it just says page cannot be displayed. It's a naff experience, and if you think about mobile apps, if mobile apps did that, you'd think they were rubbish, you know, if there was no interaction, there was no transition from different types of content to other different types of content, you'd give it a one star. But on the web, we're still just kind of used to that, because that's what we've always had. So, yeah, I really like that quote. It kind of summarizes the feeling, and there used to be the things about browser compatibility and progressive enhancement, but the fact that the matter is most browsers today can handle most of the cool things you could do with animations and loading content on the fly. So, second part of the talk, how can you work with a REST API? The most common way that some of you have probably heard of is a single-page application, or SPA, this is the kind of umbrella term that's being given to websites that do this kind of thing. So what is a single-page application? It's not a multi-page web application, which is sort of the term for the traditional website. So that's kind of how we can differentiate the two different things we're talking about. And as I say, multi-page is where you just have a set of links, and it's just the standard, it's the web, it's kind of the original way that browsers read the web. And generally speaking, it will have only one initial server-side page load. So, users will come to your site, some content will be loaded, and from that moment onward, the content is being loaded dynamically, and they're not actually rendering on the server again from that point onwards. And therefore, all interactions are handled with JavaScript. So when a user clicks a link, you don't let the browser do the default thing. You stop that happening, and you get in the way, and you do something else instead, like load some content from the REST API, and bring that back to the user. And when done well, it provides a more continuous and fluid experience. And it's nothing new. This is Gmail, which I'm sure some of you are familiar with. And this, I believe, went live in 2004. This was kind of one of the first really big single-page applications. And the big term that was around when this came out was Ajax. This was kind of the birth of asynchronous JavaScript and XML. And yeah, it was that idea that you would go to Gmail, and from the moment you actually hit Gmail.com, when you click through the links on the left-hand side, or you clicked into your emails, it was never actually reloading the page. It was just getting new content and bringing that back into you. And obviously, that's good, because why, you know, if you've got all this content here already, why throw the whole thing away to load the whole thing again, and throw the whole thing away, load the whole thing again. So this started to move people into this idea of thinking actually this wasn't such a bad thing. And Gmail, fortunately, was kind of the canary down the mine, who managed to kind of find a lot of the problems, work out ways around a lot of the problems with building a site like this, because it's not easy. And certainly, back in 2004, it really wasn't easy. It's also worth pointing out, while we're talking about single-page applications, that they're not all or nothing. And by that, I mean, you know, a part of an app can be a single-page application. And where Prosteams and plugins have steadily done more and more of this, there was a mention in the last talk of easy digital downloads. And for example, on the sales dashboard, the sales update automatically. You don't have to kind of refresh the page to see if anything new has happened. And there's little things like that that have worked their way in throughout the internet broadly, but certainly there's lots of WordPress plugins, lots of themes that have little bits of this within them, but very few full-on, full-page applications. So, and yeah, and the key one actually, to what speaking of single-page applications, is that we have Backbone in WordPress Core since 2012, and that is for this reason. This is the customiser, the theme customiser, which hopefully people are familiar with. And as you know, if you've played with the customiser and all WordPress websites have it, if you just go to Appearance, Customise, you'll get this. You can change stuff on the left-hand side, and on the right-hand side, the iFrame will dynamically refresh with the content that you're adding on the left-hand side. And often, actually, the content is added immediately. So, in something like 2015, if you change your site title, it will happen dynamically as you type. It's really nice, and so it's kind of WordPress with its own single-page application. So, what can you actually do with the REST API? I've kind of shown some basics of what comes back for a simple get request. REST API is centered around a series of verbs. The basic ones are get, post, put, delete. There are more, but we don't need to go into that now. You can always look up kind of all the different ones that can go alongside those. And, obviously, fundamentally, get allows you to get... I'm going to disable my notifications. Should have done that before. Oh, God. Okay. Never mind. Right. Get, yeah, allows you to get post, pages, comments, et cetera. You can edit and add post, pages, and comments via post or put, if you're adding. They're at the back rounding me up. I can see this. Right. Excuse me a second. I'm going to... I will actually get rid of them. There we go. Right. And finally, we have delete, where you can, yeah, delete, post, pages, and comments. So that's the kind of basics of the REST API. Didn't I say something about themes? Oh, wait. It's the title of this talk. So let's get on to the idea of actually building themes that use the REST API and how am I doing for time? Not bad. Okay, a couple of minutes. Cool. So why would you build a theme that uses the REST API? Hopefully, I've made the case clear, but in case I haven't, just to kind of summarise what I'm trying to say. What we're actually talking about is building themes with JavaScript. The REST API in itself, as you can see, is a way of getting data, but it's not actually... You can't just build a theme with it. You need something else in the way. And if we're talking about improving engagement and we're talking about making these more futuristic websites that don't throw the whole thing away on each page load, we're going to need JavaScript. Now, there are some very clear benefits, I think. The top one for me is the look and feel. You've got this much more engaging user experience. As the user moves from bit of content to bit of content, there can be potentially no page load at all if you've got content ready to show them. And it's a much more human interaction. People expect things to sort of move around. When you're reading a book, you sort of turn the page and the page flaps over and you get some new content. You don't look at it and then it stops for about three seconds and then a new page appears. That's just not what we used to. And that's what most mobile apps try and replicate. They try and imitate that sense of actually moving from content to content. The second one is the speed. So as I've said, you can queue content up because you can just get data in this really simple way. For example, on Picard, the reason that that theme I showed at the start can actually get the same content. So say when you're on your homepage and you have your list of posts, you click and it loads immediately. And the reason is that as you saw on the rest API response, all of that content that makes up the post, we've already got. So when we load the homepage, we get each post's title and we get each post's featured image, for example. But we've already got the content because that comes back anyway. So why throw that away? So we just store it all and wait until the user actually clicks the post and then it's already there. We don't even go back to the server. There's no other request. It's all done from the homepage. And technically you can do whatever you like with this. There's most rest APIs allowed for a batch request. So for example, you could request the top 10 posts when you first go to the server. But you can also request all the navigation, for example. So all the different pages on your navigation or if you've got hundreds of pages, you're obviously going to want to limit it a bit. But you can get, say, the top 10. You can use analytics to see what things most of your users are doing. So you know that most users are probably going to go through a similar process of using your site. So use a news website example like BBC again. Most people probably come to the BBC. They probably click on the top most recent story. So you know why not have all that content ready? Why wait and have them do exactly the same thing they always do and then still load it after they've got there when we know what they're going to do anyway? And as a few other people said, like the SEO talk as well, speed is everything. It's very important. And you can reduce load times to literally, well, almost literally zero because you're not actually going back to the server. As I said, we also take control of interactions. So we can say what happens if the user is offline. If they don't have a connection, we can say, oh, sorry, you're not connected. But we could also say, you know, we've already stored this data because you came on here when you did have a connection. So we have the 10 most recent stories. So while you're not online, like, you can still view those. They can still load. It's really exciting. Whereas, you know, what happens mostly for users is they'll click a link when they've gone, say, in London they'll go in the underground. There's no internet. So it just drops. You do have 3G in the underground here, which I noticed, which is very nice, but we don't have that. So it's really nice. And then obviously you've got the potentially reduced server load because you're not going back to the server every time. You're going once, you're getting a batch of content, and you're done. And that kind of ties in as well with the ideas of, you know, smishing all of your CSS into one file these days. You know, we used to have, like, people used to like to separate everything up and you'd have like 15 different CSS files. That came up as well in another talk. But ideally, you can just have one. And that's that same kind of thing. You're just bringing everything down into one request for most users. Only fringe users who are going to go really far into your site are going to need to get more requests. Obviously things like images and stuff are still going to load from the server. So it doesn't cover everything. But yeah, they're the benefits. So how can you get started? I think there are two main routes that we can take today. And I've kind of shown the two of them at the start of the talk. The first one is the build the news example. And what you have there is an angular front end. And then you've basically got a full JavaScript experience from that point. So the WordPress is the data storage. And everything else is happening through Angular. Now, that's really good. And certainly for big projects I can see that being a good way of moving. The problem with that kind of approach is that you can't install something like that. Because if you're trying to build a theme, for example, and it's just an angular front end, then you need to put it somewhere. So in that case they have kind of a node server that's running that angular front end. And then they're interacting with a separate WordPress thing on a separate domain. And there's a whole kind of back and forth going on the whole way through that. But they can't distribute that very easily. And if you're a theme developer or a plug-in developer or you want to do more of this kind of thing now, you need something to allow you to do that. There are also, I should say, lots of default things within WordPress that would quickly cause you problems. So, for example, what happens when a user is creating a new post on the back end and they click for you post? Because that's going to have a standard thing that WordPress does. Or if they want to prove you a draft, that's not going to work. Because if they do that, it's going to just go to some different site or whatever. And obviously, you could have a different site that mimics the Angular front-end or whatever, but it's going to get a bit messy and you probably don't want to be dealing with that. The second route, which I think is possibly better, is to have a skeleton theme, which can be installed. So you have an index.php and you have a style.css, which all themes have. And then you don't necessarily need much else because the rest of what you're going to have is going to be JavaScript. So the user can take your theme, they can install it, but you can do all this weird and wonderful stuff from that moment, which is pretty exciting. So that's the route that I'm taking. So I'm going to briefly, I've got about, well, what have I got? Fine, not that much time. Anyway, I'll quickly go through the last bit. So I'm going to go through some ideas around how you could do this. Obviously, as soon as we hit this point, it becomes opinionated because, as I said, you could do something with Backbone. You could still use Angular in this setup. I've gone around everything pretty much. I've tried using Ember, and Angular, and Backbone, and a few others. And I've sort of rested on what I think is the simplest way of creating what I've been showing you. And this is what's behind Picard. And that is a vanilla JavaScript base. So not necessarily using jQuery. You can use jQuery, but my feeling is that jQuery creates a level of abstraction. But if you're going to build stuff with JavaScript, it's better to really understand what's going on. And actually, you'll see when I get to this, there's very little JavaScript that's actually needed to get some of these things happening. And I think it's better to understand what's happening rather than kind of just have these jQuery functions that might be adding bloats to your project that you don't need. React, which I'll explain in a little bit, is an interface library. Browserify is a build tool that basically allows you to combine all of your JavaScript into one file. As I said, you don't really want lots of different files. This allows you to build themes more like you would build a WordPress theme with lots of individual PHP files. But you can do the same thing with JavaScript instead. And you can, if you want, follow the same sort of structure. And then something like Gulp. This is, again, this just allows you to run tasks automatically. So when you update your files, they automatically all get squeezed into one. So if you update your JavaScript, it runs all of that for you. You may have had a grunt. There's also you can use the old make files. From like 30 years ago, you can use make. There's lots of ways of doing it. But Gulp is one way of doing it. And it's pretty good to sort of cross-platform. Am I nearly out of time? How long? Oh, OK. Cool. So let's drill a bit deeper into each one. So we have vanilla JavaScript. So the three sort of, well, actually, the two main things, one's just like a little bonus thing, the two main things that we need from JavaScript, as well as obviously just the general syntax. But the two functions we're probably going to want to use are the XML HTTP request, which you've probably all seen in one form there's like jQuery Ajax, which uses the same thing in jQuery post. That is basically the core function that allows you to make a request of an external service. Technically, with using the WordPress REST API, it's JSON. So it's actually a JSON HTTP request. But anyway, they didn't think about that when they put it in. So that's what it's called. You've then got something like local storage, which I've mentioned. That's your way of storing responses from the server so you can come back to them. Local storage is it's in, I think all browsers going back to, I think at least IE 9. So, yeah, and it's sort of allows you to store data in the browser's memory. And that's what Picard was doing. That's how everything loads so quickly when the user first hits it. There are some other things. ServiceWorker is actually in Chrome. Has anyone heard of ServiceWorker? Okay, cool. Very cool. So, if you haven't heard of it, it's a, what's the best way to do it? It's something that Google are working on. It's, it basically allows you to control what happens when the user doesn't have a connection. So, in the normal example where a user will come to your website and if there's no connection, it will just say this page cannot be displayed. If the user has been to your website before, then the browser that the user's using will know that you have the ServiceWorker. And so actually you can control all sorts of stuff together where you already have data stored in local storage. It's really exciting. It's in released version of Chrome now. It was in Canary for a while. It's certainly going to be a big thing down the line with this approach to building websites. So that's why I throw it in there, but I won't go into any detail on it now, but there's some great talks that I'd recommend watching about how it works. So, React. There's a talk coming up after this, so I won't go into too much detail. React is a JavaScript library using user interfaces. It was developed by Facebook, and I think it powers the entire web experience of Instagram, and it was open-sourced in 2013. I've got some links at the end for resources on it. It's really nice. It's really lightweight. It's not a framework. It just helps you build user interfaces, which if we're talking about theming is quite important. This is what React looks like. So you can see it's essentially it's a JavaScript class with a render method. So, you can hopefully see how this works. Sorry, but I mean, in this example, the mount node would be the node in the browser that we want to attach this to, so it could be like div, id, main, or something like that. This is taken straight from the React home page that Facebook has set up where they have some live demos that you can tinker with. Now, the thing that might look really weird if you're looking closely is something called JSX. And it basically allows you to have HTML inlined in your JavaScript, which may seem horrible, but it's not. And obviously, this doesn't actually go through to the, this isn't rendered by the, sorry, it's not read by the browser, it gets compiled. So, you write it one way and then when it's actually smushed into one file with browser file, something else, you can compile it into normal JavaScript and then it just becomes, you know, normal objects. But that's where you can kind of see what it allows us to do. But it's great because it means that you can have designers, you can have people that don't understand any of this JavaScript and they can still play around with the HTML quite easily and it's still readable and to be honest, it's much more fun than writing things like that, which is one thing I would say about it. So, how might a JavaScript-based theme look? So this is the current standard that we're probably all used to. There's some things missing, I haven't got which hopefully looks familiar to most people here. Now, how could it look? Well, it might look like this. So here we have the two core things that a theme actually needs and that's an index.php and a style.css and from that point it just goes completely different. So we have these different components which are built with React and JavaScript that I was talking about and the JSX thing is the, that's the React thing I was talking about. So they could just be pure JS files, it could be, React, it might look a bit like this. So we have our kind of core, our theme name.js at the bottom, that's going to be where the core stuff goes on that kicks everything off, the boot as it were that sort of takes control and I'm going to go into a couple of these of what these different components actually do but yeah, it all effectively gets compiled into theme name.js and then that's the JavaScript file that it's going to take over when the user first hits this theme. So, I'm going to go into how this works, I've got just a few minutes so I'll be as quick as I can. It's on GitHub if you want to have a look at it and I've just tidied it up a bit, it was a bit messier and now it's a bit neater before this talk so you can see there's actually some commits pre-WC Vienna update. So, I'm going to go into how this works so I'm going to go into how this works so I'm going to quickly go into how this works I've got just a few minutes so I'll be as quick as I can. So, I've got a bit of an explanation as to how it works I've got two minutes so I'm going to have to really whiz through this. So, you can see there's a load of stuff here like you've got the things like the gulp file.js and stuff, that's not something you would necessarily need to worry about and the git ignore and stuff. The key thing we have an index and we have a style.css and we have picard.js so the components directory this is where things get interesting and to demonstrate what I mean about how small this can be that's picard.jsx that's what starts the whole thing off it's that much JavaScript so we're using this require thing that's Browserify there's also require.js some of you may have heard of but we're pulling in the router which is a component that we need and then the way I'm rendering that that's how React can do that so I can pull in the router component as a variable and I can then render it like that and I'm rendering it on the main element with the idea of main in the DOM so the router what does this do now we have the luxury of not having to worry about this but when you build a theme with JavaScript you do need to worry about the router the router or router as Americans would say basically controls what happens when the URLs change so we have the I was talking about taking control of the user's interactions so we can't rely on PHP dealing with that we're going to need to do that ourselves so the most important one here is that if it's a post I'll quickly highlight the text so it's from page to so this is what's important for this particular theme what we're doing is we're saying we're working out what the slug's going to be sorry I'm using a little JavaScript library called page which allows you to kind of simplify how this could look you could roll your own completely but there's a JavaScript library called page.js we're taking the URL to find out what the slug is because that's all we actually need and with the REST API we can actually and you can see where it says URL we can use all of the things that you could use with WP query so we can say WP.js and slash post slash and then we use these filters and we say we want the slug that matches the slug from the URL so oh and then and then we render the content element with the data that we get back and I'm running out of time and we're also doing a super agent request do you know what I was going to go into this I might just stop and you can ask me questions it's all online and I can talk about anyone who wants to talk to anyone about this who wants to talk to me but I'll answer questions and I'll just stop here and before I do that thank you thank you all right so we have time for three questions so one is there who are the other two one is there third one okay two one and two please hi thanks for this lightning speed talk sorry I'm wondering you said Google is very involved in this right obviously they've been using this for a long time but I'm just thinking from my SEO perspective right is Google able to crawl understand and make sense of my site if I built it in this way because basically then there's just one URL right yeah yeah well so that's something I didn't actually manage to get onto what this theme does it has an index.php file and that is the fallback it's not the same experience but it does have the basic loop in it so for any URL that the user hits without JavaScript enabled or a Google crawler they're still going to get that content back and they're still going to have the H1s and everything and actually I should have also said it does change the URL so if you look at the top it's annoying because it's quite small if I go back the URLs are changing as I go back and forward the animation is the same whichever way you go which is slightly confusing but if I go back so the URLs are changing that's using that page router that I mentioned so you could send someone a link from a website and they could turn JavaScript off and technically this would still work because it's in index the index.php can control it and it will still handle because with JavaScript off the links will work and everything you won't have the animations and you won't have the flashy cool stuff but it works enough for a crawler a quick follow up to that sorry, quick is that I don't think it's been officially announced yet but I heard a podcast with one of the other guys remember it wasn't Trek it was someone else and he was saying that he gave a talk about Ember at some big conference and was talking about how to deal with the SEO aspect of this and he was actually contacted afterward by someone from Google who said we can actually crawl sites that are using JavaScript rendering so I don't know how good it is and I don't know if they're officially saying they do it yet but they are actually supporting it now so they can read JavaScript and they can get that content and with React if you're using Node with React you can render on the server so you can actually turn JavaScript off on a Node-based site that uses React and it will still work as well yeah yeah I was going to ask about SEO as well so thank you you just answered that okay so I'm just going to ask you in your opinion when will this be production ready when can we actually use it for client projects I mean theoretically someone could build something really good now and there are some things popping up so that Picard theme I showed we're still working on that that's hopefully going to be open sourced through automatic hopefully by the start of next month and it will handle most things it will deal with static home pages and all the different settings that a user might want to have we've got some ideas around handling widgets and sidebars obviously lots of plugins will be broken temporarily but yeah who needs plugins so but yeah a lot of plugins do still work if they're filtering things like the content that will work fine so theoretically you could do it now like the browser supports there there's no reason not to and hopefully the WPAPI going into core is going to really push that and make people start building things this way there's obviously sites like Quartz and stuff available now and the last thing I was going to say is that I hope I'm doing all I can to make the next if the rest API goes into core this year I think the next default theme should be built this way but there's some resistance understandably so just very very quick follow-up is it is it theoretically possible to build a hybrid theme that uses the standard PHP structure but leveraged in progressive enhancement to use the rest API if that's available yeah and there are there is actually a theme on webpress.com called collections which uses it was built by the theme foundry and it's on I think it's available for self-hosted sites as well so yeah you look at collections and I think there are some others and there's other people working on this I've mentioned Cabin White who wrote this post at the bottom in fact it's a talk he gave like there's some big companies that are using it already now Wired are actually building part of their website using this with webpress and it's a hybrid as you say so halfway between the two yeah cool thank you very much cool thank you