As I mentioned in a previous blog post this website is now on the deno
runtime and is deployed with deno-deploy
.
It's your classic server rendered application. I have some routes that receive a request and send HTML back in a response.
Some interesting things about this:
- I'm just using the standard library
serve
to listen on a port - I'm defining my routes using an array and then some generated
regex
to determine which handler the request should go to - The handlers for
/
,:year/:month/:title
and/archive
do aDeno.readTextFile
to read in an RSS file that has the generated blog posts - This RSS file is parsed and sent to the template, something awesome about
deno
is that it has support for.tsx
templating, this is where I'm most comfortable at organising my frontend components and I also get nice type errors if the props are wrong - After the
.tsx
template server renders I get a standardResponse
object that I send back to the client,deno
supports the web fetch API response which is really neat - I'm using
unoCSS
for styling, it's basically the same asTailwind
but it's setup is super simple
Doing some benchmarking compared to my old create-react-app
site is also really interesting.
The biggest *.chunk.js
file with my old site was 295kb.
Now my site is server rendered I have basically no JS being loaded on the client (except for highlight.js
). The size of the document in the response is 11.8kb which I think represents the actual size of the HTML sent.
The biggest wins for me is that I really understand what is being sent back in each response. There's no weird *.chunk.js
file. It's just simple Request -> Response
and simplicity is what I love when making websites.
I now also get correct metadata moving away from being fully client rendered. This to me was super annoying when sending a link of a blog post over Slack or Messages as you wouldn't see a useful title or description.