WTF is JAMstack? | Hacker News Reader

WTF is JAMstack?

jamstack.wtf

54 pointsChrisArchitect47 comments

Open articleView on HN

How is this different from a single page app?

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?

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.

If you're trying to sell plain ol' websites to management who are obsessed with flavour-of-the-month frameworks, a slick website promoting the benefits of "JAMstack" is a really useful thing.

Ironically, "documents" are what the original web elders called the things at the end of links.

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.

It's amazing how much easier everything gets when you define all the hard parts as somebody 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 miss "The modern web revolution starts" from the 2017 block on the page.

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.

LOL

Am I missing something or is this just a plain old normal static website?

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.

So there is no server-side rendering of content? Will Google index this correctly?

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.

[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

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.

[1] https://www.gatsbyjs.org, also checkout: https://www.gatsbyjs.org/showcase/

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.

Good point.

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

https://www.namecheap.com/domains/registration/results.aspx?...

To late

.wtf has been around for a long time now

I don't know if I have a "JAMstack", but here's my tooling to create a product marketing site:

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

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

I still prefer Hugo to JAM. The lesser JavaScript, the better

Hugo doesn't really replace javascript - it, in fact, still uses it if your theme does.

Love Hugo, can go from git commit to serving in 30s. GCloud builder + GKE on a single n1 vm.

JS shows up in the themes / customization, but for the most part you're only dealing with Markdown

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.

Hugo is not a competitor to JAMstack; it is a component of it.

BANG ON!

When did "deploy" become a noun? I always considered it only as verb. Can someone enlighten me?

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.

Perhaps, ahem... "buildment"?

But no, apparently "build" has been screwed up since the 1660s[1].

[1] https://www.etymonline.com/word/build#etymonline_v_18047

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

It's 2019, we gotta innovate :D

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

Oh look, something that takes 10x longer to develop than static html that is more performant and easier to manage.

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.

How does it take 10x longer? The guide clearly says you can hand code your HTML, if that's your jam ;)

It seems you haven't had to do the tango with modern ~code~ javascript compilers.

I got more information about 50% down (the timeline) explains everything.

Better, faster, cheaper. They've cracked the code!

rube goldberg stack

Reply on news.ycombinator.com