Bejofo Blog – How I Made My Online Game Work Without JavaScript and Why You Probably Shouldn’t

function enhanceCB({ formData, cancel }) {
  let move = formData.get('move')
  makeMove(move) // Sends move via websocket
  cancel() // Prevents the default POST request
}

...
form action="?/makeMove" use:enhance={enhanceCB}>

Realtime updates (sort of)

So far so good, but how the heck can I replace the live updates that are provided by the websocket? This is impossible, right? Well, no, it turns out we can use the auto-refresh meta-tag for this: . It simply tells the browser to refresh the whole website after a predetermined number of seconds. This feature has been used by live-ticker websites for ages. This of course means there can be a relatively long delay before you can see your opponents move. But for a board game this is sufficient, in my opinion.

Animations

In theory, I could try to replace the JavaScript-powered animations with pure CSS animations, but I decided that’s not worth it for me. Also, I’m not sure how smooth a full page refresh followed by a bunch of CSS animations would look. Still, even if I only animate things for JavaScript users, I need to ensure animations always transition to the final state that the server has already rendered in the HTML. Otherwise, if JavaScript animates from an old state to a new one, a user without JavaScript will be stuck seeing the old state forever.

What I Learned

Okay so what do I take away from all of this? What are the benefits and drawbacks? Why should you or should you not implement this for your website?

Pros:

• The main benefit of a setup that is capable of both server side rendering and client side rendering is the much faster initial page load. We send a complete HTML document to the client that is ready to be displayed. This means no JavaScript needs to be executed and no additional network requests are required before the page is visible to the user. After that, the page is made interactive (“hydrated”) and efficient client side rendering can take over for subsequent navigation events. Using something like SvelteKit can be worth it just for this performance upgrade.
• The whole procedure made my site more resilient: When all state is stored either in a cookie, in the URL or on the server, no state can be lost in case of a crash or if the browser tab is unloaded from memory. This can be especially useful on ressource constrained devices like phones.
• The site has become more usable for JavaScript users: Initially, I did not bother to change the navigation history when the login modal was opened. But since that is required for the JavaScript-free functionality, it is now possible to close the modal by navigating back. The change also enabled me to link directly to the login form, which wasn’t possible before.
• And last but not least, my HTML has become more semantically correct, by using Elements for changing requests and

  elements for dropdown menus. I don’t know if that really improves anything in practice, but it gives me that warm, semantically correct feeling.