> - 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.
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.
> 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.
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.
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.
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.
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!
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.
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.
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.
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...
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'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.
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'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 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.
Eventually I just got fed up and now wrote my subsequent react app from scratch.
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 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.
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.
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.
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.
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.
Every non technical person I've spoken with loves Wordpress and Squarespace for good reason.
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.
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.
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.
I wrote a bit about this topic here: https://dev.to/fllstck/where-when-should-you-render-your-htm...
Instead of only /dist/index.html, you have /dist/index.html, /dist/about/index.html etc.