I’m personally more intrigued by the range of options Jamstack gives rather than speed/edge. eg Im currently toying with a pipeline that deploys to cloud run. But the output is so inherently portable pretty much any tech/cloud/cdn will work. That’s definitely a priority for me given how the big clouds are starting to feel like walled gardens
Is this just caching HTML fragments on a CDN? I'm confused here.
I grew up making websites using server side includes[1] and using tools like (Macromedia) Dreamweaver to generate static sties. I guess I should've just stuck with that approach but shoved the results on a CDN?
I just so feel like it can't be that obvious. Please someone learn me for my benefit.
If I understand right, it's similar to caching but done beforehand, automatically identifying what can be done. Just like in their examples moving a loop invariant out is similar to either calculating once and caching or manually moving it out - but you let your compiler do that.
For those unfamiliar with the the general subject, the author is CEO of Vercel (Zeit until recent VC funding), a company that provides "serverless" hosting, especially for Nextjs, an open source Reactjs (Facebook) framework. Among other things, Nextjs makes it easy to segment a React app at build time into parts that are either server side rendered (SSR) or static (which can be "hoisted" onto a CDN). In the same declarative fashion, data can either be fetched from the server for the SSR components, from the browser client (e.g. to reduce server load and useless hops), or "prefetched" at build time for components that can be static like blog posts, documentation, a top 10, etc. Interestingly, the Vercel Nextjs and Google Chrome teams have collaborated... from memory: to reduce bundle sizes and to stream assets after initial render for better performance.
"Static Hoisting" is pushing data to the edge and replicating it ahead of time. Legacy CDNs are just in time. The approach discussed in this article has a performance and availability advantage.
Isn't React itself already a giant JS framework? They've made a framework-for-a-framework?
So the idea is to let developers write as though it's all one big React SPA (single page app) but then actually the static bits of it get compiled into vanilla HTML/CSS and served from a CDN?
Yes, Next.js is "hybrid" framework for React. It allow you to incrementally adopt React, as well as evolve your application over time. Static pages, server-rendered, serverless functions––all within the same project.
For larger React projects, it's impractical to use the same rendering strategy for every page. Your marketing page can be static and your dashboard can be client-side rendered.
This is what people come up with if their product is dead simple but they have to justify VC funding. Seriously, there is no hidden analogy in "JAMSTACK". It is just a bunch of webservers around the globe, served via Georouting or Anycast DNS. No new pattern, no new frontiers.
Look at the comments here, people are more confused about this idea and terminology than anything else.
Generating a static website ahead of time is great, but it can have a few downside. On a big website, if you have many combinations of configuration for each page (like languages, amp/non amp, variant for several partners, etc) you have to generate a page for all combinations, which can quickly become pretty large and take a long time to generate.
16 comments
[ 3.2 ms ] story [ 32.2 ms ] threadI grew up making websites using server side includes[1] and using tools like (Macromedia) Dreamweaver to generate static sties. I guess I should've just stuck with that approach but shoved the results on a CDN?
I just so feel like it can't be that obvious. Please someone learn me for my benefit.
https://en.wikipedia.org/wiki/Server_Side_Includes
Is this another Heroku "routing mesh" gate in the making?
https://techcrunch.com/2013/02/14/heroku-admits-to-performan...
https://genius.engineering/herokus-ugly-secret/
I'm also not getting what the magic is. That little what Jamstack can actually do, might just not need a CDN?
"Static Hoisting" is pushing data to the edge and replicating it ahead of time. Legacy CDNs are just in time. The approach discussed in this article has a performance and availability advantage.
Isn't React itself already a giant JS framework? They've made a framework-for-a-framework?
So the idea is to let developers write as though it's all one big React SPA (single page app) but then actually the static bits of it get compiled into vanilla HTML/CSS and served from a CDN?
For larger React projects, it's impractical to use the same rendering strategy for every page. Your marketing page can be static and your dashboard can be client-side rendered.
Look at the comments here, people are more confused about this idea and terminology than anything else.