The license

This website has its source code publicly available. The source code has been published under a modified version of the very popular MIT license.

What are the modifications?

I chose to modify the MIT license in order to add protection for anyone mentioned in the website. Any published, redistributed, sublicensed, or sold copies of the source code or website must remove any information about any person mentioned on the website.

If you have any questions about the license, feel free to contact me at license@intherain.cloud.

The stack

Given the year is 2024, the construction of this website is probably considered "weird" by most standards. As such, I thought it might be worth while sharing some of the reasons behind why I chose to build it this way.

This website can reasonably be thought of as the modern version of an old HTML/CSS/JavaScript website. This website is able to be run on a static file server. That said, there are downsides to writing pure HTML, CSS, and JavaScript. As such, I've opted to use some alternatives that can be compiled into their web-friendly alternatives.

Why not a modern framework?

Modern web frameworks are wonderful things which can be used to build websites that if done well are performant and charming to use. I very much enjoy working with Svelte and React. However, I have two key requirements for this website's tech stack.

Firstly, it should require very little maintenance. When your website has run time dependencies, you need to be able to account for each one and keep up to date with any upgrades or security patches. In general, frameworks of any kind have large trees of sub-dependencies which means that the frequency of package bumps also needs to be higher.

Secondly, I want to be able to embed other projects into my website somewhat like a micro-frontend architecture. This means that I need to have lots of control over the assets on each page. I don't want to end up bloating every page on the website by introducing some widget or tool on another page. Some frameworks like Next.JS have started implementing code splitting which helps alleviate the problem, but its still not a perfect science. Furthermore, it is often times harder to embed other arbitrary code in a page, as the widget may not play well with the framework's dom diffing and rendering lifecycle.

The tech I chose to power the site

Templating: EJS

HTML is a wonderful markup language which is incredibly expressive, allowing the user to encode a large amount of semantic meaning as well as providing helpful information to screen readers. I didn't want to move to a less expressive markup language like markdown or MDX as its much less flexible and in the case of MDX, is often best suited to have some form of frontend framework for rendering components. This left me in the land of HTML templating languages. When picking one of these, my primary goal was to find something that I could use with minimal setup and for it to have little or no awareness of the HTML syntax. If I was building my assets with ruby, my first choice would have been ERB, but having chosen to use JavaScript as the language to script my asset compilation, that would have been more complicated. I ended up going for EJS, which uses a syntax that is very similar to ERB, has built in support for including other .ejs fragments, and has an easy to use API.

Styling: SCSS

Writing pure CSS is becoming more and more compelling by the day. Especially with nested styles now being supported by all major browsers. That said, complete support is still very much not complete. There are also nice things like macros, compile time variables, extends, and modules that don't yet exist in modern CSS. In a year's time, I very well may end up using regular CSS, but at the minute, in my mind its still just not quite there.

Scripting: TypeScript

Its JavaScript, but with types! What more could you want? Well, PureScript is pretty attractive, but I would be concerned about being able to include impure libraries. I'm also very familiar with TypeScript, and am aware of many of the foot-guns which it provides. TypeScript is also easy to set up in a very simple manner, making it easy to use without a fancy build tool.

Build tools?

There are lots of bundlers and build tools out there, with vite being a very attractive tool, but I wanted to manually orchestrate my build process, giving me much more control, and meaning I'm not bound by any limitations a particular one might provide.

My setup firstly runs a small build.js script that I wrote, which orchestrates the template rendering and SCSS compilation. I then call tsc which takes care of the TypeScript code.