Origins: Static Web Pages
In the history of this planet's civilization some discoveries or inventions have led to breathtaking changes in our lifestyle. There's a revolution in software, an incredible breakthrough. The software's going to change everything. Let's go. I'm actually kind of pumped right now. Every decade or so a technology comes along that changes how we write software. Is Next.js that technology or is it just another framework that'll be obsolete by next year? To better answer that we need to go back way back to the beginning of the web. In the early days of the web there were just documents with links between them. When a browser made a request to a server for a particular page the server would find the HTML file stored on its hard disk and send it back to the browser. It was a simple, relatively fast process primarily because everything was static. Every user no matter what received the exact same static experience.
Dynamic Server Rendering Emerges
Not long after, instead of serving up static files, servers started pre-processing the HTML before it was sent to the client. Every time a browser would request a page, based on the user's cookies or authentication headers, the server would generate the HTML on the fly for that specific user. This allowed you to create sites that were more than just for reading static documents. Now you could create unique experiences for each individual user. But there was still something missing. Yes, pages were being dynamically created on the server, but the end result the user got was still a static experience. For the web to take a step towards being a real application platform it needed a way to make static pages more interactive.
JavaScript Is Born
Then in 10 days in the summer of 1995 with Braveheart while you were sleeping in a goofy movie topping the box office charts one man on a lot of caffeine did just that. I did a prototype under Mark's code named Mocha. It was done in 10 days, notoriously where I didn't sleep much and then after I did it I started embedding it into the Netscape browser and immediately early users said 'can you change this, can you change that' and I made some changes which I regret, but it was so soon on a rocket toward shipping that I couldn't change much. After a time early mistakes and design decisions were frozen and I was busy trying to make the rest of the browser appear as a set of objects in the language you could play with. And then it shipped and it went through a name change from Mocha which was just the code name to LiveScript because somebody in Netscape marketing liked the 'live' prefix. Then the real goal all along with at least Mark and Bill was to make it the sidekick language to Java, so in December of 1995 it was renamed JavaScript. That son gave to Netscape JavaScript was a step in the right direction but its initial release was rushed, underfunded, and it was treated as sort of a toy sidekick to Java. Not only that but the way it was initially used was not ideal. JavaScript had enough good at the beginning to survive. Now if you think back though to the mid 90s JavaScript was cursed because it was mainly used for annoyances like little scrolling messages in the status bar at the bottom of your browser or flashing images or things that popped up windows massively. The good news was even though it was rushed JavaScript was malleable enough to encourage user innovation. It just needed something to push it over the edge.
AJAX and the Rich Web App Era
Then in 1999 that something came in the form of an ugly but powerful API. AJAX changed the game because it allowed browsers to send and receive data from the server without needing to reload the page. This one change ushered in the next era of rich dynamically generated web apps. In fact, believe it or not, AJAX was so powerful that Apple's original developer strategy for the iPhone was centered on it. 'We've got an innovative new way to create applications for mobile devices.' Really innovative. And it's all based on the fact that iPhone has the full Safari inside it. You can write amazing Web 2.0 and AJAX apps that look exactly and behave exactly like apps on the iPhone. So at this point with the addition of AJAX and additional improvements to the JavaScript language the web started to look like a viable application platform. This ushered in the angsty teenage years of the web, the era where you could build real applications before any of us knew what we were actually doing.
The State of the Web in 2011
Now we're in 2011 and what has changed? The JavaScript engines are amazingly fast. They can work with a lot more memory. The garbage collections have improved. The browsers have improved and so on. But the way you write a web application is fundamentally the same. Nothing has changed since 2005 when original AJAX applications were introduced. Mishka goes on to describe that there are three ways to build web apps: treating the browser as a dumb terminal with a round trip to the server, abstracting away HTML and JavaScript and DOM manipulators, each coming with their own set of opinions and trade-offs, none of which were ideal.
From jQuery to React: Component Paradigm
So where did we go from here? Well when you're a hammer everything tends to look like a nail. The DOM scripting era of vanilla JavaScript and jQuery eventually led to the lawless period of AngularJS which eventually led to the creation of a library called React.js. One of the core innovations of React was that they made the view a function of your application state. All you had to do is worry about how the state in your application changed and React would handle the rest. But this was only really half the picture. The real innovation happened when you encapsulated this idea into a proper component-based API. By doing so the same intuition you have about creating and composing together functions can directly apply to creating and composing components. To truly embrace a component-based API React needed a way to allow you to describe what the UI for a component would look like from inside the component itself. To do this they created JSX. Though some people hated it, JSX combined the power and expressiveness of JavaScript with the readability and accessibility of HTML. If you were already comfortable with both JavaScript and HTML, which you probably were if you were building web apps, then you could get up to speed with JSX in a matter of minutes. Not only that, but by embracing both JSX and React's component-based API all of a sudden what used to require imperative operational-like code could be extracted behind a declarative API. This not only enabled a better developer experience but also a vibrant ecosystem of third-party components.
So sounds pretty nice. What's the problem? Well React by design is very good at what it cares about and it's unopinionated about everything else. Since most applications need more than just a view layer this led to the dark ages of React where you needed a PhD in computer science to figure out how to actually build something. We're talking gulp config-levels of despair here, or if you're really kinky you could choose the webpack docs for your punishment of choice. Regardless the simple elegant nature of React was often overshadowed by the massive pain in the heart it was to get even the most basic app up and running. React's unopinionated nature was great because it allowed you to choose your own adventure but the adventure most normal devs wanted was to build nice performant web applications and then leave work as soon as they could ideally without tinkering with webpack or gulp configs. Then after years of wandering in the wilderness, Create React App was created by a team at Facebook to make getting up and running with a React app as easy as possible. With one command you'd get a production ready React app. No longer did you have to worry about tinkering with webpack, ESLint, or Babel. This allowed you to focus on building your app rather than configuring it. Create React App was a huge blessing to the React ecosystem at the time and today it's perfectly suited for a world that no longer exists. The problem that AngularJS ushered in and Create React App embraced was that both were optimized for creating single page applications. With SPAs instead of making a request to the server every time a user visited a new page your application would load all the necessary HTML, CSS, and JavaScript for your app on the initial request. This meant that subsequent route transitions would happen entirely on the client giving the app a more native-like feel. Done well SPAs create a brilliant user experience that feels snappy and app-like. Done anything less than well and SPAs leave a lot to be desired. By their nature SPAs tend to encourage large bundle sizes if you're not careful. This is especially problematic for users on slow internet connections or mobile devices. Second, with SPAs your data is typically loaded on an as-needed basis; again if you're not careful this leads to an experience where every route transition is met with a barrage of loading spinners. Finally if you care about SEO creating an SPA is less than ideal because you're relying on Google's ability to execute your JavaScript before it's able to figure out the content of your page. Now it's not so much that SPAs are bad because they're not; it's more that the pit of success with SPAs is small and creating one well takes a lot of experience, thought, and attention to detail. They should exist but they probably shouldn't be the default way we create applications.
Next.js: Combining Eras of the Web
So with all that what's the solution? Today I'm talking about Next.js which I hope many of you are already familiar with. If not, it's a simple framework for server-rendered universal applications with React. The main idea is very similar to what Tom was talking about with Create React App: there is an opportunity to make starting with React development much easier, but at the same time there's an opportunity to make it really, really simple by taking advantage of the fact that React is a very universal paradigm as it is for any kind of UI related work. A lot of what it's trying to do is merging the world of how the web used to work with all the new exciting possibilities that heavy and fat clients come with. This cuts to the heart of what Next.js is: the culmination of everything we've learned from the last 20 years of building for the web. With Next.js you get the simplicity of the document era, the power of the server-rendered era, the composition of the React era, and the UX of the SPA era, all while minimizing a lot of the tradeoffs that each era brought. So how does it do this? Well first Next.js is a framework built on top of React. This lets Next embrace React for what it is: a UI framework, and ignore it for what it isn't: anything else. Like Create React App you can get up and running with a Next.js app with a single command. To create a new page in your app with Next.js you just add a file in the pages directory that exports a React component describing the UI for that page. By default Next.js will statically generate the page at build time and, like websites of old, serve up the HTML for every request allowing it to be cached by CDNs. Unlike websites of old, if that page needs external data that can be fetched at build time you just export a getStaticProps function which fetches and returns the data which will then be passed as props to the component. Static generation is nice because you still get all the benefits of a static document but with the flexibility of external data. But if that page needs data and it can't be fetched at build time you have two choices: you can either server render the page which allows you to both fetch the data on the server and create a unique experience for each user by analyzing the request cookies, or you can fetch the data on the client like a traditional single page application. Regardless, Next.js gives you the flexibility to choose when you want to get data into your application: at build time, on the server, or as users use your app. There's even a feature called Incremental Static Regeneration which allows you to statically generate your site at build time then on a per-page basis regenerate a page on demand with new data. And since Next.js is a framework it comes with a bunch of other features that aren't just related to getting data into your app. For example, Next.js comes with code splitting out of the box which means that each file inside of your pages directory will be split into their own bundles during build time so users only download the assets they need. Another example is image optimization. Next.js comes with an Image component that's like if the HTML image element had been built for the modern web. Out of the box you get improved performance by always serving correctly sized images for each device using modern image formats. You get visual stability by preventing cumulative layout shift automatically. You get faster page loads because images are only loaded when they enter the viewport and you get on-demand image resizing even for images stored on remote servers. And since Next.js is more than just a front-end framework you can create API routes without having to spin up your own server, meaning you can literally build out an entire API with Next.js by simply creating a file. Next.js isn't the only framework of its kind; however, it was the first that combined decades of innovation into a single package which is why as of today I believe Next.js is the best way to create web applications. Mosaic put a face to the web, and Mosaic plus the web then finally gave us a way to express to the non-technical person what all of us in computing knew was the tremendous value of having networks interconnected.
