I must admit, I haven’t exactly been maintaining this website all too frequently as I’d hoped (and as some of my friends at university constantly remind me about, they know who they are 😉), but I’ve been busy getting stuck in my second year of my bachelor’s degree.
For those of you who haven’t seen the GitHub repository, this site uses a powerful static site generator called Hugo, which is automatically synchronised to Netlify whenever I push a commit to that repository. Hugo has gained a lot of attention recently1 as being almost the de-facto static site generator when you aren’t invested in a user interface framework like React or Vue. When I started using this Hugo and Netlify combination, I had used a Netlify template to get going. That boilerplate project used Node.js and grunt to manage a pipeline for Babel to transpile, build and minify JavaScript modules as well as provide Sass style preprocessor integration, but I decided to reset and build a fresh new Hugo-only project and avoid using JavaScript as much as possible.
I was convinved to strip as much JavaScript out as possible after a long-time good friend of mine was discussing enabling the popular NoScript browser extension to disable JavaScript whilst browsing to save battery life and improve performance when using his aging ThinkPad T400 powered by a Core 2 Duo (Penryn? microarchitecture). Those C2D machines are certainly not slouches, and this brings home a rather prevalent issue within the web development community of dependency on multiple third-party JavaScript libraries for simple websites. I’ve also personally experienced problems when using Safari on my iPhone, where disabling JavaScript gave a significant improvement in web browsing experience, but many sites would simply break, leaving it untenable for me, someone who spends most of my time researching and browsing around websites.
Don’t get me wrong, I see the benefit that these frameworks provide and I think they really are pretty cool. We used Angular 8 for our group software project this year. It allowed us to decouple individual components of our application like we never would have dreamed of doing without it. It enforced a clear and practical seperation of responsibilities which might have slipped without it. And it allowed us to use rx-js with Firebase to create an immediate, reactive, cloud-oriented application with no server-side code whatsoever, bar the complex database access rules required to restrict individual users from modifying parts of the database that they shouldn’t. This was all really impressive. But, that was a fully-fledged, mobile-first application, using location services to track the player’s location around campus and the device’s rear camera for QR code scanning, not blogs. It seems like requiring JavaScript and client-side rendering for your blog might be a bit overkill.
In addition to this, I’ve long been a fan of Inferno.js, a React replacement which gives you almost all of the bells and whilstles of React but without the performance penalty, which the framework’s lead discusses in the most important reasons for the project’s inception in his Medium post. Recently, however, I’ve discovered Svelte, which, albeit not as fast as Inferno in benchmarks, I’m rather fond of too. It moves most of the work off the browser and in to the build. But what’s even cooler about Svelte, is what’s coming next for it, in the form of Sapper, which combines the web framework with a smart server-side framework built atop Express (or in the instance of Sapper, a drop-in replacement, called Polka), which allows pre-rendering on the server, and is SEO-friendly.
Anyway, I’m hoping to have some stuff on my website in the coming few weeks, so stay tuned. Some of it might still require JavaScript…