3 ms·

Can anyone in plain English explain the advantage of JAMstack over the typical nodejs or LAMP stack? All I seem to get is jargon filled press releases from com

Can anyone in plain English explain the advantage of JAMstack over the typical nodejs or LAMP stack? All I seem to get is jargon filled press releases from companies with millions of dollars of venture capital.

jameslk 6y ago
One offloads a large portion of rendering to the browser where as the other does it mostly on the server. Less processing on the server means less server costs. The former results in an API that can usually be repurposed more easily by other types of clients, such as Android and iOS apps. Also the API can usually be anything that responds to a HTTP request, such as Firebase, PostgREST, or even Airtable's API. Since the rendering is handled in the browser, the frontend can be placed any server that serves up static HTML, CSS, JS and images. Usually this is a CDN. Of course all these things are really trade-offs. It's arguably much easier just to throw together some PHP and stick it on some LAMP shared hosting if that meets your needs. Or if you're more comfortable with server side languages, you'll be a fish out of water. If you don't know why you would need it, you probably don't.
- shiftpgdn 6y ago
  That makes sense. But isn't that punishing to lower end hardware users? Also aren't you moving much more data back and forth to do that?
  - jameslk 6y ago
    > That makes sense. But isn't that punishing to lower end hardware users? Yes, and the punishments will continue until hardware improves. More seriously, this is definitely a big trade-off. That's why page weight has been growing over time and client side metrics haven't been getting much better despite improved hardware and connection speeds. There's no free lunch. As I've mentioned in past comments, now's a great time to be a web performance consultant. > Also aren't you moving much more data back and forth to do that? Considering that usually the bulk of the frontend arrives once and then gets cached/runs continuously, I would say generally no. Server side rendering requires the page to be sent in whole on each request, unless you're doing some funky hybrid stuff with partial server rendering.
- sbarre 6y ago
  The other problem with this approach is that is moves a lot of complexity to the edge of your environment. All the transformation & orchestration of your content has to happen in your app. If you have one backend and one app, that's not necessarily a bad thing, because you have to do that work somewhere, but if you have multiple apps (perhaps by multiple teams) that all consume the same backend, you start to duplicate a lot of that complexity all along the edge of your system.

jameslk 6y ago

One offloads a large portion of rendering to the browser where as the other does it mostly on the server. Less processing on the server means less server costs. The former results in an API that can usually be repurposed more easily by other types of clients, such as Android and iOS apps. Also the API can usually be anything that responds to a HTTP request, such as Firebase, PostgREST, or even Airtable's API. Since the rendering is handled in the browser, the frontend can be placed any server that serves up static HTML, CSS, JS and images. Usually this is a CDN. Of course all these things are really trade-offs. It's arguably much easier just to throw together some PHP and stick it on some LAMP shared hosting if that meets your needs. Or if you're more comfortable with server side languages, you'll be a fish out of water. If you don't know why you would need it, you probably don't.

shiftpgdn 6y ago
That makes sense. But isn't that punishing to lower end hardware users? Also aren't you moving much more data back and forth to do that?
- jameslk 6y ago
  > That makes sense. But isn't that punishing to lower end hardware users? Yes, and the punishments will continue until hardware improves. More seriously, this is definitely a big trade-off. That's why page weight has been growing over time and client side metrics haven't been getting much better despite improved hardware and connection speeds. There's no free lunch. As I've mentioned in past comments, now's a great time to be a web performance consultant. > Also aren't you moving much more data back and forth to do that? Considering that usually the bulk of the frontend arrives once and then gets cached/runs continuously, I would say generally no. Server side rendering requires the page to be sent in whole on each request, unless you're doing some funky hybrid stuff with partial server rendering.
sbarre 6y ago
The other problem with this approach is that is moves a lot of complexity to the edge of your environment. All the transformation & orchestration of your content has to happen in your app. If you have one backend and one app, that's not necessarily a bad thing, because you have to do that work somewhere, but if you have multiple apps (perhaps by multiple teams) that all consume the same backend, you start to duplicate a lot of that complexity all along the edge of your system.