https://gist.github.com/Widdershin/98fd4f0e416e8eb2906d11fd1da62984

Skip to content
 
[                    ]
All gists Back to GitHub Sign in Sign up
 
Sign in Sign up
{{ message }}

Instantly share code, notes, and snippets.

@Widdershin

Widdershin/ssr.md

Last active Apr 19, 2022

  * Star 7
  * Fork 1

Star
Code Revisions 2 Stars 7 Forks 1
Embed
What would you like to do?
">Embed Embed this gist in your website.
Share Copy sharable link for this gist.
Clone via HTTPS Clone with Git or checkout with SVN using the
repository's web address.
 
Learn more about clone URLs
[<script src="https:/]
 
Download ZIP
The absurd complexity of server-side rendering
Raw
ssr.md

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.

@oshox
Copy link

oshox commented Apr 19, 2022

I'm a novice, but I've been following the new generation of SSR apps
to address some of your issues:

First, ECMA Script Modules (es modules)can be run in all modern
browsers and Node14+. While libraries written in the old format will
not usually import correctly, library maintainers are acknowledging
the other benefits of es modules and converting.

Second, SSR does not mean that your whole app is written in JS/TS.
The Server in SSR can fetch data from APIs written in Rust or
whatever, which is more secure and performant than letting the
browser do it.

Third, rendering in a separate app on the server (a la PHP) adds its
own complexity. You will have to learn twice as many framework to
support both sides of the app, and possibly a third to handle
interoperability between them.

Sorry, something went wrong.

@rauchg
Copy link

rauchg commented Apr 19, 2022

Hey @oshox - one of the designers of Next.js here. We've also
identified the issue you've run into, and we're introducing [?] a
filesystem convention (.server.ts) for more cleanly separating client
and server component trees, as well as focusing the rendering layer
on a [?] Web standards runtime. This makes bundling and DX a breeze,
in my opinion.

This work is ongoing and looking really promising already. SSR is
getting easier, faster, cheaper, and edgier than ever 

Sorry, something went wrong.

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

  *  (c) 2022 GitHub, Inc.

  * Terms
  * Privacy
  * Security
  * Status
  * Docs
  * Contact GitHub
  * Pricing
  * API
  * Training
  * Blog
  * About

You can't perform that action at this time.
You signed in with another tab or window. Reload to refresh your
session. You signed out in another tab or window. Reload to refresh
your session.