Creating This Website

I have wanted a personal website for a while now, but never got around to doing it. Partially, not having hosting lead to this procrastination, but it was also due to not knowing a suitable stack. The former deterrent was overcome when I was gifted a domain and some cheap web hosting for Christmas. The latter disappeared when I decided (perhaps over-zealously) to ditch server-hosted JavaScript altogether.

That does sound a little rash (which it was), so let me explain. Whilst I have dabbled in learning some front-end stacks such as Nunjucks for the MSS Website (cheers Tom Cranitch for the help) or React for the hackathon project Betcoin (cheers Carson for dealing with most of it), I have never used one from start to end on my own. I'm not against JavaScript or any other web framework, but the task of trying to find the right one for me (only to find out that its too old/too slow/doesn't have XYZ...) had always extinguished any plans of a website. As I only wanted a static website, I chose to just get started and to go without.

Arising Issues

For most of "development" (if you can call it that), I found HTML and Sass were sufficient. I had only chose to use Sass over plain CSS as I had used it yonks ago when CSS variables weren't a thing, but it turned out to be quite useful later on. As you can imagine, there were a few problems that came up due to my anti-JavaScript conviction.

The first issue came about after I noticed the amount of duplicate HTML each page had for the header. After searching templating languages for a bit, I decide upon Moustache as it felt minimal and stand-alone. A quick python build script later and it all started working together well. This would form my default problem solving strategy: preprocess. This is how I dealt with the blog posts and getting the list of projects on the homepage.

The next issue involved styling the list of projects. I had envisioned some method of filtering the projects given that I don't have a single niche. Whilst serving the client some JavaScript would be a simple (and appropriate) way of doing this, my new found confidence assured me that CSS would be fine. By using invisible checkboxes to store state (which are toggled by labels that, by default, have a clickable region extending the checkbox), I was able toggle the display of each project. This is only maintainable because of Sass. I made some functions to be able to loop through all the tags and provide some nice selectors (despite how messy it looks in the final CSS).

I had to be careful with accessibility here, as invisible checkboxes can muck up the tab-order or not be visible, but with a bit of fiddling around, I've gotten rid of all of these issues (I believe) and kept the HTML as semantical as possible.

However, this only lead to further issues when I wanted to animate the filter. Note that display cannot be animated (which make sense; it's not a value you can interpolate), so instead, I had to muck about with the opacity, visibility and width. It's still a little janky and I'll try to improve it in the future, but it somewhat works for now.

I also wanted a way to expand the projects within the project list and see more of them. This turned out easy enough without JavaScript, as the <details> and <summary> do a nice job of this already. It's still a bit of a hack but it works.

Adding Math

The final big problem was math. The web is a bit of a wild west when it comes to math. Whilst MathML is becoming the standard, for me there is not enough by browsers without relying on JavaScript (there is a wonderful CSS fix, however JavaScript is still needed to know when to apply it and I tend to use a larger range of symbols). Thus, once again, my build script got larger as I added more preprocessing.

My solution involves taking any $\TeX$ equations within a page, using $\TeX$ to process them in a standalone document class. The resulting DVI file is then passed into a program called dvisvgm to make it a nice web-friendly SVG image. That's not the end though. I modify the SVG slightly to add a title containing the $\TeX$ equation so that screen-readers can interpret the image. I also ensure that all the ids used within the SVG are unique (I had a few weird bugs because of this). I then add a 0-width <span> (which is also ARIA hidden for screen-readers) to the image containing the $\TeX$ code, so that copying and pasting the text will result in valid $\TeX$ (though highlighting within the equation will lead to nothing copied, so it is not a perfect solution). The result is equations that (hopefully) are readable and copyable.

I'm really happy with the result. Inline math like $x^3-\frac{x^2}{2}$ or $\int_0^\frac{\pi}{2}\frac{\sin^3 x}{\cos^3 x + \sin^3 x}\,dx = \frac{\pi}{4}$ is set out well. I can also have display equations like so: $$f_X(x) = \int_{-\infty}^x \frac{1}{\sqrt{2\pi}\sigma}\exp\left(\frac{-1}{2}\left(\frac{t-\mu}{\sigma}\right)^2\right)\, dt$$ It does length the build time significantly ($\TeX$ is not known for being quick), but having full $\TeX$ at my fingertips is well worth it.

Reflection

Would I avoid JavaScript if I could start again? No, though I wouldn't try to use it for everything. Using SVGs for equations has turned out really well (see above), but JavaScript is a much more appropriate tool for things like the project filters (which I may end up redoing in the end). In fact, there is still some JavaScript used (albeit only in the preprocessing stage as Sass and some CSS minifiers; no JavaScript code was written by me).

I do, however, believe that avoiding a large web framework was the right choice for this. Not only is my website incredibly light-weight (my poor web hosting sadly slowing it down), but the stack feels very much like my style. My old laptop struggled to run Node when making the React web application for Betcoin, and the satellite internet I used all through high school really struggled with all but the smallest of websites. The hacking around to get this website to function reminded me of this... and also of how useful a web framework might be.

At some point I'll learn some sort of large web framework; it'll probably be so much more productive and I'll kick myself for not doing it earlier. And seeing that I'm not a web designer, it'll probably look a lot cleaner as well. I'll probably even do this for the next website I have to make. However, right now, it still gives me a little joy that I can do it from scratch.