You are missing something. Your content is dynamic but the html markup is generated ahead of time and served from CDN. The difference to static site is that your content lives in a CMS server + APIs and is not embedded in your codebase. Your codebase contains just the layout and components etc. without content. You can use all modern methods and frameworks such as React, but the final website is just html.
Yup, it pulls stuff in ahead of time. That said, that's just for the initial render. Once things are mounted and "static" can take advantage of apollo or whatever request lib you'd like for "dynamic" content. But the idea is to build out most paths in the build phase and then push up. A lot of the time thats all a site will need. It works amazingly well, at least with Gatsby.
The way Gatsby works is during the build phase it will take every path it can through your app _as if_ it was an SSR app, and compile flat html files out of that. So by the time it gets to your server it's remarkably SEO friendly.
How is that different from a regular single-page application? My understanding of JAM from watching [1] was that your entire site is static, except for JS that calls out to serverless APIs to CRUD your content on the backend or initiate some workflow with a third-party service like PayPal or Twilio. If your site allows user comments, then you would rebuild your static site every time the user comment is submitted instead of rendering the comments on the server when handling the request.
Google's HTTP 203 show about JAM stack [2] talks about doing sites claiming the do static site rebuilds "every second" and debates whether static site rebuilds would scale for a large site with lots of old content like the BBC or New York Times.
Static Site Generators basically compile the entire site and serve it as static files to a S3 equivalent bucket with the API component which could connect anywhere. There are faster compilers than others (i.e. Hugo, written with Go) that can compile 1000s of pages in a handful of seconds while others are slower comparatively (i.e. Jekyll); I personally like Gatsby[1] since it's Javascript based making it easy for me to understand and debug. There are setups where those builds can be more modular, so in the case of your News Industry example, you can split it up by section or have custom builds with web hooks based on the section that needs to be updated.
Comments normally would probably be something like Disqus but I've also seen a demo of a Netlify dev doing a hacky hijack of their forms function which allowed you to approve a comment then re-render based on approved comments.
You can also setup a CD system that builds every X seconds/minutes/hours/days/etc.
It's just a different way to build websites. I think it's useful for marketing websites but not as helpful when you need a true app.
There was a discussion on the HTTP 203 show about the JAM stack as well, which talks relatively quickly and briefly about concerns when deciding whether or not to implement a JAM stack vs other architectures. https://www.youtube.com/watch?v=QXsWaA3HTHA
It didn't. They are shortening "deployment" to "deploy" for unknown reasons when they say: "Atomic deploys -
Each deploy is a full snapshot of the site"
Not that weird though. We've, for example, turned "build" into a noun.
I can think of other -ment words that get shortened like that in just some online games I've played: "I need to change my equip[ment]", "my invest[ment] made money", "who's your replace[ment]?", "which adjust[ment] do you have on your rig?", etc.
It's not just "-ment". You invite someone with an invitation, but the verb is being used as the noun these days. In many contexts "package" is shortened to "pack", like "gift pack" or "bonus pack".
Am I the only one wondering if this was a covert announcement of the availability of domains in the WTF tld? If you move fast you can grab HackerNews.wtf ...
> Faster performance. Serve pre-built markup and assets over a CDN
Just like every single-page app.
> More secure. No need to worry about server or database vulnerabilities
Total BS. A form post is an API call by another name. Your server and database are just as vulnerable via an API.
> Less expensive. Hosting of static files are cheap or even free
Just like every single-page app.
> Better developer experience. Front end developers can focus on the front end, without being tied to a monolithic architecture. This usually means quicker and more focused development
Really? And templating languages do not exist on the backend? The only difference is where the processing occurs, and a single-page app has just as much templating whether the template is rendered in-browser or on-server. Often it has a lot more.
> Scalability. If your product suddenly goes viral and has many active users, the CDN seamlessly compensates
25 days ago I made this comment:
"The key is to invent a new term for an existing entity. Here the author tries to introduce the term "document site" for static websites."
The same happens here. Take an existing concept. Stick a new label-term on it. Market it like you're the inventor of this revolutionary concept to the unaware. Profit.
SPAs can be JAMstack or non-JAMstack. JAM is secure as fuck when there's no 'A' or when you trust the 'A' strongly. (e.g. Google Maps API) Otherwise, you're just making security someone else's problem.
The term is probably not great for reasons mentioned here, but the concept is nifty.
It makes tricks like React pages rendering without javascript possible, and works with pretty much any language that can manipulate strings (awk, sed & curl build process, why not).
If your api is only used during the build step, scaling is really easy like tfa mentions.
You seem to confuse things. JAMstack doesn't try to replace SPAs, it's trying to replace Wordpress. It's simply a better choice for websites and blogs than either SPA or Wordpress. It really is a different concept than SPA.
In pure JAMstack, APIs are used only at the build step, and you don't have to expose them. You get your content such as blog posts from the API, render them to html and store on CDN.
Monolithic architecture refers mostly to Wordpress. With JAMstack you separate your CMS from your frontend, and you can manage your content with a service like https://www.contentful.com/ that doesn't define how the content gets rendered.
You use Kubernetes (GKE, right?) for a static website? How does that work? (or am I misunderstanding)
What about bandwidth costs? With Google and AWS, bandwidth is expensive — have you considered the case where your blog gets suddenly super popular, or maybe DoS attacked? ... to me, that feels dangerous o.O what do you think?
I like Hugo too b.t.w., I've written a blog comments plugin for Hugo (and others), link in my profile.
I don't like the term and predict that it will fade quickly, but I do admire the way Netlify coined a term that they could market to their audience of developers who are all yearning for a less insanely complicated way of working.
Whether or not JAMstack is less complicated is a question for another day. What's important is that Netlify owns the hype here and is doing a very good job of leveraging it.
This is pretty much exactly a JAMstack, provided you keep your content in some separate markup.
Static site generation had an image problem, because people thought that having a static site meant that they would not be able to have dynamic content on their site.
JAMstack is basically a way of rebranding static sites saying that you should generate the pages you are serving and push them to a CDN edge network for TTFB speed, but you can still make them dynamic by using API calls to anything that needs to access a DB, etc.
It's a way of showing people that we should be doing more things statically when we can, and separating out dynamic components into their own APIs.
I struggle to beat a Django/Rails site with a few libraries and server side rendered templates. Not as straightforward to host as a static site, but much more straightforward than a static site plus a bunch of micro service APIs, plus I can render content on a fast server rather than a slow phone.
I’m all for SPAs for products that reach a certain level of complexity. They are 10x more capable, but take 10x the work.
I wish they spent a bit more time on the CMS part of the equation. It's hugely important to enable content editors to make changes. The solution isn't that valuable if it's limited to devs only. I also don't think there's a clear winner yet. Maybe, Contentful if you have a boatload of money, but I certainly don't.
I did just implement Netlify CMS in a project though. Super easy to get set up and it's open source. It's missing some things from more polished CMSes that you might expect, like editor roles, but it's still pretty young. The project lead is really responsive and I have high hopes for it long term.
50 comments
[ 2.5 ms ] story [ 112 ms ] thread[1] https://www.youtube.com/watch?v=grSxHfGoaeg
Google's HTTP 203 show about JAM stack [2] talks about doing sites claiming the do static site rebuilds "every second" and debates whether static site rebuilds would scale for a large site with lots of old content like the BBC or New York Times.
[2] https://www.youtube.com/watch?v=QXsWaA3HTHA
Comments normally would probably be something like Disqus but I've also seen a demo of a Netlify dev doing a hacky hijack of their forms function which allowed you to approve a comment then re-render based on approved comments.
You can also setup a CD system that builds every X seconds/minutes/hours/days/etc.
It's just a different way to build websites. I think it's useful for marketing websites but not as helpful when you need a true app.
[1] https://www.gatsbyjs.org, also checkout: https://www.gatsbyjs.org/showcase/
Not that weird though. We've, for example, turned "build" into a noun.
But no, apparently "build" has been screwed up since the 1660s[1].
[1] https://www.etymonline.com/word/build#etymonline_v_18047
https://www.namecheap.com/domains/registration/results.aspx?...
The article is also loaded with BS:
> Faster performance. Serve pre-built markup and assets over a CDN
Just like every single-page app.
> More secure. No need to worry about server or database vulnerabilities
Total BS. A form post is an API call by another name. Your server and database are just as vulnerable via an API.
> Less expensive. Hosting of static files are cheap or even free
Just like every single-page app.
> Better developer experience. Front end developers can focus on the front end, without being tied to a monolithic architecture. This usually means quicker and more focused development
Really? And templating languages do not exist on the backend? The only difference is where the processing occurs, and a single-page app has just as much templating whether the template is rendered in-browser or on-server. Often it has a lot more.
> Scalability. If your product suddenly goes viral and has many active users, the CDN seamlessly compensates
Ahem! API?
The same happens here. Take an existing concept. Stick a new label-term on it. Market it like you're the inventor of this revolutionary concept to the unaware. Profit.
It makes tricks like React pages rendering without javascript possible, and works with pretty much any language that can manipulate strings (awk, sed & curl build process, why not).
If your api is only used during the build step, scaling is really easy like tfa mentions.
In pure JAMstack, APIs are used only at the build step, and you don't have to expose them. You get your content such as blog posts from the API, render them to html and store on CDN.
Monolithic architecture refers mostly to Wordpress. With JAMstack you separate your CMS from your frontend, and you can manage your content with a service like https://www.contentful.com/ that doesn't define how the content gets rendered.
JS shows up in the themes / customization, but for the most part you're only dealing with Markdown
What about bandwidth costs? With Google and AWS, bandwidth is expensive — have you considered the case where your blog gets suddenly super popular, or maybe DoS attacked? ... to me, that feels dangerous o.O what do you think?
I like Hugo too b.t.w., I've written a blog comments plugin for Hugo (and others), link in my profile.
Whether or not JAMstack is less complicated is a question for another day. What's important is that Netlify owns the hype here and is doing a very good job of leveraging it.
- GitHub for version control
- AWS CodePipeline for building and deployment (include cache invalidation)
- NextJS to statically export my site built in React
- S3 to host my content
- Cloudfront as my CDN
- Route53 to manage my domain (that I got from Google Domains)
- API's are hosted on a different stack
I didn't use a service like Netlify because I wanted to reduce the number of vendors that had access to my user's data (like IP address etc. etc.)
Static site generation had an image problem, because people thought that having a static site meant that they would not be able to have dynamic content on their site.
JAMstack is basically a way of rebranding static sites saying that you should generate the pages you are serving and push them to a CDN edge network for TTFB speed, but you can still make them dynamic by using API calls to anything that needs to access a DB, etc.
It's a way of showing people that we should be doing more things statically when we can, and separating out dynamic components into their own APIs.
I’m all for SPAs for products that reach a certain level of complexity. They are 10x more capable, but take 10x the work.
I did just implement Netlify CMS in a project though. Super easy to get set up and it's open source. It's missing some things from more polished CMSes that you might expect, like editor roles, but it's still pretty young. The project lead is really responsive and I have high hopes for it long term.