Ask HN: What is JAMStack? How is it different from SPAs with SSR, if at all?
2 comments
JAMStack is the fancy term netlify introduced.
Most of the time its just a static site generator like gohugo.io with a bit js and apis sprinkled into. So instead of rendering the page at request time, its rendered before deployment, deployed as static html with the js part managing the dynamic parts like stripe, apis, etc.
Umm, that all sounds like SPA+SSR to me?
EDIT: Nvm. Upon rereading, I picked up on the distinction that the rendering is done before a request is made.
EDIT: Nvm. Upon rereading, I picked up on the distinction that the rendering is done before a request is made.
The JAMStack (JavaScript, APIs, and Markup) is a web architecture that was born out of the need for faster development and better performance. A JAMStack site/application is designed to be as fast as possible, and to be built with a wide variety of different technologies--which makes it easier for developers to build sites without having spent years learning a certain technology.
One of the main differences between JAMStack and SPAs with SSR (Single-page applications with server-side rendering) is that JAMStack sites are pre-rendered rather than rendered on the fly by servers. This means that they can't use any dynamic content on the page—everything must be done when the page is pre-rendered. This makes them much faster since they don't have to make requests to servers in order to render pages after they're loaded in the browser.
That doesn't mean you can't use dynamic content on your site, though! You just need to pull it in after your app loads using APIs. That way you get the best of both worlds: a fast-loading site that pulls in dynamic data when it needs to through APIs.
One of the main differences between JAMStack and SPAs with SSR (Single-page applications with server-side rendering) is that JAMStack sites are pre-rendered rather than rendered on the fly by servers. This means that they can't use any dynamic content on the page—everything must be done when the page is pre-rendered. This makes them much faster since they don't have to make requests to servers in order to render pages after they're loaded in the browser.
That doesn't mean you can't use dynamic content on your site, though! You just need to pull it in after your app loads using APIs. That way you get the best of both worlds: a fast-loading site that pulls in dynamic data when it needs to through APIs.
Ok, so the only difference between JAMStack and SPA+SSR that I've picked up here is that, in a JAMStack setup, the server-side-rendering happens before a request is made by the end user, while in a SPA+SSR setting, it happens after a request is made.
Is that right?
Is that right?
The beauty of JAMStack in my opinion is that everything is pre-rendered at build time, so your site is 100% static and can be served out of a CDN.
Pair that with third party APIs or a serverless backend like Firebase and you basically have an infinitely scalable dynamic website for little effort.
Pair that with third party APIs or a serverless backend like Firebase and you basically have an infinitely scalable dynamic website for little effort.
I can't think of many cases where pre-rendering before the request is more advantageous than both completely static sites, and pre-rendering after the request.
I say this because most of the cases I can think of for dynamic websites would benefit from (or require) information about the currently logged in user, which is information only available when a request is made.
The only case I can think where JAMstack as we are defining it here would be a good fit is may be newspapers/magazines, where you'd perhaps like to make some API calls (to embed a tweet or whatever), but the content doesn't depend on the currently logged in user.
For that, and other reasons, I'm not at all convinced that JAMstack (or, tbh, I would like to call it pre-request-SSR) is an advantageous architecture in most cases. If anyone can point to blog posts by companies that have adopted JAMstack in production, and write about the tradeoffs they had to make and how that suited them, that would be great!
I say this because most of the cases I can think of for dynamic websites would benefit from (or require) information about the currently logged in user, which is information only available when a request is made.
The only case I can think where JAMstack as we are defining it here would be a good fit is may be newspapers/magazines, where you'd perhaps like to make some API calls (to embed a tweet or whatever), but the content doesn't depend on the currently logged in user.
For that, and other reasons, I'm not at all convinced that JAMstack (or, tbh, I would like to call it pre-request-SSR) is an advantageous architecture in most cases. If anyone can point to blog posts by companies that have adopted JAMstack in production, and write about the tradeoffs they had to make and how that suited them, that would be great!
I think your analysis is fairly accurate. There are plenty of sites that are mostly static with some dynamic functionality injected in. JAMStack is great for those use cases.
For fully dynamic applications, JAMStack may not be the optimal approach but it does work. I don't use SSR for my dynamic applications and it's not bad. The user downloads a static React app, the app pings Auth0 to see if they're logged in, and then the app fetches data from my server. That takes 100-200ms but that's totally acceptable for my use case.
One downside to SSR is that you do need the server capabilities to handle whatever load gets thrown at your site.
For fully dynamic applications, JAMStack may not be the optimal approach but it does work. I don't use SSR for my dynamic applications and it's not bad. The user downloads a static React app, the app pings Auth0 to see if they're logged in, and then the app fetches data from my server. That takes 100-200ms but that's totally acceptable for my use case.
One downside to SSR is that you do need the server capabilities to handle whatever load gets thrown at your site.
1. This[0] is what I mean by JAMStack. 2. "SPA" refers to single-page-app. 3. "SSR" refers to server-side-rendering.
[0] http://jamstack.wtf