Ahead of the Small is Beautiful livestream this evening, I thought I’d share what I’ve been working on recently in text too.
Site.js starter theme
For the last (checks repository) nine months, I’ve been working on a Hugo starter theme for Site.js. As we were using Hugo, a static site generator, for our own sites, and Hugo was available as a binary, Aral decided it made sense to include Hugo in Site.js. The idea was that we make it as easy as possible for developers, and people with a little development experience, to get a basic blog or website up and running with Hugo and Site.js. The starter theme is my attempt to create a theme that has everything you need for an easily-maintainable website with accessible, rights-respecting defaults.
Pretty good defaults
The theme has quite a few elements of the theme that please me:
- Accessible default templates making it easy to author accessible content.
- Vanilla CSS for easy-to-read typography and using flexbox and grid for simple progressively-enhanced responsive layouts.
- Responsive images generated using Hugo, including srcset images, and thumbnail images generated for social media.
- Multiple colour scheme options, including dark modes, with accessible colour contrasts.
- Favicons generated using Hugo, matching the chosen colour scheme.
- A simple-as-possible (especially for Hugo!) six step process for getting a site running locally with Site.js.
- Privacy page
- RSS Feed
Ambition pared back
The current version of the theme is not quite production-ready, but still has a lot of useful bits and pieces if you’re a developer working with Hugo. Ambitiously, we originally aimed to have the theme fit flexibly for a photoblog, standard blog, and simple few-pages website. This led to a lot of different configuration options which I tested across a few different demo sites. Below is a couple of examples of them:
As with all things Small Tech, our aim is to create things that we first use ourselves. That way we very quickly realise if something isn’t working, and we’re not making assumptions about the people who use what we build.
Towards the end of 2020, we came to three realisations:
- Site.js, now a mature project, worked fine with Hugo, but didn’t need Hugo when it was forked into Place.
- While my sites has a photoblog section, neither of us currently have a photoblog, and so the scope of the starter theme was moving further away from our specific needs.
- Having a theme that accommodated so many different requirements added too many configuration options which raised the barrier to entry for anyone trying to understand the theme.
I was divided. Do I completely ditch the starter theme, pulling what I’ve learned into the custom Hugo themes we’ve created for our other sites? Or do I rework the theme, pare back the ambition, into something we can build all our sites upon, and hopefully be more useful for other developers too?
At first I dabbled a little with the former approach. I had learned loads about Hugo in the process, it hadn’t been wasted time and effort. But then I realised that my own site sorely needed the update. The Small Tech site could do with it as well. A website is fairly easy to maintain if you’re never updating the content, or even if updating the content is your full-time job. But if you don’t have much time to update your website, or multiple websites, the maintenance has to be really easy. You should need to re-learn a content management system, add a bunch of new CSS, or write HTML in your markdown every time you want to share a new blog post.
So my 2021 starter theme strategy was born: strip out any excessive configuration, make the theme easy to use, and make it a joy to update my own website again. I’m less than a week in and it’s going well. You’ll know if my new strategy has worked when my site gets updated again!
Last year, on top of all the other things, I still managed to get a few blocking rule updates out for Better Blocker. Honestly, Better Blocker doesn’t make us a load of money, and we’re running a not-for-profit organisation, so I try to be very efficient with my updates. (And close my ears to people who don’t believe an app is worth a onetime payment of €2 unless it has frequent arbitrary updates!)
Over time, the updates to the blocking rules are fairly repetitive. Not much has changed in the tracking landscape in the nearly-five years that Better Blocker has existed. Every update I find a few more prolific trackers to block, I block a couple more blocker blockers, and I tend to revisit the same German tabloid websites with the most determined anti-blocking strategies.
The absolute state of web development nowadays means I’m seeing more sites break more spectacularly in the face of tracker blocking. The tech industry seems to be increasingly indiscriminate in relying on third-party solutions for large chunks of their functionality. Did you notice how many non-Google sites fell over when Google went down at the end of last year? I see that happen a lot with tracker blocking. Logins broken, checkouts broken, even links broken. CSS and even basic HTML content blocked from loading. No progressive enhancement anywhere. Fragile websites built entirely reliantly on other people’s platforms.
Every time I get cranky about development on social media, it’s usually because I’ve been trying to fix sites that break when visited with Better Blocker. I do a lot of work because of other people’s poor development practices, the venting helps a little. Takes deep breath.
We’ve also enrolled in Apple’s new Small Business programme, which essentially means we’ll see a little bit more money from app sales in the future. It’s something, but our involvement with Apple as a platform is plagued with irritations, and not a long-term investment, so I won’t go on about it here!