The Evolution of Jamstack | Hacker News Reader

The Evolution of Jamstack

smashingmagazine.com

79 pointsphawksworth47 comments

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

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

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.

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.

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.

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.

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.

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.

Hmm, so basically you're saying it's a scam right?

I wouldn’t call it a « scam » technically.

But remember GWT ? I work in one Europe largest bank , the majority of internal apps are written in GWT.

In the 2010 era this trend was at its peak.[0]

Some members of the teams decided that they should « invest » in GWT because this would be the future.

Here we are 10 years laters , GWT is a deprecated legacy framework and developers have been burned out by this strategy.

For Jamstack the same will happen , the hype is reaching its peak and is going to come down as developers and businesses realize it doesn’t actually solve anything from their actual problems.

But in the process, people who are selling « Jamstack » books probably made a fortune. Same thing for GWT...

What’s your point? Technologies come and go. People built Ruby apps that did their job and now good luck finding maintainers for them. It’s just how our market works. We’re lucky if our stack lasts 10 years.

Ruby is still alive and well! It’s still focused on functionality over flash, and it’s not hard to find developers for it.

I agree with your larger point, but FWIW your example does not match my experience.

I've never had any special difficulties hiring Ruby/Rails devs. Quality is high, availability is reasonable (hiring is always something of a struggle!). My first Rails hire was in 2003 (rails-0.8, IIRC) and my most recent was about 6 months ago.

That's 17 years, and counting.

OTOH, I've never had a good time hiring people to maintain EOLed apps. Ruby or otherwise. "Sustaining Engineering" is a (misnamed) trade that isn't as broadly attractive as new development.

You may be confusing ruby with perl or clojure.

You're talking about *Jamstack* like it's some kind of proprietary framework or platform.

It's a methodology for building websites in a particular way using an enormously diverse set of tools and platforms. Comparing it to GWT is not correct.

I tend to agree. Rise of JAMStack as a concept is likely backed by companies like Netlify, Vercel, Auth0, Twilio, Firebase, and very other API-as-a-service company.

Though I think its part natural evolution of how web apps are built - it makes sense that common web apps functionality (like auth, database, email, etc) would be commoditized as services. I don't see that as a bad thing, especially since there is a lot of open source software (RoR, Django) that commoditizes and standardizes those aspects anyway.

JAMStack also has the side benefit of encouraging developers to focus on the business value of the software they are building, rather than the underlying plumbing.

It's sort of funny to see how this has suddenly become such a big term. I started out building a CMS that deploys static sites. I did that because I didn't want to deal with DBs / Wordpress, etc. I just wanted to quickly throw static pages onto a CDN and not worry about hosting. Netlify and the likes enabled this and I thought it was rather fantastic. So easy to deploy, very little performance worries, no DB to secure etc. etc. Then the JAMStack term started showing up (pushed by Netlify initially, I believe?). And you're right, just like 'serverless' (which is a ridiculous misnomer), I think this is just the kind of thing that's needed to get non-technical people on board with a better way of doing things.

At the same time, I think there's true advantages to this approach, so long as you do things right and don't fall into the traps of paying through the nose for things that should be cheap. cough Netlify form handling.

The challenge for Netlify (and my own business as well) is finding a way to capitalise on static sites, so often they will decide on some arbitrary metric and restrict that.

So, while I think the term jamstack may go away, I feel the idea behind static sites probably won't. To be able to make a whole shop, including financial transactions, without a DB in sight is quite appealing imo.

Just don't get suckered into the walled gardens / closed ecosystems out there.

I get how static sites are useful for readonly content, but what do you mean by "financial transactions without a DB in sight"? Even in jamstack you still have an API backed by a DB, no?

Ah, you are right, my wording was imprecise.

If using something like snipcart, you can then have a whole shop without you yourself having to maintain or admin a DB, it's all managed by a third party. They do, however, still maintain a DB themselves.

For my product I am planning to create a Stripe-based shop-module, which would allow anyone to create a shop using their own Stripe credentials. This would require some API calls coordinated by our own server and therefore some DB entries, at which point the sites cannot be considered pure readonly from our side.

All of this reminds me of the horrible misnomer 'serverless'...it's servers everywhere. And even the whole 'without DB' moniker doesn't hold up if things get a bit more involved. Maybe ultimately it's worth calling it the "let's try to keep sites as static and readonly as possible"-stack ;)

Thanks for the observation!

After so much time wasted with all of this, SPAs, microservices, microfraneworks, etc, I've ended up pretty burned out of the amount of work it takes, and the incredible number of corner cases I've found. From development environment issues to how to have a staging or testing environment to how to do authentication. Do many things you get for free with more traditional approaches.

Last year we started at work a project with plain old Rails. This year we started using stimulus and turbo. You cannot believe how much our lives have improved. Things are so easy and feel so solid. Everything has documentation, things don't change every other day. Patterns are clear, libraries well tested, we focus 99.9% on actual business problems.

Two members of the team left because they wanted to react node monorepos all the things. It's. South they left, but overall we are so much happier and more productive now, even with two members less (team of 6).

I really wish the pendulum swings back, as they say, and we stop this madness. At least for the 95% use cases that don't need to be an SPA with a Go backend for google scale.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

Sounds like you built something for yourself instead of building something that the market wants.

Every non technical person I've spoken with loves Wordpress and Squarespace for good reason.

> Sounds like you built something for yourself

Absolutely! That appears to be how all of my projects start. If I have a need for something, I'll go build it for myself. That way I am ensuring I am using my own product, which I find vital.

> instead of building something that the market wants.

I don't quite have that information yet. So far, reactions seem positive, but the jury is out on whether it'll work. I'm only about a month in, but I felt it's worth giving it a shot and seeing if there are others who want the same features I've built. I am not planning to even show up on Wordpress' or Squarespace's radar. Their user figures are in the millions. If I, by some stroke of luck and opportunity, ended up with a few hundred, maybe a thousand users, I'd consider this thing hugely successful.

> Every non technical person I've spoken with loves Wordpress and Squarespace for good reason.

This is super relevant, could you let me know how many people and what sort of level of technical knowledge? You mention 'for good reason', which would also be most interesting to hear more about. What sort of reasons?

I have found Wordpress and Squarespace to be good products. Squarespace much more so, especially for less-technical people. I find that setting up a Wordpress instance, even in this day and age is an extremely varied experience (from 1-click providers all the way to installing your own SQL DB and whatnot). But I have also found that you run into certain limitations quite quickly. Themes can be oddly restrictive. Changing your mind about something substantial on your site can quickly become an issue. At the same time, my product has other limitations, so it's obviously about what you think you need as a user. I'd wager that if you took someone properly non-technical and set them in front of our CMS vs. the Wordpress site builder (or even a site pre-built in either CMS), ours would be more intuitive to use. But I am still doing that research and while my sample size is growing, I wouldn't with confidence declare my product easier to use.

Edit: I feel documentation is another pretty big area where things quickly get confusing for users of the other providers' systems. I'm really trying to build a kind of documentation that encompasses the whole system and makes it very clear how to use every part of it. With something as complex as Wordpress that's nearly impossible to do, as Wordpress can be as complex as you like it to be. That's obviously one of its strengths: Even a dev can use it and not feel hindered by it. My product, on the flipside, does not cater to devs whatsoever.

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

I strongly disagree. IMO a headless CMS is perfect because it provides a good seperation of concerns. Marketing people want to adjust taglines and tweak text, add tags and do that sort of stuff, they don't want to spend their time building interfaces. Developers want to build interfaces but don't really care to spend their time figuring out the perfect tagline or adjusting verbiage on a landing page.

With a headless CMS I can focus on creating the page, hook it up to my CMS, and then message the marketing person that the page is ready for them to add data to it.

They don't want to build the whole interface but they sure want to move things around and try out pages with different layouts.

The goal is to allow them to ship marketing experiments as quickly as possible. With Jamstack, they always have to wait on the developer.

The only people who enjoy Jamstack are developers themselves because it's a cool toy to play with. I used to like playing around with Gatsby and Contentful 3 years ago. Then I decided that businesses need to make money and I can't be doing what I find fun to use at the detriment of the ecosystem.

Preach.

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?

They render HTML on the server. Revolutionary idea.

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

Good article!

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.

This seems... convoluted.

We, the people doing front-end, like to keep things exiting.

Surely you meant this facetiously?

I think not, what he describes is really the way some of these tools work.

Why render headless and repackage the output though?

The main benefit is for SEO tags on each individual route and proper 404 status code

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

Reply on news.ycombinator.com