Interactivity without JavaScript

Bejofo reworks their JavaScript game to run without JavaScript, which is an interesting experiment — and reinforces my biggest concern about modern web development hosting infrastructure.

Bejofo has an interesting article about making their JavaScript game playable without JavaScript using a mix of server-side rendering, native HTML controls, and some super-old-school forced page reloading. It is an interesting exercise of dubious value, much like my (silly, broken) vanilla webstack zombie game.

The effort involved here is not entirely without value; they were forced to turn everything interactive into an actual interactive form element, which has got to be good for accessibility. They also say they managed dropdown menus using the details /summary elements. This is interesting, but I suspect doing so violates the expectations of keyboard users on how menus are supposed to behave.

Some of the areas he thought were particularly difficult, like dialogs and animations, would probably be doable with a bit more time / expertise. Dialog boxes in particular require no JavaScript at all in certain circumstances. But I still feel like this is mostly an exercise. Some things are just better with JavaScript.

Here’s another thing that struck me. They say:

All that server side rendering uses resources on the… server side. Especially if the page is fully refreshed in regular intervals like it is when the auto-refresh meta-tag is active. This leads to increased server resource usage.

This is not a trivial concern. I’ve spent the last five years or so almost exclusively on the front end. Much longer if you are only counting my personal projects. It’s been a seriously long time since I hand-tooled PHP on a server. Adding comments to this blog turned out to be a lot more confusing and complex than I expected once I got server-side stuff involved. Not because “doing things on the server” is hard, you understand. But because AWS has popularized having fragmented, metered compute resources with cute, barely-descriptive names.

Faced with this (and the conceptual complexities around hydrating SSR content, which are significant), the temptation to short-circuit all of that fuss and just render everything in the browser is pretty dang strong. I’ve been pretty baffled by why so many developers seem OK with buying “tokens” for LLM use and absorbing the unpredictable pricing, but I am beginning to understand that this is just how things are billed now. Somehow, in 2025, we have settled on the billing structure of 1960s mainframe computing.