My Journey Away from the JAMstack

Earlier than I offer you my facet of the story, I’d prefer to level you to Brian Rinaldi’s comprehensive take on the demise of Jamstack (or as I nonetheless favor to name it, JAMstack) for some much-needed context on what’s been taking place. He asks “is Jamstack formally completed?” and this text is basically my reply.

TL;DR: the reply is sure.

As for the explanation why, we should level our finger straight at Netlify.

Pay attention, I get it. Operating a profitable and hopefully worthwhile internet hosting firm with buyers respiration down your neck is difficult. I don’t begrudge them for having to pivot to enterprise cloud mumbo-jumbo to be able to reel within the massive bucks and justify their valuation.

However I can’t assist however really feel duped…like a lot of the opposite “enshittification” we’ve been coping with in tech over the previous couple of years. The cycle repeats itself: we make investments our hard-earned time and typically cash to construct on high of pleasant, seemingly benign platforms—solely to see these platforms wriggle out from underneath us and morph into one thing totally completely different (and for our functions, a lot worse).

Collect round of us, and take heed to my story of my first expertise with the JAMstack. I’ll additionally clarify why previous to this information I’d already moved on from the it and from Netlify, and what as an alternative I consider the online dev trade needs to be heading in direction of as a “default” stack.

The Yr Was 2015 #

I had simply come off a prolonged stint making an attempt to construct and promote a paid, tablet-first CMS. With a failed startup behind me, in addition to numerous WordPress websites I merely hated to manage as a result of they have been so buggy and insecure and costly, I used to be getting determined. On account of my expertise as a Ruby on Rails developer, I even tried reaching for some Rails-based CMSes, however discovering a slam-dunk enchancment over WordPress was removed from simple.

After which I stumbled upon Jekyll. ????

To today, I’ve no clue why it had initially taken me so lengthy to find Jekyll. Jekyll was built-in into GitHub (powering their Pages product) and was constructed with Ruby! I do keep in mind listening to increasingly more about “static website turbines” (aka SSGs) as I used to be winding down manufacturing of my very own CMS, and I filed that thought away as a doable approach to salvage a few of the work I’d performed.

Ultimately I lastly gave Jekyll an actual attempt, and I used to be floored. Right here was an incredible developer-friendly device the place I may simply to take a bunch of straightforward HTML / Markdown, CSS, JavaScript, and picture recordsdata, run a single command, and BOOM: get an internet site trivially straightforward to deploy anyplace. I even grokked the Liquid template syntax with out concern, as a result of I used to be already accustomed to each Shopify and my very own CMS which had used Liquid.

The one actual head-scratcher was the content material authoring facet of the equation—I couldn’t anticipate my purchasers to discover ways to enter Markdown into GitHub—however with my expertise having already constructed authoring interfaces, I figured it wouldn’t be exhausting to place collectively a easy Rails editor app that might work with Markdown and GitHub underneath the hood.

I dogfooded Jekyll first for my very own private web site at jaredwhite.com, relaunching it in February 2016. (It’s since been resigned many instances and is now constructed with Bridgetown as an alternative…nevertheless it stays a static website!) From there, I labored on quite a lot of initiatives for myself and for purchasers. To this very day, a few of these websites are nonetheless on the net buzzing alongside with out concern (here’s one of my favorites) as a result of, hey, static websites are superior!

Alongside Got here Aerobatic Netlify #

Once I first obtained into this brand-new world of recent SSGs, the gold commonplace for internet hosting Ruby-powered internet functions was Heroku. I used to be fairly accustomed to Heroku and had used it on numerous initiatives. However Heroku had nothing to supply me when it got here to SSGs. Heroku was engineered round a mannequin of dynamic internet servers and databases, not build-once-and-cache-on-a-CDN-forever deployments.

I suppose I may have simply used GitHub Pages, however at the moment I used to be primarily utilizing Bitbucket for internet hosting my initiatives and people of my purchasers. So it was excellent timing that, proper after I wanted to determine this all out, alongside got here Aerobatic.

Aerobatic was principally Heroku however for static websites hosted on Bitbucket (it was actually an add-on for that platform). Good! I may simply get that “push by way of Git and robotically deploy” workflow going with no different setup required. And the deployed websites have been quick, safe, and low cost as hell to function indefinitely.

For my consumer’s content material editors, I normally simply spun up an inexpensive VPS on Digital Ocean. They didn’t should be high-powered in any respect, as a result of these servers weren’t promoted to the general public or accessed by multiple particular person actually. And since all of the content material was saved in a Git repo, I didn’t even have to wrestle with a database!

