- Building HTML pages is easy
- Pure HTML is evergreen
- Bloated web pages are too slow
- I can host it anywhere, often for free
- Accessibility and SEO benefits are automatic
- It won’t need security patches
- There are no build steps
Practice Progressive Enhancement.
Build first and foremost with forgiving technologies, declarative technologies, and forward and backward compatible coding techniques.
All content should be readable without scripting.
If it’s worth building on the web, it’s worth building it robustly, and building it to last.
Ah, this is wonderful! Matt takes us on the quarter-decade journey of his brilliant blog (which chimes a lot with my own experience—my journal turns 25 next year)…
Slowly, slowly, the web was taken over by platforms. Your feeling of success is based on your platform’s algorithm, which may not have your interests at heart. Feeding your words to a platform is a vote for its values, whether you like it or not. And they roach-motel you by owning your audience, making you feel that it’s a good trade because you get “discovery.” (Though I know that chasing popularity is a fool’s dream.)
Writing a blog on your own site is a way to escape all of that. Plus your words build up over time. That’s unique. Nobody else values your words like you do.
Blogs are a backwater (the web itself is a backwater) but keeping one is a statement of how being online can work. Blogging as a kind of Amish performance of a better life.
About halfway through this talk transcript, Aaron starts dropping a barrage of truth bombs:
I understand the web, whose distinguishing characteristic is asynchronous recall on a global scale, as the technology which makes revisiting possible in a way that has genuinely never existed before the web.
What the web has made possible are the economics of keeping something, something which has not enjoyed “hockey stick growth”, around long enough for people to warm up to it. Or to survive long past the moment when people may have grown tired of it.
If your goal is to build something which is designed to flip inside of ten years, like many things in the private sector, that may not seem like a very compelling argument.
If, however, your goal is to build something to match the longevity of the cultural heritage sector, to meet the goal of fostering revisiting, or for novel ideas to outlast the reluctance of the present and to do so at a global scale, or really any scale larger than shouting distance, then I will challenge you to find a better vehicle for doing so than the internet, and the web in particular.
I’m not a fan of Nicholas Carr and his moral panics, but this is an excellent dive into some historical media theory.
What Innis saw is that some media are particularly good at transporting information across space, while others are particularly good at transporting it through time. Some are space-biased while others are time-biased. Each medium’s temporal or spatial emphasis stems from its material qualities. Time-biased media tend to be heavy and durable. They last a long time, but they are not easy to move around. Think of a gravestone carved out of granite or marble. Its message can remain legible for centuries, but only those who visit the cemetery are able to read it. Space-biased media tend to be lightweight and portable. They’re easy to carry, but they decay or degrade quickly. Think of a newspaper printed on cheap, thin stock. It can be distributed in the morning to a large, widely dispersed readership, but by evening it’s in the trash.
Wherein Brad says some kind words about The Session. And slippers.
Slippers are cool.
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.
This magnificent piece by Maxwell Neely-Cohen—with some tasteful art-direction—is right up my alley!
This piece looks at a single question. If you, right now, had the goal of digitally storing something for 100 years, how should you even begin to think about making that happen? How should the bits in your stewardship be stored with such a target in mind? How do our methods and platforms look when considered under the harsh unknowns of a century? There are plenty of worthy related subjects and discourses that this piece does not touch at all. This is not a piece about the sheer volume of data we are creating each day, and how we might store all of it. Nor is it a piece about the extremely tough curatorial process of deciding what is and isn’t worth preserving and storing. It is about longevity, about the potential methods of preserving what we make for future generations, about how we make bits endure. If you had to store something for 100 years, how would you do it? That’s it.
What are your own scribbles, your own ordinary plenty, not worth much to you now but that someone in the future may treasure?
Since the early days of the web, large corporations have seemingly always wanted more than the web platform or web standards could offer at any given moment. Whether they were aiming for cross-platform-compatibility, more advanced capabilities, or just to be the one runtime/framework/language to rule them all, there’s always been a company that believes they can “fix” it or “own” it.
Applets. ActiveX. Flash. Flex. Silverlight. Angular. React.
When I write a blog post, I want it to live on my blog, rather than a platform. I can thus invest my time thinking about how to make my blog better and backing it up, rather than having to worry about where my writing is, finding ways to export data from a platform, setting up persistent backups, etc.
It would be much harder for a 15-year-old today to View Source and understand the code structure that built the website they’re on. Every site is layered with analytics, code snippets, javascript plugins, CMS data, and more.
This is why the simplicity of HTML and CSS now feels like a radical act. To build a website with just these tools is a small protest against platform capitalism: a way to assert sustainability, independence, longevity.
One of the reasons to own your content is to make it last. When you have control of the text you write or the photos you post, it’s up to you whether that content stays on the internet. When you post to someone else’s platform, you’ve given up that control. It’s not up to you whether the company that hosts your content will stay in business or change everything to break your content.
If you have a project that uses just plain HTML, CSS, and JavaScript, you can just open up the files and start working on them at any time. A project from 20 years ago will still work just fine, and can be easily modified.
Projects that use build tools? Well… to work with them, you need your build tools to actually build. And that’s not always guaranteed.
Also, it me:
One of my least favorite things as a developer is wanting to do a quick patch fix on an older project—I’m talking a simple one-line of CSS kind of fix—but first having to spend 30 minutes patching my build tools to get them running again.
There’s a cost to using dependencies. New versions are released, APIs change, and it takes time and effort to make sure your own code remains compatible with them. And the cost accumulates over time.
This post is about more than web components:
If we want our work to be accessible in five or ten or even 20 years, we need to use the web with no layers in between. For all its warts, the web has become the most resilient, portable, future-proof computing platform we’ve ever created — at least, if we build with that in mind.
The best reason to write a library in plain JavaScript is that it lasts forever. This is arguably JavaScript’s single most underrated feature. While I’m sure there are some corner cases, JavaScript from 1999 that ran in Netscape Navigator will run unaltered, alongside modern code, in Google Chrome downloaded yesterday. That is true for very few programming environments.
And yet:
Of course, most people’s experience with JavaScript is that it ages like milk. Reopen a node repository after 3 months and you’ll find that your project is mired in a flurry of security warnings, backwards-incompatible library “upgrades,” and a frontend framework whose cultural peak was the exact moment you started the project and is now widely considered tech debt.
Before getting into the details of the code, Matt hits the nail on the head talking about the the one thing that web components have that no framework can offer: longevity.
Quoting Stuart Brand:
Old systems break in familiar ways. New systems break in unexpected ways.
Well! The web is an old system.
In the fullness of time, the files you create are more important than the tools you use to create them. Apps are ephemeral, but your files have a chance to last.
- Don’t wrap too much of your identity in a tool.
- Every tool will eventually fade.
- Flexibility is a valuable skill
- Changing tools does not mean starting over.
I agree with pretty much every word of this article.
Perhaps most problematic of all is the effect that contemporary developer experience has on educational programs (be they traditional classes, bootcamps, workshops, or anything in between). Such a rapidly expanding and ever changing technological ecosystem necessarily means that curricula struggle to keep up, and that the fundamentals of web development (e.g. HTML, CSS, HTTP, browser APIs…) are often glossed over in favor of getting students into the technologies more likely to land them jobs (like React and its many pals). This leads to an outpouring of early career developers who may speak confidently about things like React hooks or Redux state reducers, but who also lack any concept about the nature of HTML semantics or the most basic accessibility considerations. To be clear, I’m not throwing shade at those developers — they have been failed by an industry obsessed with the new and shiny at the expense of foundational practices and end user experiences.
And so, I ask: what exactly are we buying when we are sold ‘developer experience’ today? Who is benefiting from it? And if it is indeed something many of us aren’t too excited about (to put it kindly), how can we change it for the better?
I agree with pretty much every word of this article.