Website Devlog: November 1, 2023
My website is in continual development flux. I thought I’d provide a bit of an overview of how it’s built as of the first day of November in 2023.
Priorities
Some priorities as I build:
- Use the Web platform.
- Try to build in a runtime-agnostic way.
- Going live should be fast and should not be easily blocked.
- Being able to blog on a whim should never be blocked.
- Avoid dependencies.
- It only needs to be maintainable for me.
- If you can’t do it right, don’t do it at all.
- Do the minimum correctly rather than the maximum incorrectly.
- Try to write some tests.
Technologies
Some core technologies I’m using:
- Deno as the JavaScript runtime.
- Using a capable runtime that focuses heavily on standards is important. No, I’m not using TypeScript.
- Deno Deploy is how I’m sharing this website with the world.
- With this being a one-person endeavour with not a tonne of risk, I don’t need many steps between the code in my editor and my live website. Deno Deploy’s “no-build” deploys are fast and support this workflow.
- Hono is its backend web framework.
- Initially, I was stubbornly rolling my own sort of web framework that was largely inspired by Sift, using Deno’s web server APIs directly, Web standard
Request
andResponse
, andURLPattern
for routing. It was fun and learned a lot, but over time I found myself distracted by improving the capabilities of said framework. I also wanted something to easily employ middleware. Hono is simply and works with various runtimes.
- Initially, I was stubbornly rolling my own sort of web framework that was largely inspired by Sift, using Deno’s web server APIs directly, Web standard
- Pug.js is the templating language.
- Vanilla HTML is great, but when it comes to dynamic content, especially with attributes a lot of templating solutions are just not pleasant. I wanted a templating syntax that is designed for HTML, but also doesn’t try to be HTML (e.g. JSX). Pug does this very well. My only gripe with it is that the JS which it supports is missing some modern features (e.g. the null-coalescing operator, etc.). Pray that I don’t get distracted trying to write my own templating language in Rust.
Styling
I’m taking a very exploratory and scaled-down approach to styling.
- Avoid introducing a build step as much as possible.
- Only ship the CSS that the page needs.
- Figure out how to leverage layers (i.e.
@layer
). I think layers can be a key for reducing how much CSS is shipped. - Don’t solve problems before they need to be.
Right now all I have is a “main” stylesheet which includes only the styles for the “public” template of the site. Then any page specific styles are just included in a <style>
element within the <head>
. The source of these route specific styles are actually in their own co-located stylesheets. Pug makes it pretty easy to do this:
append head
style: include route.css
Currently, the design is quite limited. I’ve intentionally put off fleshing out a complete colour scheme.
Closing thoughts
Overall, I hope my approach preserves a space for my desire to experiment and explore, while helping me actually create tangible progress. I have a lot that I’d like to accomplish with this website. Much of that won’t actually be publicly accessible, since the most complex thing I’m building is my own personal CMS. We’ll see how it goes, but so far, even though it’s been a slow process building, this has been the most enjoyable personal website project and the one I have the most hope for.