The Spicy Web

Sunsetting The Spicy Web, and What Comes Next

2026-04-23T00:00:00-07:00

This is a post I’ve been putting off for a long time, but it really is time to make a clean break and share with y’all what my plans are and where you can go to keep the dream alive of an HTML-first, indie-friendly, “vanilla” open web.

When I first launched The Spicy Web Discord in February 2021, the goal was to create a destination where people could go and talk specifically about how to build awesome websites and applications without needing to reach for gargantuan client-side JavaScript frameworks or obtuse build processes. We were shouting to the world that with a few JS “sprinkles” (which I preferred to call spices, hence the name!), you could craft some truly powerful and delightful experiences which also “go with the grain of the web” and don’t lock folks into vendor-specific idioms. We were putting a stake in the ground that modern CSS was getting, like, really really really good, and the perceived benefits of utility class frameworks Tailwind were far less potent than as advertised. We were making the bold claim that if you were to pick a website framework, it needed to provide you great leeway to get “down to the metal” and access the latest & greatest native web APIs, rather than get in your way with its own slew of techniques.

We were right about all of these approaches! And many more people have caught on in the past five years, with growing popularity of lightweight libraries like htmx, Lit, many flavors of signals, design systems like Web Awesome, and a whole lot more becoming go-to solutions for a wide variety of applications.

But something else has happened too in the past five years. The so-called agentic revolution in software engineering has sucked all the oxygen out of the room, and endless debates and controversies around LLMs, agents, generative AI companies, models, cybersecurity, and even the very nature of open source itself threatens to tear the fabric of our industry apart—nay, I would argue it already has.

But before I continue down that conversational path, let me first get you up to speed on the projects I’ve worked on since The Spicy Web Discord was founded in 2021.

In 2022, I launched this website for The Spicy Web, and for a while it was just a place for me to write the occasional blog post, whether a tutorial of sorts or more of a think piece. Most of those did very well—some were widely shared and read thousands of times. The Great Gaslighting of the JavaScript Era, published in 2023, definitely escaped containment and brought a whole lot of new folks into the Discord. (Quick aside: three years later, I actually believe the JavaScript language/ecosystem is in pretty good shape. ES modules have become the norm, Node/NPM is extremely capable out of the box, esbuild is absolutely brilliant, JavaScript itself has amassed a pretty decent stdlib, and in general you can use JS to write both frontend and full-stack apps in a fairly straightforward & maintainable manner. So congratulations, web!)

In 2023, I launched my first (and, alas, only) course for The Spicy Web, called CSS Nouveau. It was a paid subscription product, and it did rather well right at first, but then sales dropped off a cliff in 2024 and never recovered. That was also around the time a lot of other folks I knew who were offering education products saw their sales tank. Gee, thanks AI! 🙄 (And inflation, and Big Tech layoffs, and the U.S. elections, and, and…) So now CSS Nouveau is free, and shall always remain so.

Also in 2023, I felt the need to create more of an “aggregator” news-style blog centered on the nitty-gritty of web development topics, so I designed & launched That HTML Blog and eventually established its accompanying newsletter. In hindsight, I might have done a better job of establishing connective tissue between The Spicy Web and That HTML Blog, rather than having them live parallel lives, but at this point that’s actually a good thing as you’ll soon see.

Which brings us to recent changes. By the summer of 2025, I felt that the particular mission of “The Spicy Web” had run out of gas, and there was a much more urgent need to focus on the massive sea change which had engulfed the developer community. For those of us who are deeply committed to the pro-craft movement, standing firm on the principles that handcrafted code, art, and communication are vitally important and that the slop machines (aka “generative AI”) are a net negative for society and serve the interests of a fascist billionaire class not creative workers, it was important to create a destination where such matters could be discussed freely and people could be supported in their AI skepticism and the fight against unethical LLMs. (Spoiler alert: all LLMs as we currently know them are unethical.)

So I started a brand-new project called the Human Web Collective (HWC), and renamed The Spicy Web Discord to The Human Web Collective Discord. I also launched a new Reddit-style forum site built with PieFed to encourage more open sharing of links and resulting conversation. While the Discord server has been thriving, the forum never really took off (even though I use it every day to engage with other “Threadiverse” servers running Lemmy and PieFed). I haven’t given up on it completely, but my more immediate focus is to launch a proper “landing page” for the HWC, featuring links to apps and resources which are slop-free and encourage people not to let their brains get scrambled by chatbots and sloppy agents.

My personal stance is quite clear. I will never use LLMs to write code for me, nor will I ask a chatbot to write or edit any of my prose, or create images, or produce videos, or any other creative endeavor. I stand 100% in opposition to AI slop. This is a core value of mine, one which has already cost me some business but I’d much rather be “poor” and keep my soul intact than gain the whole world and lose my soul in the process. So I’m dead serious about this, and I know a lot of you out there are as well.

However, just because the moment is serious doesn’t mean we can’t have some fun. So one of the goals of the HWC is to celebrate human creativity & the indie web, and perhaps to laugh a bit at the absurdity of modern life. There’s much still to appreciate and explore, both online and off. And so ultimately the Human Web Collective isn’t simply a “negative” push against some ill, but a positive push towards a better world. I hope you’ll join us in that effort.

OK, so what’s the final tally? I said I was sunsetting The Spicy Web, and that means I’ll be adding a disclaimer to the top of this site saying it’s been archived, and I’ll switch off logins. It’ll just be a static site, frozen in time. Which is fine! That’s the beauty of a static site, it can live on “forever”.

And as mentioned, I’ll be putting my attention into all things Human Web Collective, as well as spin back up writing for That HTML Blog to highlight groovy new web APIs as well as the micro-libraries which utilize them to offer awesome DX for vanilla-adjacent projects. So the original mission of The Spicy Web will live on in one form or another, finding a place in corners of the HWC Discord as well as posts on the blog.

This feels good. I’m certainly bummed that I wasn’t able to keep up the momentum of working on new courses, but I’m confident there is plenty of good material out there now from other sources to help you learn how to build for the web utilizing all that the web itself has to offer. And as for all the threats developers now face to their craft and their livelihoods, The Human Web Collective is here to give you a voice. Coding is dead, long live coding. 🫡

I Made a Squircle Button (and of Course It’s a Web Component)

2025-01-26T00:00:00-08:00

Before we get into the nitty-gritty, just what is a squircle? And how it related to a superellipse?

Here’s a definition I found from this article by Olga Nikolskaya:

The Superellipse is the name given to a family of shapes and the most popular of them is Squircle, the shape intermediate between circle and square. The appearance of squircle seems optically balanced: no sharpness, no angles…

In other words, unlike typical CSS-based “rounded corners” you see on the web where the point at which the straight side angle starts to curve is very noticeable, a squircle offers a very gradual shift from a side to a corner. This was a major topic of conversation back when Apple first released iOS 7, as Mark Stanton at HackerNoon points out:

A ‘secret’ of Apple’s physical products is that they avoid tangency (where a radius meets a line at a single point) and craft their surfaces with what’s called curvature continuity. Once you know how to spot it on products, you’re likely to start seeing it (or more likely the lack of it) all around you.

iOS 7 brought that hardware curvature to their software, but unfortunately that aesthetic never made it over to the web where we still just have a very boring (yet still extremely useful) border-radius.

I got the idea to investigate this topic after noticing (of all things) a Help Scout Beacon button installed on a client app I was working on. I kept looking at the button and wondering why the shape of it seemed unusual to me, and it finally dawned on me that I was looking at a squircle button and not a typical button with CSS rounded corners. (You can see it in action here.)

Upon further investigation, I discovered they were using SVG shapes on the left and right sides of the button to provide the necessary curvature. That’s a pretty interesting technique, but it got me wondering if there might be another approach that, yes, still uses SVG yet not for the “endcaps” but for the entire shape of a button.

Oops I Clipped My Path

A bit of sleuthing on DuckDuckGo turned up this fascinating article by Simeon Griggs (funny enough, he references Olga’s article I mentioned above!). The trick is to define a clipPath inside of an SVG element, and then reference that using a clip-path CSS property. From Simeon’s example:

<svg width="10" height="10" viewBox="0 0 10 10">
  <clipPath id="squircleClip" clipPathUnits="objectBoundingBox">
    <path
      fill="red"
      stroke="none"
      d="M 0,0.5 C 0,0 0,0 0.5,0 S 1,0 1,0.5 1,1 0.5,1 0,1 0,0.5"
    />
  </clipPath>
</svg>

