I’m going to say something that will probably ruffle a few feathers, but this is just my opinion: you don’t need to make everything a JAMstack site.
I’d argue that decoupling the back-end and the front-end usually makes development more complicated, not less. If you need a separation of concerns for some reason or another, then by all means, do your thing. But it shouldn’t be the default.
The default in client services — which is what web design and web development is — should be to make something that serves the client. And your latest NPM-dependencies-from-hell software stack on their website is a recipe for disaster. NPM, React, Next, Nuxt, whatever, all that stuff is barely better than the WordPress spaghetti pile; it’s a ton of dependencies that all go down like a stack of cards if one thing goes wrong.
A good rule of thumb: make it as simple as it can be, but not simpler. Maybe you need a JAMstack. But maybe you don’t. Don’t start with an assumption! Start with the shape of the work, and use the solution that best matches it.
I don’t like using the JAMstack typically, and it would take a lot for me to see it as a solution to a problem. Maybe I’m a crusty old man after more than a decade in this industry, but here’s how I see it:
- JAMstack sites are not necessarily more secure than even a WordPress site (and WordPress is not secure). You still have to build with security in mind; otherwise it’s trivial for hackers to inject some javascript and subvert your login or security processes.
- Javascript is a crutch that too many developers rely on to avoid being good at the basics of HTML markup and CSS styling. You know what clients want? They want to rank on Google! You know what makes that a lot harder? Javascript injection! it is possible to use client-side rendering without nuking your client’s SEO, but it’s opaque and more difficult to do, and SEO experts say not to do it. If you’re good at HTML and CSS, you’ll need javascript injection a whole lot less frequently.
- It is simply too easy to be an average developer and rely on JAMstack to do the hard things for you. The problem, as I see it, is that JAMstack also makes easy things hard — like distribution! You can put plain old HTML anywhere, just about any server can run PHP, a lot of them can run Ruby, but by comparison, there are far fewer competitors to Vercel and Netlify than you might think.
Here’s the thing: maybe I’m wrong and JAMstack is the future. But it’s sort of like the way the smart home is the future. There are a lot of competing standards that are mostly similar, but wildly incompatible with one another, and the future is always one or two years away. Is PHP just peachy creamy all the time? No! PHP sometimes sucks. But it sucks in predictable ways compared to my experiences with JAMstack.
But my strong opinions on this are loosely held. We’ll see how this all shakes out over time. I am deeply concerned that Netlify is going to torch every bridge its built with developers as it adds more and more fees to its services, and I worry that React is a Meta-controlled “open source” project that still lives on a Facebook domain.
For a lot of use cases — most of which I don’t encounter with my client work — JAMstack is a pretty cool and interesting approach. All I’m asking is that you think before you use it for everything.