This might sound funny, but at Stackbit, we're big fans of Squarespace and friends. Of course, we're also all in on the cost, security, and speed benefits of the Jamstack, so we think you should use Stackbit, not other site builders! But hear us out: site builders are the future of web site development.
Components are the hidden magic behind site builders today, allowing content creators to experiment without worrying that they'll "break" a web site or make it "ugly."
To make our site builder even more powerful, we've begun work on our very own component library — heroes! calls to action! forms! — which will be added to an updated set of Stackbit themes later this year.
Our component library is open-source so you can customize it to match your project's needs. One of the first things you might notice when looking at the code is: we're using Next.js.
After evaluating all our options, we felt like building on top of Next.js would strengthen our library, while improving the developer experience of using our components with our themes, and we'd love to give you a peek behind the curtain to share why.
Focus facilitates quality
At the time of researching this article, Jamstack.org listed 333 site generators (it's probably more by the time you're reading).
In our early days, we developed our own theme transpiler, Unibit, that let us write components once and transform them into themes for Jekyll, Hugo, Gatsby, and Next.js.
By removing this extra step and picking one templating technology, we knew we could focus on making rich components (like forms) that:
Might not have worked in every site generator
Are easy to customize without asking developers to learn a templating language we made up
Modern frameworks for modern functionality
Jekyll and 11ty will always have a special place in our hearts, thanks to their support of beginner-friendly templating languages like Liquid and Nunjucks. Don't worry -- you'll still see plenty of Eleventy on our blog, because it's an excellent teaching framework!
Although simpler site generators do components perfectly well, trying to develop a rich component library with one can be "death by a thousand papercuts" to productivity.
With "classic" static site generators, you often write (or use tooling to bundle) something along the lines of a massive main.js file that every visitor to every web page in your site has to download (and that a theme developer has to wade through to customize!).
We've also found that modern site generators like Next.js typically facilitate breaking up CSS into modules, too.
Styling can be extremely finicky to debug, so we're keen on keeping things clean.
.map().reduce() or destructuring can save when rendering content into components.
import becomes equally useful if you'd like to develop components that piggyback off each other (the same "card gallery" look and feel is often a great choice both for a staff directory and for a teaser about your latest 6 blog posts).
The Case for Next.js
Sorry Vue and Svelte, you're great, but there are a lot of React developers in the world, including us! So that narrowed our choice down to writing components for Gatsby or writing components for Next.js, the two leading React site generators.
How did we pick Next.js between the two?
1. Fetching data seamlessly
Writing code that fetches data from a source and passes it into the properties available to a given page-rendering React template is a bit more straightforward in Next.js than in Gatsby.
As James Bedford points out, GraphQL is almost handing your roommate a specific shopping list for dinner ... and sending them over to the dining room instead of the store, where you've already set out all of the ingredients on a serving tray.
To us, adding GraphQL code between content fetching and component templating felt a little cluttered.
2. Dynamic and catch-all routing
Although both do it now, Next.js released Dynamic Routing earlier than Gatsby, letting you surround the filename of a given page-generating React template with punctuation marks to specify that it's responsible for building many URLs, each named according to a property that will be passed to the template when it is called.
(Hint: this is the same idea as programmatically setting 11ty permalink values with pagination or directory data files, if you're feeling a little out of the loop!)
3. Server-side rendering
Although Gatsby also jumped aboard, Next.js let you choose Wordpress-style server-side rendering vs. Jekyll-style static site generation on a per-page basis earlier than Gatsby. (And Gatsby didn't offer server-side rendering at all when we had to make up our minds.)
When you have a site with thousands or millions of web pages, publishing new content or codebase updates into production can get slow, so letting some pages be served via SSR is nice.
After evaluating our options, we felt like we could deliver killer components in Next.js, and we're super excited to share them with you a little later this year. Stay tuned! After evaluating all our options, we felt like building on top of Next.js would strengthen our library, while improving the developer experience of using our components with our themes, and we'd love to give you a peek behind the curtain to share why.