8 ms·

The Evolution of Jamstack

79 points by phawksworth 5y ago

sbazerque 5y ago
What 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?
- lostfocus 5y ago
  They render HTML on the server. Revolutionary idea.
- k__ 5y ago
  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-html-41b5 https://dev.to/fllstck/where-when-should-you-render-your-htm...
  - gadders 5y ago
    Good article!
  - deleted 5y ago
    [deleted]
- trinovantes 5y ago
  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.
  - sbazerque 5y ago
    This seems... convoluted.
    - Tade0 5y ago
      We, the people doing front-end, like to keep things exiting.
  - arcturus17 5y ago
    Surely you meant this facetiously?
    - sbazerque 5y ago
      I think not, what he describes is really the way some of these tools work.
      - arcturus17 5y ago
        Why render headless and repackage the output though?
        trinovantes 5y ago
        The main benefit is for SEO tags on each individual route and proper 404 status code
meagher 5y ago
> 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.
- websitescenes 5y ago
  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.
- dkarl 5y ago
  I agree. The importance of separating presentation concerns from business logic was in the air, impossible to avoid, when I became a software engineer in the early 2000s. > At that point [in 2016], the idea of fundamentally decoupling the front-end web layer from the back-end business logic layer was only an early trend, and not yet a named architectural approach. The first named architectural approach I ever learned was three-tier application architecture (presentation, business logic, database,) named to contrast it to the two-tier approach of combining the presentation logic and the business logic in a single layer (often a desktop application that communicated directly with a database.) The problems arising from this mixing and the advantages of separating UI and business logic into different architectural tiers were well known to people writing internal business applications long before web applications took over this niche. I don't know the history prior to my own introduction to the industry, but I wouldn't be surprised if it dated back to the mid-1990s or even earlier.
