Today I'm officially committing to building an idea I've had for several years.
Flags is a calm platform for communities (I'll explain more later).
I'm going to be building in public, so follow me on <a href="https://twitter.com/jessethesibley">Twitter</a> if you'd like to keep up to date with progress!

Introducing Flags

<a href="https://vercel.com">Vercel</a> announced <a href="https://nextjs.org/blog/next-9-5">Next.js 9.5</a> today which gave us 'Stable Incremental Static Regeneration'. But, what on earth is that?
If you're not familiar, Static Generation is the process of dynamically generating pages at build time. For example, an e-commerce website might generate a static HTML page for each product in their catalog as oppose to the traditional approach of using a server to load in product information from a database.
This is nice because static HTML files are fast to serve. Additionally, static HTML can be easily served from a global CDN, resulting is quick page loads wherever you are in the world.
This technique also causes less load for databases and servers, making it a much cheaper option.
The major drawback of traditional static generation however, is that if a small change is made to a single page, the entire site must be rebuilt and redeployed. For a site with thousands of articles or products, this could take a long time.
<h2>Incremental Static Generation</h2>
To address this issue, the Next.js contributors have been working on giving static pages the ability to be "revalidated" at runtime.
In practise, this works with the <code>revalidate</code> option in the <code>getStaticProps()</code> method of a Next.js page. The <code>revalidate</code> option, if specified, will instruct the page to be regenerated at a given interval.
When a user visits an "out of date" page, they will be served up a "stale" version. Traffic on the site will then cause the page to be re-rendered in the background meaning that the next users to visit the page will see the latest, "up to date" version.
<h2>It gets better...</h2>
Instead of having to define all pages at build time and then incrementally rebuilding them at runtime, you can now <a href="https://nextjs.org/blog/next-9-5#stable-incremental-static-regeneration">register new static pages at runtime</a>.
This is like automatic server-side rendering but once rendered, pages are served statically and can then also be updated on demand.
Here's a <a href="https://static-tweet.now.sh/">demo with an explanation</a> if you don't believe me...
2020 really is a crazy year.
<h2>Big Wins</h2>
In my opinion, this approach to static generation is a defining moment for <a href="https://jamstack.org">JAMStack</a> which could make it far more adoptable than before.
You just can't beat the speed of pure HTML.
If you can build complex dynamic sites with the simplicity of a tool like <a href="https://nextjs.org">Next.js</a> why use anything else?

What on Earth Is Static Regeneration?

You may have heard the term JAMStack being thrown around a lot recently in web development circles.
<a href="https://jamstack.org">JAMStack</a> (JAM standing for Javascript, APIs &#x26; Markup) is a set of principles for developing web applications.
In my opinion, the defining features of JAMStack can be summarised as follows...
<ol>
<li>Statically render your markup</li>
<li>Use client-side fetching to make your site dynamic</li>
<li>Decouple your backend from your frontend</li>
</ol>
These ideas have been championed by cool developer-tooling companies such as <a href="https://netlify.com">Netlify</a> (whose founders coined the term), <a href="https://vercel.com">Vercel</a> and a whole bunch of other companies building tools that empower the stack. For example, companies providing CMS products like <a href="https://sanity.io">Sanity</a> or image hosting like <a href="https://cloudinary.com">Cloudinary</a>.
<h3>JAMStack isn't that new</h3>
Chances are, if your blog is a bunch of static files, then you're already using JAMStack. Congratulations. Welcome to the club!
<h3>JAMStack is being sold to developers</h3>
The main way this new approach is being pushed forward is by capturing the attention of developers. Of course, these ideas wouldn't mean much to non-developers anyway.
This has led to what I would say is the biggest misconception about JAMStack, and that is... "JAMStack is about Developer Experience".
<h3>JAMStack Is Not About Developer Experience</h3>
Don't get me wrong. The developer tooling associated with the JAMStack revolution is well built and exciting.
Separating a messy backend from the frontend can be incredibly empowering for frontend developers. Having full decision-making control over the frontend without being constrained by choices made on the backend can be hugely impactful. Often this leads to more considered and accessible web experiences with an additional performance boost too.
But JAMStack is more than just the look on a developer's face after a really good coding session.
One of the down sides to JAMStack is that there can be so many decisions to make. What framework? Which tools? Which service?
There are lots of other approaches to web development that have a simpler onboarding process that also don't require you to make so many decisions. For many developers, this alone is a good enough reason to stick to their well-understood, battle-tested tools.
Developer experience is subjective.
<h3>Pushing it to the edge</h3>
I would argue that JAMStack is actually more of a push towards developing web applications that can take full advantage of improvements in cloud technology.
JAMStack apps were born to be served on <a href="https://en.wikipedia.org/wiki/Content_delivery_network">CDNs</a>.
CDNs are cloud networks that can serve your content from "edge nodes" in regions all around the world. The advantages of using a CDN, as opposed to having a server somewhere in the world, which will probably fall over at some point, is that your application can be highly available, scalable &#x26; fast to serve.
<ul>
<li>
Highly available because if one region goes down, users will just be served up content from the next closest region.
</li>
<li>
Scalable because web traffic is automatically load balanced.
</li>
<li>
Fast because CDNs are optimised for fast content delivery, wherever you are in the world.
</li>
</ul>
<h3>This is how the world works now</h3>
The development of this kind of technology is based on the fact that this is how the world works now. The nature of the internet is that your users can be anywhere. Therefore, it is important to make sure that irrespective of where your users are, they will always receive the best service.
<h3>JAMStack doesn't always make sense</h3>
On the other hand, deploying your site globally doesn't always make sense.
Whether you're building internal tools for your company or you just prefer the tried and tested path, you can always make a good argument for not choosing the JAMStack way.
I should also mention that using a CDN isn't a unique thing to the JAMStack. It feels most natural to use a CDN when serving static files but you can serve cached contents from a server-rendered application in the same way. There are added complications, such as cache-invalidation, but many applications run quite happily behind a reverse-proxy cache served through a CDN in regions all over the world.
The difference is, with JAMStack, this is delightfully easy.
<h2>Summary</h2>
For most developers, the wisest path to tread in 2020 is to build web applications the JAMStack way.
The overall advantage that JAMStack gives developers from the start is the opportunity to focus less on deployment and general performance and more about crafting an excellent user experience.

JAMStack Isn't About Developer Experience

Building friendly software and talking about design for humans, digital wellbeing & privacy.