Nevertheless, my love affair with Aerobatic didn’t final lengthy. As a result of one other shiny providing quickly emerged: Netlify.

One of the simplest ways I can describe Netlify after I first began utilizing it’s “like Aerobatic…besides higher”. I’d encountered a couple of technical difficulties getting Aerobatic websites up and working, and Netlify was a noticeable enchancment. Builds have been quick, deploys have been rock-solid, and It. Simply. Labored. Plus it supported each GitHub & Bitbucket, so both means I used to be golden. I overlook once they added the Varieties function, nevertheless it was fairly early on and that additionally proved an enormous benefit.

One concern many people encountered when making an attempt to market these wonderful new “static website” to potential prospects was the time period static. Calling an internet site “static” for many individuals implied a website which not often modified and couldn’t accommodate any dynamic, interactive performance. Boring. For example, certainly you couldn’t run your e-commerce website as a “static” website as a result of e-commerce is something however static!

Enter JAMstack.

The JAMstack is Right here to Clear up All Our Issues (Proper?) #

Netlify’s advertising and marketing sleight of hand in inventing and promoting the JAMstack was sheer brilliance. As a substitute of calling these builds “static websites” and these instruments “static website turbines”, let’s imagine we’re constructing JAMstack websites (to compete with LAMPstack websites I suppose) and utilizing some scorching new JAMstack frameworks. The JAM stood for:

And lest anybody get confused (as a result of as we’ll quickly uncover EVERYONE finally obtained very confused), the JavaScript of the J in JAM referred to client-side JS, not server-side. The entire level of JAMstack was that the device constructing out the markup and so forth. may very well be written in something, and simply as importantly the APIs utilized by the client-side JS may very well be written in something. In any case, each Jekyll and Rails are Ruby-based instruments, and I fortunately used each as a part of my JAMstack deployments.

As time went on, a significant enchantment of the JAMstack was that it allowed a decoupling of the frontend from the backend, which is why Netlify and different hosts prefer it in a while proved extraordinarily well-liked with frontend builders. Satirically, in at present’s world the place SSR (server-side rendering) and progressive enhancement is now high of thoughts for a lot of internet builders, it’s positively wild to show again the clock and understand that JAMstack structure arose throughout the top of the SPA motion. You may even see it in all of the advertising and marketing supplies—your app “shell” may very well be statically deployed, after which your fancy-pants client-side app may take over and name APIs from everywhere in the internet. And numerous JAMstack websites have been actually that. Disable JavaScript and what do you get? Perhaps a easy header and footer for those who’re fortunate. All the pieces else is clean. Whoops!

Nevertheless, that was by no means my JAMstack. I had intuitively understood that the thrilling promise of JAM was in a way the reverse acronym of MAJ: Markup, then APIs, then JavaScript. In different phrases, construct as a lot as you possibly can with static HTML (by way of templates, Markdown, and so forth.), then determine what you may want for some dynamic server interactions—which possibly you’d simply write your self as a Rails app or no matter—then write solely the JavaScript you completely have to entry these APIs (understanding that possibly sure dynamic pages would simply get fetched instantly from the server if want be).

In different phrases, progressive enhancement. ????

However by some means that story obtained misplaced within the fray, and JAMstack finally gave rise to a rebranded “Jamstack” with the main worth prop being one thing somewhat totally completely different: you could possibly now construct complete web sites out of JavaScript libraries (aka React, or possibly Vue or Angular or Svelte) and JavaScript frameworks (aka Subsequent.js, Gatsby, Nuxt, SvelteKit, and so forth.). And, whoa, take a look at this! You don’t want servers ever once more! You may simply write serverless features to associate with your frontends! Fullstack, server-first internet growth is lifeless, lengthy reside frontend + serverless!

(Coinciding with this sea change, Jekyll started an extended, sluggish, painful decline into irrelevance, as a result of inexplicable failure of GitHub’s management to assist its correct growth and promotion in addition to an unforgivable neglect of the Pages platform. It stays one in all my biggest frustrations in 25+ years of internet growth…a lot in order that I forked Jekyll in 2020 and created Bridgetown. However I digress…)

Together with this “second technology” Jamstack mindset shift got here an order of magnitude extra construct complexity. As a substitute of a simple CLI kicking off easy transformations to go from Markdown -> HTML plus concatenate some (S)CSS recordsdata collectively or no matter, you’d get multi-minute lengthy builds and GBs of node_modules and poorly-written tutorials on DEV.to about find out how to ship emails from Gatsby features and which distributed “web-scale” databases of the day are the good and loopy CLI device churn and all types of different complications. Issues which used to take hours or days to perform in commonplace Rails or Laravel or Django apps—most of these things isn’t rocket science, of us—now took weeks or months! Progress! ????

