Our great sponsors
-
-
eleventy 🕚⚡️
A simpler site generator. Transforms a directory of templates (of varying types) into HTML.
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
I've recently taken on my first project that's fully "Jamstack" [1] and I'm finding it very hard to understand who exactly these statically generated sites builders are aimed at?
The project is using Gatsby Cloud and Contentful. The key problems they have encountered are a) build times being painfully slow (+5 minutes per content change) and therefore b) the authoring/publishing experience is really poor as you can't easily see previews. These seem to be common complaints of static site generators (I'm also skipping over the general complexity required to get a website up and running with so many moving parts)
In order to tackle this problem, Gatsby offers a rendering feature called "DSG" (Deferred Static Generation) [2]. When enabled, instead of building all of your content up-front (the entire point of a statically generated site), only your core pages are generated at build-time. The rest of your "long tail" pages are only generated when someone first access them. To use this feature, you need to put a server in-front of your static site.
What?! It seems that the build times with statically generated sites have gotten so bad that the work-around is to literally go full-circle and re-create a dynamic website. The two big benefits of statically generated sites are apparently performance and server-less infrastructure, yet to deal with the downsides of generating pages up-front you need to introduce ... dynamically generated pages ... via a server.
I don't understand who this is for? Any company that requires the touted performance gains that statically generated sites offer will surely also need quick builds and a good authoring experience? But to get those build times down you have to re-introduce infrastructure and dynamically generated pages?
Are there teams out there that are happy with their statically generated sites? Am I going mad?
[1] https://jamstack.org/
I have long thought that the JAM stack is primarily aimed at hobbyists, and I have changed my mind on the subject.
True, for a hobbyist updating a blog a couple times per month, it works great.
No Wordpress nightmares to wake you up at night, no databases going down and taking your site offline. And, should I mention performance? Once the site is built and deployed, that is.
Also, no limits as to how you can configure your site. With a bit of coding, you can usually make the static site generator do your bidding.
Personally, I use Eleventy [1]. My site has 200+ pages and the build time is not an issue.
Now, I am authoring manually in Markdown using VS Code. That's probably not the right tooling for the editors at some content shop.
Many static generators do have hooks into CMS's. Eleventy, for example, has a plugin that interacts with the Ghost CMS API [2]. I haven't tried it but if I read it right, it can suck content out of Ghost and publish it as static HTML.
That might be a way to get the best of both worlds: a comfortable authoring experience AND the performance of a static site.
My argument for why the content shops should give the JAM stack a try is based on a recent experience.
I was helping out a team developing a large content website with hundreds if not thousands of articles and many updates throughout the day.
I was there mostly for backend work and DevOps. And boy, did I have my hands busy!
We hosted on a PaaS with maxed-out specs for both the application server and the database (Postgres). The bills must have been in the four figures monthly just for the servers. And yet, it took us months to get the performance to a level that was even acceptable: not great but okay-ish.
I would not recommend a database-backed CMS for a popular content website if we could avoid it at all, and if budget was a thing. Rather, I'd explore how to make a JAM stack-based solution work for the client.
With that said, I concede that yes, of course the static site generators have their own issues. The right answer depends on which tradeoffs you are willing or able to make.