Guillermo Rauch - SeattleJS Conference 2017

Our closing keynote, a fellow who needs very little introduction, talking about Next.js 3. Everybody give it up for Guillermo Rauch. Thank you, thank you, thank you, thank you. So, um, we've been working on this thing Next for almost a year now. It's a framework that we created to work on our own product Zyte. We wanted to have this really awesome web application that was highly dynamic, but also had a lot of static parts. So at Zyte, we make deployment really easy to do with one command, and we have a lot of documentation. We have a lot of pages that are like user profiles. We have lists of deployments. We have real-time logs. So everything that has to do with your cloud, we render on online, so it's a very interactive React application. When we started designing it, we were faced with the problem of how do we start? So we make deployment really easy to do with one command, but we didn't find the tool that did that for React applications. It required a lot of bootstrapping. It required a lot of effort just to get going with a really simple application. So on one hand, we wanted the simplicity of let's get started with one command, zero config. On the other hand, we also wanted this tool to address a very general, uh, set of scenarios. So what you're looking at here is actually my presentation, which I built with Next.js itself. So you're gonna see that I can go back and forth throughout the Next.js routes and so on, but this is all just a very simple set of React components that get exposed as routes with Next.js. Other things that we've created with Next.js include our main website, so you can go to it. And what's cool about this presentation is that you're gonna be able to see the results and we're gonna deep dive into how they were created and what features Next.js has enabled. So this entire application, which kind of feels like a single page application because the transitions are immediate and every page has been preloaded in the background, is also a Next application. Another one that I'm going to show today is my personal blog. So I wanted this tool to be so versatile that you can go from something that's rendering a lot of data in real time, something that incorporates components like React Virtualized, but also something that could, for example, be a simple exported static website like my blog. Yet also, thanks to the awesome React lifecycle, could have real interesting properties once the React components are mounted. So for example, in this blog, every time I get a view, you see a little real-time counter. Um, if, if I open or refresh this one, or if someone, uh, helps me out, so you're gonna see that change in real time. So React allows us to do server-side rendering, and then when the components boot up on the client, we can start changing data and mounting and mounting components, et cetera. So everything from the spectrum of really static to super dynamic, you can solve with Next.js. We wanted to make it easy and simple. So I'm gonna demonstrate now how to get started building a really basic website, uh, with Next.js. So for that, I prepared, I prepared all my demos, but we're gonna start with new. So you're gonna see that there's only 3 basic dependencies that are involved with the Next.js application. Obviously there is React and ReactDOM. And the cool thing here is Next doesn't embed those. Next makes sure that you can bring in your own React. B-Y-O-R, bring your own React. And then there's, like I said earlier, there's a very simple command just to start developing your application. So if I run dev or if I just run next, I get started developing my application. So first next tells me that I have no pages directory. So what I'm gonna do is I'm gonna create it and now I'm gonna rerun it and hope it works. So you're gonna see there's a, a little bit of a delay initially. So this could seem a bug, but it's actually a feature and bear with me. The reason that it's a feature is Next.js acts as a compiler. So it takes all your dependencies and always ends up with unique bundles for your application. So the reason it's taking a little bit of time is like this is under the hood running Webpack within, with the dependencies that you defined. So I'm gonna create a, first of all, I'm gonna go to localhost:3000 and you're gonna see that you get a 404. Which is to be expected because the application has nothing in it. So the only contract that Next.js requires from you is that you export in your code splitting entry points, and I'm gonna get into that a little bit more later. Every page that you create has to export either a class or a stateless functional component. So you're gonna see, I'm gonna save this file. Ooh. Sorry about that. I'm in the wrong directory. And I need to type my buffer again. All right. Now we're good to go. So you're gonna see that it immediately reloaded to what I just created. So an, an interesting property of Next when you're developing is that it also sets up the hot module replacement pipeline on your behalf. And as of 2 days ago with this, uh, stable release of Next.js 3, it's actually really robust. So what happens sometimes with hot module replacement is like, it's really cool for like 2 seconds and then it starts breaking down. It breaks down when like you have thousands of components or pages that are being monitored. It breaks down across platforms. It just explodes in a million ways. But as of Next.js 3, it's really— it's pretty solid. Now hopefully it doesn't break throughout this demo. So the idea is that as long as you maintain that contract that your page exports a React component, you can sort of bring anything in. So one cool feature that we have is you can sort of style with what we call styled.jsx. So this is similar to what style scoped was gonna be for the web, or you can imagine this as a shadow DOM component where everything that you define here is limited to the scope of your component. So when I apply that style, you're gonna see that actually under the hood, it's being compiled to a really strange looking CSS selector. It's strange, but it has a really cool property. Your styles are never gonna be competing with other styles that you define elsewhere in your application. So this is a kind of a cool default that Next.js comes with. It allows you to write CSS in a way that doesn't break the world, and that's kind of cool. So if you don't like that, you can still do your own thing. So you can obviously If anyone from React Core is here, they probably love inline styles and so on. So you can do this. Great. It looks beautiful. So as I said earlier, you start with pages. Within pages, you define all your entry points, and those become your pages. So if I wanted to create another page, I go to second.js, and I go export default. Hello world 2. So here you see I created pages second. So automatically Next.js will set up routing for these pages. And as I said earlier, one cool property of how Next.js does hot module replacement is each page becomes its own universe and gets refreshed and monitored and recompiled. So if you have a very large application with a lot of entry points, if that entry point is loaded here, only that gets monitored and refreshed. So if I make changes to this, you're going to see it's really instant. And on the background, the other one is getting unloaded, and it's not monitored anymore. So this sets up a really nice and scalable system for pretty much creating any sort of application that you want. Okay, what happens when we wanna go to production? Typically when you wanna go to production, you have to start changing your settings because you have to say, well, we have to apply minification, we have to run React in production mode, we have to perhaps do a little bit of smarter code splitting and sharing bundles between this entry points that are your pages. So Next.js also makes your life a little easier there in that there are two steps, build and start, that are meant for production. If anyone here is used to setting up Dockerfiles, for example, you know that in the build step, you want to run things that perhaps take a little longer, but then you want to make your boot-up time instantaneous. And that's what this divide between the build step and the start step does. When you run next build, it actually takes quite a bit of time because, for example, if you have a really large codebase and you're minifying and— stuff like that, it can take a little bit of time. So once it's done, is you pay that price ahead of time, you run next start, and your application will boot up immediately. So that's all you need to do really to go to production with any, any Next.js application that you build. So I mentioned earlier that we kind of have this versatility in what you can create. So I brought an exa— I brought a few examples for today. We're gonna start with Material UI, and I bring this one up because it's nice to get started with a component ecosystem. So one really important property is Next doesn't break the React component ecosystem. So we're not making the trade-off of making things easy to use and then, you know, we abandon the ecosystem behind. Hashtag use the React platform. So I'm gonna load again. The Material UI demo. So I actually didn't build this demo, so I'm going to give a shout out later to the great creator of this. So we have a very basic application here. It is a Material UI. Here there is obviously what I call an emerging convention. When you come to a Next project, you sort of already know where to go. Because you know that there's a pages directory. Likely the next thing that you do is you set up a components directory. So it's very easy to know what's going on when you come to a Next.js application. So I'm gonna go to pages, uh, index. I'm, I'm gonna focus a little bit on this. And I mentioned earlier, there are two things that you can export from these entry points. One is a function that returns React elements that make up your page. Or you can export a React component. So a React component is what allows you to do really interesting things once the page loads. So since Next.js performs server-side rendering, kind of like old style, uh, PHP applications, you're gonna see that all the styles and, uh, HTML already comes with the page. So the question typically was way back in the day, what do we do once we have all this blob of HTML coming from the server? Well, we put in a bunch of jQuery spaghetti, but no, not anymore. You load up your class and within that class you have all the lifecycle hooks to do interesting things once that page loaded. So Next.js seamlessly takes the pre-rendering output, which can be static files or server rendering, and then boots up the frontend and reconciliates both. So you can do really cool things when like You can do here componentDidMount. And this code is only going to be executed on the client side. So if I perform a server rendering of this page, obviously that code path is never going to get executed. So I'm going to go— I'm going to do— so had I placed that alert call in the constructor, Obviously, it would have broken because we don't have alert on the server side. But this is a really nice property of Next. Once you've prerendered, then you're free to do whatever you want on the frontend. So I mentioned that we play really nicely with the React ecosystem. So I'm going to show how here. I'm just going to— there is a Material UI thing called RaisedButton. And we're going to add it. And I'm going to go back to the left side. Hi there, Seattle, and wave emoji. So we can see that now we have our Material UI button. So again, works really nicely with any sort of module that exports React components from the ecosystem, and in addition, Everything kind of works really neatly with hot module replacement. So in order to get started with Next, you just install it, run Next, bring in your component library, and it should, should just work. So this is, uh, the Material UI. Another thing that's worth, um, keeping in mind here, uh, something that's really nice when you do pre-rendering like we do with Next, like you wanna include like Twitter cards or things in the header of the page, Twitter cards, Open Graph tags. Since Facebook created this, shout out to Open Graph, all sorts of things that have to come in the head of the page. So for that, Next.js gives you this little helper called head. And in that you can put obviously title. I'm gonna reopen that just to show you. We're gonna see the title change right there. Title change. So this is a nice thing that Next.js comes with. That typically is a little harder to do in the React ecosystem because when you're prerendering, you have to make sure that the head component goes inside the actual head of the page, which React cannot precisely render to. So there's a little bit of nuance there and like we decided, okay, Next.js is gonna make your life easier there. Obviously meta tags are another great use case. Without this, your pages don't render well on mobile. So we got— we got you covered there. Great. So the next example that I'm going to show you is just going throughout the spectrum of from more static to more dynamic. I'm going to show you my blog. So the reason that I'm going to show a blog example is what happens a lot of times with these frameworks is, like, they become too application-specific or too domain-specific. Specific. So for example, you go to the documentation of a Shiny framework and you find out that the documentation is not actually written with the same view system that the framework is advertising. So for a long time, that paradox sort of puzzled me. So I want to make sure that Next worked really well for tasks, even like writing documentation, because frankly, React is a great fit there. For the most— for the vast majority of things that you're going to blog about, for example, you're just going to use really simple paragraphs and images. But once in a while, you want more dynamism. You want— and this is something that blog engines like WordPress sort of have always struggled with, because they give you a lot of simplicity, but then it's very hard to break out of the little box and list of allowed elements or paragraphs or images that they give you. So for the most part, my blog— and again, following this idea that we can just explore the file system to sort of understand how it works. I'm gonna load it up on the, on this side. So this is my blog, of course. So this is, uh, uh, index page. So if I go to the, my index page here, we're gonna see one, uh, emerging pattern in Next.js applications, which is the use of higher-order components to define layout. So you're gonna see here, I'm bringing in a page element. And you can see there I have an import from layouts/main. So this is really cool, because across almost all your pages in your application, there are a lot of things that are going to be shared, such as font configurations. Header and footer perhaps are the same, and then you want to include something in the middle. There is no need for us to create a layout system, or we can just take advantage of React's inheritance system and component system. So I have for my purposes two layouts, one that I call the main layout, and then another layer that builds on top of this layer, which is what I use for my blog posts. So we're going to go here. One thing to mention that I kind of touched upon earlier is Notice that the page transitions are really quick. When you connect Next.js pages through the Link component, we preload a lot of stuff in the background. So when I'm visiting this page, everything has already been preloaded for me. So I'm going to click here, and I'm going to now go and find this component. 2017 is hard to forgo efficiency. So I just go to it. And you're going to see that it's— once again, I'm using composition here. In this case, I'm using withViews. It's a helper I wrote to bring in a real-time component. So withViews will give me the number of views, but it will also set up the component lifecycle hooks to keep it updated over time. So my withViews helper here is also upon didMount loading Firebase, subscribing to it, then passing on the views again when that changes and so on. One really cool feature that we just announced, uh, I think it was yesterday if I'm not too jet lagged, uh, is, uh, dynamic imports. So we don't wanna load Firebase every time we render a page. So with Next.js 3.0, you can just use the dynamic version of import anywhere in your application and it'll just take care of producing the chunks. And loading them on demand for you. So in this case, I made a pretty naive implementation of withViews. I think it's in lib. Yeah, withViews. And here I kind of assume that Firebase is already there. With Next.js 3, I could have made this a lot better because we don't need to load 50 kilobytes of real-time database code just to perform that initial rendering. So if I were to refactor this today, I would sort of make that improvement. So to finalize on something that I mentioned earlier about preloading, one thing that's interesting to mention is the vast majority of page transitions that you make in your application are going to be client-side, which allows you to retain state from page to page. So notice here I declare that, stays there. So as I transition between all my pages, I can retain global state. This is a really cool feature because there are a lot of things that you don't want to re-fetch from the server when you go from page to page to page. So this is another really nice improvement that Next.js makes over the traditional server rendering model. When you transition between pages in this, from the server, you tell a server, give me everything again. When you transition between pages with Next.js on the client, you can sort of maintain your own global state. So obviously a global variable like this is not gonna be very useful, but you can bring in Redux, for example, to keep authentication state, uh, to keep, um, perhaps you wanna maintain a cache of a lot of these things. So, uh, if you listen to one of the, uh, early, uh, Dan Abramov talks, he talks about he wanted to make pressing the back button really fast. So what does it mean to press a back button and load the previous page really fast? Well, what it means is like the data must be somewhere cached in memory. So if I go here and then I go here and then I go back, you're gonna notice that we're sort of hitting, um, sorry about my ad blocker. We're sort of hitting the database again, but because Next.js is making those transitions on the client side, I could have just used any sort of local cache to maintain that when I'm transitioning. So that's another really interesting property. Just because we do server rendering doesn't mean that we forego a lot of these niceties that front-end heavy applications give you, like persisting state across transitions. So in a similar vein, we created another example. And all of this is open source or in the process of being made open source. Another really interesting one that we created is Next News. So Next News is the Hacker News version of Next. And I'm going to open here the file system for you to see. So one cool thing about cloning Hacker News was almost every URL maps really neatly into the file system. But I want to make it clear that just because all the URLs map neatly into the file system, Next doesn't have that limitation. So every piece of functionality that you have in Next, you can invoke programmatically. That means you can bring Express, for example, to do routing. So you can have fancy style routing and, and so on. It just happened that in my example so far, I have the benefit of having all these really nice URLs. And what I mentioned earlier about the emerging convention is what you find yourself with is you have all these entry points in pages, and then you have components which tend to be pure stateless components. If you come from the world of like other, um, backend server rendering technologies, it's typically like the, um, dummy templates, like the things that you reuse page after page after page. And then the other one is typically have a lib— lib directory where I place all my utilities, all my data fetching stuff, and so on. And as you could, can probably guess, uh, up until this point, we, uh, Next doesn't really enforce how you get data from the server. You can think of Next more as a frontend, uh, build tool/compiler that doesn't have any opinions about how you, uh, get your data. So to give you a cool example, we recently rebuilt our desktop application for Zeit. And this is an Electron application, uh, that has a lot of local state actually. We, we don't want to like go to a server when we switch between, um, accounts. But the cool thing is this Electron application was built with Next.js as well. So instead of using server rendering, what we do is we pre-render to static files. So that feature we also introduced a couple days ago with Next.js 3, you can which is take your entire application, run next build, and then you add next export, and it'll give you a set of files. So I'm quickly gonna show you a really cool example that we just put together. So I'm gonna refresh this. We just put that together with docs, we call it. So for our documentation, we wanted to obviously make it open source., but also we wanted to make sure that every time we get a pull request, we make a deployment with the documentation itself. So you're gonna see that every time we made a change to this set of docs, we got a new version of our application being deployed. So this kind of shows you that you can build really nice fractal applications with Next.js. We're able to extract our documentation put it into its own repository, and then publicize it that way. So when we open source this, you're going to be able to play with really cool— really two features. Sorry, I messed that up. With two really cool features. One is static exports. So when you look at the package.json for our documentation, you're going to see that we have the build and export step. So the build will produce the webpack build and so on. The export will give you a set of static files, and you're going to see that we actually went ahead and incorporated Markdown preprocessing. So this is an— another really cool thing that is typically associated with one category of application, static site generators, but really this actually falls under the category of preprocessing. So with Babel, Babel macros, Markdown in JS and any other sort of extension that's already out there, you can incorporate it into Next. And for example, for this, uh, piece of documentation, we just wrote a bunch of Markdown. So, uh, the, the build step invokes Babel, which invokes preprocessors like Markdown in JS. So we have this import right there, Markdown in JS, and Then we just write Markdown. So one really cool thing about this is you're not limited to just Markdown. So you can bring in any React component and interleave it inside your Markdown. So the really cool thing about this is we're writing Markdown, but we're preserving all the really awesome compositional features of React. So for example, the fact that we're actually just exporting a component. And it turns out that that component is rendered from a bunch of Markdown. So when React actually receives this Markdown, it's been preprocessed into a bunch of React elements. But for the practicality of the day-to-day editing of our, of our codebase, it's really nice to just be able to like send someone a pull request for Markdown. But when you need to break out of Markdown because it's limiting, then you can do two things. One is you can define your own components. So notice here I'm passing them as basically a set of references. So we have all the text components here. So when Markdown finds a heading, for example, it converts it into this React component. So when you need to break out of this, you can do two things. You can say, Markdown preprocessor, turn my paragraphs into this new component. Or you can just stop using Markdown altogether. So the abstraction never locks you in, into a particular configuration. So, uh, that example shows a new Next.js 3 feature of static exports. We're also going to make our, uh, Electron application open source if you wanna play with using Next to build, um, React, uh, desktop applications. Another cool thing about that is When you're developing an Electron application, you can develop it in Chrome and then bring it over to the menu bar. So you get all the nice hot module replacement, debugger, and inspection features that you've come to expect from any regular website. And finally, I was going to show a little framework that I just discovered recently, which is called ant.design. And I found out that it plays really well with Next.js. Thankfully, didn't break our assumptions. So this is similar to Material UI, and we put together an example called Next Ant. So I'm gonna run it. Let me go to— And this one also shows, uh, localization and internationalization capabilities. So something, uh, that happened there is Next.js was actually able to reconcile two completely different applications through hot module replacement because I didn't press refresh manually. And that kind of seems like something trivial, but actually highlights that our hot module replacement engine is— you can think of it as eventually consistent. It's always able to recover and be in the correct state that you expect. So here I'm showing that you can do code splitting in combination with bringing in any component ecosystem. So when I'm using this specific 3 Ant design components, Next.js creates a bundle dynamically with only the dependencies that you specify in this page. So imagine that I remove, uh, this slider and I leave those 2 components. When you publish this page, the resulting JavaScript bundle will only contain the button and alert components from this library. So this is a really important distinction because what happens with a lot of these frameworks of tools and components is you bring in all or you bring nothing. So you bring in the entire Bootstrap stylesheet or you bring in nothing. So one thing that we want to see the community move towards is this idea of creating more of micro-components that collocate their styles or use basically composition and imports to have shared styles. So that you come up with really, really optimal bundles. So this is something that, again, Next.js handles automatically for you because if you go here to view the source, you're going to see that I have a specific bundle for this page. So you're going to see that here I have this. So obviously this is the development bundle, so don't worry about what you're about to see. It's pretty nasty. But the bottom line is this is only gonna contain those modules that you define. And as you're navigating through very complex systems, Next.js is gonna handle loading those dependencies of more heavy pages seamlessly for you. Uh, so going back to the blog example, if I'm on the homepage, I'm actually not loading Firebase. I have to go to the specific module that required the Firebase module to sort of get that bundle and then go from there. Finally, I wanna show the last feature that we introduced with Next.js 3, which is dynamic imports. So dynamic components. So one thing is to load a JavaScript library dynamically. So you can say import moment.js and you get the moment namespace loaded for you. But another interesting space of dynamic um, code loading is swapping components on the fly and loading the code with them. So you can imagine a chat application that has all these different message types. Like you have animated GIFs and you have polls and you have photos and videos, but not all message threads are gonna require the same exact bundle of modules. So what happens typically is you either load everything for every user, Or you sort of have a best guess of what the most common bundle is gonna be. Or the best of both worlds with Next.js is we can actually load code depending on the data that the user is loading. So that's what we call the Next Chat example. We're very creative with our names. So Next Chat is sort of like Messenger by Facebook, the Facebook. Oops. I actually think I might have to downgrade for this demo. So unfortunately, this demo I couldn't get around to preparing for this presentation, but the— we're making it open source anyway, so I apologize for that mistake. But the bottom line is what you'll— what you're gonna see is a demo of a thread in a chat application that depending on what messages a user is receiving will load the code dynamically. And even though we couldn't parse that example, I'm gonna show you a little bit how that works in terms of code. So here I'm defining my components as imports. So those are dynamic. But I map them to specific types. So when you're rendering data, such as loading your messages, you're gonna load this dynamic component called message. And depending on the data that message has, it's gonna pick the right component from this, uh, set, uh, sorry, map and load it on your behalf. And also statically Next.js is gonna look at those imports and it's gonna create independent bundles for those. Which means you can create applications with arbitrary complexity over time. You could have thousands of message types for your chat application, and no user is going to pay the penalty of how your application is evolving or what, you know, the marketing team came up with. So— and the other really neat thing is we preserve server-side rendering. So when you're actually loading the page from the beginning, we load the bundles that the user needs for for that initial render to happen. So, that's an overview of Next.js, basically 1, 2, and 3. Something I wanted to share today as well is some of the, some of the things that we touched upon in this presentation today, for example, the initial bootup time, are things that we are aggressively trying to fix. For example, when you first execute Webpack or Next, what you find is the same compilation happens over and over and over again. You're basically redoing all this work from scratch. So one of our goals for Next.js 4 is to actually move towards incremental compilation with a cache that you can persist and even share with your coworkers in the cloud. So imagine if Node modules you had to like bring in every time you started developing. That's sort of what development feels like today because we re-execute bundling, we re-execute parsing, we re-execute Babel transformations. So Next.js 4 is gonna try to retain this APIs that work really well, but make some of these things even more, uh, scalable, faster, and easier to share with, uh, teams and faster to deploy to the cloud. Uh, if you have, uh, any questions, I'm gonna be around later today and all of these demos, the vast majority of them are already online. So, uh, obviously, uh, my blog and Next.js and so on. And we're open sourcing the chat application soon. We're open sourcing the Electron demo. I also recommend that you look at— we recently published something called Next Electron or Electron Next. Yeah, Electron Next. So if you wanna share the principles that we used for building Electron applications with Next, you can also look at this example. Also recommend learnnextjs.com. So it'll just walk you through, this is also a Next.js application itself, um, that will walk you through all the, uh, steps basically from building the most basic application to doing a dynamic, uh, a compo— uh, an application with dynamic components and so on. And yeah, so thanks a lot for your time.