Ask HN: Who Is Jamstack Aimed At?
8 comments
Deferred static generation is the tradeoff they've arrived at where quick builds and full static site generation are at odds for large sites powered by an API-first CMS.
There's also a cache feature in Gatsby that might be able to help reduce the 5 minute build time.
https://www.gatsbyjs.com/docs/build-caching/
There's also a cache feature in Gatsby that might be able to help reduce the 5 minute build time.
https://www.gatsbyjs.com/docs/build-caching/
But why go with a static site in the first place if the benefits are so compromised at scale?
There are huge _read_ benefits, especially at scale. They traded that off against write performance - which means it's an awful idea for Twitter, but write performance isn't exactly a problem for someone who only write a blogpost or two a week.
In my opinion, most Wordpress sites (specifically ones that are not updated multiple times a day) should be generated static sites. They can them be hoisted on S3 with CloudFront/CloudFlare in front of them, and never ever need to worry about scale or security. You can't SQLi or XSS a website that's just static html. It's practically un-DDOSable too.
In my opinion, most Wordpress sites (specifically ones that are not updated multiple times a day) should be generated static sites. They can them be hoisted on S3 with CloudFront/CloudFlare in front of them, and never ever need to worry about scale or security. You can't SQLi or XSS a website that's just static html. It's practically un-DDOSable too.
I think one short answer is that many static sites aren't "at scale" when they start and probably will never get there.
But if they do, this feature is sort of insurance. I'm a backend dev / DevOps engineer, so you might get a different take from someone who works in frontend daily.
But if they do, this feature is sort of insurance. I'm a backend dev / DevOps engineer, so you might get a different take from someone who works in frontend daily.
When you see different static site generators in the wild, most people want:
Your marketing team needs instant feedback, your options are now:
- api for creating pages from remote data
- developer experience
- build speed
Your marketing team needs instant feedback, your options are now:
- use client side rendering for page previews. (i.e. use a js-based framework)
- containerize your project & run the framework's dev mode as a preview server (i.e. you might as well have not used a SSG)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.
[1] https://www.11ty.dev/ [2] https://www.npmjs.com/package/eleventy-plugin-ghost
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.
[1] https://www.11ty.dev/ [2] https://www.npmjs.com/package/eleventy-plugin-ghost
I think there 2 main groups of people that these static site generators are aimed at.
1) People who care more about cost than anything else. You can host a static site for free with github pages and the like.
2) People who don't modify the content too often meaning that they don't care too much if the site takes 5 minutes to update.
Other people I've seen use them to great effect are photographers who have static sites generating based exclusively of images that they upload. As there's no real text content, they don't end up doing many "changes" as they generally upload images in bulk.
Other people I've seen use them to great effect are photographers who have static sites generating based exclusively of images that they upload. As there's no real text content, they don't end up doing many "changes" as they generally upload images in bulk.
also 3) people who've had their WordPress site script kiddied before and have worked out securing static html is trivial.
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/ [2] https://www.gatsbyjs.com/docs/how-to/rendering-options/using-deferred-static-generation/