So much ink spilled supposedly explaining what “the web platform” is …when the truth is you can just swap in the “the web” every time that phrase is used here or anywhere else.
Anyway, the gist of this piece is: the web is good, actually.
Mastodon is not a platform. Mastodon is just a tiny part of a concept many have been dreaming about and working on for years. Social media started on the wrong foot. The idea for the read/write web has always been different. Our digital identities weren’t supposed to end up in something like Twitter or Facebook or Instagram.
Decentralisation, Federation, The Indie Web: There were many groups silently working on solving the broken architecture of our digital social networks and communication channels – long, long before the “web 3” dudes tried to reframe it as their genius new idea.
I’ve been a part of this for many years until I gave up hope. How would you compete against the VC money, the technical and economical benefits of centralised platforms? It was a fight between David and Gloiath. But now Mastodon could be the stone.
Wouldn’t it be nice to have a site that’s not run by an amoral billionaire chaos engine, or algorithmically designed to keep you doomscrolling in a state of fear and anger, or is essentially spyware for governments and/or corporations? Wouldn’t it be nice not to have ads shoved in your face every time you open an app to see what your friends are up to? Wouldn’t it be nice to know that when your friends post something, you’ll actually see it without a social media platform deciding whether to shove it down your feed and pump that feed full of stuff you didn’t ask for?
Wouldn’t that be great?
Your easy guide to starting a new blog.
A blog is an easy way to get started writing on the web. Your voice is important: it deserves its own site. The more people add their unique perspectives to the web, the more valuable it becomes.
It turns out that in 2022, for a lot of apps, the dream of write once run anywhere has finally arrived.
Every year browsers and web technologies become more capable and more powerful. Every year there are more kinds of app that you can make cross platform.
So before you start your next project, why don’t you take a look at cross platform web apps. Maybe they aren’t right for your project, but maybe, like me, you’ll discover that you can code once and run everywhere. And I think that’s amazing.
The result of adding more constraints means that the products have a broader appeal due to their simple interface. It reminds me of a Jeremy Keith talk I heard last month about programming languages like CSS which have a simple interface pattern:
selector { property: value }. Simple enough anyone can learn. But simple doesn’t mean it’s simplistic, which gives me a lot to think about.
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.
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.
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.
This is a terrific analysis of why frameworks exist, with nods to David Hume’s is-ought problem: the native features are what is, and the framework features are what somebody thinks ought to be.
I’ve been saying at conferences for years now that if you choose to use a framework, you need to understand that you are also taking on the philosophy and worldview of the creators of that framework. This post does a great job of explaining that.
It’s great to see browsers working together to collectively implement a range of much-needed features.
These scores represent how browser engines are doing in 15 focus areas and 3 joint investigation efforts.
This is an intriguing idea for a content management system: write words on paper and then take a picture of the page. Artisinal retro vintage blogging.
Say you’re into the indie web without saying you’re into the indie web…
The internet wasn’t really convenient in 1994 or 1995, but it was a very collaborative space.
There was a moment where we replaced this idea of the internet being a medium that we can all write to and participate in to one that is mediated. That happened at some point after social networks started to arrive and when the smartphone started to arrive. It’s a combination of the nature of those platforms and the prevalence of the technologies, which meant the economic rewards of getting this right rose significantly.
And so there’s a really distinctly different feel in the 2013, or 2014, internet to the one that you might have had in 1997, or 1998. It’s not just that it’s easier and I’m yearning for a world of cars with manual choke and manual transmission and crank-up starter handles, but it’s that the programmability of the internet and its endpoints has turned into something that is increasingly permissioned by major platforms.
Elise Hein documents what it was like to build a website (or web app, if you prefer) the stackless way:
- use custom elements (for modular HTML without frameworks)
- use the in-browser package manager (for JavaScript packages without build tools)
- match pages with files (to avoid routing and simplify architecture)
- stick to standards (to avoid obsolescence and framework fatigue)
Her conclusions are similar to my own: ES6 modules mean you can kiss your bundler goodbye; web components are a mixed bag—it’s frustrating that Apple are refusing to allow native elements to be extended. Interestingly, Elise feels that a CSS preprocessor is still needed for her because she wants to be able to nest selectors …but even that’s on its way now!
Perhaps we might get to the stage where it isn’t an automatic default to assume you’ll need bundling, concatenation, transpiling, preprocessing, and all those other tasks that we’ve become dependent on build tools for.
I have a special disdain for beginner JavaScript tutorials that have you run
create-react-appas the first step, and this exercise has only strengthened my conviction that every beginner programmer should get to grips with HTML, CSS and vanilla JS before delving into frameworks. Features native to the web are what all frameworks share, and knowing the platform makes for a stronger foundation in the face of change.
I’ve been thinking some more about the technical experience of booking a vaccination apointment and how much joy it brought me.
I’ve written before about how I’ve got a blind spot for the web so it’s no surprise that I was praising the use of a well marked-up form, styled clearly, and unencumbered by unnecessary JavaScript. But other technologies were in play too: Short Message Service (SMS) and email.
All of those technologies are platform-agnostic.
No matter what operating system I’m using, or what email software I’ve chosen, email works. It gets more complicated when you introduce HTML email. My response to that is the same as the old joke; you know the one: “Doctor, it hurts when I do this.” (“Well, don’t do that.”)
No matter what operating system my phone is using, SMS works. It gets more complicated when you introduce read receipts, memoji, or other additions. See my response to HTML email.
Then there’s the web. No matter what operating system I’m using on a device that could be a phone or a tablet or a laptop or desktop tower, and no matter what browser I’ve chosen to use, the World Wide Web works.
It feels like the principle of least power in action.
But another way of rephrasing “least power” is “most availability.” Technologies that are old, simple, and boring tend to be more widely available.
I remember when software used to come packaged in boxes and displayed on shelves. The packaging always had a list on the side. It looked like the nutritional information on a food product, but this was a list of “system requirements”: operating system, graphics card, sound card, CPU. I never liked the idea of system requirements. It felt so …exclusionary. And for me, the promise of technology was liberation and freedom to act on my own terms.
Hence my soft spot for the boring and basic technologies like email, SMS, and yes, web pages. The difference with web pages is that you can choose to layer added extras on top. As long as the fundamental functionality is using universally-supported technology, you’re free to enhance with all the latest CSS and JavaScript. If any of it fails, that’s okay: it falls back to a nice solid base.
Alas, many developers don’t build with this mindset. I mean, I understand why: it means thinking about users with the most boring, least powerful technology. It’s simpler and more exciting to assume that everyone’s got a shared baseline of newer technology. But by doing that, you’re missing out on one of the web’s superpowers: that something served up at the same URL with the same underlying code can simultaneously serve people with older technology and also provide a whizz-bang experience to people with the latest and greatest technology.
Anyway, I’ve been thinking about the kind of communication technologies that are as universal as email, SMS, and the web.
QR codes are kind of heading in that direction, although I still have qualms because of their proprietary history. But there’s something nice and lo-fi about them. They’re like print stylesheets in reverse (and I love print stylesheets). A funky little bridge between the physical and the digital. I just wish they weren’t so opaque: you never know if scanning that QR code will actually take you to the promised resource, or if you’re about to rickroll yourself.
Telephone numbers kind of fall into the same category as SMS, but with the added option of voice. I’ve always found the prospect of doing something with, say, Twilio’s API more interesting than building something inside a walled garden like Facebook Messenger or Alexa.
I know very little about chat apps or voice apps, but I don’t think there’s a cross-platform format that works with different products, right? I imagine it’s like the situation with native apps which require a different codebase for each app store and operating system. And so there’s a constant stream of technologies that try to fulfil the dream of writing once and running everywhere: React Native, Flutter.
They’re trying to solve a very clear and obvious problem: writing the same app more than once is really wasteful. But that’s the nature of the game when it comes to runtime-specific apps. The only alternative is to either deliberately limit your audience …or apply the principle of least power/most availability.
The wastefulness of having to write the same app for multiple platforms isn’t the only thing that puts me off making native apps. The exclusivity works in two directions. There’s the exclusive nature of the runtime that requires a bespoke codebase. There’s also the exclusive nature of the app store. It feels like a return to shelves of packaged software with strict system requirements. You can’t just walk in and put your software on the shelf. That’s the shopkeeper’s job.
There is no shopkeeper for the World Wide Web.
Six years old. Still very astute. Still very true.
Principles behind the design of web APIs:
- Put user needs first (Priority of Constituencies)
- It should be safe to visit a web page
- Trusted user interface should be trustworthy
- Ask users for meaningful consent when appropriate
- Support the full range of devices and platforms (Media Independence)
I should add these to my collection.
Own. Your. Nook. There’s power in owning your nook of the ‘net — your domain name, your design, your archives — and it’s easier than ever to do so, and run a crowdfunding campaign at the same time.
Some good blogging advice.
Building a blog for the long run? Avoid Medium.
On the internet, everything can appear equally legitimate. Breitbart resembles the BBC. The fictitious Protocols of the Elders of Zion look as valid as an ADL report. And the rantings of a lunatic seem as credible as the findings of a Nobel Prize winner. We have lost, it seems, a shared sense of the basic facts upon which democracy depends.