Tags: indieweb



Monday, June 20th, 2022

The Message Behind the Medium of a Personal Blog - Jim Nielsen’s Blog

  • 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

Just Put Stuff Out There · Matthias Ott – User Experience Designer

I’m honoured to mentioned in the same paragraph as Seth Godin and Chris Coyier (and I too have really been enjoying Chris’s writing).

Tuesday, June 7th, 2022

Am I on the IndieWeb Yet? | Miriam Eric Suzanne

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 alt text.

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 alt text.

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

Changing with the times · Chris Burnell

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

Why blog? – Chuck Grimmett

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.

Recently Jonathan Aldrich posted a thread about the same bug. He included a link to my blog post. He also said:

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:

All three are very handy tips. Thanks, Eric! Thanks, Rich! Thanks, Stephanie!

Sunday, May 1st, 2022

Increasing the surface area of blogging

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.

RSS - Chris Coyier

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.

Chris obliged:

I can’t speak for the industry, but I have a guess. Third-party code (like the referenced Bootstrap and React) have a history of smoothing over significant cross-browser issues and providing better-than-browser ergonomic APIs. jQuery was created to smooth over cross-browser JavaScript problems. That’s trust.

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:

I think this perspective of trust has been hammered into developers over the past maybe like 5 years of JavaScript development based almost exclusively on inequality of browser feature support. Things are looking good in 2022; but as recently as 2019, 4 of the 5 top web developer needs had to do with browser compatibility.

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.

Charles again:

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

The lost thread

Twit­ter’s only con­clu­sion can be abandonment: an over­due MySpace-ification. I am totally con­fi­dent about this prediction, but that’s an easy confidence, because in the long run, we’re all MySpace-ified.

What Robin said.

Thursday, April 14th, 2022

A Web Renaissance

Thanks to the mistrust of big tech, the creation of better tools for developers, and the weird and wonderful creativity of ordinary people, we’re seeing an incredibly unlikely comeback: the web is thriving again.

Smart analysis from Anil, though I’m not sure I’d agree with his emphasis on tools and frameworks—it’s the technology built into browsers that has really come along in leaps and bounds, allowing people to do more with less code.

But then there’s this:

So if we have the tech, then why hasn’t it happened already? The biggest thing that may be missing is just awareness of the modern web’s potential. Unlike the Facebooks and Googles of the world, the open, creative web doesn’t have a billion-dollar budget for promoting itself. Years of control from the tech titans has resulted in the conventional wisdom that somehow the web isn’t “enough”, that you have to tie yourself to proprietary platforms if you want to build a big brand or a big business.

True! Anil also points to an act of rebellion and resistance:

Get your own site going, though, and you’ll have a sustainable way of being in control of your own destiny online.

Thursday, April 7th, 2022

home sweet homepage

I can’t remember the last time that a website made me smile like this.

Sunday, March 20th, 2022

🐠 Robin Sloan: describing the emotions of life online

Obviously, no one does this, I recognize this is a very niche endeavor, but the art and craft of maintaining a homepage, with some of your writing and a page that’s about you and whatever else over time, of course always includes addition and deletion, just like a garden — you’re snipping the dead blooms. I do this a lot. I’ll see something really old on my site, and I go, “you know what, I don’t like this anymore,” and I will delete it.

But that’s care. Both adding things and deleting things. Basically the sense of looking at something and saying, “is this good? Is this right? Can I make it better? What does this need right now?” Those are all expressions of care. And I think both the relentless abandonment of stuff that doesn’t have a billion users by tech companies, and the relentless accretion of garbage on the blockchain, I think they’re both kind of the antithesis, honestly, of care.

Sunday, March 13th, 2022

Building a Digital Homestead, Bit by Brick

A personal site, or a blog, is more than just a collection of writing. It’s a kind of place - something that feels like home among the streams. Home is a very strong mental model.

Friday, March 4th, 2022

How Websites Die ⁑ Wesley’s Notebook

This is like the Gashlycrumb Tinies but for websites:

It’s been interesting to see how websites die — from domain parking pages to timeouts to blank pages to outdated TLS cipher errors, there are a multitude of different ways.

Interoperable Personal Libraries and Ad Hoc Reading Groups

Speaking of hosting your own reading list, Maggie recently attended an indie web pop-up on personal libraries, which prompted these interesting thoughts on decentralised book clubs—ad hoc reading groups:

Taking a book-first, rather than a group-first approach would enable reading groups who don’t have to compromise on their book choices. They could gather only once or twice to discuss the book, then go their seperate ways. No long-term committment to organising and maintaining a bookclub required.

Nelson’s Weblog: Goodreads lost all of my reviews

Goodreads lost my entire account last week. Nine years as a user, some 600 books and 250 carefully written reviews all deleted and unrecoverable. Their support has not been helpful. In 35 years of being online I’ve never encountered a company with such callous disregard for their users’ data.

Ouch! Lesson learned:

My plan now is to host my own blog-like collection of all my reading notes like Tom does.

Thursday, February 24th, 2022

The Ultimate Guide to Writing Online - David Perell

Blogging isn’t dead. In fact, the opposite is true. We’re about to enter a golden age of personal blogs.

Make it easy for people to find you. Buy a domain name and use it to create your own website, even if it’s very simple at first. Your website is your resume, your business card, your store, your directory, and your personal magazine. It’s the one place online that you completely own and control – your Online Home.

Good advice. Also:

Don’t write on Medium.

Look, I get it. Writing on Medium is an easy way to pick up readers and increases your chances of going viral. But the costs exceed the benefits. Medium is terrible for SEO. You don’t own your content and the platform makes it difficult to turn one-time readers into loyal ones.

The more you can use platforms you own, the better. Rather than writing on Medium, do the work to build a personal blog. That way, you can have a central place to point people to.

Monday, February 14th, 2022

Personal Websites as Self-Portraiture | starbreaker.org

What, then, is a personal website? It is precisely that, personal. It is a new kind of self-portraiture done not with pencils, charcoal, ink, or paint. Instead it is self-portraiture done in markup language, code, prose, images, audio, and video.