You can still have a home. A place to hang up your jacket, or park your shoes. A place where you can breathe out. A place where you can hear yourself think critically. A place you might share with loved ones who you can give to, and receive from.
Now, more than ever, it’s critical to own your data. Really own it. Like, on your hard drive and hosted on your website.
Is taking control of your content less convenient? Yeah–of course. That’s how we got in this mess to begin with. It can be a downright pain in the ass. But it’s your pain in the ass. And that’s the point.
Working on this project is great but ten minutes into it and I already miss the resilience of the web. I miss how you have to really fuck things up to make a browser yell at you or implode.
Heydon’s latest video is particularly good:
All of my videos are black and white, but especially this one.
I’ve been tagged in a good ol’-fashioned memetic chain letter, first by Jon and then by Luke. Only by answering these questions can my soul find peace…
Why did you start blogging in the first place?
All the cool kids were doing it. I distinctly remember thinking it was far too late to start blogging. Clearly I had missed the boat. That was in the year 2001.
So if you’re ever thinking of starting something but you think it might be too late …it isn’t.
Back then, I wrote:
I’ll try and post fairly regularly but I don’t want to make any promises I can’t keep.
I’m glad I didn’t commit myself but I’m also glad that I’m still posting 24 years later.
What platform are you using to manage your blog and why did you choose it? Have you blogged on other platforms before?
I use my own hand-cobbled mix of PHP and MySQL. Before that I had my own hand-cobbled mix of PHP and static XML files.
On the one hand, I wouldn’t recommend anybody to do what I’ve done. Just use an off-the-shelf content management system and start publishing.
On the other hand, the code is still working fine decades later (with the occasional tweak) and the control freak in me likes knowing what every single line of code is doing.
It’s very bare-bones though.
How do you write your posts? For example, in a local editing tool, or in a panel/dashboard that’s part of your blog?
I usually open a Mardown text editor and write in that. I use the Mac app Focused which was made by Realmac software. I don’t think you can even get hold of it these days, but it does the job for me. Any Markdown text editor would do though.
Then I copy what I’ve written and paste it into the textarea of my hand-cobbled CMS. It’s pretty rare for me to write directly into that textarea.
When do you feel most inspired to write?
When I’m supposed to be doing something else.
Blogging is the greatest procrastination tool there is. You’re skiving off doing the thing you should be doing, but then when you’ve published the blog post, you’ve actually done something constructive so you don’t feel too bad about avoiding that thing you were supposed to be doing.
Sometimes it takes me a while to get around to posting something. I find myself blogging out loud to my friends, which is a sure sign that I need to sit down and bash out that blog post.
When there’s something I’m itching to write about but I haven’t ’round to it yet, it feels a bit like being constipated. Then, when I finally do publish that blog post, it feels like having a very satisfying bowel movement.
No doubt it reads like that too.
Do you publish immediately after writing, or do you let it simmer a bit as a draft?
I publish immediately. I’ve never kept drafts. Usually I don’t even save theMarkdown file while I’m writing—I open up the text editor, write the words, copy them, paste them into that textarea and publish it. Often it takes me longer to think of a title than it takes to write the actual post.
I try to remind myself to read it through once to catch any typos, but sometimes I don’t even do that. And you know what? That’s okay. It’s the web. I can go back and edit it at any time. Besides, if I miss a typo, someone else will catch it and let me know.
Speaking for myself, putting something into a draft (or even just putting it on a to-do list) is a guarantee that it’ll never get published. So I just write and publish. It works for me, though I totally understand that it’s not for everyone.
What’s your favourite post on your blog?
I’ve got a little section of “recommended reading” in the sidebar of my journal:
But I’m not sure I could pick just one.
I’m very proud of the time I wrote 100 posts in 100 days and each post was exactly 100 words long. That might be my favourite tag.
Any future plans for your blog? Maybe a redesign, a move to another platform, or adding a new feature?
I like making little incremental changes. Usually this happens at Indie Web Camps. I add some little feature or tweak.
I definitely won’t be redesigning. But I might add another “skin” or two. I’ve got one of those theme-switcher things, y’see. It was like a little CSS Zen Garden before that existed. I quite like having redesigns that are cumulative instead of destructive.
Next?
You. Yes, you.
Some interesting experiments in web typography here.
Many interactions are not possible without JavaScript, but that doesn’t mean we should look to write more than we have to. The server doing something useful is a requirement for building an interesting business. The client doing something is often a nice-to-have.
There’s also this:
It’s really fast
One of the arguments for a SPA is that it provides a more reactive customer experience. I think that’s mostly debunked at this point, due to the performance creep and complexity that comes in with a more complicated client-server relationship.
This is a great idea that I’m going to file away for later:
I like the idea of redirecting
/nowto the latest post tagged asnowso one could see the latest version of what I’m doing now.
I have to agree with John here:
There’s absolutely no reason the mobile web experience shouldn’t be fast, reliable, well-designed, and keep you logged in. If one of the two should suck, it should be the app that sucks and the website that works well. You shouldn’t be expected to carry around a bundle of software from your utility company in your pocket. But it’s the other way around.
There’s absolutely no technical reason why it should be this way around. This is a cultural problem with “modern front-end web development”.
Back in 2019 I had the amazing experience of going to CERN and being part of a team building an emulator of the first ever browser.
Remy was on the team too. He did the heavy lifting of actually making the thing work—quite an achievement in just five days!
Coming into this, I thought it was hugely ambitious to try to not only recreate the experience of using the first ever web browser (called WorldWideWeb, later Nexus), but to also try to document the historical context of the time. Now that it’s all done, I’m somewhat astounded that we managed to achieve both.
Remy and I were both keen to talk about the work, which is why we did a joint talk at Fronteers in Amsterdam that year. We’re both quite sceptical of talks given by duos; people think it means it’ll be half the work, when actually it’s twice the work. In the end we come up with a structure for the talk that we both liked:
Now, we could’ve just done everything chronologically, but that would mean I’d do the first half of the talk and Remy would do the second half. That didn’t appeal. And it sounded kind of boring. So then we come up with the idea of interweaving the two timelines.
That worked remarkably well.
You can watch the video of that talk in Amsterdam. You can also read the transcript.
After putting so much work into the talk, we were keen to give it again somewhere. We had the chance to do that in Nottingham in early March 2020. (cue ominous foreboding)
The folks from local Brighton meetup Async had also asked if we wanted to give the talk. We were booked in for May 2020. (ominous foreboding intensifies)
We all know what happened next. The Situation. Lockdown. No conferences. No meetups.
But technically the talk wasn’t cancelled. It was just postponed. And postponed. And postponed. Before you know it, five years have passed.
Part of the problem was that Async is usually on the first Thursday of the month and that’s when I host an Irish music session in Hove. I can’t miss that!
But finally the stars aligned and last week Remy and I finally did the Async talk. You can watch a video of it.
I really enjoyed giving the talk and the discussion that followed. There was a good buzz.
It also made me appreciate the work that we put into stucturing the talk. We’ve only given it a few times but with a five year gap between presentations, I can confidentally say that’s it’s a timeless topic.
Here’s a handy free tool from Calibre that’ll give your website a performance assessment.
This is a great history of the idea of progressive enhancement:
It is an idea that has been lasting and enduring for two decades, and will continue.
When haters deny HTML’s status as a programming language, they’re showing they don’t understand what a language really is. Language is not instructing an interlocutor what to do in a way that leaves no room for other interpretations; it is better and richer than that. Like human language, HTML is conversational. It is remarkably adept at adapting to context. It can take a different shape on any machine, from a desktop browser or an e-reader screen to a mobile app or a screen reader for the blind (so long as that device is built to present hypertext).
Hell, yeah!
Ultimately, even as HTML has become the province of professionals, it cannot be gatekept. This is what makes so many programmers so anxious about the web, and sometimes pathetically desperate to maintain the all-too-real walls they’ve erected between software engineers and web developers.
Hell, yeeeeaaaaahhh!!!
What other programmers might say dismissively is something HTML lovers embrace: Anyone can do it. Whether we’re using complex frameworks or very simple tools, HTML’s promise is that we can build, make, code, and do anything we want.
Remember when every company rushed to make an app? Airlines, restaurants, even your local coffee shop. Back then, it made some sense. Browsers weren’t as powerful, and apps had unique features like notifications and offline access. But fast-forward to today, and browsers can do all that. Yet businesses still push native apps as if it’s 2010, and we’re left downloading apps for things that should just work on the web.
This is all factually correct, but alas as Cory Doctorow points out, you can’t install an ad-blocker in a native app. To you and me, that’s a bug. To short-sighted businesses, it’s a feature.
(When I say “ad-blocker”, I mean “tracking-blocker”.)
People spent a lot of time and energy in 2024 talking about (and on) other people’s websites. Twitter. Bluesky. Mastodon. Even LinkedIn.
I observed it all with the dispassionate perspective of Dr. Manhattan on Mars. While I’m happy to see more people abondoning the cesspool that is Twitter, I’m not all that invested in either Mastodon or Bluesky. Or any other website, for that matter. I’m glad they’re there, but if they disappeared tomorrow, I’d carry on posting here on my own site.
I posted to my website over 850 times in 2024.
I shared over 350 links.
I posted over 400 notes.
I published just one article.
And I wrote almost 100 blog posts here in my journal this year.
Here are some cherry-picked highlights:
The Session has been online for over 20 years. When you maintain a site for that long, you don’t want to be relying on third parties—it’s only a matter of time until they’re no longer around.
Some third party APIs are unavoidable. The Session has maps for sessions and other events. When people add a new entry, they provide the address but then I need to get the latitude and longitude. So I have to use a third-party geocoding API.
My code is like a lesson in paranoia: I’ve built in the option to switch between multiple geocoding providers. When one of them inevitably starts enshittifying their service, I can quickly move on to another. It’s like having a “go bag” for geocoding.
Things are better on the client side. I’m using other people’s JavaScript libraries—like the brilliant abcjs—but at least I can self-host them.
I’m using Leaflet for embedding maps. It’s a great little library built on top of Open Street Map data.
A little while back I linked to a new project called OpenFreeMap. It’s a mapping provider where you even have the option of hosting the tiles yourself!
For now, I’m not self-hosting my map tiles (yet!), but I did want to switch to OpenFreeMap’s tiles. They’re vector-based rather than bitmap, so they’re lovely and crisp.
But there’s an issue.
I can use OpenFreeMap with Leaflet, but to do that I also have to use the MapLibre GL library. But whereas Leaflet is 148K of JavaScript, MapLibre GL is 800K! Yowzers!
That’s mahoosive by the standards of The Session’s performance budget. I’m not sure the loveliness of the vector maps is worth increasing the JavaScript payload by so much.
But this doesn’t have to be an either/or decision. I can use progressive enhancement to get the best of both worlds.
If you land straight on a map page on The Session for the first time, you’ll get the old-fashioned bitmap map tiles. There’s no MapLibre code.
But if you browse around The Session and then arrive on a map page, you’ll get the lovely vector maps.
Here’s what’s happening…
The maps are embedded using an HTML web component called embed-map. The fallback is a static image between the opening and closing tags. The web component then loads up Leaflet.
Here’s where the enhancement comes in. When the web component is initiated (in its connectedCallback method), it uses the Cache API to see if MapLibre has been stored in a cache. If it has, it loads that library:
caches.match('/path/to/maplibre-gl.js')
.then( responseFromCache => {
if (responseFromCache) {
// load maplibre-gl.js
}
});
Then when it comes to drawing the map, I can check for the existence of the maplibreGL object. If it exists, I can use OpenFreeMap tiles. Otherwise I use the old Leaflet tiles.
But how does the MapLibre library end up in a cache? That’s thanks to the service worker script.
During the service worker’s install event, I give it a list of static files to cache: CSS, JavaScript, and so on. That includes third-party libraries like abcjs, Leaflet, and now MapLibre GL.
Crucially this caching happens off the main thread. It happens in the background and it won’t slow down the loading of whatever page is currently being displayed.
That’s it. If the service worker installation works as planned, you’ll get the nice new vector maps. If anything goes wrong, you’ll get the older version.
By the way, it’s always a good idea to use a service worker and the Cache API to store your JavaScript files. As you know, JavaScript is unduly expensive to performance; not only does the JavaScript file have to be downloaded, it then has to be parsed and compiled. But JavaScript stored in a cache during a service worker’s install event is already parsed and compiled.
I hold this truth to be self-evident: the larger the abstraction layer a web developer uses on top of web standards, the shorter the shelf life of their codebase becomes, and the more they will feel the churn.
So what are the advantages of the Custom Elements API if you’re not going to use the Shadow DOM alongside it?
- Obvious Markup
- Instantiation is More Consistent
- They’re Progressive Enhancement Friendly
I wrote a book about service workers. It’s called Going Offline. It was first published by A Book Apart in 2018. Now it’s available to read for free online.
If you want you can read the book as a PDF, an ePub, or .mobi, but I recommend reading it in your browser.
Needless to say the web book works offline. Once you go to goingoffline.adactio.com you can add it to the homescreen of your mobile device or add it to the dock on your Mac. After that, you won’t need a network connection.
The book is free to read. Properly free. Not the kind of “free” where you have to supply an email address first. Why would I make you go to the trouble of generating a burner email account?
The site has no analytics. No tracking. No third-party scripts of any kind whatsover. By complete coincidence, the site is fast. Funny that.
For the styling of this web book, I tweaked the stylesheet I used for HTML5 For Web Designers. I updated it a little bit to use logical properties, some fluid typography and view transitions.
In the process of converting the book to HTML, I got reaquainted with what I had written almost seven years ago. It was kind of fun to approach it afresh. I think it stands up pretty darn well.
Ethan wrote about his feelings when he put two of his books online, illustrated by that amazing photo that always gives me the feels:
I’ll miss those days, but I’m just glad these books are still here. They’re just different than they used to be. I suppose I am too.
Anyway, if you’re interested in making your website work offline, have a read of Going Offline. Enjoy!
Unfortunately, this is what all of the internet is right now: social media, owned by large corporations that make changes to them to limit or suppress your speech, in order to make themselves more attractive to advertisers or just pursue their owners’ ends. Even the best Twitter alternatives, like Bluesky, aren’t immune to any of this—the more you centralize onto one single website, the more power that website has over you and what you post there. More than just moving to another website, we need more websites.