This fast march of slapdash B.S. internet expertise underneath the guise of creating our lives simpler was one hell of a whiplash, and I actually hadn’t seen it coming after I first entered this house. As a substitute of JAMstack saving us all from the horrors of WordPress, we have been crushed underneath the load of Jamstack! Janky SPAs, numerous immature buggy frameworks, and NPM ecosystem madness—together with the multi-headed hydra that’s trendy React.

See Also

./techtipsy — Ramblings of a tech fanatic.

It got so bad I wrote about it. (Warning: for those who assume this article has taken on a dour tone, keep away from studying that spicy take! ????️)

Netlify isn’t responsible…besides Netlify is responsible ???? #

We are able to’t put all the fault squarely on Netlify, within the sense that folks mistakenly thought they wanted to construct their blogs with Gatsby and their enterprise dashboards with Subsequent.js as a result of that’s what all of the “techfluencers” and VC-backed device distributors informed them.

But I do blame Netlify, as a result of they’re the individuals who invented the time period JAMstack! Netlify proved more than pleased to return alongside for the journey and oblige as one of many high internet hosting platforms of selection for this new ecosystem. They may have come out in favor of saner architectures and higher assist for languages aside from JavaScript (consider me, I went round and round with them about their lack of curiosity in supporting Ruby-based server functions at the same time as their very own platform used Ruby underneath the hood!). They may have warned us of the hazards of sophisticated API spaghetti code and microservices. In any case, why ought to Netlify care in case your static website calls out to twenty completely different APIs or your individual monolithic API you wrote in a battle-hardened, “boring” server framework? This bizarro-world concentrate on “serverless features” and later “edge features” by no means made a lick of sense to me (except Netlify actually thought they may by some means considerably revenue off of perform utilization…once more, a prospect which makes little sense to me).

In the end the failure of Jamstack to reside as much as the promise of its authentic JAMstack incarnation, and the trade’s manic pendulum swing into unmaintainable architectures and vendor lock-in, led me to desert Netlify as a internet hosting platform of selection and look as an alternative to extra cheap choices. At this second in time, that selection for me is Render. Render offers you the perfect of all worlds: deploy a static website to a CDN, deploy a server API written in any framework you need—even Rails!—deploy a Docker container…something you want, BOOM, performed. Need to use PostgreSQL? Examine. Want Redis? Examine. Would you want simultaneous deploys of all these providers without delay? Examine.

I’ve no enterprise association with Render, and I guarantee you this isn’t a sponsored submit. I simply actually like their service. And if Render does develop into enshittified down the street, I’ll be tremendous bummed and search for one more different. (I positive hope that gained’t develop into needed!)

What saddens me is Netlify may have grown right into a Render and meaningfully competed with Heroku—besides they didn’t. They took a unique street, and I might argue they failed. Hey, hindsight is 20/20…however actually this was so straightforward to foretell. ????????‍♂️

I’m unhappy to see Jamstack die, however the factor is: most internet functions deployed by most people and small groups solely want modest server choices and possibly a static website. Once more, it’s not rocket science. Most initiatives by no means have to develop into “internet scale” and most internet architectural complexity is totally pointless. You may spin up a Node.js API with Fastify, or a Ruby Roda API, or, heck, some PHP, stick it on a good cloud server someplace, and that’s completely wonderful. Boring expertise is nice. And servers are in reality completely superior, as increasingly more builders are fortunately coming to find (once more).

The Legacy of Netlify #

What Netlify gave us initially was a imaginative and prescient of find out how to deploy HTML-first web sites simply by way of git commits and pushes, identical to Heroku had performed for dynamic functions. All we’d like now’s a contemporary Netlify/Heroku mashup that’s low cost, steady, and doesn’t have to reinvent the rattling wheel yearly.

What will we name this, now that Jamstack is lifeless? I don’t know.

I vote for KISSstack. (Preserve It Easy, Foolish.) ????

However severely, I believe it’s vitally necessary to keep in mind that easy web sites and extra advanced internet functions all sit on a spectrum, and an excellent internet host will be capable to determine your particular person wants and provision builds and runtimes accordingly—it doesn’t matter what the actual service choices is perhaps. (I wrote about this too.)

From my vantage level, the solely purpose I care about is to make constructing & deploying websites dramatically simpler for people and small groups. (Sorry Big Co. Enterprises, I don’t think about you at all.) And whereas it’s an actual disgrace that Netlify is not ready to usher on this future for us, I’m optimistic we’ll see Render, Fly.io, and different firms down the street decide up the slack.

Anyone has to.