I believe strongly in the indieweb principles of distributed ownership, control, and independence. For me, the important thing is that this is how we get to a diverse web. A web where everyone can define not just what they write but how they present is by definition far more expressive, diverse, and interesting than one where most online content and identities must be squished into templates created by a handful of companies based on their financial needs. In other words, the open web is far superior to a medium controlled by corporations in order to sell ads. The former encourages expression; the latter encourages consumerist conformity.
Friday, September 30th, 2022
Tuesday, September 20th, 2022
I like the way this work-in-progress is organised—it’s both a book and a personal website that’ll grow over time.
Monday, September 12th, 2022
Blog your heart! Blog about something you’ve learned, blog about something you’re interested in.
Excellent advice from Robin:
There are no rules to blogging except this one: always self-host your website because your URL, your own private domain, is the most valuable thing you can own. Your career will thank you for it later and no-one can take it away.
Tuesday, August 30th, 2022
Can you feel the energy?
Monday, August 22nd, 2022
I really like this experiment that Jim is conducting on his own site. I might try to replicate it sometime!
Tuesday, August 16th, 2022
When I wrote about democratising dev, I made brief mention of the growing “no code” movement:
Personally, I would love it if the process of making websites could be democratised more. I’ve often said that my nightmare scenario for the World Wide Web would be for its fate to lie in the hands of an elite priesthood of programmers with computer science degrees. So I’m all in favour of no-code tools …in theory.
But I didn’t describe what no-code is, as I understand it.
By that definition, something like WordPress.com (as opposed to WordPress itself) is a no-code tool:
Create any kind of website. No code, no manuals, no limits.
I’d also put Squarespace in the same category:
Start with a flexible template, then customize to fit your style and professional needs with our website builder.
And its competitor, Wix:
Discover the platform that gives you the freedom to create, design, manage and develop your web presence exactly the way you want.
Webflow provides the same kind of service, but with a heavy emphasis on marketing websites:
Your website should be a marketing asset, not an engineering challenge.
Bubble is trying to cover a broader base:
Bubble lets you create interactive, multi-user apps for desktop and mobile web browsers, including all the features you need to build a site like Facebook or Airbnb.
Wheras Carrd opts for a minimalist one-page approach:
Simple, free, fully responsive one-page sites for pretty much anything.
All of those tools emphasise that don’t need to need to know how to code in order to have a professional-looking website. But there’s a parallel universe of more niche no-code tools where the emphasis is on creativity and self-expression instead of slickness and professionalism.
Create your own free website. Unlimited creativity, zero ads.
Make a website in 5 minutes. Messy encouraged.
unique tool for web publishing & internet samizdat
I’m kind of fascinated by these two different approaches: professional vs. expressionist.
I’ve seen people grapple with this question when they decide to have their own website. Should it be a showcase of your achievements, almost like a portfolio? Or should it be a glorious mess of imagery and poetry to reflect your creativity? Could it be both? (Is that even doable? Or desirable?)
Robin Sloan recently published his ideas—and specs—for a new internet protocol called Spring ’83:
It’s not a no-code tool (you need to publish in HTML), although someone could easily provide a no-code tool to sit on top of the protocol. Conceptually though, it feels like it’s an a similar space to the chaotic good of neocities.org, mmm.page, and hotglue.me with maybe a bit of tilde.town thrown in.
It feels like something might be in the air. With Spring ’83, the Block protocol, and other experiments, people are creating some interesting small pieces that could potentially be loosely joined. No code required.
Wednesday, August 10th, 2022
I met up with a supersmart programmer friend of mine a little while back. He was describing some work he was doing with React. He was joining up React components. There wasn’t really any problem-solving or debugging—the individual components had already been thoroughly tested. He said it felt more like construction than programming.
My immediate thought was “that should be automated.”
Or at the very least, there should be some way for just about anyone to join those pieces together rather than it requiring a supersmart programmer’s time. After all, isn’t that the promise of design systems and components—freeing us up to tackle the meaty problems instead of spending time on the plumbing?
I thought about that conversation when I was listening to Laurie’s excellent talk in Berlin last month.
Chatting to Laurie before the talk, he was very nervous about the conclusion that he had reached and was going to share: that the time is right for web development to be automated. He figured it would be an unpopular message. Heck, even he didn’t like it.
But I reminded him that it’s as old as the web itself. I’ve seen videos from very early World Wide Web conferences where Tim Berners-Lee was railing against the idea that anyone would write HTML by hand. The whole point of his WorldWideWeb app was that anyone could create and edit web pages as easily as word processing documents. It’s almost an accident of history that HTML happened to be just easy enough—but also just powerful enough—for many people to learn and use.
Anyway, I thoroughly enjoyed Laurie’s talk. (Except for a weird bit where he dunks on people moaning about “the fundamentals”. I think it’s supposed to be punching up, but I’m not sure that’s how it came across. As Chris points out, fundamentals matter …at least when it comes to concepts like accessibility and performance. I think Laurie was trying to dunk on people moaning about fundamental technologies like languages and frameworks. Perhaps the message got muddled in the delivery.)
I guess Laurie was kind of talking about this whole “no code” thing that’s quite hot right now. Personally, I would love it if the process of making websites could be democratised more. I’ve often said that my nightmare scenario for the World Wide Web would be for its fate to lie in the hands of an elite priesthood of programmers with computer science degrees. So I’m all in favour of no-code tools …in theory.
The problem is that unless they work 100%, and always produce good accessible performant code, then they’re going to be another example of the law of leaky abstractions. If a no-code tool can get someone 90% of the way to what they want, that seems pretty good. But if that person than has to spend an inordinate amount of time on the remaining 10% then all the good work of the no-code tool is somewhat wasted.
Funnily enough, the person who coined that law, Joel Spolsky, spoke right after Laurie in Berlin. The two talks made for a good double bill.
(I would link to Joel’s talk but for some reason the conference is marking the YouTube videos as unlisted. If you manage to track down a URL for the video of Joel’s talk, let me know and I’ll update this post.)
In a way, Joel was making the same point as Laurie: why is it still so hard to do something on the web that feels like it should be easily repeatable?
He used the example of putting an event online. Right now, the most convenient way to do it is to use a third-party centralised silo like Facebook. It works, but now the business model of Facebook comes along for the ride. Your event is now something to be tracked and monetised by advertisers.
You could try doing it yourself, but this is where you’ll run into the frustrations shared by Joel and Laurie. It’s still too damn hard and complicated (even though we’ve had years and years of putting events online). Despite what web developers tell themselves, making stuff for the web shouldn’t be that complicated. As Trys put it:
We kid ourselves into thinking we’re building groundbreakingly complex systems that require bleeding-edge tools, but in reality, much of what we build is a way to render two things: a list, and a single item. Here are some users, here is a user. Here are your contacts, here are your messages with that contact. There ain’t much more to it than that.
And yet here we are. You can either have the convenience of putting something on a silo like Facebook, or you can have the freedom of doing it yourself, indie web style. But you can’t have both it seems.
This is a criticism often levelled at the indie web. The barrier to entry to having your own website is too high. It’s a valid criticism. To have your own website, you need to have some working knowledge of web hosting and at least some web technologies (like HTML).
Don’t get me wrong. I love having my own website. Like, I really love it. But I’m also well aware that it doesn’t scale. It’s unreasonable to expect someone to learn new skills just to make a web page about, say, an event they want to publicise.
That’s kind of the backstory to the project that Joel wanted to talk about: the block protocol. (Note: it has absolutely nothing to do with blockchain—it’s just an unfortunate naming collision.)
The idea behind the project is to create a kind of crowdsourced pattern library—user interfaces for creating common structures like events, photos, tables, and lists. These patterns already exist in today’s silos and content management systems, but everyone is reinventing the wheel independently. The goal of this project is make these patterns interoperable, and therefore portable.
At first I thought that would be a classic
/927 situation, but I’m pleased to see that the focus of the project is not on formats (we’ve been there and done that with microformats, RDF, schema.org, yada yada). The patterns might end up being web components or they might not. But the focus is on the interface. I think that’s a good approach.
That approach chimes nicely with one of the principles of the indie web:
UX and design is more important than protocols, formats, data models, schema etc. We focus on UX first, and then as we figure that out we build/develop/subset the absolutely simplest, easiest, and most minimal protocols and formats sufficient to support that UX, and nothing more. AKA UX before plumbing.
That said, I don’t think this project is a cure-all. Interoperable (portable) chunks of structured content would be great, but that’s just one part of the challenge of scaling the indie web. You also need to have somewhere to put those blocks.
Convenience isn’t the only thing you get from using a silo like Facebook, Twitter, Instagram, or Medium. You also get “free” hosting …until you don’t (see GeoCities, MySpace, and many, many more).
Wouldn’t it be great if everyone had a place on the web that they could truly call their own? Today you need to have an uneccesary degree of technical understanding to publish something at a URL you control.
I’d love to see that challenge getting tackled.
Tuesday, August 2nd, 2022
I have days were I can write a well researched blog post in a few hours. And I have days were I don’t feel like writing. Or I want to add one more thing but don’t know how to speak my mind. So this is a reminder to myself: just hit publish.
Sunday, July 17th, 2022
So to me, this blog represents the original promise of the open web.
The one that’s here, and still is here, and always has been here, and is available to you.
The one where you can speak the truths that you believe without the permission, or the editorial control, or the power dynamics, of anyone claiming to hold authority over you; or, perhaps, anyone keen to impose it.
Heather takes a break from her relentless crusading in favour of users against the idiocy of the UK government and reflects on the joy of doing it all from her own personal website.
And perhaps you should too, on your own blog, owned on your own hosting space, using your own words, and speaking your own truth. That sounds like a good little weekend project, don’t you think?
Monday, June 20th, 2022
- Each voice is individual and matters
- Slow is ok
- Diversified and independent is good
- Not fitting a pattern is ok
- Not being easily commodified is ok
Tuesday, June 7th, 2022
Miriam has a wishlist for scaling up the indie web approach:
What I would like to see is a tool that helps bring the entire system together in one place. Somewhere that non-technical people can:
- build their own site, with support for feeds/mentions
- see what feeds are available on other sites, and subscribe to them
- easily respond to other sites, and see the resulting threads
(Oh, and by linking to this post, this should show up as a bookmark—I’m also testing Miriam’s webmention setup.)
Sunday, May 15th, 2022
Image previews with the FileReader API
I added a “notes” section to this website eight years ago. I set it up so that notes could be syndicated to Twitter. Ever since then, that’s the only way I post to Twitter.
A few months later I added photos to my notes. Again, this would get syndicated to Twitter.
Something’s bothered me for a long time though. I initially thought that if I posted a photo, then the accompanying text would serve as a decription of the image. It could effectively act as the
alt text for the image, I thought. But in practice it didn’t work out that way. The text was often a commentary on the image, which isn’t the same as a description of the contents.
I needed a way to store
alt text for images. To make it more complicated, it was possible for one note to have multiple images. So even though a note was one line in my database, I somehow needed a separate string of text with the description of each image in a single note.
I eventually settled on using the file system instead of the database. The images themselves are stored in separate folders, so I figured I could have an accompanying
alt.txt file in each folder.
Take this note from yesterday as an example. Different sizes of the image are stored in the folder
/images/uploaded/19077. Here’s a small version of the image and here’s the original. In that same folder is the
This means I’m reading a file every time I need the
alt text instead of reading from a database, which probably isn’t the most performant way of doing it, but it seems to be working okay.
Here’s another example:
In order to add the
alt text to the image, I needed to update my posting interface. By default it’s a little
textarea, followed by a file upload
input, followed by a toggle (a checkbox under the hood) to choose whether or not to syndicate the note to Twitter.
The interface now updates automatically as soon as I use that
input type="file" to choose any images for the note. Using the
FileReader API, I show a preview of the selected images right after the file input.
Here’s the code if you ever need to do something similar. I’ve abstracted it somewhat in that gist—you should be able to drop it into any page that includes
input type="file" accept="image/*" and it will automatically generate the previews.
I was pleasantly surprised at how easy this was. The
FileReader API worked just as expected without any gotchas. I think I always assumed that this would be quite complex to do because once upon a time, it was quite complex (or impossible) to do. But now it’s wonderfully straightforward. Story of the web.
My own version of the script does a little bit more; it also generates another little
textarea right after each image preview, which is where I write the accompanying
I’ve also updated my server-side script that handles the syndication to Twitter. I’m using the
/media/metadata/create method to provide the
alt text. But for some reason it’s not working. I can’t figure out why. I’ll keep working on it.
In the meantime, if you’re looking at an image I’ve posted on Twitter and you’re judging me for its lack of
alt text, my apologies. But each tweet of mine includes a link back to the original note on this site and you will most definitely find the
alt text for the image there.
Thursday, May 12th, 2022
I think, with the sheer volume of functionality available to us nowadays on the front-end, it can be easy to forget how powerful and strong the functionality is that we get right off shelf with HTML. Yes, you read that right, functionality.
Thursday, May 5th, 2022
Platforms come and go. Buy a domain and set up a permanent space on the web where others to find you and link back to. I have no idea what I put on Myspace back in the day, but everything I’ve published on this site since 2008 is still accessible and the links still work.
A personal website is a digital homestead that you can improve, tinker with, and live in for years to come. It is a home for your thoughts, musings, opinions, trials, and happenings, built in a way that suits you.
I like this little prompt:
What do you wish you had found via Google today but didn’t? Write that.
Tuesday, May 3rd, 2022
A while back I wrote a blog post called Web Audio API weirdness on iOS. I described a bug in Mobile Safari along with a hacky fix. I finished by saying:
If you ever find yourself getting weird but inconsistent behaviour on iOS using the Web Audio API, this nasty little hack could help.
Thanks so much for your post, this was a truly pernicious problem!
That warms the cockles of my heart. It’s very gratifying to know that documenting the bug (and the fix) helped someone out. Or, as I put it:
Yay for bugblogging!
Forgive the Germanic compound word, but in this case I think it fits.
Bugblogging doesn’t need to involve a solution. Just documenting a bug is a good thing to do. Recently I documented a bug with progressive web apps on iOS. Before that I documented a bug in Facebook Container for Firefox. When I documented some weird behaviour with the Web Share API in Safari on iOS, I wasn’t even sure it was a bug but Tess was pretty sure it was and filed a proper bug report.
I’ve benefited from other people bugblogging. Phil Nash wrote Service workers: beware Safari’s range request. That was exactly what I needed to solve a problem I’d been having. And then that post about Phil solving my problem helped Peter Rukavina solve a similar issue so he wrote Phil Nash and Jeremy Keith Save the Safari Video Playback Day.
Again, this warmed the cockles of my heart. Bugblogging is worth doing just for the reward of that feeling.
There’s a similar kind of blog post where, instead of writing about a bug, you write about a particular technique. In one way, this is the opposite of bugblogging because you’re writing about things working exactly as they should. But these posts have a similar feeling to bugblogging because they also result in a warm glow when someone finds them useful.
Here are some recent examples of these kinds of posts—tipblogging?—that I’ve found useful:
- Eric wrote about flexibly centering an element with side-sligned content using CSS.
- Rich documented how to subset a variable font on a Mac.
- Stephanie wrote about a CSS technique for animating in a newly added element.
Sunday, May 1st, 2022
RSS is kind of an invisible technology. People call RSS dead because you can’t see it. There’s no feed, no login, no analytics. RSS feels subsurface.
But I believe we’re living in a golden age of RSS. Blogging is booming. My feed reader has 280 feeds in it.
How is all this social? It’s just slow social. If you want to respond to me, publish something linking to what I said. If I want to respond to you, I publish something linking to what you wrote. Old school. Good school. It’s high-effort, but I think the required effort is a positive thing for a social network. Forces you to think more.
Thursday, April 28th, 2022
I’ve already had some thoughtful responses to yesterday’s post about trust. I wrapped up my thoughts with a request:
I would love it if someone could explain why they avoid native browser features but use third-party code.
Very true! jQuery is the canonical example of a library smoothing over the bumpy landscape of browser compatibilities. But jQuery is also the canonical example of a library we no longer need because the browsers have caught up …and those browsers support standards directly influenced by jQuery. That’s a library success story!
Charles Harries takes on my question in his post Libraries over browser features:
Browser compatibility is one of the underlying promises that libraries—especially the big ones that Jeremy references, like React and Bootstrap—make to developers.
So again, it’s browser incompatibilities that made libraries attractive.
Jim Nielsen responds with the same message in his post Trusting Browsers:
We distrust the browser because we’ve been trained to. Years of fighting browser deficiencies where libraries filled the gaps. Browser enemy; library friend.
For example: jQuery did wonders to normalize working across browsers. Write code once, run it in any browser — confidently.
Three for three. My question has been answered: people gravitated towards libraries because browsers had inconsistent implementations.
I’m deliberately using the past tense there. I think Jim is onto something when he says that we’ve been trained not to trust browsers to have parity when it comes to supporting standards. But that has changed.
This approach isn’t a sustainable practice, and I’m trying to do as little of it as I can. Jeremy is right to be suspicious of third-party code. Cross-browser compatibility has gotten a lot better, and campaigns like Interop 2022 are doing a lot to reduce the burden. It’s getting better, but the exasperated I-just-want-it-to-work mindset is tough to uninstall.
I agree. Inertia is a powerful force. No matter how good cross-browser compatibility gets, it’s going to take a long time for developers to shed their suspicion.
Jim is glass-half-full kind of guy:
I’m optimistic that trust in browser-native features and APIs is being restored.
He also points to a very sensible mindset when it comes to third-party libraries and frameworks:
In this sense, third-party code and abstractions can be wonderful polyfills for the web platform. The idea being that the default posture should be: leverage as much of the web platform as possible, then where there are gaps to creating great user experiences, fill them in with exploratory library or framework features (features which, conceivably, could one day become native in browsers).
Yes! A kind of progressive enhancement approach to using third-party code makes a lot of sense. I’ve always maintained that you should treat libraries and frameworks like cattle, not pets. Don’t get too attached. If the library is solving a genuine need, it will be replaced by stable web standards in browsers (again, see jQuery).
I think that third-party libraries and frameworks work best as polyfills. But the whole point of polyfills is that you only use them when the browsers don’t supply features natively (and you also go back and remove the polyfill later when browsers do support the feature). But that’s not how people are using libraries and frameworks today. Developers are reaching for them by default instead of treating them as a last resort.
I like Jim’s proposed design princple:
Where available, default to browser-native features over third party code, abstractions, or idioms.
(P.S. It’s kind of lovely to see this kind of thoughtful blog-to-blog conversation happening. Right at a time when Twitter is about to go down the tubes, this is a demonstration of an actual public square with more nuanced discussion. Make your own website and join the conversation!)
Wednesday, April 27th, 2022
Twitter’s only conclusion can be abandonment: an overdue MySpace-ification. I am totally confident about this prediction, but that’s an easy confidence, because in the long run, we’re all MySpace-ified.
What Robin said.