 How's it going guys? Before we get started, I'd like to get a picture of the crowd. I wanted to do this in my first talk. If everyone could just wave. Alright, I appreciate that. So today we're going to be talking about headless WordPress and server-side rendering with Next.js and React. I want to be a little upfront here. I had a live coding session planned for this. A couple things went awry with that. Number one, I had some errors in my code and couldn't get them out. And number two, we're actually running very short on time. So this is going to be more of an introduction to Next.js and React and what it can bring to you and how to use it. So first of all, hold on just one second. Let's see where are my notes. So first of all, what is server-side rendering? Normally when using React, your browser will download a minimal HTML page and then from there JavaScript will actually fill that page up with your content. With server-side rendering, the initial content is already within the browser, or already within the page and updates to the content are still dealt with through the browser. So what is a headless website? Sometimes called a decoupled website. With a headless website, there's a database-driven back-end which in the case of WordPress is used to maintain the content for the site and is decoupled from the front-end to allow you to use the tried-and-true editing experience that WordPress offers at the front-end or another view library. The content for the site is available via REST API or a very different API, up to you. The end-user experience is delivered by a JavaScript application rendering the output of the API into the built-in-styled front-end of the website. A couple examples and variations of headless sites. So just recently at Human Made we launched the redesign of TechCrunch.com which is decoupled, but it's not actually isn't entirely decoupled. It's very decoupled, but it still uses WordPress theming. Essentially what we're doing is the WordPress side of things. It just renders the minimal HTML content as well as the all the scripts that are necessary to load the content and everything after that is asynchronous, but it's not fully decoupled. One's not running on a node server and then you have your PHP application server. It is still just one application. Another example at Human Made we recently also launched Fairfax Media's new sites. Fairfax Media is the largest media corporation in Australia. Their sites are Brisbane Times, The Age, Sydney Morning Herald, and more. And in conjunction with Fairfax Media at Human Made we created an entire custom editing experience for them to maintain all their content and then they had their own internal team that went ahead and had their own data layer on top of that that then fed their front end of their websites which are all React-based. So this is, this one is an example of a totally decoupled site where you have the React site running on a node server and you have WordPress running on a totally different location. So what is Next.js? It's a server rendering React applications. It was created by Zite and released in October of 2016. Zite is an organization that is stable. They're very involved inside the open-source world. So Next isn't going anywhere anytime soon. It's here to stay. And it's built to follow the seven principles of rich web applications written by Automatician Guillermo Rausch. Those seven principles are server render pages are not optional. Now this is something that is a little bit opinionated but with the world that we're living in today where it's not just Googlebot that you have to worry about scraping your site, there's social previews. If you paste a link into Slack, the same thing. You want these types of things to actually still be able to retrieve your content and show the user a preview of them. And without using server-side rendering you're really missing out on a lot there. You should be able to act immediately on user input. In JavaScript we can essentially make it to where it looks like there's low latency just by performing an action and then running the actual networking of that in the backend. Take for instance you're in Gmail. You go to archive an email and immediately that email flies off of your screen. Really in the backend it's still running that operation to archive that. But as far as you the user is concerned there's zero latency there. It's automatic as soon as you do it. Your code should be able to react to data changes. So your UI should be self-updating. When data changes on one side it should flow to your front end. You should be able to control the data exchange with the server. Don't break the history. This is something huge when you are controlling the history and not the browser itself. When you're adding things to the push date you need to make sure that if you're hitting the back button that it's not breaking for the user. That's a bad experience. Push code updates. With your data also comes code updates. If you have one without the other you're going to get a mismatch there. So essentially what Next.js provides is hot module replacement thanks to Webpack to be able to actually replace the modules hot swapping them on the fly as you change in your website where you're located at. You should be able to predict the behavior of your user. With Next.js it's done with prefetching. Essentially you can load a page and all the links on that page you can tell it to prefetch it. If I'm the user and I click on any of those links it's going to load instantaneously because we've already prefetched all that data while I've been reading the current post that I'm on. So things to consider when you're considering to do server side rendering. Server side rendering usually increases the performance of your app but not always. Server side rendering helps with search engine optimization. Now we all know that Googlebot now can parse JavaScript render your content in there but it's all based on a time. It's not based on when the completion of your code has actually been finished. So if you have long running processes that are going to be filling the content of your site by the time Googlebot actually indexes it it probably will only see half of that content while it's still trying to fetch the rest of it. And complexity. So obviously when you add server side rendering you're adding another layer of complexity and this makes it to where it's harder to address bugs or implement new features because you're maintaining server side rendering. So these are just things to keep in mind. Now that's not to turn you off from it either. Why should I use an XJS? So a lot of us create PHP apps and when you're using something with PHP usually just start coding you don't have to worry about routing not much at least you don't have to worry about things as far as how you deploy it you just start coding and go. And that's kind of what you have with Next. Instead of PHP we build the application with JavaScript and React and here are some of the cool features that React provides. So by default you're already server side rendering just by serving it with Next.js. So don't make it to where your HTTP responses are definitely going to be longer than they were before especially if you're under heavy load or if you have a DOM list of thousands of nodes a large table it's very easy for this to to balloon out of control a little bit. You get automatic code splitting for faster page loads. So essentially depending on where I'm at in the site it's only going to be loading the modules that are actually necessary for what I'm viewing at the time. You're not loading any code that isn't needed and this is all done automatically just by throwing your stuff into Next.js. It knows what to pull in and when. Simple client side routing so this is all based on pages essentially there's a pages directory in Next.js and within there you put JS files for every single one of your pages or routes and that is how all the routing works. It's not some complex React router and you also don't have to do on the front end and the back end essentially using the page based routing of Next.js takes care of both sides there. Webpack based dev environment which supports hot module replacement now I touched on this a little bit before essentially it adds and removes the modules that you're currently loading based on where you are in your site without doing a full page reload and this significantly can speed up development process. You retain the application state which is lost during a full page reload you save valuable development time by only updating what's changed on the front end of the site and you can tweak styles so much faster with hot module replacement it's almost like as if you're inside the dev tools essentially just changing things in the browser as soon as you save it's automatically loading that but it's not doing a full page reload it's just loading the new styles that you've saved. You're able to implement with Express or any other Node.js server so if Express isn't really your liking there's a ton more out there and you can use pretty much any of them and you can customize it with your own Babel and Webpack configuration so out of the box it already is configured to run how it's supposed to but if you want to tweak those if you want to add things in totally possible and very easy to do within the next config there's also prefetching so prefetching picks up where code is splitting left off Next.js allows us to all of our optimized bundles to be lazy loaded behind the scenes using prefetching and there's actually fantastic error reporting and I know what you're thinking error reporting how can it really be that fantastic but the way that the error reporting comes back to you it's in such a readable way that it makes it a lot easier to pinpoint where the issue actually is and not an issue that's you know called ten times after that every developer knows the struggle of fixing something and it ended up being something trivial that you spent two or three hours on we've all been there and with Next.js it really just makes it a lot easier to avoid that so how do you get started with Next.js pretty basic we're going to create a directory just called hello next cd into the directory we're going to initialize an npm package that will just essentially create our package JSON from there we're going to install and save React, React DOM and Next and we're going to make a directory called pages as I said before this is where all of our routing is going to be located at so so far our tree looks like this we have our package lock our package pages directory and a node module directory obviously I deleted everything that was in the node modules directory otherwise this slide would not fit inside your package JSON you want to just add in a script here and your dev is just going to run the command of next build is going to run next build and start runs the server the next start to get started you only like you can use Windows, Mac or Linux all you really need is just node.js install so inside your pages this is a very simple page obviously we're just exporting the default we're just literally just saying welcome to Next.js and there's actually a bunch more in Next.js but we are running short on time there's 15 minutes until the closing ceremonies and I wanted to leave room not just for questions here which I'm sure you have a ton because I didn't go over too much but also leave room for questions on my ES6 talk as well as I said I had a coding session to demo here but it wasn't working which I guess kind of shows that maybe the error messaging isn't the best there isn't as good as I tried but that's where we are for today so thank you is there any questions on this talk or even my ES6 talk that I went over earlier that I wasn't able to get to for the ES6 talk I will have them up I'd say within two hours of leaving here this one I'll have up as well then I will put them up on Slack yes I don't know if I can just export from slides to be PDF or I'll just share the link to the actual slides there was also there was a question in my ES6 talk someone asked about ArrayFind and how that differs from ArrayFilter and I was a little bit incorrect there when I had answered after thinking it over a little bit more ArrayFind will actually provide you with the single element the single object that you're looking for whereas ArrayFilter is going to provide you with an array with that item in it so that's the difference there any questions yes that's a very good question especially with WordPress it's something that has been debated I've talked to Bobby about this and Bobby's working on something right now I know oh yes how do you work with authentication inside of a headless app so there's a couple different ways to do it and it also brings up the question of should you do it if you need authentication like do you have the resources for this app to build that all out usually if you need login it's usually like for at least a WordPress site on the front end it's usually going to be for commenting or anything like that that's usually pretty basic and I would usually just say use a service for that but if you actually need interaction on the front end like almost like a forum or any other type of interaction on the front end where the user actually has to be authenticated I would wait until more tools are produced for that because right now it's kind of up in the air even the creators of the REST API hey how do you do authentication on the front end where you want them to be able to authenticate it's still opinionated and not really locked down yet so I will tell any other questions that's easy older browsers polyfills like there's still things that are not that even though ES6 is implemented there's still features that still need to be polyfilled I believe and maybe you could correct me maps, weak maps I believe those are a polyfill so it's more for the advanced users like if you're using constant let I would still run it through Babble just because you're going to maintain that support at least for a little bit longer people are still using IE11 you know unfortunately it's just it's the truth if you don't care about those users I guess you can absolutely not so essentially Babble just takes it and transpiles it into ES5 code it will do it on the fly essentially you would have a build system so when you're deploying your application you would have Babble go ahead and build it and from there you're referencing only the ES5 code can you repeat the question I'm sorry fully working component with all the content already in it essentially everything that you're going to see rendered on the front end when it renders whether it's a React app or a Next.js app what you're seeing there is what Next is going to deliver build out HTML absolutely and so essentially when it loads it to the front end it still has those React references to everything so say I do an interaction like after my page loads I go ahead and I click on a new page it's going to know to change out the main component with this new component but it's not doing a full page refresh then so essentially once you load the page and you start interacting it's just acting like regular React on the front end but if you were to actually fully refresh the page or if you were to copy the link and send it to someone in Slack it's going to pull up the preview based on the content that's actually produced from the back end of Next.js great we have 9 minutes until the closing ceremonies is that in another room anyway perfect then it gives CBC 155 I'll see everybody there