There's been a lot of talk lately about how JAMstack is dead, after Netlify shut down the JAMstack Discord, ended their conference, and so on.
If you aren't familiar with the term, JAMstack (which Netlify later insisted should be spelled Jamstack), was originally an acronym for JavaScript, APIs, and Markup. The idea was that you serve mostly static HTML, use APIs and microservices instead of a monolithic backend, and use JavaScript for the dynamic bits.
I've been an advocate for years, and use it to build all of my sites… or do I?
This morning, while digging up an article on how I handle automated deploys of my static websites for someone, I stumbled onto this old tweet from Nicole Sullivan.
JAMStack is 99.9% branding and .1% substance. 😳😆
…the advantages of static vs a web server w a good cache are unclear to me.
At the time I first shared this tweet, I thought it was wrong. But today, it got me thinking about how I actually build my "JAMstack" sites.
The site students use to access my courses was originally a "proper" JAMstack site. It was entirely static HTML from the server, with the lessons you had access to rendered using JavaScript and an API call.
The site itself was fast, but the JavaScript bits were slow, because JavaScript and API calls are inherently slower than server-side HTML. I added a service worker to cache API calls, and that helped a lot, but I still wasn't wild about how it worked.
This year, I rebuilt the site using mostly static HTML and a bit of PHP. It's much, MUCH faster, even without service worker caching.
And here's where things get murky…
The site is built with a static site generator. I use Hugo to generate index.php files. They're mostly static HTML, with just a touch of dynamic PHP in the areas where content is conditional on what the person has access to.
Is that JAMstack? Probably not. Is it better for performance, resilience, and the user? Abso-fucking-lutely!
Which brings me back to Nicole's tweet. The goal is fast, resilient websites. JAMstack approaches can help with that—especially for websites sites with little dynamic content.
As soon as you go down the path of needing APIs and JS instead of server renderings, though, the entire cost-benefit analysis changes.
Is JAMstack dead? Honestly, at this point, I don't care. It doesn't matter.
It's just one approach of many for building a leaner web, and that's the thing that really matters.
I have a favor to ask. If you enjoyed this email, could you forward it to someone else who you think might also like it, or share a link to my newsletter on your favorite social media site?
Cheers,
Chris
Want to share this with others or read it later? View it in a browser.
0 Komentar untuk "[Go Make Things] Is JAMstack dead (and was it ever alive)?"