.squircle {
  clip-path: url(#squircleClip);
}

Slap that on a tag and you’ve got yourself a squircle.

I was excited to try this out on a button, so naturally there was only way I’d want to package this up into a reusable component: by building a web component. And of course, once I got the initial technique all squared (squircled?) away, I needed to take it just a few steps further.

And here’s the result! Say hello to <sq-button>:

See the Pen Squircle Web Component Button by Jared White (@jaredcwhite) on CodePen.

So yes indeed, we have that appealing shape without any sharpness to the curvature. But on top of that, I added an eye-catching gradient background (thanks oklch!) to the button—which when you hover over it, it rotates! Whoa! How did I do that?

That’s all thanks to the magic of @property, a way of defining typed CSS custom properties. The typing is crucial, because if you were to attempt to define a value like 135deg for a new CSS custom property without using @property, it wouldn’t be usable for a transition. By typing it as an angle specifically, we gain animation functionality.

@property only recently became available across all browsers, so bear that in mind—but as a nice bit of progressively-enhanced visual flourish, I’m quite impressed!

Drop Your Shadows

I also added a drop shadow to the button. Note that when you’re using the clip-path technique, you can’t utilize box-shadow any longer because the clipped element will no longer display the shadow either. derp 🤪

Thankfully, filter is still an option for applying an SVG-based drop shadow to the host element. I made the shadow, the background gradient, and the hover animation duration all customizable using CSS variables, and if I were to spend more time with this I’d make a bunch of other aspects of the component’s appearance customizable as well.

I really like my squircle button. 🥰 I think I might introduce it to an upcoming app I plan to start working on soon, because when you’re so used to the typical “roundrect” buttons on the web, squircles really do stand out.

Future Thoughts: in a production application, I would of course use declarative shadow DOM to render out these buttons so they don’t purely rely on JavaScript to render. As you might notice, I’m not actually using JavaScript to do anything in the CodePen except to inject HTML & CSS into the shadow DOM. This might also mean I’d break out the SVG into its own external file, as well as the styles (loading them via <link>), so that each declarative shadow DOM template is as minimal as possible. That’d require some performance testing for an optimal approach, as I’m not sure if a delay in loading an external SVG would cause any graphical glitching. That’s why this section is titled future thoughts! Welcome to how my brain works. 😅

Creative Strategies for Surviving the AI-pocalypse

2025-01-13T00:00:00-08:00

I am very sorry to inform you, but if you are a React / TypeScript frontend engineer a few years into your career, you are ground zero for getting replaced by “AI engineers”. Mark Zuckerberg hath decreed it to be so!

Big Tech is literally salivating at the idea of taking your job away and replacing it with automation at an industrial scale. Their plan seems to be to hire a bunch of low-wage prompt monkeys to coax AI agents into spitting out “working” React code and JSON APIs, and then handing that work off to a dwindling number of senior engineers for final polish and bug-fixing. And if you thought The Great Gaslighting of the JavaScript Era was finally behind us, oh you ain’t seen nuthin’ yet!

If you are one of the senior engineers standing idly by while your industry is targeted for mass disruption (not the fun kind), well I can’t say I feel much empathy for you.

And if you are one of those “prompt engineers” helping to take jobs away from qualified craftspeople, well, I’m genuinely sorry you have been trapped inside of a capitalist hellscape which is more than willing to exploit you.

But if you are a “mid-level” software developer, one of the “people engineers” whom Mark Zuckerberg claims will be replaced by “AI engineers”, I have some encouragement for you:

There is a place for you in this world. Just probably not in Big Tech. You may need to downsize, move to an area with a lower cost of living, and get real creative about how you find means of gainful employment.

Here are a few ideas on how to weather the coming storm. Because trust me on this—it is coming. Things will get worse before they get better. The Zucks of the world will see to that.

Local-first community

The pandemic really did a number on small local tech meetups. Many of them never recovered. It’s been pretty grim here in Portland, Oregon, I can tell you that.

But hope is not lost. New meetups spring up all the time. You should be putting a good deal of time and effort into finding these meetups and attending them as regularly as possible. And if you can’t find any? Start one! (Or two or three!)

In short, wherever you are, you MUST find flesh-and-bloom humans and enjoy face-to-face time with them. Maybe there aren’t enough Programmers with a capital P in your local area, but usually you can find creatives in adjacent industries to network with.

Your ability to survive the coming AI-pocalypse is largely dependent on your ability to network with real people in real life. The Internet alone may have gotten you far, but it won’t get you far enough over the next few years.

Side-hustle like you’ve never hustled before

January 26, 2025 Update: I got a fair degree of pushback regarding this section on Mastodon and Discord. And I should have seen it coming, as a lot of folks are understandably weary of “hustle culture” and think in many ways it’s detrimental to the programming industry. And I get it, I really do. I personally can’t stand all the l33tcode style competitions either and think “whiteboard interviews” are the very work of the devil. So yeah, I should have worded this section more artfully. As evie in our Discord put it, I could have acknowledged it as necessary without valorizing it. And Thib on Mastodon would encourage a focus on soft skills and extra-professional activities outside of programming as a way of standing out. With my mea culpa and these caveats out of the way, here is what I initially wrote:

It’s always been true that programmers do well when they have some extra irons in the fire besides whatever they’re tasked to do at their day job. Sometimes there is resentment along these lines however—what, are you expecting me to work 9-5, 5 days a week, coding until my fingers ache, and THEN ALSO launch a SaaS and build a mobile app and release ten open source libraries at 11pm or 6am?!

Yes. 🤷🏻‍♂️

I hate to break it to you, but I’ve met with many junior or mid-level programmers over the years for community conversation or coaching, and when I ask them questions such as:

So what libraries have you written or contributed to?
What’s your blog URL?
What meetups are you attending or have started?
Got an app idea in the works?
Any cool new techniques you’re willing to share?
Where are the repos of demos you’ve worked on?

All too often the answers are:

Ah, well I haven’t done that
I don’t have a blog
I haven’t been to any meetups in ages
I don’t have any app ideas
Nothing comes to mind
Oops, I don’t have any good demos

This essay isn’t a deep-dive into time management techniques and productivity tips to help you prioritize these things, but I will just flat out say you must be spending a significant portion of your time focusing on some or all of these initiatives.

And in case you’re wondering, I’m happy to personally help you on the blogging front at least—I maintain a blogging engine (and more besides!) and have been passionate about web publishing even longer than I’ve been passionate about web development. I’ve found the blogosphere to be a pretty welcoming place over the years, and it could be said there’s an exciting resurgence in this area as IndieWeb ideas gain traction once more.

Look beyond the Tech Industry

It is a misnomer that the best place to work for a programmer is the “tech industry”. I’ve spent the bulk of my career not working for tech companies!

Yes, the pay isn’t as great, generally speaking, but the flip side is I’ve had plenty of work on my plate during several major downturns (including the most recent one!) which adversely affected many of my fellow developers. I’ve developed Web sites and applications for a diverse range of companies and organizations over the decades. I’ve worked with art gallery administrators, non-profit communicators, small business owners, educators, publishers, musicians, and consultancies operating in the public sector—to name but a few!

It’s true that it’s become more of a challenge to discover this type of work in recent years, but over the long term I feel like it’s a much less risky proposition than sticking it out at FAANG-like Silicon Valley-style corporations.

Not only that, but there’s much less likelihood that “AI” will even be relevant in any of the work you’re doing. Thus far I’ve managed to get by just fine with zero, and I mean ZERO usage of any AI coding tools.

No Copilot.

No Claude.

No Supermaven.

None of any of it.

And I’m going to keep on noping the frack right out of touching any of these tools, because they are detrimental and devastating to my personal wellbeing and the future of my professional craft.

Just. Say. No.

Create new industries

Ultimately we programmers are going to have to take matters into our own hands: building the tools, services, social networks (hello Fediverse! 👋), and markets we wish to see in the world. After all, the tech industry we have today was directly built on top of the backs of the workers—the people truly writing code and caring deeply about the quality and the caliber of the code (and the end-user products) they write.

That’s us, and we need to push back and push back hard on low-quality industrial automation of our profession. Big Tech CEOs should be shamed & shunned at every opportunity whenever they make such ridiculous and insulting grandiose claims that “most code” will be written by “AI engineers” rather than “people engineers”.

I was talking with a fellow prognosticator just recently about this topic, and they claimed not to be seeing any push back in trend data. Supposedly, programmers everywhere are simply embracing LLMs and all of these AI tools.

I have two answers to that:

If true, this will the be the death knell of our industry. We are sowing the seeds of our own destruction.
I don’t actually believe this is true! I disagree with their assertion—I see an active, healthy, and growing backlash against so-called “artificial intelligence” being thrust in our faces which isn’t actually intelligent at all.

Listen, there’s a reason the WGA (Writers Guild of America) worked hard to ensure their writers’ rooms were protected—how can seasoned professional writers with award-winning credits to their name become seasoned professionals in the first place if the opportunities to join writers’ rooms as newcomers and learn from the best simply…vanish?

Similarly, how can junior developers become senior developers if the talent development pipeline is utterly upended? Our industry already has a lousy track record when it comes to hiring and nurturing new talent, and I fear it’s about to get much, much worse.

So what can we do about it?

Join the revolution!

Refuse to use these “AI” tools. Refuse to work for companies which won’t care for their workers and won’t train new workers to become mid-level and eventually senior programmers. Refuse to use products and services sold to you by capitalist pigs.

Recognize the moment we are in. This is war. I didn’t ask for it. I don’t want it. But “war must be, while we defend our lives against a destroyer who would devour all; but I do not love the bright sword for its sharpness, nor the arrow for its swiftness, nor the warrior for his glory. I love only that which they defend.” –J. R. R. Tolkein

Do support indie social web initiatives, do support fellow programmers striking out to build new products and services which respect users and respect the art & craft of programming. Be a part of local & online communities which have a zero-tolerance policy against the intellectual theft inherent in commercial AI training data.

Remember, when we band together, when we stand strong and express our values loudly and firmly, we have much more power than we realize. We don’t have to accept the proclamations of Big Tech CEOs as fact! Nothing is “inevitable”. We can tell them that if they won’t support their workers, if they won’t protect civil rights (especially those of marginalized communities), if they won’t back down from promoting the shameless strip mining of the Open Web, they can go pound sand.

Be a part of the revolution. The revolution always has and will always start with you.

SolidJS is Not the Future

2024-10-01T00:00:00-07:00

Use the Platform™ has become an amusing rallying cry which is essentially more of a philosophical argument than a technical one.

Which is why I’m going to avoid virtually all technical jargon in this article, because I’m not here to refute Ryan Carniato.

I’m here to tell you how much I resent we’re even having this conversation in the first place.

Ready for some real talk? Good. Let’s goooooo…

Bad Web Standards Are Always Better Than Good “Userland” Solutions

This is the first point I want to make, which is that if I can do something with a native “vanilla” web API, and that API is “less good” than a clever API written by a clever developer in userland, I will invariably go with the vanilla API.

Because in 10 years, we’ll have gotten used to that bad API, we’ll know how to deal with it, and we’ve moved on. Whereas in 10 years, the added support and cognitive burden of understanding and supporting that broken/outdated/deprecated/refuted dependency which was once thought to have been a clever API by a clever developer just isn’t fucking worth it.

In other words, I’m sorry Ryan Carniato, but I won’t be using today’s SolidJS in 10 years, whereas I will be use today’s custom elements in 10 years. That’s just a fact. And I know it’s a fact because of all the other vanilla web APIs I use today in the same way I used them 10, 20, even ~30 years ago.

Teaching People How to Write Less-Good Vanilla Web Apps is More Valuable than Teaching Frameworks

Again, if you brought a junior developer to me who is seeking education, and asked me if I thought they’d be better off writing applications which are “less good” (in whatever metric you care to measure…let’s say slick UI polish for the sake of example) using vanilla APIs or writing “more good” (aka slicker) applications in the frontend framework du jour, I’d say the vanilla route is much more valuable.

Because those are skills which are going to be applicable to all projects, in all categories, for all users, in the years and decades to come. Whereas all the skills you learn in a particular frontend framework are by and large specific to that particular framework at this particular moment in time.

Furthermore, you can still apply many of the vanilla skills you once picked up now that you’re working in a framework in order to solve thorny problems no one else understands, whereas the framework stans are often rather lost without their framework.

I know this because for years now I have seen, over and over and over again, people missing out on great vanilla solutions to common problems because they never heard about them or don’t grok how they work…because of all the noise of userland JS solutions. I recommend every framework stan spend a few hours every month poring over MDN and other resources to learn what’s new for the web platform. That kind of platform-level developer knowledge over time is worth its weight in gold.

(Also, truth is that framework-y web apps regularly offer worse UX anyways, exhibiting severe performance and reliability issues. But I’m not even here to make that argument. Go talk to Alex Russell.)

Your Framework is Incompatible With My Stack

This is perhaps the most damning argument I’ll be making today. The idea that I have to switch my entire stack over to your metaframework in order to make the most of your frontend framework is fucking bullshit.

Let me make myself quite clear here:

I’m not going to adopt Next.js just so I can use React.
I’m not going to adopt Nuxt just so I can use Vue.
I’m not going to adopt SvelteKit just so I can use Svelte.
I’m not going to adopt SolidStart just so I can use Solid.

There’s really only one JS metaframework I can think of that’s achieved some popularity in recent years and for good reason, and that’s Astro. And the thing which makes Astro rather awesome is precisely because you can start with real vanilla HTML, CSS, and JavaScript—and then go beyond that only when and where you need to.

Use React! But just on that one page where needed. Use Vue! But just on that one page where needed. And so on and so forth.

And guess what? Astro is a great place to get started using web components as well! Heck, you can even server-render Lit web components. Yeah, seriously.

Actually, Web Components Are Components

I will now annoy many of my friends who do advocate for web components, because I reject the framing that “web components aren’t components” and that you can’t really replace the idea of framework components with web components.

I simply don’t agree with that argument at all.

You absolutely can build an entire web application out of components and those components can be custom elements and those custom elements can be called web components.

No, I’m not going to get into the nitty-gritty technical details here because that’s not what this article is about. You’ll either trust me on this, or not. That’s entirely up to you.

But it really, really, really bothers me that even while praising web components, we must for whatever reason feel the need to show deference to userland JS frameworks. Like, somehow, their concepts of what a “component” is and how “components” should work are so immensely important, we gotta give credit where credit is due.

Nope. 😝

If React, Vue, Angular, Svelte, Solid, etc. all simply “poofed” out of existence tomorrow and all we had to build web applications with were vanilla APIs & web components, a tiny handful of tiny userland libraries for a healthy splash of DX, and good ol’ fashioned server-side web framework stacks in a variety of server-side languages which have been trucking along just fine for the past 20+ years, that would be perfectly fine with me.

I simply don’t respect these frontend frameworks. Never have. Never will. I actually think—on the whole—today’s web is far worse off because of them.

But you do you.

This Entire Discussion is Pointless and Stupid

I will now end this blog post with the rant of all rants. You’ll probably want to unfollow me on all the socials. Good for you!

I hate this conversation, I resent having to talk about all of this YET AGAIN, I think the JavaScript ecosystem is full of donkey-doo, this is all stupid, and talking about if web components should be web…components…AARGH it makes me want to gouge my eyes out. 😖

It’s time to touch grass, y’all. Go walk through a meadow by a lake. Enjoy a cuppa with your friends. Watch a movie. Write a poem. Throw a ball. Bake a cake.

Anything—anything—ANYTHING but this. 😭😭

We are literally shitting on the World-Wide Web as a healthy platform for reasonable people to build nice things on by endlessly arguing points which were already moot years ago.

Ryan Carniato, and a hundred clever developers like him, can write 1,000 more articles on DEV.to saying things like “the promise of Web Components is so alluring and so dangerous” and none of it actually matters. None of it.

But maybe that’s just me. I wake up every morning and ask myself if I even still want to work in this industry…for these very reasons! (checks watch) Oh, is it time for another Tailwind vs. Vanilla CSS debate again? Should we argue about if Safari is, indeed, the New IE™?

I DON’T FUCKING CARE!!!

Meanwhile, on Planet Earth, real people are having real problems. Generative AI is shredding any hope of creative people to make an honest day’s living, climate change is wiping out parts of modern civilization, political parties are being held hostage by radical extremists who hate democracy, housing prices are going through the roof, car culture (even with EVs!) is polluting urban environments, VC-fueled crony capitalism is enshittifying basic digital goods and services on a daily basis, and the bottom is falling out of sustainable open source due to maintainer burnout and corporate consolidation & entrenchment.

But nooooo, let’s not focus our precious waking hours on addressing these existential human issues, and instead let’s talk again about FUCKING WEB COMPONENTS !!??!?!! 🤬

I’m done y’all.

I’m done.

<im-done>So long, and thanks for all the fish.</im-done>

P.S. Subscribe to my podcast. It’s like ranting in a blog post, but there’s two of us and it’s way more fun! 😁

Action Web Components Which Span the Server-Client Divide

2024-08-11T00:00:00-07:00

(Note: this content was originally intended for a new course in JavaScript programming, but with my course development on hold for the time being, it’s being released to the public for free. Enjoy!)

I want to preface this article with a little reminder of something which often gets overlooked in discussions like these:

There’s only one web API for executing JavaScript code when a particular tag appears on a page, and that’s the Custom Elements API. Yes, we’re talking about web components—but forget everything you know about “components” for this discussion because we’re going to dive into a very different pattern than you might be accustomed to.

First, a Little Backstory

In the early 2000s, when I was but a wee lad learning how to build web applications as a greenhorn PHP developer, I happened across a fantastic little library called Xajax (snapshot from 2005).

Xajax brought the still-new concept of Ajax programming to PHP & JavaScript in an exciting way. You could write simple PHP functions on the backend, and then easily call those functions from your frontend. The response of a function could return various commands, things like “append this HTML to that element” or “delete those elements”. You could even write your own custom commands.

Now before you start gesturing wildly and shouting how that’s just like [insert modern HTML-first library here], trust me—we’re getting there! 😄

In short order, I ended up taking over maintenance of Xajax—my very first experience with open source collaboration—and used it for a few years (even integrating it into my short-lived PHP fullstack web framework!) until I eventually gave into public peer pressure and learned Ruby on Rails. (I kid, I kid…but you have to realize in the late 2000s, RoR was the new hotness and PHP seemed old and busted.)

Fast forward to 2019, when I heard about a fancy new library for Rails called StimulusReflex. It extended the functionality of the Stimulus library provided by Rails and utilized asynchronous web sockets via an interrelated dependency called CableReady to enable dynamic UI updates pushed from the backend to the frontend. CableReady lets your backend “functions” return various operations, things like “append this HTML to that element” or “delete those elements”. You can even write your own custom operations.

Yes, you can now point at the screen just like Leanardo. 😆

I got heavily involved in the StimulusReflex community on Discord, utilizing the library in new Rails application development throughout 2020 and 2021, and even contributed some functionality for what seemed to be an exciting future update to CableReady called CableCar. This would let you return operations from any standard HTTP request/response, not just async functions running via web socket connections. My journey back to the “Xajax” paradigm was nearly complete…

…until Rails’ “new magic” was unveiled in the form of Turbo as part of the launch of HEY, Basecamp’s new email app.

Turbo at heart was an evolution (aka Turbo Drive) of the previous TurboLinks library which itself was a spiritual successor to PJAX (a worthy pattern all in itself, but one we don’t have time to delve into here). In addition to Turbo Drive and Turbo Frames, it came with a paradigm called Turbo Streams. Turbo Streams enables your backend responses or async background jobs to return various actions, things like “append this HTML to that element” or “delete those elements”. You can even write your own custom actions—not a sanctioned concept at the start but one which was eventually merged into the library due to high demand.

There we go again! 🤣

Xajax Commands. CableReady Operations. Turbo Actions. Turns out these are all variations on a theme: letting your backend’s HTML rendering pipeline update your frontend dynamically, rather than needing your frontend to take on the responsibility of updating its own UI (which requires an order of magnitude more frontend complexity and introduces performance headaches due to requiring large bundles of JS code to execute in order to generate DOM and run business logic).

I’ll also note that Alpine.js’s Directives and htmx’s Attributes—while different in the sense they both offer an API that is “pull-based” rather than “push-based” (* wut)—offer a similar overall developer experience by putting HTTP and HTML at the center of the UI programming model.

Actions…But Vanilla?

So we’ve presented these various libraries which can translate various backend “actions” (we’ll go with that generic term from here on) to client-side interactivity. But in keeping with the spirit of The Spicy Web, it’s time to muse on the following question:

How might we write our own actions using nothing but native JavaScript APIs?

We have a handful of initial feature requests to consider:

These actions should be HTML-centric and easy to generate using any backend framework or toolchain.
These actions should be easily processed as part of any request/response cycle or async mechanisms (Server-Sent Events or Web Sockets) without special casing action-specific requirements.
These actions should be easy to write and adapt for various application needs.

The first point has me leaning towards wanting to use HTML as the transport format rather than JSON. JSON necessitates jumping through a lot more hoops on the frontend to do anything useful with the incoming data, whereas HTML can be read, parsed, and injected into a web page with virtually no client-side smarts required.

The second point means we shouldn’t assume anything about the “context” in which actions are delivered to the client. In other words, we shouldn’t combine action execution with any particular function or pattern that was specifically tailored to transport processing.

And the third point means action “handlers” should be standalone, via some sort of fully modular and atomic API which isn’t tied to any singular application shape or build dependency.

So…where does that leave us? If HTML is our transport mechanism and we need actions to be universally applicable, it sounds like we’re saying we should define actions using HTML tags.

Which brings us back around to what I said at the top of the article:

There’s only one web API for executing JavaScript code when a particular tag appears on a page, and that’s the Custom Elements API.

Anything else is much more fiddly. We could try to use a MutationObserver, as does Stimulus and many other libraries looking for special attributes contained within HTML, but that’s a much harder prospect. We could require some kind of JavaScript code to call a function explicitly in order to process a chunk of incoming HTML, but that would require a tighter coupling between action processing and whatever code is pulling down HTML in the first place.

Here’s the great thing about web component technology: we know it will work anywhere, anytime. Literally the moment a custom HTML tag shows up in some DOM somewhere, our client-side connectedCallback function will execute. This turns out to be the perfect mechanism for what I am calling Action Web Components.

Similar to how an HTML Web Component in popular parlance is a custom element which wraps standard HTML and applies interactivity to those child elements when rendered on a page, an Action Web Component performs a one-time operation when it’s rendered on the page and then (not always but typically) removes itself from the DOM upon completion. These actions don’t themselves have any visual appearance—they aren’t content, but commands.

It’s telling that Turbo Stream Actions are built using the custom elements API. In that case, there’s one tag—<turbo-stream>—which is responsible for reading in attributes and using that data to determine which action to execute. We’re however going to go a step further in our quest to stay close-to-the-metal: we’ll stick with a simple 1:1 action type == tag name nomenclature, using an ac prefix.

Let’s explore our first example.

Example Action: Class Toggle

Let’s say in response to a particular event on the frontend (say, a button click), you want to add a class to an element on the page with a certain ID.

Here’s how that would look in HTML, the idea being that this could be directly rendered out in a response via a fragment (or it could live embedded in a larger template partial).:

<ac-toggle-class target="checkmark-12345" classname="success"></ac-toggle-class>

and this is how we would define the action in JavaScript as a web component:

customElements.define("ac-toggle-class", class extends ActionWebComponent {
  connectedCallback() {
    let force = this.getAttribute("force") || undefined
    if (force) {
      force = force == "true"
    }

    this.target.classList.toggle(this.getAttribute("classname"), force)
    this.remove()
  }
})

Our ActionWebComponent base class is extremely minimal, merely providing a few convenience methods such as using this.target to refer to the DOM element with the ID matching the tag’s target attribute. As you can see here, we get the CSS class via the classname attribute and then either toggle it by default or force it on or off via the presence of force="true" or force="false" attributes. The custom element removes itself as soon as it runs, leaving behind no trace in the DOM upon completion.

And…that’s it! It seems almost too simple to be true. Literally any place you might write <ac-toggle-class> in your codebase, your HTML now has the power to affect your UI.

There are numerous other such actions we could imagine…actions such as updating some HTML element with new children, scrolling to an element, focusing on an element, redirecting to another page after a short delay, or displaying a message in an alert.

Thankfully, you don’t need to imagine. I’ve already done the hard work for you! 🤯

Astro + Alpine.js + Action Web Components = 😍

I’ve put together a demo repo of a web application using the Astro framework. It uses Alpine.js as an easy way to handle JavaScript events like clicks in order to fetch HTML fragments, and Pico for good default styling. From there, we sprinkle in our Action Web Components to give Astro server → client superpowers. Advanced UI interactivity in mere lines of code? You betcha.

Demo Repo

Here are the actions I’ve written for this demo. You can find all of these in this JS file in the repo. And again, in case it’s not obvious—there’s absolutely nothing specific to Astro or Alpine.js about how Action Web Components work. I’m just using those tools for some helpful smarts to build the demo site, but you could just as easily go with a hand-rolled zero dependency static .html file and PHP backend. Party like it’s 1999. 🕺🏽

`ac-yellow-fade` aka the “Yellow Fade Technique”

This one’s an oldie but goodie. When adding a new item on a page in a list or a grid or something to that effect, you temporarily highlight the new item. A yellow fade is still cool IMO, but there are many other design techniques you could use to draw the user’s attention to the new item. Perhaps a more generic take on this could be named ac-highlight.

`ac-toggle-class` aka Switch a class on and off

Use this one to toggle a CSS class on a particular element.

`ac-portal` aka Render content at the bottom of `<body>`

This may be less useful now in the age of <dialog> which doesn’t require portal techniques, but there are still times when you may want to inject some content at the very end of <body>.

`ac-scroll-to` aka Scroll the viewport to an element

Maybe you have an Edit button which triggers an inline editing form…but what if the user can’t see nearly any part of the form because it’s below the viewport? You’ll likely want to scroll down to the form so it’s mostly or completely visible onscreen. This will do just that!

`ac-focus` aka Focus on a particular form field

Perhaps in tandem with the scroll action, this lets you focus on an interactive element upon the user performing some task. BTW, in real-world usage I’ve also found adding a timeout of, say, 200ms is best if you’re also scrolling.

`ac-children` aka Replace a part of the DOM with a new HTML fragment

This is a pretty common action, and something developers need to do often when programming using HTML-first techniques. If you’ve already used libraries like Turbo or htmx, this will feel entirely familiar!

`ac-redirect-to` aka Redirect to another URL after a short delay

You’d be surprised how handy this action can be after various form submissions. I tend to use this technique a lot. (An immediate redirect doesn’t make much sense since you can trigger that server-side with an HTTP 302 status, but using a delay means you can notify the user of something, then after a few seconds take them to their next destination.)

`ac-message-dialog` aka An attempt at a better `alert()`

There are times when you need to display critical information to the user. I thought it would be helpful to design a simple dialog (using <dialog> of course!) and make that an action, but it’d probably also be helpful to write a custom JavaScript async function to do this so client-side code could also trigger such a dialog.

Guess what? There were a couple of additional actions I thought about writing for this demo, but didn’t…an exercise left for the reader! They were:

Toast Notification: showing a notification after a form save is a very common pattern…but notification components as well as the toast stack can also get very complicated. My recommendation: just use ~~Shoelace~~ Web Awesome!

Attribute Swaps: a pattern I increasingly like is an action which will swap out one or more attributes of an element, typically a web component. This is a pretty powerful combo, as you can write a web component which manages internal state and re-renders DOM accordingly, and with an attribute action you can just pass some new state along to the web component and let it handle the re-render. With an action like this, as well as the children action mentioned above, I almost never feel the need to reach for full-blown DOM morphing! (Which is technique I happen to think borders on anti-pattern…)

Can you think of some additional actions you might like to reach for? (Maybe an ac-delete for removing a DOM node?)

A Word on Progressive Enhancement

Inevitably when discussions arise of updating UI in a manner which requires JavaScript—even if HTML remains at the center of the approach—you’ll hear the common refrain: but what about progressive enhancement? And for good reason: our industry has fallen down hard when it comes to the best practice that you should be writing web applications in a multi-layered fashion: first HTML, then CSS, then JavaScript.

Unfortunately, some folks tend to overcorrect on this issue, and present progressive enhancement as first HTML, then CSS, then…well, you probably shouldn’t use JavaScript for anything but the slightest of polishing techniques which are totally optional. 🧐

I’m here to make a bold statement: progressive enhancement does not mean a complete JavaScript-optional experience. And before you start throwing tomatoes at me, I’ll simply crib from the MDN documentation on this topic:

Progressive enhancement is a design philosophy that provides a baseline of essential content and functionality to as many users as possible, while delivering the best possible experience only to users of the most modern browsers that can run all the required code.

The word progressive in progressive enhancement means creating a design that achieves a simpler-but-still-usable experience for users of older browsers and devices with limited capabilities, while at the same time being a design that progresses the user experience up to a more-compelling, fully-featured experience for users of newer browsers and devices with richer capabilities.

The most important phrase in this definition: “baseline of essential content and functionality”. And that’s up to you as the application developer…what is the baseline of essential content and functionality you want to make sure is available to the widest possible set of users?

In practical terms, it might mean that some key features of your application work fine without JavaScript, whereas other less-vital features do require JavaScript. Or perhaps you offer a simpler HTML form UX to baseline users and a much-improved interactive HTML+JS form UX to high-end users. See also: Graceful Degradation.

The reason this is all so important to understand is as soon as you start introducing techniques like fetch, server-sent “actions”, etc., you immediately leave behind the world of of no-JS, HTML-only interactions. Which isn’t a bad thing as we’ve just covered, but you should understand the tradeoffs. Action web components, libraries like Alpine or htmx or Turbo, etc., are great for building on top of considerate baseline experiences, but they shouldn’t comprise your only experiences or you will inevitably run into the sorts of issues progressive enhancement is intended to address. Construct your application architecture accordingly.

Conclusion: HTML-First Programming Works

The reason so many people have fallen in love (again?) with HTML-first programming techniques in web development is because the levels of complexity, performance issues, accessibility concerns, and fragile build tooling required to build with JavaScript-first techniques (aka the React apps of the world) has proven to be wildly against “the grain of the web” for all but the most specific of application types. It may still be true that “nobody ever got fired for using React” (a riff off the old canard about IBM), but at the same time, “you probably don’t need React” is increasingly true for most web projects. (Just ask Zach…he knows!)

Which opens the door to all sorts of other interesting techniques and tools, some of which harken back to years past when the web was still understood to be founded on server-first, HTML-first principals. Today, we have the chance to embrace the best that the web platform has to offer all while continuing to evolve the types of architectures best suited to a dizzying array of application types.

I personally think Action Web Components offers an intriguing paradigm which is compatible with a near-infinite number of client/server topologies. It’s totally framework-independent, and save for a wee bit of client-side JavaScript, it’s totally language-independent as well. Which suits me, as someone who still primarily writes server applications in Ruby, just fine. Give it a try, and let me know what you think in The Spicy Web Discord!

Building Courseware I Can Understand: The Launch of CSS Nouveau

2023-10-23T00:00:00-07:00

I’ll breeze through the marketing-speak quickly so as to get to the heart of the matter. I have a new course out, the first one for THE SPICY WEB, called CSS Nouveau. This is my very latest, up-to-date, pedal-to-the-metal thinking on how to build up a 100% vanilla CSS architecture from scratch, from design tokens to global stylesheets to encapsulated components. When people tell me “vanilla CSS doesn’t scale” or “best practices don’t actually work” (which I agree with, but in a completely different way than they probably do!) or “only a framework will let you build maintainable software” blah blah blah, CSS Nouveau is my whole-hearted rebuttal to that line of thinking. It’s designed to get you from zero-to-hero—even if you don’t already have a ton of CSS design expertise.

So check it out and hopefully you’ll take advantage of the $59 deal for six months or $10.99 a month. Yes, this isn’t just a single course—this is the first entry in a whole array of courses! Which brings me to the much larger story…

Don’t Ask Me to Take a Course

For many, many, many years, I kept banging my head against the proverbial brick wall. You see, I knew without a doubt I wanted to get into the education space, dearly. After literally decades of working in the #WebDev industry, I felt like there were at least a few topics I might feel comfortable enough to touch upon from a position of freelance-driven experience across numerous client projects, “there be dragons here” cautionary tales, and genuine enthusiasm over new advances in the state-of-the-art.

However, there was just one problem.

I hate taking courses. 😭

Courses suck:

Courses force you to pay lots of money up front. Often hundreds and hundreds of dollars. Listen, I’ll admit it. I’m a cheap bastard. But for good reason—I work for myself. And I don’t have a mega-huge discretionary budget to spend on educational pursuits. I don’t go to nearly any major tech conferences for the same reason. I take one look at the starting ticket price and…well…some months I can either do that or eat nothing but ramen noodles for a few weeks. And let me tell you—living in Portland, I sure like my fancy takeout an awful lot. 😅
Even on the chance a course doesn’t cost so much or is part of a nice subscription, they usually require you to watch videos. And here’s where things get weird: I really don’t like watching videos about technical topics. 😬 Now don’t get me wrong—I like watching videos where people show off a cool demo they made, or talk about some upcoming framework or product features, or banter about on a panel regarding a particular industry topic. That’s all fine and dandy—and I hope to put more effort into this space myself going forward (hence the shiny new Videos page!). But ask me to learn anything substantial via a series of videos spanning hours which touch on tons of code and specs and concepts and funky details? Ugh. I ain’t ever doing that. (For the most part, I don’t read books about technical topics either…)

And this, dear Reader, is why the years rolled on by and I never managed to get a course off the ground. If you don’t intend to charge much for it, and you don’t want to produce a ton of videos, what do you do?

Leaning Into Your Strengths

From a very early age—I’m talking about the internet’s age, as well as my age!—I have received many compliments as a writer.

And for some odd reason, I always had a hard time believing them. Not because I thought I was a bad writer, but because I just assumed “anybody” could hop on the internet and write. Anyone could start a blog, anyone could publish a website. Who am I to think I’m anything special?

It’s taken literally decades for me to get over my “imposter syndrome” and acknowledge to myself that, actually, I’m a pretty damn good writer.

Which is how I eventually arrived at my Aha! 💡 moment:

How do I like consuming and learning about intricate technical information? Blogs. Podcasts.
What do I like producing myself as a content creator? Blogs. Podcasts.

Now the ending writes itself. The solution to my dilemma was crystal-clear. The best course is one which looks very much like a series of blog posts and podcast episodes.

And so that’s exactly what I’ve done.

CSS Nouveau isn’t just a “course”. It’s a series. And a series will have multiple seasons. (This first season is actually titled “Vanilla Has Never Tasted So Hot”.) And each season will have multiple episodes. And an episode is structured much like how I’d write an in-depth blog post, and I literally record myself speaking the whole episode as well which you can follow along with or download to listen to at your leisure—just like a podcast.

Once I had determined that’s how I wanted to structure the courses I create, the next question was how to deliver them.

The Birth of Intuitive+

I’ll be talking more about this down the road a bit on my personal blog—and I have a little already—but the gist of it is that I’ve been wanting to offer a subscription content platform in earnest for quite some time. I toyed with Patreon a few years ago, but somehow the idea of merely being beholden to some other content platform never appealed to me. (I think I’ve just always had a bent towards DIY on the web. Own your own content. That sort of thing.)

Again, the Aha! 💡 moment was coming to the realization that I shouldn’t be dividing my efforts trying to build a subscription platform for THE SPICY WEB and another one for my “personal” podcast & newsletter and another one for some other project down the road. Are you getting it yet? These aren’t three different subscription platforms, they’re one platform! And I call it…

Intuitive+. 😁

Once you’re a member, you gain access to the “Jared Multimedia Universe” (JMU). Just kidding, I’m never calling it that. But seriously, the idea is to unify my efforts right out of the starting gate, and then slowly expand outward from there—not just additional projects I embark on (and believe me, I have a slew of efforts just waiting in the wings), but bringing other creators on-board with like-minded values and goals. Nothing would make me happier than for Intuitive+ to become an indie powerhouse with tons of shows, websites, and educational materials on a variety of “open web”-themed topics.

But I’m getting way ahead of myself. Today, the principal raison d’être for the membership service is to power THE SPICY WEB, and I’m very excited that day has finally arrived.

Cool. So What’s Next?

Obviously, the near-term goal I have is to release the few remaining bits of “Vanilla Has Never Tasted So Hot” (the final two episodes will be released on November 6 & November 13 respectively), and then start immediately on Season 2. In addition, I’ll be starting work on a new series about how to build legit frontend UI using vanilla web components (touching on concepts like state management, the client/server divide, progressive enhancement, performance, optimistic UI vs. waiting for request/response round-trips, and all of those sorts of concerns).

I could be wrong, but I think producing and releasing new material will be an order-of-magnitude “easier” than this first course, because the courseware and membership services have already been built. There are plenty of ways to improve it all of course, but I’m fairly satisfied with the “bones” at this point. (BTW, the process of putting that all together pretty much from scratch deserves a whole series of posts in and of itself!)

All right, enough of my bloviating. I’m extremely grateful for all the support folks have shown me through the Discord and on social media (Mastodon), and I might not have ever gotten to this point if it weren’t for a few encouraging voices in particular. I can’t possibly thank everybody by name, but please know that I’m deeply appreciative.

TL;DR: CSS Nouveau. It’s out. Check it out. 🥳

Yeah, But is Tailwind a Cult Tho?

2023-09-18T00:00:00-07:00

I’ve been a part of “cults” before, whether that’s being a total Apple fanboy or a total Ruby fanboy or—perhaps more recently—a total web components fanboy.

So as the seemingly never-ending debate over Tailwind CSS continues to rage on, some haters of Tailwind hurl accusations that Tailwind is a “cult” and überfans are responsible for perpetuating it. Even pro-Tailwind promoters are getting in on the act, as a recent blog author states: “I’m in a cult, but hey, I’m happy, and this Kool-Aid tastes delicious.”

Now I’ve made a name for myself I suppose as a frequent critic of Tailwind, so you might think I’d point to this and say “Haha, you said it, you’re in a cult! Pwned!” But I think we need to be careful here. Lots of people get excited about all sorts of technologies and tools. If we actually believe that a fan community has crossed a line, we need to be careful to point it out in a reasonable manner and back that up with hard evidence.

So here you go. I will now endeavor to present hard evidence in the form of YouTube comments on Adam Wathan’s keynote at the recent Tailwind Connect conference. I simply scrolled through the list of comments and pulled out anything that seemed, er, rather in the direction of sounding cult-like. Does this prove Tailwind is a cult? Well, you be the judge!*

(* Actually, I will also be the judge but I will hide my commentary behind disclosures. Feel free to ignore! 😉)

Shoutouts from the Fans Cult Members?

Everyone that can afford buying Tailwind UI should do it. These people deserve that and more.

Hmm… 🤔

Always a little concerning when folks encourage “everyone” to funnel money into the mothership…

nothing but love for the tailwind team and the extended community - you both revolutionised styling and allowed me to go from struggling with maintanance to getting creative with ease. I salute you, and am excited for what else is in store! Thank you from the bottom of my heart

Hmm… 🤔

“Bottom of my heart” sort of feels like it should be reserved for “you saved my puppy” or “my grandmother can now walk again thanks to your therapy treatments” rather than, er, utility classes, but that’s just me.

Steve is so smart when it comes to design. Dude is literally a genius. By far one of the best designers on the web right now.

Hmm… 🤔

Nice use of the word literally. 🤡

The greatest thing about Tailwind for me as a beginner was I didn’t have to discover what were the best ways to achieve some things, Tailwind had already done the hard task of figuring out browser compatibility issues and on top the most amazing tech documentation I have seen anywhere. Also not to forget that I haven’t had to deal with any bugs whatsoever. You guys are amazing.

Hmm… 🤔

Perhaps chalk this one up to framework honeymoon glow, but it’s perhaps unwise to cast any software tool as having “the best documentation ever” and “no bugs ever” and “figured out all compatibility issues”. You’re just setting yourself up for disappointment…

Tailwind is hands down the best thing that ever happened to css. Thank you 👏

Hmm… 🤔

Let’s see, some additions to CSS in recent years:

Grid
CSS Variables
Logical Properties
Light/Dark Mode
Container Queries
:has
Shadow DOM
Comparison functions like clamp
HDR Color
Nesting (!!)
Cascade Layers
Future SPA-like behavior in MPAs with ViewTransition API

Eh, but nope, Tailwind is the best thing that ever happened to CSS. 😝 (Perhaps it’s worth mentioning that Tailwind would do absolutely ZERO of these things without actual CSS functioning?! After all, Tailwind is essentially just a bespoke DSL… 😃)

Adam Watham is turning into Gigachad with all the self-improvement and I’m all for it!

Hmm… 🤔

Any discussion of any programmer’s personal appearance (especially women and queer/non-binary folks, but cishet men too) makes me extremely uncomfortable. Adam lost weight and grew muscles, awesome. Remind me again how that’s in any way relevant to a CSS framework??

Tailwind team is the definition of the perfection

Hmm… 🤔

Glad to see they’re striving for the ultimate DX.

Hmm… 🤔

Doesn’t that describe, like, every software library tho? 😅 “Naw, I’m striving for the most mid DX. Download today and experience the mediocre!”

Just wanna start using Tailwind CSS. Can’t wait to get into it.
Just love it already 🥰💯

Hmm… 🤔

This technology is so good, I’m 100% in love and I haven’t even used it yet!

“My vision for what I want to help people with Tailwind which is build CUSTOM stuff” -Adam
that’s why I use tailwind since his first release, I never use css frameworks, no bootstrap, no anything, until I discover tailwind! because I’d always want CUSTOM stuff, thank you Adam!

Hmm… 🤔

Huh? 🤔

Always a joy to listen to Adam

Hmm… 🤔

Always a joy!

After i tried tailwind i couldnt stop using it, i use it for everything to the point where I feel like im forgetting vanilla css syntax 😂

Hmm… 🤔

Whoa, this one needs a warning label! I haven’t see anything this scary in a long time! 😱

after an year of raw CSS i switched to tailwind css and felt like heaven

Hmm… 🤔

🌈🦄

Adam and the team, you’re all just awesome. Thank you.. Adam and the team, you’re all just awesome. Thank you..

Hmm… 🤔

Adam and the team, you're all just awesome. Thank you..

I think Tailwind should just become the new css standard, like even when am in vanilla css, I check tailwind for documentation on the css property!

Hmm… 🤔

Duuude, wait until I show you MDN. 🤯

Great product glad to be alive and see the revolution of css hahah 😂 to tailwind

Hmm… 🤔

I’m just so thankful to have lived to see the day…the day when…Tailwind.

The single most revolutionising architecture ever created …

Hmm… 🤔

Single! Most! Revolutionising! (sic) Architecture! Ever! Created!

OK, I’m calling it.*

👉 Tailwind is a cult. 👈

(* Also I’m sick of scrolling through all those creepy YouTube comments. Yeeesh!)

Enhance vs. Lit vs. WebC…or, How to Server-Render a Web Component

2023-08-13T00:00:00-07:00

One thing I’d like to get off my chest right away.

It was always possible to render custom elements on the server. Any server.

Setting any “web component-y JavaScript-y” bits aside, you could always output something like this directly in your HTML:

<my-custom-element>
  <my-custom-header><h1>Wee!</he></my-custom-header>
  <my-custom-button variant="primary"><button>A button!</button></my-custom-button>
</my-custom-element>

And then you could style all of those custom elements however you like:

my-custom-element {
  display: block;
  background: lightyellow;
  padding: 1rem;
}

my-custom-header {
  display: block;
  padding-bottom: 1rem;
  margin-bottom: 1rem;
  border-bottom: 1px solid rebeccapurple;
}

my-custom-header h1 {
  margin: 0;
}

my-custom-button button {
  background: gray;
  color: white;
  padding: 0.75rem 1rem;
  font: inherit;
  border: none;
  border-radius: 3px;
}

my-custom-button[variant="primary"] button {
  background: navy;
}

Look Ma! Custom elements! Rendered by a server! JavaScript totally optional! 😲

OK OK, I know what you’re thinking. I’m leaving out some key details…

Component-Centric View Architecture and Shadow DOM

What people usually mean when they ask if they can SSR their web components is this: hey, can I take the code I’ve already written for client-side web components using all of the web component APIs (especially shadow DOM), and basically take an on-the-fly snapshot of that render tree and stick it in my output HTML (whether for a static site or a dynamic server)?

And so we’ve seen various projects, most notably Lit, tackle this very problem and provide a mechanism to render web components on the server, with an optional hydration step on the client to take those server-rendered components and make them interactive after initial load.

Yet, this sort of “isomorphic” architecture where client and server code is essentially identical has increasingly fallen out of step with what many developers actually want. Components which only run on the server are making a big splash across a variety of ecosystems, with even React/Next.js getting in on the action.

I like using the term “split components” which I first heard about from the Marko project. A split component essentially divides each component into two: a server-only portion, and a client-only portion. Sometimes you can pull some or all of the server logic over to the client as well for full isomorphism, but oftentimes you simply don’t need to.

I’m going to make a bold statement to kick off our explorations of web component SSR’ing today:

The future of web components is split components.

Or to put it another way, the future of web components is HTML-first, server-first—a mantra I’ve been preaching for a long time.

But this means we have a lot to do. The web components spec historically has been pretty squarely focused on client-side APIs which potentially make the most sense in a world of client-driven app architecture, namely SPAs. It pains me that as many frameworks are deep in the throes of migrating away from SPA-as-default across our industry—thank god!—web components feel behind the times. But there are promising signs ahead.

Declarative Shadow DOM lets us server-render the internals—the guts if you will—of web components and ship those directly to the browser. Yes, Firefox still needs a simple polyfill (2024 update: not any longer! DSD is supported by Firefox!) which is really no biggie, and for Chrome and Safari you can display your server-rendered components including shadow DOM with zero JavaScript. Pretty darn cool.

Furthermore, there are ongoing efforts to spec other parts of the web component APIs for a world of declarative markup. In the future we might gain declarative custom element registration and declarative ElementInternals functionality and even declarative reactive templates using DOM parts. People who work on this stuff at the spec and browser implementation level now understand the gravity of the situation. If a major API is only available to client-side JavaScript, it’s less likely to work well in an HTML-first, server-first landscape.

But…we’re not here to dream about the future. We’re here to see what we can do right here, right now. And so on with the show!

There’s Node Business Like Sh(ad)ow Business

Groan. 😅

I’m going to demonstrate three different component formats which you can use today in any Node project inside of any potential template rendering environment. These are:

Of the two, Enhance and WebC are closer in terms of general concept. Both start with a “0kb JS” mindset and use terminology of “expansion”—aka, your top-level HTML templates include custom element tags, which then are “expanded” with the full rendered components…and those components might expand other components, and so on and so forth.

Lit’s certainly a bit different and, as a popular library for web component authors, is a well-known quantity. Like I said, Lit is typically used for “isomorphic” components (aka the code you SSR and the code you load client-side is virtually identical). However, there’s actually no hard-and-fast reason you have to do it this way. And so I demonstrate that Lit too could be used to author “split components”—although you’re fairly “on your own” in term of practical applications of it.

Starting in alphabetical order, let’s first look at Enhance.

Region 3. Move Down 5. Zoom In 300%. Enhance!

Demo Repo

Enhance made a splash a while back as a fullstack framework you can use to build entire web applications, all centered around the concept of server-rendering custom elements. What’s particularly nice about how Enhance is architected is that the piece which deals directly with component SSR is a standalone library anyone can grab off the shelf and use.

Here’s an example of an Enhance component:

export default function MyElement({ html, state }) {
  const { attrs } = state
  const { hello='?', easy=[] } = attrs
  return html`
    <style>
      :host {
        display: block;
        padding: .5rem 1rem;
        border: 3px double orange;
      }

      h2 {
        color: maroon;
      }
    </style>

    <h2>Hello ${hello}!</h2>

    <p>Easy as ${easy.join(", ")}. <slot></slot></p>
  `
}

And here’s a (simplified) example of rendering it in a main server process:

import MyElement from "./my-element.js"
import enhance from "@enhance/ssr"

const html = enhance({
  elements: {
    'my-element': MyElement,
  }
})

const data = {
  hello: "world",
  easy: [1, 2, 3]
}

const result = html`
  <my-element hello=${data.hello} easy=${data.easy}>Boom done.</my-element>
`

You can look at the full example code in the repo link above.

What I like about this is its conceptual simplicity. There’s not a lot you need to learn. If you know the basics of HTML, CSS, JavaScript, and Node, you can use this to DIY your own web framework.

Enhance also provides some nice style scoping features right out of the box. By default, Enhance components do not use shadow DOM. You can certainly opt-into it though, but if you don’t, you can still use some of the same nomenclature in your component styles like :host, and all of the selectors will end up prefixed with the tag name automatically. In other words:

:host becomes my-element
p becomes my-element p
.cls becomes my-element .cls

and so on. Neat-o!

Because Enhance components are server-only components from the start, the way you add your client-side web component code is simply by adding a script tag to your component template. So for example, I have an s-dom.js Enhance component which uses a combination of Declarative Shadow DOM and “light DOM” content, which is fantastic, and my client component is simply embedded at the bottom of the template like so:

<script type="module">
  class SDomElement extends HTMLElement {
    static {
      customElements.define("s-dom", this)
    }

    connectedCallback() {
      const para = this.shadowRoot.querySelector("p")
      para.style.border = "1px dashed gray"
      para.style.padding = "0.5em"
    }
  }
</script>

Enhance is smart enough to collect all of the scripts in the entire render tree and include them only once at the bottom of <body>. (And components styles are also collected and included in <head>.)

While there’s much to recommend here, there are also some things I don’t like about Enhance which I’ll cover shortly. I also had to patch Enhance so that I could get at its rendered <head> content separately from the <body> content. I think Enhance is used to the idea it’s always rendering an entire HTML page template. I filed an issue on GitHub, so we’ll see if this is a use case they’d like to support going forward.

This Component is Lit. Lit AF.

Yes, it’s mandatory to engage in juvenile humor when talking about Lit. Listen, I don’t make the rules!

Demo Repo

So for our Lit example, things are a wee bit different than Enhance. Lit always defaults to using shadow DOM, and while you can switch it off, stuff sort of breaks because slotted content is no longer a thing (and scoped styles are more of a pain). So I just left it all as is. I’m a huge shadow DOM fan so that doesn’t bother me, but for folks who have an aversion to it or it doesn’t play well with the rest of their HTML/CSS architecture, it might prove a hurdle.

Here’s a component in Lit, similar to the first Enhance example:

import { LitElement, html, css } from "lit"

export class MyElement extends LitElement {
  static styles = css`
    :host {
      display: block;
      padding: .5rem 1rem;
      border: 3px double orange;
    }

    h2 {
      color: maroon;
    }
  `

  static properties = {
    hello: {},
    easy: { type: Array },
  }

  constructor() {
    super()
    this.hello = '?'
    this.easy = []
  }

  render() {
    return html`
      <h2>Hello ${this.hello}!</h2>

      <p>Easy as ${this.easy.join(", ")}. <slot></slot></p>
    `
  }
}

customElements.define('my-element', MyElement)

Pretty standard fare if you’re used to the Lit API. The question is, how easily can you server-render this component? Well, you be the judge:

import { render } from "@lit-labs/ssr"
import { collectResult } from "@lit-labs/ssr/lib/render-result.js"
import { html } from "lit"
import { MyElement } from "./my-element.js"

const data = {
  hello: "world",
  easy: [1, 2, 3]
}

const result = await collectResult(render(html`
  <my-element hello=${data.hello} .easy=${data.easy}>Boom done.</my-element>
`))

In a streaming scenario, they recommend working with RenderResultReadable so the output response can flush at various intervals to the browser, but in simpler contexts this seems to work just fine.

The split component mechanism is a bit wonky, but still doable. I ended up adding a separate template as a static property of the component, and then including that in a separate render of JS assets:

// in s-dom.js
static clientComponent = html`
  <script type="module">
    class SDomElement extends HTMLElement {
      static {
        customElements.define("s-dom", this)
      }

      connectedCallback() {
        const para = this.shadowRoot.querySelector("p")
        para.style.border = "1px dashed gray"
        para.style.padding = "0.5em"
      }
    }
  </script>
`

// and then later:
const jsResult = await collectResult(render(SDom.clientComponent))

So…this is doable, but it probably just makes more sense to have a separate .js file for your client component and include that as part of whatever frontend build/bundling pipeline you might have. Maybe you even adopt .server.js and .client.js conventions, and for components where you want the same one running in both places….iso.js? .hybrid.js? Hmm.

(It should be noted the Enhance example doesn’t offer an isomorphic possibility, only split components. So if you think you’ll actually need to write lots of isomorphic components, Lit becomes awfully attractive…although the number of caveats you need to keep all in your head is quite daunting.)

WebC Lets You Render Components for the Web, See?

Yeah, see? You can now render components on the server, see? Yeah!

Like Johnny Rocco, I “want more” when it comes to options for custom elements SSR, and so we arrive at our third and final demonstration which is WebC.

Demo Repo

WebC grew out of the Eleventy project, and like Enhance you can simply spin up an Eleventy site and install the WebC plugin and you’re off to the races with a full framework (albeit mostly oriented towards static sites).

For our purposes, WebC can be used standalone without any major gotchas and the API is straightforward (although once again I must admit it took me a bit of time to stumble onto the right formula).

It’s worth explaining up front that WebC is quite different from Enhance and Lit in terms of the syntax of writing a component. WebC doesn’t use JavaScript files like the other two. WebC provides its own HTML-based SFC (Single-File Component) format which looks a lot more like Vue or Svelte. JavaScript can be embedded into component files, whether it’s code to run on the server or code to include as scripts for the client.

Here’s an example of a WebC component:

<script webc:setup>
  const join = (input) => input.join(", ")
</script>

<style webc:scoped="my-element">
  :host {
    display: block;
    padding: .5rem 1rem;
    border: 3px double orange;
  }

  h2 {
    color: maroon;
  }
</style>

<h2>Hello <span @text="hello"></span>!</h2>

<p>Easy as <span @text="join(easy)">...</span>. <slot></slot></p>

And here’s how to render it. We’ll use a page entrypoint to include the element and then render that entrypoint from our Node process:

<my-element :@hello="hello" :@easy="easy">Boom done.</my-element>

import { WebC } from "@11ty/webc"

const page = new WebC()

page.defineComponents("./webc-ssr/components/*.webc")
page.setInputPath("./webc-ssr/page.webc")
page.setBundlerMode(true)

const data = {
  hello: "world",
  easy: [1, 2, 3]
}

const { html, css, js } = await page.compile({ data })

WebC happily provides you with separate HTML, collected styles, and collected scripts which you can then include inline on your page or hand off to some other frontend process.

WebC also provides a “light DOM” scoping mechanism similar to Enhance, except that it uses hashed class names by default and you have to manually specify a human-readable class name (and then it’s a class not the actual tag name as the selector prefix). It’s fine, but I’d prefer true scoping at the element level. Certainly shadow DOM can also be used in WebC for style scoping.

Unfortunately, the interactions between WebC server-level slots and shadow DOM slots are painful, far more than in Enhance. Within your Declarative Shadow DOM template, you have to add a webc:keep attribute to maintain proper semantics in the output HTML. And for “light DOM” tags which need to preserve a slot attribute and avoid processing by WebC, you have to add something like @attributes="({ slot: 'hello'})". Again, it really took some time to figure this all out! There’s an issue to track this if you’re curious to see if the WebC folks can come up with a simpler solution.

It also took me a beat to figure out how to process incoming component state in JavaScript (aka to join the incoming array into a string) in my component template. Providing a function in <script webc:setup> to use in the HTML portion is pretty obvious in hindsight, but I fiddled around with a lot of other approaches before stumbling across this one.

In spite of these gotchas, I really appreciate WebC’s aesthetic, from its API design to the HTML template syntax. Others may disagree, but I truly enjoy authoring HTML as HTML, and I’ll talk much more about this in a moment. (Just be aware that, like Enhance and unlike Lit, WebC doesn’t offer isomorphic components, only split components.)

Enhance vs. Lit vs. WebC: Who Wins?

The short answer: none of them. 🤡

So here’s a thing which really annoys me about the Node ecosystem. There’s no community protocol or meta-library (that I’m aware of at least) which lets you easily render templates from any server configuration.

In Ruby, we have Tilt. Tilt lets you render templates in a wide variety of languages, both out of the box or via third-party plugins. And by way of example, I actually created my own template language a while back as an offshoot of ERB, called Serbea. Because Serbea is available through Tilt, you can render Serbea templates from any Ruby web framework easily. Adding support for Rails was mere lines of code!

Now this does break down a bit when talking about real server components. Ruby frameworks have to supply their own partial/component render methods to use with Tilt. We also have work to do here it would seem.

Nevertheless, in an ideal world, there’s be “Nilt” (Node…Interface (for) Loading Templates? Hey, that tracks!), and Enhance and Lit and WebC and a dozen other flavors of this stuff would all just plug into “Nilt” and a variety of web frameworks would know how to use “Nilt” for views and you’d be up and running in no time. Choose your flavor.

Instead…if you’re going to use Enhance you might as well use Enhance (the framework). And if you’re going to use WebC you might as well use Eleventy. And if you’re going to use Lit…well, good luck with that. There’s no “Next.js but for Lit” (yet). Maybe use Astro?

(Speaking of Astro, it also comes with a shiny-new server component format which you could use alongside custom elements. But it only works in Astro! 😭)

I think it’s vitally important we keep talking about and emphasizing the need for interop, hence the reason I wanted to write this article. And here’s where I really get on my soapbox, so buckle up folks!

The promise of web components in browsers is that you get a true write once, run anywhere API. I can write my card or my color picker or my audio player or my site header or my business dashboard once, and utilize those components anywhere. I don’t need to tear down the whole world and rebuild from scratch because I’m using Vue, no wait React, no wait Svelte, no wait Solid, no wait Qwik, no wait…

And because web component APIs use declarative HTML standards as their launching pad, in theory my web server could be anything—as it should be. Render web components from Ruby! From Python! From Java! From Elixir! From whatever the heck you and only you like!

What we truly need is a sense of server-side interop, a vision of a component format where you could squint and see how server components could be authored in one environment and ported over to another environment without too much hassle.

And that brings me to my actual clear winner in all of this. Drumroll, please! 🥁

It’s WebC.

WebC: an Enchanting Path Forward

WebC is the only tool I’m aware of on the market today which lets you author web components as HTML from the very start. The .webc extension of a component highlights that while this isn’t pure HTML, it certainly isn’t JavaScript either. And that’s the Achilles’ heel of technologies like Enhance or Lit. It’s HTML-in-JS, CSS-in-JS…nothing but .js files as far as the eye can see.

I really hate writing HTML in JavaScript files. 😬

It’s not how the web was architected. The browser downloads HTML first—then processes any styles or scripts which are either contained inline or linked to externally. As someone with nearly 30 years of experience working on the web, I instinctively think HTML-first when I think about how to structure my page, structure my layout, structure my components. The content always comes first, then presentation, then behavior. HTML, then CSS, then JavaScript.

And past eras of tooling understood this. Most “old-school” HTML template languages start with pure HTML-as-string-data and let you sprinkle in your code bits. Heck, PHP is essentially an entire language that was built to be HTML-first! The reason you have to include <?php at the top of every PHP code file is because otherwise it’s just a text template! (Look at this opening example in PHP’s documentation if you don’t believe me…)

The modern evolution of this concept is a component format which actually parses your HTML server-side to turn it into the server equivalent of a DOM tree, and then walks the tree searching for special attributes, directives, handlebars, etc. to apply processing. This is slower and more effort than basic string manipulation/RegEx-fu like the older template formats, but it provides opportunities for better syntax, fewer bugs and security holes, and tighter integration between the HTML markup and the underlying server programming language.

WebC takes full advantage of this concept. When you write <span @text="msg"></span> instead of something like <span><?php echo $msg; ?></span>, you’re moving from old-and-busted “inject string output here in text file” to new-hotness “when you process this dynamic attribute, swap the execution output into this node’s contents”. In other words, you’re writing a declarative template, but it’s translating that into imperative manipulations of the DOM, just like it would on the client in a component format there.

And while WebC only runs in a JavaScript server context, you could imagine applying these same concepts and using the same component format nearly unchanged elsewhere. Yeah, that’s right. Imagine, say, a “WebR” that’s a Ruby port of WebC. The above WebC example could look like this:

<script webc:setup type="application/ruby">
  def join(input) = input.join(", ")
</script>

<p>Easy as <span @text="join(easy)">...</span>. <slot></slot></p>

Here’s what’s astounding about this hypothetical example. I rewrote the script block which executes on the server as Ruby code, but the HTML template didn’t have to change. At all.

Very little would have to change when you think about it. In server-rendered applications, most logic lives elsewhere. Controllers or routes pull content from databases and handle requests, models or entities encapsulate records, and you can easily write functions or PO(X)Os (Plain Old Ruby / JavaScript / Python / etc. Objects) to mange all sorts of business logic. The view layer only has to provide a base level of smarts to take a data structure defined elsewhere and translate it into markup.

It’s only in the so-called “modern” world of SPAs where components have fast expanded like a virus to take over the bulk of application architecture. You’re fetching data from APIs and handling forms and validating data and executing business logic all from view-layer components. It’s nothing but another form of big ball of mud software architecture.

We have a real opportunity to reset expectations and reassert best practices and codebase health, and I’m very excited about this. I can easily see a future where:

A variety of SSR web frameworks across a variety of languages…
…Use something like WebC as a common server component format…
…And then WebC-friendly client libraries help bridge the gap between “split components” and possibly handle WebC-style templates client-side as well for true isomorphism.

This way, you don’t really need to learn the “Enhance” way or the “Lit” way or the “Astro” way or the this way or the that way to just write a freakin’ web component. 🤪

Put another way, we desperately need a common language around thinking of web components as fullstack components. Custom elements aren’t merely a way to spin up some JavaScript and attach it to a node in the browser. They form the baseplate of the view layer of your web application.

I have to say, I really do appreciate what the Enhance folks are doing. Because they too see a world of fullstack custom elements-as-view-layer and are making that a reality today in the Enhance framework. It’s good stuff.

But then again, I keep getting tripped up by the JavaScript-centric nature of it. I can never truly get onboard with a universal web component format which is unable ever to be rendered by the infinite number of other web servers out there which aren’t Node/Deno/Edge/etc..

And so I find myself extremely enthused by WebC. I think Zach Leatherman struck gold when working on this format. And even if we end up with further permutations down the road (and admittedly it’s an area of intense experimentation for me), WebC is the technology to take seriously today.

My Journey Away from the JAMstack

2023-07-31T00:00:00-07:00

Before I give you my side of the story, I’d like to point you to Brian Rinaldi’s comprehensive take on the demise of Jamstack (or as I still prefer to call it, JAMstack) for some much-needed context on what’s been going down. He asks “is Jamstack officially finished?” and this article is essentially my reply.

TL;DR: the answer is yes.

As for the reason why, we must point our finger straight at Netlify.

Listen, I get it. Running a successful and hopefully profitable hosting company with investors breathing down your neck is hard. I don’t begrudge them for having to pivot to enterprise cloud mumbo-jumbo in order to reel in the big bucks and justify their valuation.

But I can’t help but feel duped…like so much of the other “enshittification” we’ve been dealing with in tech over the last few years. The cycle repeats itself: we invest our hard-earned time and sometimes money to build on top of friendly, seemingly benign platforms—only to see those platforms wriggle out from under us and morph into something entirely different (and for our purposes, much worse).

Gather around folks, and listen to my story of my first experience with the JAMstack. I’ll also explain why prior to this news I’d already moved on from the it and from Netlify, and what instead I believe the web dev industry should be heading towards as a “default” stack.

The Year Was 2015

I had just come off a lengthy stint trying to build and promote a paid, tablet-first CMS. With a failed startup behind me, as well as a number of WordPress sites I simply hated to administer because they were so buggy and insecure and expensive, I was getting desperate. Due to my experience as a Ruby on Rails developer, I even tried reaching for some Rails-based CMSes, but finding a slam-dunk improvement over WordPress was far from straightforward.

And then I stumbled upon Jekyll. 😍

To this day, I have no clue why it had initially taken me so long to discover Jekyll. Jekyll was integrated into GitHub (powering their Pages product) and was built with Ruby! I do remember hearing more and more about “static site generators” (aka SSGs) as I was winding down production of my own CMS, and I filed that thought away as a possible way to salvage some of the work I’d done.

Eventually I finally gave Jekyll a real try, and I was floored. Here was an amazing developer-friendly tool where I could just to take a bunch of simple HTML / Markdown, CSS, JavaScript, and image files, run a single command, and BOOM: get a website trivially easy to deploy anywhere. I even grokked the Liquid template syntax without issue, because I was already familiar with both Shopify and my own CMS which had used Liquid.

The only real head-scratcher was the content authoring side of the equation—I couldn’t expect my clients to learn how to input Markdown into GitHub—but with my experience having already built authoring interfaces, I figured it wouldn’t be hard to put together a simple Rails editor app that could work with Markdown and GitHub under the hood.

I dogfooded Jekyll first for my own personal website at jaredwhite.com, relaunching it in February 2016. (It’s since been resigned many times and is now built with Bridgetown instead…but it remains a static site!) From there, I worked on a variety of projects for myself and for clients. To this very day, some of those sites are still on the web humming along without issue (here’s one of my favorites) because, hey, static sites are awesome!

Along Came Aerobatic Netlify

When I first got into this brand-new world of modern SSGs, the gold standard for hosting Ruby-powered web applications was Heroku. I was quite familiar with Heroku and had used it on a number of projects. But Heroku had nothing to offer me when it came to SSGs. Heroku was engineered around a model of dynamic web servers and databases, not build-once-and-cache-on-a-CDN-forever deployments.

I suppose I could have just used GitHub Pages, but at that time I was primarily using Bitbucket for hosting my projects and those of my clients. So it was perfect timing that, right when I needed to figure this all out, along came Aerobatic.

Aerobatic was basically Heroku but for static sites hosted on Bitbucket (it was literally an add-on for that platform). Perfect! I could easily get that “push via Git and automatically deploy” workflow going with no other setup required. And the deployed sites were fast, secure, and cheap as hell to operate indefinitely.

For my client’s content editors, I usually just spun up a cheap VPS on Digital Ocean. They didn’t need to be high-powered at all, because those servers weren’t promoted to the public or accessed by more than one person really. And because all the content was stored in a Git repo, I didn’t even need to wrestle with a database!

However, my love affair with Aerobatic didn’t last long. Because another shiny offering soon emerged: Netlify.

The best way I can describe Netlify when I first started using it is “like Aerobatic…except better”. I’d encountered a few technical difficulties getting Aerobatic sites up and running, and Netlify was a noticeable improvement. Builds were fast, deploys were rock-solid, and It. Just. Worked. Plus it supported both GitHub & Bitbucket, so either way I was golden. I forget when they added the Forms feature, but it was pretty early on and that also proved a huge advantage.

One issue many of us encountered when trying to market these amazing new “static site” to potential customers was the term static. Calling a website “static” for many people implied a site which rarely changed and couldn’t accommodate any dynamic, interactive functionality. Boring. For instance, surely you couldn’t run your e-commerce site as a “static” site because e-commerce is anything but static!

Enter JAMstack.

The JAMstack is Here to Solve All Our Problems (Right?)

Netlify’s marketing sleight of hand in inventing and promoting the JAMstack was sheer brilliance. Instead of calling these builds “static sites” and these tools “static site generators”, we could say we’re building JAMstack sites (to compete with LAMPstack sites I suppose) and using some hot new JAMstack frameworks. The JAM stood for:

JavaScript
APIs
Markup

And lest anyone get confused (because as we’ll soon discover EVERYONE eventually got very confused), the JavaScript of the J in JAM referred to client-side JS, not server-side. The whole point of JAMstack was that the tool building out the markup etc. could be written in anything, and just as importantly the APIs used by the client-side JS could be written in anything. After all, both Jekyll and Rails are Ruby-based tools, and I happily used both as part of my JAMstack deployments.

As time went on, a major appeal of the JAMstack was that it allowed a decoupling of the frontend from the backend, which is why Netlify and other hosts like it later on proved extremely popular with frontend developers. Ironically, in today’s world where SSR (server-side rendering) and progressive enhancement is now top of mind for many web developers, it’s positively wild to turn back the clock and realize that JAMstack architecture arose during the height of the SPA movement. You can even see it in all the marketing materials—your app “shell” could be statically deployed, and then your fancy-pants client-side app could take over and call APIs from all over the web. And a number of JAMstack sites were literally that. Disable JavaScript and what do you get? Maybe a simple header and footer if you’re lucky. Everything else is blank. Whoops!

However, that was never my JAMstack. I had intuitively understood that the exciting promise of JAM was in a sense the reverse acronym of MAJ: Markup, then APIs, then JavaScript. In other words, build as much as you can with static HTML (via templates, Markdown, etc.), then identify what you might need for some dynamic server interactions—which maybe you’d just write yourself as a Rails app or whatever—then write only the JavaScript you absolutely need to access those APIs (understanding that maybe certain dynamic pages would just get fetched directly from the server if need be).

In other words, progressive enhancement. 😂

But somehow that story got lost in the fray, and JAMstack eventually gave rise to a rebranded “Jamstack” with the major value prop being something rather entirely different: you could now build entire websites out of JavaScript libraries (aka React, or maybe Vue or Angular or Svelte) and JavaScript frameworks (aka Next.js, Gatsby, Nuxt, SvelteKit, etc.). And, whoa, look at this! You don’t need servers ever again! You can just write serverless functions to go along with your frontends! Fullstack, server-first web development is dead, long live frontend + serverless!

(Coinciding with this sea change, Jekyll began a long, slow, painful decline into irrelevance, due to the inexplicable failure of GitHub’s leadership to support its proper development and promotion as well as an unforgivable neglect of the Pages platform. It remains one of my greatest frustrations in 25+ years of web development…so much so that I forked Jekyll in 2020 and created Bridgetown. But I digress…)

Along with this “second generation” Jamstack mindset shift came an order of magnitude more build complexity. Instead of a straightforward CLI kicking off simple transformations to go from Markdown -> HTML plus concatenate some (S)CSS files together or whatever, you’d get multi-minute long builds and GBs of node_modules and poorly-written tutorials on DEV.to about how to send emails from Gatsby functions and which distributed “web-scale” databases of the day are the coolest and crazy CLI tool churn and all sorts of other headaches. Things which used to take hours or days to accomplish in standard Rails or Laravel or Django apps—most of this stuff isn’t rocket science, folks—now took weeks or months! Progress! 🤪

This quick march of slapdash B.S. web technology under the guise of making our lives easier was one hell of a whiplash, and I really hadn’t seen it coming when I first entered this space. Instead of JAMstack saving us all from the horrors of WordPress, we were crushed under the weight of Jamstack! Janky SPAs, countless immature buggy frameworks, and NPM ecosystem insanity—along with the multi-headed hydra that is modern React.

It got so bad I wrote about it. (Warning: if you think this article has taken on a dour tone, avoid reading that spicy take! 🌶️)

Netlify isn’t to blame…except Netlify is to blame 😬

We can’t put all the fault squarely on Netlify, in the sense that people mistakenly thought they needed to build their blogs with Gatsby and their business dashboards with Next.js because that’s what all the “techfluencers” and VC-backed tool vendors told them.

Yet I do blame Netlify, because they’re the people who invented the term JAMstack! Netlify proved more than happy to come along for the ride and oblige as one of the top hosting platforms of choice for this new ecosystem. They could have come out in favor of saner architectures and better support for languages other than JavaScript (believe me, I went around and around with them about their lack of interest in supporting Ruby-based server applications even as their own platform used Ruby under the hood!). They could have warned us of the dangers of complicated API spaghetti code and microservices. After all, why should Netlify care if your static site calls out to 20 different APIs or your own monolithic API you wrote in a battle-hardened, “boring” server framework? This bizarro-world focus on “serverless functions” and later “edge functions” never made a lick of sense to me (unless Netlify really thought they could somehow significantly profit off of function usage…again, a prospect which makes little sense to me).

Ultimately the failure of Jamstack to live up to the promise of its original JAMstack incarnation, and the industry’s manic pendulum swing into unmaintainable architectures and vendor lock-in, led me to abandon Netlify as a hosting platform of choice and look instead to more reasonable options. At this moment in time, that choice for me is Render. Render gives you the best of all worlds: deploy a static site to a CDN, deploy a server API written in any framework you want—even Rails!—deploy a Docker container…anything you need, BOOM, done. Want to use PostgreSQL? Check. Need Redis? Check. Would you like simultaneous deploys of all these services at once? Check.

I have no business arrangement with Render, and I assure you this isn’t a sponsored post. I just really like their service. And if Render does become enshittified down the road, I’ll be super bummed and look for yet another alternative. (I sure hope that won’t become necessary!)

What saddens me is Netlify could have grown into a Render and meaningfully competed with Heroku—except they didn’t. They took a different road, and I would argue they failed. Hey, hindsight is 20/20…but honestly this was so easy to predict. 🤷🏻‍♂️

I’m sad to see Jamstack die, but the thing is: most web applications deployed by most individuals and small teams only need modest server offerings and maybe a static site. Again, it’s not rocket science. Most projects never need to become “web scale” and most web architectural complexity is completely unnecessary. You can spin up a Node.js API with Fastify, or a Ruby Roda API, or, heck, some PHP, stick it on a decent cloud server somewhere, and that’s totally fine. Boring technology is great. And servers are in fact totally awesome, as more and more developers are thankfully coming to discover (again).

The Legacy of Netlify

What Netlify gave us originally was a vision of how to deploy HTML-first websites easily via git commits and pushes, just like Heroku had done for dynamic applications. All we need now is a modern Netlify/Heroku mashup that’s cheap, stable, and doesn’t need to reinvent the damn wheel every year.

What do we call this, now that Jamstack is dead? I don’t know.

I vote for KISSstack. (Keep It Simple, Silly.) 😋

But seriously, I think it’s vitally important to remember that simple websites and more complex web applications all sit on a spectrum, and a good web host will be able to identify your individual needs and provision builds and runtimes accordingly—no matter what the particular service offerings might be. (I wrote about this too.)

From my vantage point, the only goal I care about is to make building & deploying sites dramatically easier for individuals and small teams. (Sorry Big Co. Enterprises, I don’t think about you at all.) And while it’s a real shame that Netlify is no longer in a position to usher in this future for us, I’m optimistic we’ll see Render, Fly.io, and other companies down the road pick up the slack.

Somebody has to.

New Projects Galore! A Blog and a Podcast

2023-07-18T00:00:00-07:00

Hello everybody! It’s been a minute since posting here, so I wanted to get you all caught up on the thrilling projects which I’ve recently launched alongside The Spicy Web.

First, I’ve started a new aggregator-style link blog called That HTML Blog where I’ll be posting daily to share links to wonderful resources around the web about the world of standards-adjacent web development. Please be sure to sign up for the email digest and add the newsfeed to your RSS reader of choice!

Secondly, my good friend Ayush and I are now publishing bi-weekly episodes of the Just a Spec Podcast, each one focused on a particular protocol or specification that makes the internet tick (both the web and even beyond). I hope you will subscribe in your podcast player of choice, as well as follow @justaspec@intuitivefuture.com.

What about this site though? I’m in the process of redesigning it a bit to focus more on original video and course-style content, and in fact with the launch of That HTML Blog, it makes that process even more clear. I hope to have more news about the release date of my “new CSS” course next month.

But in the meantime, enjoy the links above, and of course feel free to hop in the Discord and let me know what you think! ✌️

The Spicy Web

Sunsetting The Spicy Web, and What Comes Next

I Made a Squircle Button (and of Course It’s a Web Component)

Oops I Clipped My Path

Drop Your Shadows

Creative Strategies for Surviving the AI-pocalypse

Local-first community

Side-hustle like you’ve never hustled before

Look beyond the Tech Industry

Create new industries

Join the revolution!

SolidJS is Not the Future

Bad Web Standards Are Always Better Than Good “Userland” Solutions

Teaching People How to Write Less-Good Vanilla Web Apps is More Valuable than Teaching Frameworks

Your Framework is Incompatible With My Stack

Actually, Web Components Are Components

This Entire Discussion is Pointless and Stupid

Action Web Components Which Span the Server-Client Divide

First, a Little Backstory

Actions…But Vanilla?

Example Action: Class Toggle

Astro + Alpine.js + Action Web Components = 😍

ac-yellow-fade aka the “Yellow Fade Technique”

ac-toggle-class aka Switch a class on and off

ac-portal aka Render content at the bottom of <body>

ac-scroll-to aka Scroll the viewport to an element

ac-focus aka Focus on a particular form field

ac-children aka Replace a part of the DOM with a new HTML fragment

ac-redirect-to aka Redirect to another URL after a short delay

ac-message-dialog aka An attempt at a better alert()

A Word on Progressive Enhancement

Conclusion: HTML-First Programming Works

Building Courseware I Can Understand: The Launch of CSS Nouveau

Don’t Ask Me to Take a Course

Leaning Into Your Strengths

The Birth of Intuitive+

Cool. So What’s Next?

Yeah, But is Tailwind a Cult Tho?

Shoutouts from the Fans Cult Members?

Enhance vs. Lit vs. WebC…or, How to Server-Render a Web Component

Component-Centric View Architecture and Shadow DOM

There’s Node Business Like Sh(ad)ow Business

Region 3. Move Down 5. Zoom In 300%. Enhance!

This Component is Lit. Lit AF.

WebC Lets You Render Components for the Web, See?

Enhance vs. Lit vs. WebC: Who Wins?

WebC: an Enchanting Path Forward

My Journey Away from the JAMstack

The Year Was 2015

Along Came Aerobatic Netlify

The JAMstack is Here to Solve All Our Problems (Right?)

Netlify isn’t to blame…except Netlify is to blame 😬

The Legacy of Netlify

New Projects Galore! A Blog and a Podcast

`ac-yellow-fade` aka the “Yellow Fade Technique”

`ac-toggle-class` aka Switch a class on and off

`ac-portal` aka Render content at the bottom of `<body>`

`ac-scroll-to` aka Scroll the viewport to an element

`ac-focus` aka Focus on a particular form field

`ac-children` aka Replace a part of the DOM with a new HTML fragment

`ac-redirect-to` aka Redirect to another URL after a short delay

`ac-message-dialog` aka An attempt at a better `alert()`