2019 in Review

Throughout 2019 we have continued to see the growth of the JAMstack. The idea is quite simple. Any website or app you build and deploy will use the stack of client-side JavaScript, API and Markup.

By this time client-side JS (like React and Vue) and APIs (like REST and GraphQL) are quite mainstream, but my favorite part is the assumption that your markup will be static.

First: Why Static?

• Static is globally fast. When you deploy, we can hoist all your static assets to a global CDN network. By removing the server from the equation, we can also maximize availability by reducing and even altogether eliminating cache misses.
• Static is consistently fast. It gives you O(1) TTFB, which is a fancy way of saying you get stable and predictable latency to the first byte of the screen. Always, because no code, servers, sockets, databases are involved.
• Static is always online. This should not be surprising but servers frequently go down and involve complex rollout schemes[1], while static files are trivially cacheable and simple to serve. The odds of you getting paged during the holidays because a "static asset can't be served from a CDN" are basically zero.

Second: Really, Static? I have dynamic needs.

Servers are not really going away, but they are moving around and hiding.

• Static Site Generation (SSG) can be thought of moving around the servers and taking them away from the hot path. Instead of putting a server in between the user's request and the response, we compute the response ahead of time.
  
  This subtle shift pays back handsomely. One, anything that could go wrong, goes wrong at build time, maximizing availability. Two, we compute once and re-use, minimizing database or API load. Three, the resulting static HTML is fast.
• Client-side JS and APIs that get executed later, once the static markup and code is downloaded and executed, allow for effectively infinite dynamism.
  
  Pre-computing all pages is not always possible[2] nor desirable, like when dealing with data that is not shared between all users and we wouldn't want to cache at the edge[3].

Next.js has continued to grow in adoption and now powers the likes of Hulu, Tencent News, Twitch, AT&T, Auth0 and the list goes on.

Thanks to its simplicity, it's a compelling all-in-one solution for the full straddle of JAMstack: from a static landing page, to very large websites, to fully dynamic applications.

The "secret sauce" continues to be its simple pages/ system inspired in cgi-bin and throwing .php files in a ftp webroot.

A page is just a React component, meaning the simplest Next.js app is pages/index.js which will serve the route /:

export default () => <div>Hello World</div>

But here's what happened in 2019:

• Pages can be defined like this: pages/r/[subreddit].js, which will allow you to define dynamic path segments with no configuration or custom servers.
• If a given page is static and has no server-side data props, next build will output just "boring" static .html 😄
• If you define static data props, we can fetch data at build time for a certain page, but crucially also "explode" dynamic path segments into many discrete pages.
• If you create pages/api/myApi.js, you are basically defining a serverless function that can return anything you want, which will most likely be a JSON API.

In short, Next.js is now a comprehensive, hybrid framework, supporting the full spectrum of JAMstack with a per-page granularity.

Furthermore, Next.js has been uncompromising in its commitment to backwards-compatibility. Servers (SSR) are still fully supported and no apps have been harmed as part of this evolution.

We think there's enormous value in empowering teams to instantly build and deploy JAMstack websites, with no servers or infra to manage or configure.

True to our style, deploying any static site (like just a index.html) or more complex and full-featured frameworks like Next.js, Gatsby, Nuxt, Gridsome, Hugo begins with one command:

$ now

The ZEIT Now platform gives you a comprehensive workflow with built-in CI/CD and global CDN, that are carefully optimized for production-grade dynamic sites.

A salient feature is the transition we are seeing away from code review into deployment preview.

Code review is undeniably important (specially speedy code review), but nothing beats teams collaborating by sharing URLs to the actual sites that are being worked on and experiencing them directly.

By setting up a git integration, every single git push gets its own live deployment URL. Thanks to the simplifications afforded by the model, deployments are orders of magnitude faster to build, deploy and serve than when using servers or containers, which only adds to the great team-wide collaboration experience.

------------- gif here -----------------