Monday, June 5, 2023

Blog Tech

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:

  1. I'm just using the standard library serve to listen on a port
  2. I'm defining my routes using an array and then some generated regex to determine which handler the request should go to
  3. The handlers for /, :year/:month/:title and /archive do a Deno.readTextFile to read in an RSS file that has the generated blog posts
  4. 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
  5. After the .tsx template server renders I get a standard Response object that I send back to the client, deno supports the web fetch API response which is really neat
  6. I'm using unoCSS for styling, it's basically the same as Tailwind 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.