loading...

Nextjs and Sapper Netlify Jamstack Starters

mrispoli24 profile image Mike Rispoli ・3 min read

A few weeks ago I came across some Gatsby and Netlify tutorials and was intrigued by how far the jamstack has come. I'm not going to go into a diatribe over what jamstack is, but I had my doubts over this serverless revolution. Nonetheless I decided to run through the setup and was pleasantly surprised not by serverless per say, but by the Netlify offering. Authentication, lambdas, and contact forms -- all with generous free limits?

This seemed like an incredible platform to build early prototypes and test different SaaS ideas. For client work, it appears to greatly mitigate the risks of DDoS attacks and servers going down in the middle of the night. The only issue was that I was apprehensive of leaning entirely on Gatsby. I find Gatsby to be a wonderful platform for static site generation and have used it to build a few small portfolio sites and blogs. However, long term, you are stuck with a fully static only framework. Having built quite a bit of software now, I know that one cannot fully predict the walls they will run up against at a projects outset. What seems like jamstack perfection today, could turn into a project where a good server environment would be required. At which point you have only one option, migration.

Enter next.js, my go to platform of choice for almost everything. An easy to use, robust React-based framework that's just a little bit opinionated. It has a great community as well as awesome testing and typescript support and all the good things that you will probably wish you had setup at the outset before your project got too big. It also has the ability to do static exports of pages just like Gatsby. The big difference is, if you ever want to use the server environment and move to a platform like Heroku or Digital Ocean, you can. Server side rendering is also a nice to have for your authenticated users as well down the line.

In my research I also came across a new framework called Svelte on the Undefined Podcast. I was sufficiently intrigued by it's compiler based approach to building a robust front end so I dug a little deeper. I found a wonderful platform called Sapper, built by the same team it appears to have taken the best of Next.js and built a similar environment for Svelte. I don't want to get into the pros and cons of each framework at the moment, point is it's worth checking out. Just like Next.js it features static exporting and server-side rendering that can be used if you want to enable the server down the line.

In the end I wanted to come up with a boilerplate for each so that I could easily create prototypes, client sites, and JAMstack apps on the fly. I also wanted the option to bail out without losing all my work if I found the serverless style wasn't working for me.

So I give you two repos:

  1. https://github.com/mrispoli24/next-netlify-jamstack-starter
  2. https://github.com/mrispoli24/sapper-netlify-jamstack-starter

My thoughts are to rely on next for my paid client work since it is battle tested and approved for production use. I'll be using sapper for my personal projects that I'm willing to spend some time battling the early bugs in an early framework. I also feel the svelte approach to front end is worth learning and learning well.

Since I couldn't find much like this in the google searches for either framework I hope this helps some people get started sooner.

I will also be adding netlify authentication and hopefully payments processing with stripe so you can have a "Tim Ferriss" style experimental solution for signup, try for x days and pay monthly. Sorta like opening a restaurant in a building with a kitchen already built.

Discussion

pic
Editor guide
Collapse
amitnovick profile image
Amit Novick

Great writeup, Mike!

The only issue was that I was apprehensive of leaning entirely on Gatsby. I find Gatsby to be a wonderful platform for static site generation and have used it to build a few small portfolio sites and blogs. However, long term, you are stuck with a fully static only framework.

Having built a portfolio website using Gatsby already, I absolutely second this conclusion.

To rehash my thoughts (similar to your post): while Gatsby performs very well for its intended static site use-case, it does make the architectural design assumption that the data source is static.

That assumption goes on to become a limitation as soon as requirements imply that data must be dynamic in nature. Migration to another tool is costly, and so (without the powers of foresight) we might be making better use of our time as developers by picking a tool like Next which supports both static and dynamic data use-cases.