Ridiculously cute and fun—all in the browser.
A blog post from the future. I’m on board with the subgenre of speculative blogging.
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!
Tess calls for more precise language—like “site” and “origin”—when talking about browsers and resources:
When talking about web features with security or privacy impact, folks often talk about “first parties” and “third parties”. Everyone sort of knows what we mean when we use these terms, but it turns out that we often mean different things, and what we each think these terms mean usually doesn’t map cleanly onto the technical mechanisms browsers actually use to distinguish different actors for security or privacy purposes.
I’m glad I have this site to play with things, almost all web development and ‘front-end’ stuff leaves me cold these days. It’s all so process driven, so full of unnecessary complexities and dependencies, it’s as if the entire industry wants you to forget you can write HTML by hand and upload it somewhere and it’s a working website. It’s complexity for complexity’s sake, like what accountancy software companies did to the tax code: “Oh this is too complex you need to pay us lots of money to sort it out.” Annoying. I can see some resistance to it and there are still people making blogs and playing around with stuff, so hopefully the professional professionals will calm the fuck down at some point.
You might not think this is a big deal, and maybe it’s not, but I love the idea behind the indie web: a people-focused alternative to the corporate web. Seeing everything you’ve ever linked to in one place really drives home how much of the web’s content, made by individuals, is under corporate control and identity.
So my little mashup, which was supposed to be just 3 technologies ended up exposing me to ~20 different technologies and had me digging into nth-level dependency source code after midnight.
The technologies within technologies that Dave lists here is like emptying a bag of scrabble pieces.
The “modern” web stack really is quite something—we’ve done an amazing job of taking relatively straightforward tasks and making them complicated, over-engineered, and guaranteed to be out of date in no time at all.
The plumbing and glue code are not my favorite parts of the job. And often, you don’t truly know the limitations of any given dependency until you’re five thousand lines of code into a project. Massive sunk costs and the promise of rapid application development can come screeching to a halt when you run out of short cuts.
Trys ponders home repair projects and Postel’s Law.
As we build our pages, components, and business logic, establish where tolerance should be granted. Consider how flexible each entity should be, and on what axis. Determine which items need to be fixed and less tolerant. There will be areas where the data or presentation being accurate is more important than being flexible - document these decisions.
Why keep blogging? For me, there are at least 3 good reasons:
- To leave a trace.
- To figure out what I have to say.
- Because I like it.
I’ve thought about these questions for over a year and narrowed my feelings of browser diversity down to two major value propositions:
- Browser diversity keeps the Web deliberately slow
- Browser diversity fosters consensus and cooperation over corporate rule
A wonderful introduction to the indie web—Ana really conveys her sense of excitement!
This is wonderful! A whole series on the history of the web from Jay Hoffman, the creator of the similarly-themed newsletter and timeline.
This first chapter is right up my alley, looking at the origins of hypertext, the internet, and the World Wide Web.
A great little history lesson from Amber—ah, Firebug!
Matt has thoughts on RSS:
My sense is that RSS is having a mini resurgence. People are getting wary of the social media platforms and their rapacious appetite for data. We’re getting fatigued from notifications; our inboxes are overflowing. And people are saying that maybe, just maybe, RSS can help. So I’m seeing RSS being discussed more in 2020 than I have done for years. There are signs of life in the ecosystem.
But aren’t blogs dead? · Um, nope. For every discipline-with-depth that I care about (software/Internet, politics, energy economics, physics), if you want to find out what’s happening and you want to find out from first-person practitioners, you end up reading a blog.
Dense information from real experts, delivered fast. Why would you want any other kind?
Some good blogging advice.
Building a blog for the long run? Avoid Medium.
John weighs in on the clashing priorities of browser vendors.
Imagine if the web never got CSS. Never got a way to style content in sophisticated ways. It’s hard to imagine its rise to prominence in the early 2000s. I’d not be alone in arguing a similar lack of access to the sort of features inherent to the mobile experience that WebKit and the folks at Mozilla have expressed concern about would (not might) largely consign the Web to an increasingly marginal role.
This is about seamful design.
We need to know things better if we want to be better.
It’s also about progressive enhancement.
Highly sophisticated systems work flawlessly, as long as things go as expected.
When a problem occurs which hasn’t been anticipated by the designers, those systems are prone to fail. The more complex the systems are, the higher are the chances that things go wrong. They are less resilient.