jmconfuzeus 5y ago
Jamstack 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.
- gherkinnn 5y ago
  Of all the valid criticisms of JAM, this isn’t one. Not every website is in the hands of marketing people and even if it were so, any CMS can be used. No need to teach anybody how to use Git.
  - jmconfuzeus 5y ago
    Not just Git, marketing people also hate headless CMSes because they're hard to use and make it more complicated to try new things out. You have to use different tools to build forms, pages, and track users. Even as a developer I think it's a nightmare. They best way to build a website is by using something like Elementor or Webflow so that engineers can spend time building useful things instead of reinventing the wheel. Block based CMSes like Wagtail are also very good because unlike page builders, you get good performance. Of course, there will be additional development costs. In the end, it's very important to not require development time for every little experiment your marketing team needs to carry out and with Jamstack you always need to bother your developer when you need to make a change.
    - PinkPigeon 5y ago
      Well, funnily enough, I have also found existing site builders to be insufficient in various ways. Firstly, I do not believe that the block-based approach works that well. It sounds great on paper, to be able to drag and drop block-like elements to compose a page, but it falls apart so quickly. You just don't end up with coherent pages, especially once everything starts getting rearranged on mobile. Speaking of mobile, try using one of those drag and drop based editors on a mobile phone. Plus, performance is usually terrible and getting your preview can also take a while. Not sure if they do shareable preview pages nowadays. I build a CMS for static pages (not sure it's considered jamstack?) addressing all of the above, which deploys straight to Cloudflare, handles your forms and is based on modules, not blocks. Everything is a module, basically. This has allowed us to create sites that are properly responsive AND a CMS that works properly on smartphones. The tricky part is competing in a market where everyone thinks Wordpress, Wix and Squarespace are the last word spoken (when that couldn't be further from the truth, there is so much to be improved upon). We're also competing on price, depending on what features users need. Don't know if anyone here is interested in trying it, but if you hit me up, I'll sort you out with a discount.
swyx 5y ago
> 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.
yannoninator 5y ago
so many questions about this: how does the database fit into this? how does the 'Jamstack' compare to Wordpress or it doesn't? how does content get edited in the 'Jamstack' like Wordpress? how is the 'Jamstack' 'mainstream'? compared to what? why do I have to use Git to use the 'Jamstack'?
- input_sh 5y ago
  It helps if you separate the first three letters: JavaScript + APIs + Markup = JAMstack. Markup is the content, which can be entered via any method. You can set up a CMS like WordPress or Ghost to serve this role, or you can build your own interface. That markup is then made compatible with various JavaScript libraries via APIs. But it evolved over the years to the point where "JavaScript" part isn't entirely accurate. You can throw any static site generator in the mix and just use a plugin that will convert content edited via CMS into Markdown files. It's basically a way for front-end developers to not particularly care about the backend. So instead of making WordPress themes or whatever they make a site using static site generators. Users don't like the look of an editor? You have the ability to change it completely, find a plugin, and the end result is the same website. No need to adapt the theme to the new CMS or bother with migrating content between editors.
- PinkPigeon 5y ago
  I can at least answer this for my 'Jamstack' product (I think it might be accidentally 'Jamstack', as I only recently found out that this refers to static pages with no DB etc). I wanted to just have a sensible frontend for Hugo, with easily reusable components that are not React, etc. So, your questions: > how does the database fit into this? The only DB we have is our own CMS, so that's keeping your user details and your site details. That's it. The websites the CMS produces go straight to Cloudflare as static sites. The files sit on our server and are manipulated directly from within the CMS. > how does the 'Jamstack' compare to Wordpress or it doesn't? We don't have themes, or drag and drop block-based editing. We use modules (basically components) that combine different ways of displaying text / imagery / video and can be stacked vertically into a static website. All of this runs a lot faster, as we don't have a super complex react frontend with a million loc of JS, but rather just some vanilla js sprinkled in here and there to keep things a bit dynamic. Also works really well on mobile, which Wordpress doesn't do all that well I don't think. Makes it a lot easier to represent site structure visually imo > how does content get edited in the 'Jamstack' like Wordpress? A bunch of json files / go html templates fed into Hugo, which compiles a static site. These json files are of course represented in a very visually appealing (I hope at least) way. The whole point of the CMS is to keep all technical concerns far, far away from users. > how is the 'Jamstack' 'mainstream'? compared to what? I am not sure it is. Everyone I've so far spoken to is only aware of Squarespace, Wordpress (they claim they're 40% of the web), Wix, or the site builders that come with 123reg or Godaddy. And almost nobody seems to like them, which is a real shame. I think that entire sector has failed to enable laypeople to make websites. I hope to somehow be able to rectify that. > why do I have to use Git to use the 'Jamstack'? I think it's for CI (continuous integration) convenience. The problem is that only developers understand how this works. We actually started out deploying to Netlify via git, but the process was too slow and brittle (often webhooks wouldn't work). Thus, we just deploy static sites directly to Cloudflare workers sites. No git involved. Netlify also supports .zip file deployments FWIW.
0xb0565e487 5y ago
I've been working for a company that heavily caters toward the "JAMStack ecosystem" for a while now. From my point of view, the "JAMStack" is nothing more than a piece of jargon used to aggregate various "good" ways of building and deploying web applications to trick non-technical business people or entry-level developers into using their services. There's an absurd amount of money and effort currently being spent marketing this term. Whatever it is, it's ephemeral, and I recommend anyone to avoid spending time on this unless they want to fall into another marketing funnel.
- benjaminjosephw 5y ago
  This is also true for basically all "cloud" services. There's no real innovation, just a return to mainframes and timesharing with a massive amount of marketing momentum to convince everyone that this is a step forwards. But hey, we all drank the Kool-Aid.
  - jeffreyrogers 5y ago
    Maybe there's no technological innovation, but they do make things a lot easier. I set up my own email server once (for sending mail from a webapp) and after doing that once I'm happy to use mailgun from now on (it is non trivial to configure a mail server to deliver mail to all major email providers without getting flagged as spam). Sometimes avoiding the cloud services is the right decision, and I think many architectures are overly complicated based on current and prospective performance requirements (cargo cult infrastructure/architecture), but used properly they save many thousands of hours of engineering time.
  - pudmaidai 5y ago
    Yeah, ok, maybe you’re glossing over the immense difference that there is between what could be done on a mainframe vs what a Lambda allows, including all complementary services like per-second billing and granular permissions and logging. Now tell me that this is just the same thing as “mainframes” from the 80s.
- yannoninator 5y ago
enahs-sf 5y ago
I know when I used next.js, vercel was collecting telemetry. Would be interesting for them to publish some of that data. I’d love to know the median compile time of next.js apps. On the app I worked on it was pretty slow. Like go get a coffee and come back slow. Eventually I just got fed up and now wrote my subsequent react app from scratch.
- _fat_santa 5y ago
  I found quite the opposite. Both Next.JS and Gatsby are so so fast with HMR, I really am not sure how they achieve that with Webpack. I have a few apps that are bootstrapped with Webpack and things like hot reloading take a few seconds, with Next or Gatsby it's instant. As far as build time I've noticed all my React apps, whether built with regular Webpack or Next, all compile in roughly the same time.
hutrdvnj 5y ago
I remember the time when LAMP stack was new. Every new stack will be discussed controversial at first. Some say avoid it as hell, some say it's very good, some say who cares. I think as time progresses this term will be less and less controversial until people use it like they would refer to the LAMP stack without further thinking.
IshKebab 5y ago
> At that point, the idea of fundamentally decoupling the front-end web layer from the back-end business logic layer was only an early trend, and not yet a named architectural approach. Is this a joke? As far as I can tell Jamstack is just a buzzword for web sites served via CDN that use JavaScript.

79 points by phawksworth 5y ago

What 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?

lostfocus 5y ago
They render HTML on the server. Revolutionary idea.
k__ 5y ago
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-html-41b5 https://dev.to/fllstck/where-when-should-you-render-your-htm...
- gadders 5y ago
  Good article!
- deleted 5y ago
  [deleted]
trinovantes 5y ago
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.
- sbazerque 5y ago
  This seems... convoluted.
  - Tade0 5y ago
    We, the people doing front-end, like to keep things exiting.
- arcturus17 5y ago
  Surely you meant this facetiously?
  - sbazerque 5y ago
    I think not, what he describes is really the way some of these tools work.
    - arcturus17 5y ago
      Why render headless and repackage the output though?
      - trinovantes 5y ago
        The main benefit is for SEO tags on each individual route and proper 404 status code

meagher 5y ago

> 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.

websitescenes 5y ago
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.
dkarl 5y ago
I agree. The importance of separating presentation concerns from business logic was in the air, impossible to avoid, when I became a software engineer in the early 2000s. > At that point [in 2016], the idea of fundamentally decoupling the front-end web layer from the back-end business logic layer was only an early trend, and not yet a named architectural approach. The first named architectural approach I ever learned was three-tier application architecture (presentation, business logic, database,) named to contrast it to the two-tier approach of combining the presentation logic and the business logic in a single layer (often a desktop application that communicated directly with a database.) The problems arising from this mixing and the advantages of separating UI and business logic into different architectural tiers were well known to people writing internal business applications long before web applications took over this niche. I don't know the history prior to my own introduction to the industry, but I wouldn't be surprised if it dated back to the mid-1990s or even earlier.

jmconfuzeus 5y ago

Jamstack 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.

gherkinnn 5y ago
Of all the valid criticisms of JAM, this isn’t one. Not every website is in the hands of marketing people and even if it were so, any CMS can be used. No need to teach anybody how to use Git.
- jmconfuzeus 5y ago
  Not just Git, marketing people also hate headless CMSes because they're hard to use and make it more complicated to try new things out. You have to use different tools to build forms, pages, and track users. Even as a developer I think it's a nightmare. They best way to build a website is by using something like Elementor or Webflow so that engineers can spend time building useful things instead of reinventing the wheel. Block based CMSes like Wagtail are also very good because unlike page builders, you get good performance. Of course, there will be additional development costs. In the end, it's very important to not require development time for every little experiment your marketing team needs to carry out and with Jamstack you always need to bother your developer when you need to make a change.
  - PinkPigeon 5y ago
    Well, funnily enough, I have also found existing site builders to be insufficient in various ways. Firstly, I do not believe that the block-based approach works that well. It sounds great on paper, to be able to drag and drop block-like elements to compose a page, but it falls apart so quickly. You just don't end up with coherent pages, especially once everything starts getting rearranged on mobile. Speaking of mobile, try using one of those drag and drop based editors on a mobile phone. Plus, performance is usually terrible and getting your preview can also take a while. Not sure if they do shareable preview pages nowadays. I build a CMS for static pages (not sure it's considered jamstack?) addressing all of the above, which deploys straight to Cloudflare, handles your forms and is based on modules, not blocks. Everything is a module, basically. This has allowed us to create sites that are properly responsive AND a CMS that works properly on smartphones. The tricky part is competing in a market where everyone thinks Wordpress, Wix and Squarespace are the last word spoken (when that couldn't be further from the truth, there is so much to be improved upon). We're also competing on price, depending on what features users need. Don't know if anyone here is interested in trying it, but if you hit me up, I'll sort you out with a discount.

swyx 5y ago

> 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.

yannoninator 5y ago

so many questions about this: how does the database fit into this? how does the 'Jamstack' compare to Wordpress or it doesn't? how does content get edited in the 'Jamstack' like Wordpress? how is the 'Jamstack' 'mainstream'? compared to what? why do I have to use Git to use the 'Jamstack'?

input_sh 5y ago
It helps if you separate the first three letters: JavaScript + APIs + Markup = JAMstack. Markup is the content, which can be entered via any method. You can set up a CMS like WordPress or Ghost to serve this role, or you can build your own interface. That markup is then made compatible with various JavaScript libraries via APIs. But it evolved over the years to the point where "JavaScript" part isn't entirely accurate. You can throw any static site generator in the mix and just use a plugin that will convert content edited via CMS into Markdown files. It's basically a way for front-end developers to not particularly care about the backend. So instead of making WordPress themes or whatever they make a site using static site generators. Users don't like the look of an editor? You have the ability to change it completely, find a plugin, and the end result is the same website. No need to adapt the theme to the new CMS or bother with migrating content between editors.
PinkPigeon 5y ago
I can at least answer this for my 'Jamstack' product (I think it might be accidentally 'Jamstack', as I only recently found out that this refers to static pages with no DB etc). I wanted to just have a sensible frontend for Hugo, with easily reusable components that are not React, etc. So, your questions: > how does the database fit into this? The only DB we have is our own CMS, so that's keeping your user details and your site details. That's it. The websites the CMS produces go straight to Cloudflare as static sites. The files sit on our server and are manipulated directly from within the CMS. > how does the 'Jamstack' compare to Wordpress or it doesn't? We don't have themes, or drag and drop block-based editing. We use modules (basically components) that combine different ways of displaying text / imagery / video and can be stacked vertically into a static website. All of this runs a lot faster, as we don't have a super complex react frontend with a million loc of JS, but rather just some vanilla js sprinkled in here and there to keep things a bit dynamic. Also works really well on mobile, which Wordpress doesn't do all that well I don't think. Makes it a lot easier to represent site structure visually imo > how does content get edited in the 'Jamstack' like Wordpress? A bunch of json files / go html templates fed into Hugo, which compiles a static site. These json files are of course represented in a very visually appealing (I hope at least) way. The whole point of the CMS is to keep all technical concerns far, far away from users. > how is the 'Jamstack' 'mainstream'? compared to what? I am not sure it is. Everyone I've so far spoken to is only aware of Squarespace, Wordpress (they claim they're 40% of the web), Wix, or the site builders that come with 123reg or Godaddy. And almost nobody seems to like them, which is a real shame. I think that entire sector has failed to enable laypeople to make websites. I hope to somehow be able to rectify that. > why do I have to use Git to use the 'Jamstack'? I think it's for CI (continuous integration) convenience. The problem is that only developers understand how this works. We actually started out deploying to Netlify via git, but the process was too slow and brittle (often webhooks wouldn't work). Thus, we just deploy static sites directly to Cloudflare workers sites. No git involved. Netlify also supports .zip file deployments FWIW.

0xb0565e487 5y ago

I've been working for a company that heavily caters toward the "JAMStack ecosystem" for a while now. From my point of view, the "JAMStack" is nothing more than a piece of jargon used to aggregate various "good" ways of building and deploying web applications to trick non-technical business people or entry-level developers into using their services. There's an absurd amount of money and effort currently being spent marketing this term. Whatever it is, it's ephemeral, and I recommend anyone to avoid spending time on this unless they want to fall into another marketing funnel.

benjaminjosephw 5y ago
This is also true for basically all "cloud" services. There's no real innovation, just a return to mainframes and timesharing with a massive amount of marketing momentum to convince everyone that this is a step forwards. But hey, we all drank the Kool-Aid.
- jeffreyrogers 5y ago
  Maybe there's no technological innovation, but they do make things a lot easier. I set up my own email server once (for sending mail from a webapp) and after doing that once I'm happy to use mailgun from now on (it is non trivial to configure a mail server to deliver mail to all major email providers without getting flagged as spam). Sometimes avoiding the cloud services is the right decision, and I think many architectures are overly complicated based on current and prospective performance requirements (cargo cult infrastructure/architecture), but used properly they save many thousands of hours of engineering time.
- pudmaidai 5y ago
  Yeah, ok, maybe you’re glossing over the immense difference that there is between what could be done on a mainframe vs what a Lambda allows, including all complementary services like per-second billing and granular permissions and logging. Now tell me that this is just the same thing as “mainframes” from the 80s.
yannoninator 5y ago

enahs-sf 5y ago

I know when I used next.js, vercel was collecting telemetry. Would be interesting for them to publish some of that data. I’d love to know the median compile time of next.js apps. On the app I worked on it was pretty slow. Like go get a coffee and come back slow. Eventually I just got fed up and now wrote my subsequent react app from scratch.

_fat_santa 5y ago
I found quite the opposite. Both Next.JS and Gatsby are so so fast with HMR, I really am not sure how they achieve that with Webpack. I have a few apps that are bootstrapped with Webpack and things like hot reloading take a few seconds, with Next or Gatsby it's instant. As far as build time I've noticed all my React apps, whether built with regular Webpack or Next, all compile in roughly the same time.

hutrdvnj 5y ago

I remember the time when LAMP stack was new. Every new stack will be discussed controversial at first. Some say avoid it as hell, some say it's very good, some say who cares. I think as time progresses this term will be less and less controversial until people use it like they would refer to the LAMP stack without further thinking.

IshKebab 5y ago

> At that point, the idea of fundamentally decoupling the front-end web layer from the back-end business logic layer was only an early trend, and not yet a named architectural approach. Is this a joke? As far as I can tell Jamstack is just a buzzword for web sites served via CDN that use JavaScript.