Skip to content

Instantly share code, notes, and snippets.

Last active May 1, 2024 17:36
Show Gist options
  • Save Widdershin/98fd4f0e416e8eb2906d11fd1da62984 to your computer and use it in GitHub Desktop.
Save Widdershin/98fd4f0e416e8eb2906d11fd1da62984 to your computer and use it in GitHub Desktop.
The absurd complexity of server-side rendering

In the olden days, HTML was prepared by the server, and JavaScript was little more than a garnish, considered by some to have a soapy taste.

After a fashion, it was decided that sometimes our HTML is best rendered by JavaScript, running in a user's browser. While some would decry this new-found intimacy, the age of interactivity had begun.

But all was not right in the world. Somewhere along the way, we had slipped. Our pages went uncrawled by Bing, time to first meaningful paint grew faster than npm, and it became clear: something must be done.

And so it was decided that the applications first forged for the browser would also run on the server. We would render our HTML using the same logic on the server and the browser, and reap the advantages of both worlds. In a confusing series of events a name for this approach was agreed upon: Server-side rendering. What could go wrong?

In dark rooms, in hushed tones, we speak of colours. We joke of nulls, commiserate about queues, but of colours we only whisper.

That is because colours can hurt you. We shield our juniors from this knowledge, not because it's the wise thing to do, because once you confront the abyss there's no turning back.

The common colours are no secret. Is a function synchronous or asynchronous? Does it mutate the arguments provided, or meekly return a value? Do I need to worry about it throwing an exception?

In a certain light, colours are merely a way to categorise certain types of functions. Functions of a like colour can be used together without much consideration.

It doesn't take much examination to see that colours beget complexity. Much of the art of application-level architecture is appropriately reducing and grouping colours to oppose this complexity.

In the olden days, we had few colours to worry about. The task of managing incoming connections was abstracted to a simple mapping of request to response.

All functions blocked execution for a while. Some would talk to databases or queues, and we were either content to wait, or to fire and forget while we returned the response.

It's different in the browser. Our code competes with the user's ability to interact, and therefore we must be careful. We embrace asynchronous code, and with it all the complexity that comes from another colour.

Server-side rendering (SSR) poses yet another problem on top of this one. Some functions were not designed to be used in both Node and the browser, and so we find another colour lurking.

In order to support applications that make use of both server coloured functions and client coloured functions, bundlers were built, as clever as they are obtuse.

Say you want to read a file as part of a request. This is only allowed in certain functions, designated by the framework to be server-coloured.

You cannot use a server-coloured function at the top level, since that implies it should be included in your browser, and you cannot use a client-coloured function with the framework's server-coloured functions.

Next.js describes this approach as "smart bundling". This may be smart, but it is not wise.

It's hard enough to ensure that you're only using the correctly coloured function in the right place, until you consider that one of the main advantages of this sort of framework is sharing code across the server and the client.

It's entirely up to you to ensure that you correctly manage your function colours. If you accidentally use the wrong sort of function in your shared code, your application will not work.

If you're lucky, the bundler will catch this and throw a seemingly unrelated error. More likely, you'll experience a cryptic runtime error, followed by days of agony if you don't understand this problem. There is very little available in the way of static analysis to make this easier.

To me, this seems like a very bad idea. What's worse, this important colour is generally treated as a footnote by the creators of these frameworks. Most developers only realise how bad this problem is when it's too late.

I don't think that SSR apps are fundamentally a bad idea. That said, the way we're going about it right now is terrifyingly complex and error-prone.

If you're considering using one of these frameworks, I would recommend you carefully consider if the complexity is worth it, especially for less-experienced members of your team.

For those who do pursue SSR, I advise you to work towards better static analysis to help manage these problems. Rust has built a career by explicitly recognising that lifetimes exist and that we need better tools to work with them. A similar opportunity exists here for SSR apps.

Copy link

its just serving html files mate its not that deep

Copy link

karlhorky commented Apr 27, 2022

@shuding another example of things that could be focused on a bit more are edge cases for imports and bundling for server-side rendering.

Eg. this issue that I just found with using a file with shared server + client exports in Next.js - this causes bundling of the (unused) server code, leading to the dreaded Can't resolve 'fs'. This seems like a bug to me:


Going even a bit further with this, there could be more work done to guide developers into the "pit of success" - more heuristics and development-time messaging to teach them how to do server-side rendering properly, by only accessing client or server variables.

Copy link

valdas commented Oct 21, 2022

All those javascript frameworks first create problem then tries to solve claiming they are speedy... OMG
Side note for maintainer of next.js - stop using latest-very-best javascript syntax like ,? .? or the like. Not everyone can upgrade to 200 version of browsers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment