Jerod Santo changelog.com/posts

There's a good reason why experienced devs say "it depends" so often

we're all sick of it, but we're not going to stop saying it

I was reading Chris Coyier’s Weaved Webs post the other day and was impressed by his pragmatism. Chris writes about the irony with Jamstack:

The irony is that while the concept is simple, that simplicity can be the cause of complexity.

Netlify, the company largely behind Jamstack, knows this. They know that without a back-end server with back-end languages, something like a basic contact form gets complicated. Instead of being in no-brainer solved-problem territory, we have to figure out another way to process that form. So, they solve that problem for you (among others, like auth and serverless functions). But there are tons of other companies that want to be that cog in your machine.

If you were to read that pull quote alone, you might conclude that Chris is a Jamstack Bear. Au contraire! Chris is pro-Jamstack in many cases:

Jamstack can do some things that are very ahead of the game that I cherish. Git-based deployment? All websites should have that. Previews of my pull requests? Hot damn. Sub -100-millisecond first requests? Yes please. Not having to diddle with cache? Sweet. Catch up, other stacks.

Well, which one is it? 🤔

Is Jamstack the bomb or is it a bust? Is it the savior or the devil? Should you use it for your next app or avoid it like the plague?

The answer to these questions is ultimately unsatisfying but utterly true: it depends

You hate that, don’t you? I hate it! 😡

I wish there was One Ring to rule them all. One epic silver bullet that I could load up every single time and just fire away, demolishing all problems that stand between me and success. My job would be a lot easier, that’s for sure.

Unfortunately, Fred Brooks was right:

There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.

There are no silver bullets. So beware if someone tries to sell you one.

Now, I’m not here to call out Netlify or Jamstack. Matt and Chris are building an amazing platform and their coining of the term was a master stroke in marketing. They took something people had been doing for a long time (pre-building their website before deployment, ie - static site generators) and made it sexy. Don’t take my word for it!

Here is what Matt had to say about it on The Changelog way back in 20171:

I think the first guy that tipped the word was a friend of mine, Andreas Sæbjørnsen who works at Uber. It sort of came around because, as you mentioned, this is not really something new, right? It’s something that people have been doing in different ways, like starting to really decouple the frontend and the backend. We’ve seen a huge growth in the space of static site generators and build tools, there’s been a huge growth in just general frontend build tools like Gulp and Grunt and Webpack, there’s the whole tendency around progressive web apps, and so on.

So it wasn’t so much that JAMstack reinvented something and started doing something completely different, it was more a question of all these people starting to essentially build websites and web apps with a new architecture without really having a good nomenclature around it. And obviously, because of what we’re doing at Netlify, we had contact with a ton of people in this space, and everybody was sort of suffering from not having a way to talk about what they were doing and not really having a category to refer to. That’s when that term started to emerge… (continue reading)

They named it to tame it.2 And it’s working! That’s awesome.

There are many virtues to the Jamstack architecture and the hype train has a full head of steam right now, but that doesn’t make it a panacea.

Sometimes it fits perfectly, sometimes it doesn’t. Matt Mullenweg3 recently came out against Jamstack for a few reasons:

You can patch together a dozen services, each with its own account and billing, for hundreds of dollars a month, to get a similar result you’d have for a few dollars a month using WordPress on shared hosting,” he said. “And it would be more fragile, because the chain is only as strong as its weakest link. You are chaining together different toolsets, logins, billing, hosting… any part of it going down can break the entire flow.

Or as I have stated less eloquently (but more frequently) on JS Party:

It sounds like we’re jumping through A LOT of hoops just to avoid some server-side rendering…

If you asked El Duderino if you should go Jamstack he’d probably tell you, “It’s a complicated case. Lotta ins. Lotta outs. Lotta what-have-yous. Lotta strands to keep in my head, man.”

That’s his experience talking.

And this is only one of the decisions you have to make when developing software! 😱

Remember, our job is to solve people’s problems and every tool we wield to accomplish that job has its own set of trade-offs. It’s up to us to decide which tool fits each scenario and it’s important to be aware of the fact that the tool salespeople are incentivized to convince you theirs is The One.

I don’t begrudge them for that, but where does that leave you and me? Chris answers that in his brilliantly casual way:

putting [our] adult pants on, thinking about what [our] project needs, and choosing the best option.

In other words: it depends


  • Back when it was still called JAMstack

  • A refrain for which our Brain Science listeners are well aware.

  • Noteworthy: Matt has a dog in this race. He's quite vested in WordPress's continued success, so his take on Jamstack is, of course, colored by that.


Discussion

Sign in or Join to comment or subscribe

2021-01-01T17:18:56Z ago

So refreshing. Seems like all I hear day in and day out is “client side rules, dude”. But what if I feel like blowing everything up to add a complex, brittle stack that sends giant bundle sizes to be too much risk? It hasn’t made sense to me except in a few cases (admin dashboard, for example). Just now we’re seeing critical mass around to “unified” SSR elements to client side tools, but for most businesses it’s still too early to blow everything up for that.

Player art
  0:00 / 0:00