The Evolution of Jamstack
smashingmagazine.com
The Evolution of Jamstack
1–10 of 49 posts
Re: The Evolution of Jamstack
#2What does he mean by pre-rendering? Do they spin-up a browser-like environment on the server and use that to render the page and cache it? Or has that idea been improved upon?
Re: The Evolution of Jamstack
#3> Decoupling the frontend from back-end services and platforms enforces a clear contract for how your UI communicates with the rest of the system.
It’s kinda weird that the author is trying to associate themselves as bringing this idea mainstream when it already existed and was popular before 2016.
Re: The Evolution of Jamstack
#4What does he mean by pre-rendering? Do they spin-up a browser-like environment on the server and use that to render the page and cache it? Or has that idea been improved upon?
They render HTML on the server. Revolutionary idea.
Re: The Evolution of Jamstack
#5What does he mean by pre-rendering? Do they spin-up a browser-like environment on the server and use that to render the page and cache it? Or has that idea been improved upon?
No, it's more like server side rendering with PHP or Ruby, back in the days.
I wrote a bit about this topic here: https://dev.to/fllstck/where-when-should-you-render-your-htm...
Re: The Evolution of Jamstack
#6What does he mean by pre-rendering? Do they spin-up a browser-like environment on the server and use that to render the page and cache it? Or has that idea been improved upon?
At the end of your SPA build process, you spin up a dummy HTTP server and run headless chromium on it (e.g. with puppeteer) to render each route and save the output html.
Instead of only /dist/index.html, you have /dist/index.html, /dist/about/index.html etc.
Re: The Evolution of Jamstack
#7What does he mean by pre-rendering? Do they spin-up a browser-like environment on the server and use that to render the page and cache it? Or has that idea been improved upon?
At the end of your SPA build process, you spin up a dummy HTTP server and run headless chromium on it (e.g. with puppeteer) to render each route and save the output html. Instead of only /dist/index.html, you have /dist/index.html, /dist/about/index.html etc.
This seems... convoluted.
Re: The Evolution of Jamstack
#8> Decoupling the frontend from back-end services and platforms enforces a clear contract for how your UI communicates with the rest of the system. It’s kinda weird that the author is trying to associate themselves as bringing this idea mainstream when it already existed and was popular before 2016.
100% this. APIs have existed and served content to front ends waaay before the term Jamstack was coined. The author seems to be over applying what is actually a narrow flavor.
Re: The Evolution of Jamstack
#9Jamstack sounds good on paper but it causes too much trouble for marketing people.
The role of a website is to do marketing and if your marketing people can't easily work with it then it's a failure of a website.
Re: The Evolution of Jamstack
#10> Ultimately, I see the community moving towards an extremely powerful trio that provides Jamstack developers request-level control over the performance profile of any site or application:
> - Delivering pages entirely pre-rendered at build time,
> - Delivering pages dynamically via serverless functions, or
> - Building pages on-demand that then persist as static CDN assets.
this to me is the biggest shift in jamstack since I started seriously paying attention in 2017 (and then joined Netlify for a couple years).
it used to be all about static generation and portability ("any platform that hosts static files can be a jamstack host") now the bar has shifted toward needing to tie together any combination of static files and serverless functions with seamless routing and caching. Guillermo Rauch gave a talk last year calling this "hybrid" or "post jamstack".
whatever we call it, I am looking forward to see this mature as it had clearly been a pain point of large sites and preview workflows for a long time. however I view the difference between ISR and DPR to essentially be a standards battle. Blu ray vs HD DVD, Betamax vs VHS. and just like those battles, the adoption will be decided on two fronts - from vendors (SSG frameworks) and users (webdevs who must overcome yet more learning curve and jargon). all parties lose if the fight drags on for too long.
DPR is theoretically better bc the atomic deploy guarantee is indeed simpler to reason about. but the theoretically better tech doesn't always win, bc it often comes with a higher adoption barrier. it will be a big task for you and your team to lower that barrier. all the best.