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.
1. We like bundling JavaScript and CSS
Site generators that piggyback off of modern front-end JavaScript frameworks like React, Vue, or Svelte make it easy to ship front-end JavaScript responsible for enhancing a given component (like a form) to the web browser only when someone actually visits a web page that includes that component.
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.
2. JavaScript frameworks are handy
Speaking of writing client-side JavaScript, the more "interactive" you want a given component to be, the more of a nuisance it is to hand-compose vanilla JavaScript.
With React hooks, you can do in a few lines of code what might require pages of straight JavaScript code.
3. Frameworks include JavaScript itself
Liquid isn't nearly as complex of a programming language as JavaScript. You can't simply throw a little Ruby into a Jekyll Liquid template or a little JavaScript into an 11ty Nunjucks template any time you'd like.
On the other hand, vanilla JavaScript is always valid syntax in React's JSX templating language. You'd be amazed how many lines of code a little .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.
GraphQL's original intent was to let client-side JavaScript fetch data sparingly, but it's often overkill when your data lives on the same filesystem that your build process runs on -- or when your headless CMS API has an efficient syntax of its own.
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.
4. Speed
Next.js only loads the CSS and JavaScript required for a specific page and its components. Consequently, we’ve observed faster page generation in development environments with Next.js over Gatsby.
Takeaways
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.
