The fact that so many people publish their thoughts and share knowledge, is something I’ve always loved about the web. Whether it is practical stuff about how to solve a coding issue or some kind of opinion… everyone’s brain is wired differently. It may resonate, it may not, that’s also fine.
Turns out I was the twelfth ever user of Dribbble—ah, memories!
A personal website ain’t got no wrong words.
I’m subscribed to a lot of blogs in my RSS reader. I follow some people because what they write about is very different to what I know about. But I also follow lots of people who have similar interests and ideas to me. So I’m not exactly in an echo chamber, but I do have the reverb turned up pretty high.
Sometimes these people post thoughts that are eerily similar to what I’ve been thinking about. Ethan has been known to do this. Get out of my head, Marcotte!
But even if Ethan wasn’t some sort of telepath, he’d still be in my RSS reader. We’re friends. Lots of the people in my RSS reader are my friends. When I read their words, I can hear their voices.
Then there are the people I’ve never met. Like Desirée García, Piper Haywood, or Jim Nielsen. Never met them, don’t know them, but damn, do I enjoy reading their blogs. Last year alone, I ended up linking to Jim’s posts ten different times.
Or Baldur Bjarnason. I can’t remember when I first came across his writing, but it really, really resonates with me. I probably owe him royalties for the amount of times I’ve cited his post Over-engineering is under-engineering.
His latest post is postively Marcottian in how it exposes what’s been fermenting in my own mind. But because he writes clearly, it really helps clarify my own thinking. It’s often been said that you should write to figure out what you think, and I can absolutely relate to that. But here’s a case where somebody else’s writing really helps to solidify my own thoughts.
Which type of novelty-seeking web developer are you?
It starts with some existentialist stock-taking. I can relate, what with the whole five decades thing. But then it turns the existential questioning to the World Wide Web itself, or rather, the people building the web.
In a way, it’s like taking the question of the great divide (front of the front end and back of the front end), and then turning it 45 degrees to reveal an entirely hidden dimension.
In examining the nature of the web, he hits on the litmus of how you view encapsulation:
I mention this first as it’s the aspect of the web that modern web developers hate the most without even giving it a label. Single-Page-Apps and GraphQL are both efforts to eradicate the encapsulation that’s baked into the foundation of every layer of the web.
Most modern devs are trying to get rid of it but it’s one of the web’s most strategic advantages.
I hadn’t thought of this before.
By default, if you don’t go against the grain of the web, each HTTP endpoint is encapsulated from each other.
Moreover, all of this can happen really fast if you aren’t going overboard with your CSS and JS.
He finishes with a look at another of the web’s most powerful features: distribution. In between are the things that make the web webby: hypertext and flexibility (The Dao of the Web).
It’s the idea that the web isn’t a single fixed thing but a fluid multitude whose shape is dictated by its surroundings.
This resonates with me because it highlights two different ways of viewing the web.
On the one hand, you can see the web purely as a distribution channel. In the past you might have been distributing a Flash movie. These days you might be distributing a single page app. Either way, the web is there as a low-friction way of getting your creation in front of other people.
The other way of building for the web is to go with the web’s grain, embracing flexibility and playing to the strengths of the medium through progressive enhancement. This is the distinction I was getting at when I talked about something being not just on the web, but of the web.
With that mindset, Baldur then takes us through some of the technologies that he’s excited about, like SvelteKit and Hotwire. I think it’s the same mindset that got me excited about service workers. As Baldur says:
They are helping the web become better at being its own thing.
That’s my tagline right there.
I don’t think I agree with Don Knuth’s argument here from a 2014 lecture, but I do like how he sets out his table:
Why do I, as a scientist, get so much out of reading the history of science? Let me count the ways:
- To understand the process of discovery—not so much what was discovered, but how it was discovered.
- To understand the process of failure.
- To celebrate the contributions of many cultures.
- Telling historical stories is the best way to teach.
- To learn how to cope with life.
- To become more familiar with the world, and to know how science fits into the overall history of mankind.
I love, love, love this experiment from Matt—messin’ around in websites!
Violence is never the answer, unless you’re dealing with nazis or your inner critic.
The excuses—or, I’m sorry, reasons—I hear folks say they can’t write include: I’m not very good at writing (you can’t improve if you don’t write often), my website isn’t finished (classic, and also guilty so shut up), and I don’t know what to write about, there’s nothing new for me to add (oh boy).
Matt wrote recently about how different writers keep notes:
I’m also reminded of how writers I love and respect maintain their own reservoirs of knowledge, complete with migratory paths down from the mountains.
I have a section of my site called “notes” but the truth is that every single thing I post on here—whether it’s a link, a blog post, or anything else—is really a “note to self.”
When it comes to retrieving information from this online memex of mine, I use tags. I’ve got search forms on my site, but usually I’ll go to the address bar in my browser instead and think “now, what would past me have tagged that with…” as I type adactio.com/tags/... (or, if I want to be more specific, adactio.com/links/tags/... or adactio.com/journal/tags/...).
It’s very satisfying to use my website as a back-up brain like this. I can get stuff out of my head and squirreled away, but still have it available for quick recall when I want it. It’s especially satisfying when I’m talking to someone else and something they say reminds me of something relevant, and I can go “Oh, let me send you this link…” as I retrieve the tagged item in question.
But I don’t think about other people when I’m adding something to my website. My audience is myself.
I know there’s lots of advice out there about considering your audience when you write, but when it comes to my personal site, I’d find that crippling. It would be one more admonishment from the inner critic whispering “no one’s interested in that”, “you have nothing new to add to this topic”, and “you’re not quailified to write about this.” If I’m writing for myself, then it’s easier to have fewer inhibitions. By treating everything as a scrappy note-to-self, I can avoid agonising about quality control …although I still spend far too long trying to come up with titles for posts.
I’ve noticed—and other bloggers have corroborated this—there’s no correlation whatsover between the amount of time you put into something and how much it’s going to resonate with people. You might spend days putting together a thoroughly-researched article only to have it met with tumbleweeds when you finally publish it. Or you might bash something out late at night after a few beers only to find it on the front page of various aggregators the next morning.
If someone else gets some value from a quick blog post that I dash off here, that’s always a pleasant surprise. It’s a bonus. But it’s not my reason for writing. My website is primarily a tool and a library for myself. It just happens to also be public.
I’m pretty sure that nobody but me uses the tags I add to my links and blog posts, and that’s fine with me. It’s very much a folksonomy.
Likewise, there’s a feature I added to my blog posts recently that is probably only of interest to me. Under each blog post, there’s a heading saying “Previously on this day” followed by links to any blog posts published on the same date in previous years. I find it absolutely fascinating to spelunk down those hyperlink potholes, but I’m sure for anyone else it’s about as interesting as a slideshow of holiday photos.
Matt took this further by adding an “on this day” URL to his site. What a great idea! I’ve now done the same here:
That URL is almost certainly only of interest to me. And that’s fine.
Our footpaths converged around the same 5-10 platforms, each with its own particular manner of communication. I have learned, unintentionally, to code switch every time I craft a new post. It’s exhausting, trying to keep track of all those unspoken rules shaped by years of use.
But I don’t have rules like that on my blog. I turned off stats. There are no comments. No likes.
A rant from Robin. I share his frustration and agree with his observations.
I wonder how we can get the best of both worlds here: the ease of publishing newsletters, with all the beauty and archivability of websites.
I posted to adactio.com 1442 times in 2020.
March was the busiest month with 184 posts.
This month, December, was the quietest with 68 posts.
Overall I published:
In amongst those notes are 128 photos. But the number I’m happiest with is 200. From to March 18th to October 3rd, I posted a tune a day for 200 days straight.
Elsewhere in 2020:
For obvious reasons, in 2020 I had far fewer check ins, did far less speaking and almost no travel.
Once again I wrote over a hundred blog posts this year. While lots of other activities dropped off significantly while my main focus was to just keep on keepin’ on, I still found solace and reward in writing and publishing. Like I said early on in The Situation, my website is an outlet for me:
While you’re stuck inside, your website is not just a place you can go to, it’s a place you can control, a place you can maintain, a place you can tidy up, a place you can expand. Most of all, it’s a place you can lose yourself in, even if it’s just for a little while.
Here are some blog posts that turned out alright:
I find it strangely comforting that even in a year as shitty as 2020, I can look back and see that there were some decent blog posts in there. Whatever 2021 may bring, I hope to keep writing and publishing through it all. I hope you will too.
Tending this website keeps me sane. I think of it as a digital garden, a kind of sanctuary. … And if my site is a kind of garden, then I see myself as both gardener and architect, in so much as I make plans and prepare the ground, then sow things that grow in all directions. Some things die, but others thrive, and that’s how my garden grows. And I tend it for me; visitors are a bonus.
A thoughtful and impassioned plea from Colly for more personal publishing:
I know that social media deprived the personal site of oxygen, but you are not your Twitter profile, nor are you your LinkedIn profile. You are not your Medium page. You are not your tiny presence on the company’s About page. If you are, then you look just like everyone else, and that’s not you at all. Right?
I think that working on your own website can be a good Forever Project.
It’s an open-ended topic that you can explore for a long time without running out of challenges.
Also, this is spot-on:
Compare two different situations where you tell a story at a party. In the first situation, you tell the story in a corner to one or two people, who are totally interested and smiling. In the second situation, you tell the story in the center of the party with a large group of people around you, but they’re almost all bored and uninterested, talking amongst themselves and largely ignoring you. The first situation sounds better, right? Well, that’s the non-obvious benefit of blogging. There are a load of people out there blogging, and almost all of them are better writers and better looking than you. Nobody is going to read your blog about frabulizing widgets unless they really care about frabulizing widgets. So it’s not going to be a big audience, but it should be an interested audience. And I think you’ll find that you get 90% of the benefits of socialization from a handful of readers as you would get from a sea of readers.
On your personal website, you own your work. You decide what and when to publish. You decide when to delete things. You are in control. Your work, your rules, your freedom.
Amber describes how she implemented webmentions on her (static) site. More important, she describes why!
I somehow missed this post from last year by Karin Taliga on different ways of using Huffduffer:
- As an Instapaper but for audio
- Listen to own recordings in a podcast player
- Create a podcast feed from youtube videos
- Gather your podcast guest appearances in one place
- Share a custom curated playlist
- Share supplemental material to an online course you have
Zonelets is a simple HTML blogging engine with scrappy, DIY spirit! I made it because I really want everyone to blog, but I felt that the existing options were generally overcomplicated and commercially-focused in a way that made web creativity feel intimidating and arcane.
I love the philosophy behind this blogging tool, which actively encourages you to learn a little bit of HTML:
Plenty of services can help you to “create a professional-looking website without writing a single line of code.” Now, thanks to Zonelets, you can create an UNPROFESSIONAL-looking website by writing NUMEROUS lines of code!
I’ve been like a dog with a bone the way I’ve been pushing for a declarative option for the Web Share API in the shape of button type=“share”. It’s been an interesting window into the world of web standards.
The story so far…
That’s the situation currently. The general consensus seems to be that it’s probably too soon to be talking about implementation at this stage—the Web Share API itself is still pretty new—but gathering data to inform future work is good.
In planning for the next TPAC meeting (the big web standards gathering), Marcos summarised the situation like this:
Not blocking: but a proposal was made by @adactio to come up with a declarative solution, but at least two implementers have said that now is not the appropriate time to add such a thing to the spec (we need more implementation experience + and also to see how devs use the API) - but it would be great to see a proposal incubated at the WICG.
Now this where things can get a little confusing because it used to be that if you wanted to incubate a proposal, you’d have to do on Discourse, which is a steaming pile of crap that requires JavaScript in order to put text on a screen. But Šime pointed out that proposals can now be submitted on Github.
So that’s where I’ve submitted my proposal, linking through to the explainer document.
Like I said, I’m not expecting anything to happen anytime soon, but it would be really good to gather as much data as possible around existing usage of the Web Share API. If you’re using it, or you know anyone who’s using it, please, please, please take a moment to provide a quick description. And if you could help spread the word to get that issue in front of as many devs as possible, I’d be very grateful.
(Many thanks to everyone who’s already contributed to that issue—much appreciated!)
If you’re at all interested in what I wrote about a declarative Web Share API—and its sequel, a polyfill for button type=”share”—then you might be interested in an explainer document I’ve put together.
It’s a useful exercise for me to enumerate the reasoning for button type=“share” in one place. If you have any feedback, feel free to fork it or create an issue.
The document is based on my initial blog posts and the discussion that followed in this issue on the repo for the Web Share API. In that thread I got some pushback from Marcos. There are three points he makes. I think that two of them lack merit, but the third one is actually spot on.
Here’s the first bit of pushback:
Apart from placing a button in the content, I’m not sure what the proposal offers over what (at least one) browser already provides? For instance, Safari UI already provides a share button by default on every page
But that is addressed in the explainer document for the Web Share API itself:
The browser UI may not always be available, e.g., when a web app has been installed as a standalone/fullscreen app.
That’s exactly what I wanted to address. Browser UI is not always available and as progressive web apps become more popular, authors will need to provide a way for users to share the current URL—something that previously was handled by browsers.
That use-case of sharing the current page leads nicely into the second bit of pushback:
The API is specialized… using it to share the same page is kinda pointless.
But again, the explainer document for the Web Share API directly contradicts this:
Sharing the page’s own URL (a very common case)…
Rather than being a difference of opinion, this is something that could be resolved with data. I’d really like to find out how people are currently using the Web Share API. How much of the current usage falls into the category of “share the current page”? I don’t know the best way to gather this data though. If you have any ideas, let me know. I’ve started an issue where you can share how you’re using the Web Share API. Or if you’re not using the Web Share API, but you know someone who is, please let them know.
Okay, so those first two bits of pushback directly contradict what’s in the explainer document for the Web Share API. The third bit of pushback is more philosophical and, I think, more interesting.
The Web Share API explainer document does a good job of explaining why a declarative solution is desirable:
The link can be placed declaratively on the page, with no need for a JavaScript click event handler.
That’s also my justification for having a declarative alternative: it would be easier for more people to use. I said:
At a fundamental level, declarative technologies have a lower barrier to entry than imperative technologies.
That’s demonstrably false and a common misconception: See OWL, XForms, SVG, or any XML+namespace spec. Even HTML is poorly understood, but it just happens to have extremely robust error recovery (giving the illusion of it being easy). However, that’s not a function of it being “declarative”.
He’s absolutely right.
It’s not so much that I want a declarative option—I want an option that has robust error recovery. After all, XML is a declarative language but its error handling is as strict as an imperative language like JavaScript: make one syntactical error and nothing works. XML has a brittle error-handling model by design. HTML and CSS have extremely robust error recovery by design. It’s that error-handling model that gives HTML and CSS their robustness.
I’ve been using the word “declarative” when I actually meant “robust in handling errors”.
I guess that when I’ve been talking about “a declarative solution”, I’ve been thinking in terms of the three languages parsed by browsers: HTML, CSS, and JavaScript. Two of those languages are declarative, and those two also happen to have much more forgiving error-handling than the third language. That’s the important part—the error handling—not the fact that they’re declarative.
I’ve been using “declarative” as a shorthand for “either HTML or CSS”, but really I should try to be more precise in my language. The word “declarative” covers a wide range of possible languages, and not all of them lower the barrier to entry. A declarative language with a brittle error-handling model is as daunting as an imperative language.
I should try to use a more descriptive word than “declarative” when I’m describing HTML or CSS. Resilient? Robust?
With that in mind, button type=“share” is worth pursuing. Yes, it’s a declarative option for using the Web Share API, but more important, it’s a robust option for using the Web Share API.
I invite you to read the explainer document for a share button type and I welcome your feedback …especially if you’re currently using the Web Share API!