Are static sites the future?
Hey! You're getting this email because you signed up for updates from my site or you purchased my course Mastering Next.js. If you don't want to get these emails, definitely unsubscribe — I only want to send these to you if you look forward to getting them ✌️
I'm experimenting with a new format for my newsletter. I'm going to try and write more long-form thoughts on specific topics. This change allows the newsletter to be more conversational, so don't hesitate to hit reply if anything triggers thoughts or ideas.
Are Static Sites the Future?
My blog has always been a static site, from plain HTML to static-site generators
like Jekyll and Hugo and finally to Next.js. For those familiar with Next, I started out
using next export and now utilize "static pre-rendering". If a page doesn't need to fetch
any data from the server, it will render as HTML. Static sites are:
- Cheaper – Not making requests to the server on-demand.
- Faster – Served from a global CDN close to your users.
- Easier – No complicated deployments. Better developer experience.
Does this approach scale? Either server-side rendering (SSR) or static-site generation (SSG)
will be good choices for improved SEO over a client-side rendered (CSR) application.
Depending on the type of application you're building, a completely static site might have
better performance than SSR. This is why Next.js 9.3 added getStaticProps and getStaticPaths
to make it a complete static-site generator (SSG).
Personally, I learn best by creating. I don't fully understand the topic until I've built something with it. To explore static sites more, I wrote a tutorial on Next.js 9.3 and built a SQLite database backed application showing a list of songs with links to their YouTube videos. This allows you to see Next's SSG methods in action and understand how you could scale this approach to 1000s of pages.
By shifting the database access to the build step, Next.js solves a piece of SSG.
What if your data frequently changes? You don't want to do a full rebuild every time.
You'd be better off sticking with SSR at that point. This is where
"Incremental Static Generation" comes in.
Static generation will allow pages to be regenerated without needing a full rebuild.
Under the hood, it's very similar to how stale-while-revalidate caching works.
Define a revalidate time in getStaticProps and the route will automatically regenerate
in the background when a request comes in. I'd recommend reading through the
linked RFC if you want to learn more.
Gatsby is also making significant moves in the static site space. Their "Incremental Builds" feature in Gatsby Cloud aims to solve the exact same problem as Next.js. In combination with an admin interface, "recipes", and visual code blocks (Blocks UI), it will be easier than ever to build a performant static site. I'm excited to try Gatsby more for some upcoming projects. In my opinion, the biggest advantage Gatsby has over Next is its plugin system. Do you prefer Gatsby? Let me know.
Prisma, Hasura, and Database Access
As I explored Next 9.3, I also started looking into the new-hotness for database access. Prisma makes database access easy with auto-generated and type-safe queries based on your database schema. Prisma had me thinking about Hasura, another tool I've previously worked with that streamlines how we fetch data in applications. Both Prisma and Hasura enable front-end developers to more efficiently manage the full stack and are often brought up together.
Hasura auto-generates a GraphQL API based on your schema, including the create/update/delete resolvers and queries/mutations you need. This is great if you need to build an API. With Prisma (and Next 9.3), it's possible to short circuit this entirely. You don't even need the API because you can go directly to the database. Their client gives you type-safe DB access and prevents you from writing CRUD, ditching the integration between client & API. It's another level of less code.
With Hasura, it's a bit more challenging to build on top of. Yes, you can do GraphQL mesh/stitching if you need more than just the auto-generated queries/resolvers based on your schema, but it's more overhead. I chose Hasura over Firebase for a previous project I used since I needed relational data and I didn't want to deal with complicated deployments. These same benefits apply to Prisma as well, and it's more flexible to build on top of.
I think once Prisma Studio & Prisma Migrate ditch the experimental flag and are production-ready, it will be a game-changer. Keep your eyes on RedwoodJS, which uses Prisma under the covers.
Goodbye Mailchimp, Hello Buttondown!
I was starting to get frustrated with Mailchimp's email editor. Yes, I wanted links, images, and more – but I didn't need the custom formatting or "business" features. The focus needed to be on the content. Coincidentally, that's when I found Buttondown (thanks, Max)
Buttondown allows me to write my newsletter in Markdown 😍It's powerful enough to achieve what I'm looking for, without all the extra bloat Mailchimp provides. Plus, free/hobby tier and API access! Sold. This is my first email using Buttondown. I've since archived all of my old newsletters on my site and added metrics on newsletter subscribers to my dashboard.
I’ll close this off with a reminder to hit reply and let me know what you think about any of this! I’d love to hear from you.
Cheers!