A lot of new CSS features have shipped in the last years, but actual usage is still low. While there are many different reasons for the slow adoption, I think one of the biggest barriers are our own brains.

New feature fatigue

Permalink to “New feature fatigue” #

Right now, we’re in the middle of a real renai-css-ance (the C is silent). It’s a great time to write CSS, but it can also feel overwhelming to keep up with all the new developments.

Prominent voices at conferences and on social media have been talking about the new stuff for quite some time, but real-world usage seems to lag behind a bit.

Quick question: how many of these have you actively used in production?

• Container Queries
• Style Queries
• CSS Layers
• Subgrid
• Native CSS Nesting
• :has, :is, :where
• Dialog, Popover
• Logical Properties
• Scroll-Linked Animations
• View Transitions

👉 (Disclaimer: I’ve used one.)

All of these are very useful, and support for most is pretty good across the board - yet adoption seems to be quite slow.

Granted some things are relatively new, and others might be sort of niche-y. But take container queries, for example. They were the number one feature requested by front-end devs for a looong time. So why don’t we use them more, now that they’re finally here?

From my own experience, I think there’s different factors at play:

The support excuse

Permalink to “The support excuse” #

I can’t use [feature X], I need to support [old browser].

That old chestnut.
Browser support is an easy argument against most new things, and sometimes a convenient excuse not to bother learning a feature.

The answer there is usually progressive enhancement - except that’s easier to do for actual “enhancements”, if they are optional features that don’t impact the usability of a site that much.

For some of the new features, theres no good path to do this.

CSS Layers or native nesting for example are not something you can optionally use, they’re all-or-nothing. You’d need a separate stylesheet to support everyone.

And while support for Container Queries is green in all modern browsers, people still seem reluctant to go all-in, fearing they could break something as fundamental as site layout in older browsers.

Invisible improvements

Permalink to “Invisible improvements” #

Why use [feature X] if the usual way works fine?

Some of you might be old enough to remember the time when CSS3 features first hit the scene.

Things like border radius or shadows were ridiculously hard to do back in the day. Most of it was background images and hacks, and it required a substantial amount of work to change them.

Suddenly, these designs could be achieved by a single line of CSS.
Writing border-radius: 8px instead of firing up Photoshop to make a fucking 9-slice image was such a no-brainer that adoption happened very quickly. As soon as browser support was there, nobody bothered with the old way anymore.

A big chunk of the new features today are “invisible” though - they focus more on code composition and architecture.

Layers, Container Queries, etc are not something you can actually see in the browser, and the problems they solve may not be such an obvious pain in the ass at first glance. Of course they offer tremendous advantages, but you can still get by without using any of them. That might slow down adoption, since there is no urgency for developers to switch.

Examples and design trends

Permalink to “Examples and design trends” #

I don’t know where I would even use [feature X] in my project.

The initial use-case for container queries I always heard was “styling an element that could be in the main column or the sidebar”. I think that came from a very common WordPress blog design at the time where you had “widgets” that could be placed freely in different-width sections of the site.

Nowadays, the widget sidebar isn’t as common anymore; Design trends have moved on. Of course there are plenty of other use-cases for CQs, but the canonical example in demos is usually still a card component, and people seemed to struggle for a while to find other applications.

The bigger issue (most recently with masonry grids) is that sometimes the need for a CSS feature is born out of a specific design trend. Standards move a lot slower than trends though, so by the time a new feature actually ships, the need might not be that strong anymore.

Spec authors do a very good job of evaluating the long-term benefits for the platform, but they also can’t predict the future. Personally, I don’t think the new features are tied to any specific design - but I think it’s important to show concrete, real-world usecases to get the developer community excited about them.

Breaking the habit

Permalink to “Breaking the habit” #

Whatever the technical reasons may be, I guess the biggest factor in all of this are our own habits.

Our monkey brains still depend on patterns for problem solving - if we find a way of doing things that works, our minds will quickly reach for that pattern the next time we encounter that problem.

While learning the syntax for any given CSS feature is usually not that hard, re-wiring our brains to think in new ways is significantly harder. We’ll not only have to learn the new way, we’ll also have to unlearn the old way, even though it has become muscle memory at this point.

So how can we overcome this? How can we train ourselves to change the mental model we have for CSS, or at least nudge it in the new direction?

Re-thinking established patterns

Permalink to “Re-thinking established patterns” #

If we want to adopt some of the broader new architectural features, we need to find ways to think about them in terms of reusable patterns.

One of the reasons BEM is still holding strong (I still use it myself) is because it provides a universal pattern of approaching CSS. In a common Sass setup, any given component might look like this:

// _component.scss
.component {
    // block styles
    position: relative;

    // element styles
    &__child {
        font-size: 1.5rem;
    }

    // modifier styles
    &--primary {
        color: hotpink;
    }

    // media queries
    @include mq(large) {
        width: 50%;
    }
}

The BEM methodology was born in an effort to side-step the cascade. While we now have better scoping and style encapsulation methods, the basic idea is still quite useful - if only as a way to structure CSS in our minds.

I think learning new architectural approaches is easier if we take existing patterns and evolve them, rather than start from scratch. We don’t have to re-invent the wheel, just put on some new tyres.

Here’s an example that feels similar to BEM, but sprinkles in some of the new goodness:

/* component.css */

/* Layer Scope */
@layer components.ui {
    /* Base Class */
    .component {
        /* Internal Properties */
        --component-min-height: 100lvh;
        --component-bg-color: #fff;

        /* Block Styles */
        display: grid;
        padding-block: 1rem;
        min-block-size: var(--component-min-height);
        background-color: var(--component-bg-color);

        /* Child Elements, Native CSS Nesting */
        & :is(h2, h3, h4) {
            margin-block-end: 1em;
        }

        /* States */
        &:focus-visible {
            scroll-snap-align: start;
        }

        &:has(figure) {
            gap: 1rem;
        }

        /* Style Queries as Modifiers */
        @container style(--type: primary) {
            font-size: 1.5rem;
        }

        /* Container Queries for component layout */
        @container (min-inline-size: 1000px) {
            --component-min-height: 50vh;
            grid-template-columns: 1fr 1fr;
        }

        /* Media Queries for user preferences */
        @media (prefers-color-scheme: dark) {
            --component-bg-color: var(--color-darkblue);
        }

        @media (prefers-reduced-motion: no-preference) {
            ::view-transition-old(component) {
                animation: fade-out 0.25s linear;
            }
            ::view-transition-new(component) {
                animation: fade-in 0.25s linear;
            }
        }
    }
}

My preferred way of learning new techniques like that is by tinkering with stuff in the safe playground of a side project or a personal site. After some trial and error, a pattern might emerge there that sort of feels right. And if enough people agree on a pattern, it could even become a more common convention.

One step at a time

Permalink to “One step at a time” #

When learning new things, it’s important not to get overwhelmed. Pick an achieveable goal and don’t try to refactor an entire codebase all at once.

Some new features are good candidates to test the water without breaking your conventions:

You can try to build a subtle view transition as a progressive enhancement to your site, or you could build a small component that uses container queries to adjust its internal spacing.

In other cases, browser support also does not have to be 100% there yet. You can start using logical properties in your project today and use something like postcss-logical to transform them to physical ones in your output CSS.

Whatever you choose, be sure to give yourself enough space to experiment with the new stuff. The devil is in the details, and copy-pasting some new CSS into your code usually doesn’t give you the best insight - kick the tyres a bit!

Finding inspiration

Permalink to “Finding inspiration” #

One thing I’d really love to see more of are “best practice” examples of complete sites, using all the new goodness. They help me see the bigger picture of how all these new techniques can come together in an actual real-life project. For me, the ideal resource there are (again) the personal sites of talented people.

• How do they structure their layers?
• How do they set up containers?
• What sort of naming conventions do they use?
• What problems are they solving, and how does the new architecture improve things?

Answering these questions helps me to slowly nudge my brain into new ways of thinking about all this.

---

Having said all that: you absolutely don’t have to use all the latest and greatest CSS features, and nobody should feel guilty about using established things that work fine. But I think it helps to know which specific problems these new techniques can solve, so you can decide whether they’re a good fit for your project.

And maybe we can still learn some new CSS tricks after all.

Haven't done one of these since 2020, but this feels like a good opportunity to get some writing in just before the new year. Let's see if I can still remember how to do this blogging thing.

Work

Permalink to “Work” #

We built a lot of interesting projects in 2023 with Codista, and we’ve had a very good year working with established clients and partners. Some of it has been quite challenging, but we managed to pull off a stellar track record of successful projects, and I’m really proud of our small company!

We also hired our first front-end developer (other than myself). I’ve posted the job listing on our own website and on Mastodon, and with the help from the web dev community, we found somebody who fits our team really well and I’m very happy with them. A big thanks to everyone who boosted the post or mentioned it at meetups!

Health

Permalink to “Health” #

I’ve struggled a bit with personal health issues this year. I have a moderately severe form of atopic dermatitis, an auto-immune disease of the skin. I’ve had it all my life. Some days it feels OK, while on others it feels like my skin is on fire and it’s hard to concentrate on anything else besides the impulse to scratch. If you’ve ever seen me give a talk and my face was bright red, it’s not (only) because I’ve been drinking the night before.

When I was younger I’ve tried different forms of therapy, but none of them really worked - so I’ve become pretty much used to living with it. But then it got a lot worse in 2023. I couldn’t sleep properly anymore and it started to affect other areas of my life, so I decided to take another shot at fighting it.

I got a new doctor and started treatment with a new drug that recently got EMA approval. After half a year, I switched to a different drug, which I’m currently still evaluating. First results have been promising though, so fingers crossed that this is the one. Would certainly make my 2024 more pleasant.

Traveling

Permalink to “Traveling” #

I was fortunate enough to see some beautiful places this year. Event though my pre-pandemic days of traveling the more remote parts of the world are likely over, it’s still nice to get out and explore again.

I went to Zurich for a client workshop in the spring, and immediately followed that up with a trip to Amsterdam for CSS Day 2023. That conference was one of the best I’ve ever been to. Even though I caught a pretty bad cold and had to skip some of the fun - the talks, people and just overall atmosphere of that event were amazing.

I’m grateful I got to see so many familiar faces and talk to some of my web friends in person. I also left the conference feeling very inspired and (as always) a little guilty that I can’t find enough time for community work and writing. Hopyfully next year my schedule will allow for a bit more of that.

In the summer, we went for a vacation in the south of Croatia and spent two weeks on the Dalmatian coast.

We also did some more work on our small garden house in Lower Austria and had a few lovely days in autumn hiking the surrounding hills and vineyards.

Music, Movies, Books and Stuff

Permalink to “Music, Movies, Books and Stuff” #

I enjoyed lots of stuff this year, so I’ll just give you the top 3 of each:

Music

Permalink to “Music” #

• GoGo Penguin (Jazz/Fusion)
• Run The Jewels (Hip Hop)
• Broken Bells (Indie Rock)

Movies

Permalink to “Movies” #

• Renfield (Horror/Action)
• Everything, Everywhere, All at once (Action/Sci-Fi)
• Barbie Movie (Comedy)

Books

Permalink to “Books” #

• “The Expanse” by James S.A. Corey (9-part Series, Sci-Fi)
• “Felix Blom” by Alex Beer (German, Thriller)
• “Novacene” by James Lovelock (Non-Fiction)

Stuff

Permalink to “Stuff” #

• Anker Nebula Capsule Max - a great portable projector the size of a beer can, supports streaming and external drives
• Fender Paramount PD-220E - acoustic guitar I got after my old one was stolen. really bright, warm sound
• Superdry Sports Puffer - just a nice comfy winter jacket

Tech

Permalink to “Tech” #

I think I’ve grown a bit weary of the tech industry this year. I still love the web and I love what I do for work, but I lost some of my interest in new developments, new frameworks, the hot tech of the day. I just don’t care as much anymore.

It may also be the rising topic of AI that is popping up everywhere you look, or the crypto-esque attitude that seems to go along with it. Instead of being excited about new possibilites, I feel a bit disheartened by the trends I see. AI looks like a great tool, but everything I read about how it’s actually applied comes from the same hyper-captitalist mindset that brought us gems like bitcoin mining and NFTs. I don’t know, maybe I’m just tired.

There are other trends as well that I feel more optimistic about. Ones that call for a weirder web with more original, human content. It could just be wishful thinking, but I’ve caught glimpses of that version of the future for a while now. Here’s hoping.

Well, that’s all folks. See you in 2024!

I have recently been made aware that the frequency of new content published on my site has gone down quite a bit.

Ok fine, I trash-talked Manuel’s website on Mastodon and he correctly pointed out that while I wrote an impressive two (2) blogposts last year, he wrote around 90 (while also doing talks, audits, raising an infant daughter and probably training for a marathon or some shit like that, I mean let’s face it the guy is annoyingly productive).

I know I was slacking off a bit and those numbers speak for themselves. While I generally want to write, ideas rarely make it all the way to a published post.

Like many others, “write more” is high up on my imaginary list of life improvements and although I don’t usually do new year’s resolutions, now feels like a good time to re-evaluate what’s stopping me there.

I came up with seven reasons that I use to justify why I’m not writing. In a confusing twist of perspective, I’m also going to try and talk myself out of them by explaining to you, dear Reader, why they are bullshit.

I don’t have time

Permalink to “I don’t have time” #

This is the big one, right? We all have other things to do, and writing takes time. In my case, I’ve been really swamped with client projects and other work last year.

I think if you actually want to write though, it’s more a lack of routine than a lack of time itself. People who consistently produce content have learned to make a habit out of it. I read “Atomic Habits” by James Clear a couple of months ago and its message kinda stuck with me. It’s about conditioning yourself to do certain things more often by building a routine.

Take 15 minutes every day before you check your email and just write. Or do it on your commute to work if possible! The trick is to use amounts of time that are so small you can’t possibly not fit them in your schedule. It may not be enough for a fully-fledged article, but enough to build a habit.

It’s also worth noting that your writing doesn’t always have to be well-crafted longform blogposts. It can just be a few paragraphs about your thoughts, linking out to other stuff. Chris does a great job at this, and others have recently adopted even shorter formats, mimicking social media posts in length.

I don’t have anything interesting to say

Permalink to “I don’t have anything interesting to say” #

The classic impostor syndrome comes out here. I don’t know anything special, so why bother?

The truth is that everyone has something interesting to say because everyone faces different challenges. You don’t have to go viral and make buzzword-riddled thinkpieces about the current hot topic - There’s enough sites who already do that, and AI will soon produce a shitton more of it.

A better plan is to write about what you know and experience in your day-to-day life instead. Authentic posts are always helpful, and you will solidify your own knowledge in the process too.

Here are a few common writing prompts and examples for blogposts I love to read:

• “I learnt something” (TIL)
  Michelle Barker: Negative Animation Delay
• “I noticed something”
  Dave Rupert: I’m Shadow Banned by DuckDuckGo (and Bing)
• “I built something”
  Lynn Fisher: lynnandtonic.com Refresh
• Year in Review
  Sophie Koonin: 2022: The year in lists
• Personal Stuff!
  Cassie Evans: My typical day

I gotta fix [X] on my site first

Permalink to “I gotta fix [X] on my site first” #

This one is especially popular among developers. “How can I possibly write anything before the typography is perfect? How can I ever publish anything when comments are not implemented yet?” We love to tinker with our websites and that’s cool, but at some point it gets in the way of actually using your blog and creating content.

Despite what we tell ourselves, it really doesn’t matter too much how a blog looks or what features it has. People come for the content, and as long as they can read it, they’re happy. Throw in an RSS feed so everyone can use their own reader and you’re golden. It pains me to say it but Manuel is absolutely correct here.

And if he can be “redesigning in the open” for three years while churning out massive amounts of CSS knowledge, your site will be fine too. 😉

Others have already written about this

Permalink to “Others have already written about this” #

Sometimes I’ve got a great idea for a post, but an initial Google search reveals that someone else already beat me to it. The novelty has worn off and that other post is way better than what I could have come up with anyway, I tell myself.

That’s not a real reason of course, nobody has a monopoly on a subject. Others may have already covered the topic - but not in your voice, not from your perspective. You could write a post about the exact same thing and still provide valuable information the other author has missed. Or you could approach the subject from a different angle, for a different skill-level or for a different audience.

Another way is to read the material that is already available and take notes about all the questions you still have afterwards. Try to actually do the thing (write the code, use the app, whatever) and see what other information would have been helpful for you to have. Write that!

The moment for this has passed

Permalink to “The moment for this has passed” #

There are writing ideas that are inspired by some event or conversation. Maybe something big happened on the web or I’ve had a particularly interesting discussion on social media. So I sketch out a quick outline for a post and stick it in my drafts folder, thinking I’ll get back to it later.

Three weeks pass and that lonely draft sits around gathering dust, and by the time I remember it, the moment has passed. The conversation has moved on, and so the post is abandoned and eventually deleted.

The internet moves pretty fast and there’s always a “hot topic of the day”, but that doesn’t mean that nobody is interested in anything else. A beautiful thing about blogs is that they’re asynchronous. You can just write things and put them out there, and even if they don’t hit a nerve immediately, people can discover them in their own time.

Older posts can also get re-discovered years later and get a second wind, not to mention that people constantly search for specific things - and your post might be just what they’re looking for then! Some of my old posts about webrings and the IndieWeb have recently found readers again since Twitter has started going down the drain. You never know!

I can’t get it to sound right

Permalink to “I can’t get it to sound right” #

Most of the (tech) blogs I read are in English, even though its authors are from all over the world. For a non-native english speaker like myself, it can sometimes be daunting to write in a foreign language. This is a barrier when it comes to producing “polished” text - there’s extra brain cycles involved in getting your ideas to “sound” right.

This is probably not a big deal though. People don’t expect to read world-class literature when they come to check out a blogpost about “Lobster Mode”. As long as you can get your point across, it’s fine if you don’t use fancy words. It can also be an advantage: for an international audience, simple English might even be easier to understand.

That being said, this is a usecase where AI might actually be helpful! While LLMs like GPT-3 and co are useless at creating actual content or original thoughts, they’re great at making sentences sound nice. Tools like Jasper can rewrite your copy and improve the tone without changing the contained information. Sort of like prettier but for English prose.

Nobody’s going to read it anyway

Permalink to “Nobody’s going to read it anyway” #

Let’s be honest: nobody likes to shout into the void. Everyone wants their content to be seen, and social validation is the sweet sweet dopamine reward we all crave.

There’s nothing wrong with sharing your work on social media or popular orange link aggregators either, but sometimes there just won’t be much of a reaction after you publish. That can feel frustrating - but ultimately I think obesessing over vanity metrics is not worth it anyway. Just because something doesn’t make the frontpage of Reddit does not mean it’s not valuable.

Don’t underestimate how many people actively read personal blogs though! The web dev community is especially fond of RSS, and with the Fediverse gaining more and more popularity, original content on your own domain has a much better reach now than before.

Who’s gonna read your personal blog because it has an RSS feed? I’m gonna read your personal blog because it has an RSS feed. pic.twitter.com/mtcyKhEVet

— Chris Coyier (@chriscoyier) January 7, 2020

Right, I realize it’s a bit weird to write a post about how I don’t write posts. But I hope to push back on this in 2023 and find more time for writing. I also suspect that other people have similar reasons and maybe talking about them helps a bit.

In any case, that’s one more post in the bank!

Dear Reader,

Since there’s a good chance that you -like me- are involved in web development and/or have a special interest in technology, I want you to play along and engage in a thought experiment for this post:

Imagine you’re a regular user.

Imagine you have never heard of git branches, postgres or a “webpack config” (lucky you). You really don’t care about all of that, but you do care about your friends and your connections online.

Ever since Elon took over (and actually even some time before that) Twitter has been feeling increasingly hostile. People start leaving, and you hear them talk about alternatives. You’re curious, so you type “mastodon” into Google and see what comes up.

You find the website and want to sign up. It tells you to choose a server:

Ok wait, you wanted to join mastodon, what’s all this now? Tildes? Furries? Some Belgian company? Why do you have to apply? Everyone else had that mastodon.social handle - Can’t you just use that? The real one? What the hell is a fediverse?

Confused, you close the site. This seems like it’s made for someone else. Maybe you’ll stick around on Twitter for a while longer, while it slowly burns down.

---

You can be a developer again now.

You and I know the reasons for that experience. We know that a decentralized system has to look like this, and that the choice of instance doesn’t even matter all that much. But I’ve heard this exact story a couple of times now, all from people outside my IT filter bubble.

Why was it so easy to drive these people away?

The Web as a Commodity

Permalink to “The Web as a Commodity” #

Being on the web has been heavily commoditized.

In the days of IRC and message boards, or later in the 2000s blogging era, federation was very much the norm. It was the default mode of the web: people grouping together in small communities around shared interests, but scattered on many different sites and services. It was normal to explore, find new places and discover new things by venturing out.

Through the rise of social media though, people have gotten used to being in one place all the time. Now we expect a system that’s easy to set up, handles millions of users at once and makes every interaction frictionless. We expect it to know what we want, and give it to us instantly. Anything too weird or tech-y and you start to lose people.

Mastodon is not supposed to be a second Twitter. Many of its features were designed specifically to avoid becoming another content silo and repeating the same mistakes, yet the assumption seems to be that everything should stay the same as before.

It’s like everyone has spent the last few years in a giant all-inclusive resort, screaming at each other for attention at the buffet. Now we’re moving into nice little bed-and-breakfast places, but we’re complaining because it takes slightly more effort to book a room, and the free WIFI isn’t as fast.

Maybe its time to rethink some of these expectations. Maybe we need some of that early internet vibe back and be ok with smaller, closer communities. Maybe we can even get some of the fun back and start exploring again, instead of expecting everything to be automatically delivered to us in real time.

We can remind ourselves of what social media used to be: a way to connect around shared interests, talk to friends, and discover new content. No grifts, no viral fame, no drama.

Lowering the Barrier

Permalink to “Lowering the Barrier” #

Adjusting expectations is one part - but at the same time, we as developers have to try and make these systems as approachable as possible without compromising on their independence. A lot of alternative content publication methods are still very much geared towards the IT bubble.

You could loosely map some of them by how easy it is to get started if you have no technical knowledge:

Generally speaking: The more independence a technology gives you, the higher its barrier for adoption.

I love the IndieWeb and its tools, but it has always bothered me that at some point they basically require you to have a webdevelopment background.

How many of your non-tech friends publish RSS feeds? Have you ever seen webmentions used by someone who isn’t a developer? Hell, even for professional devs it’s hard to wire all the different parts together if you want to build a working alternative to social media.

If you want the independence and control that comes with some of these IndieWeb things, you just have to get your hands dirty. You can’t do it without code, APIs, servers and rolling your own solutions. It’s just harder.

My point is this: it shouldn’t be.

Owning your content on the web should not require extensive technical knowledge or special skills. It should be just as easy as signing up for a cellphone plan.

I know it’s no small feat to lower that barrier. Making things feel easy and straightforward while handling the technical complexity behind them is quite a challenge. Not to mention the work and financial cost involved in running systems that don’t generate millions of ad revenue.

Mastodon, Ghost, Tumblr, micro.blog and others are working hard on that frontier; yet I feel they are still not widely used by the average person looking to share their mind.

Seizing Momentum

Permalink to “Seizing Momentum” #

I think we’re at a special moment right now. People have been fed up with social media and its various problems (surveillance capitalism, erosion of mental health, active destruction of democracy, bla bla bla) for quite a while now. But it needs a special bang to get a critical mass of users to actually pack up their stuff and move.

When that happens, we have the chance to build something better. We could enable people to connect and publish their content on the web independently – the technology for these services is already there. For that to succeed though, these services have to be useable by all people - not just those who understand the tech.

Just like with migration to another country, it takes two sides to make this work: Easing access at the border to let folks in, and the willingness to accept a shared culture - to make that new place a home.

When I first fell in love with the web, it was a radically different place. Aside from the many technical improvements that have been made, I feel like the general culture of the web has changed a lot as well.

Growing up with the web as a teenager meant having access to an infinite treasure chest of content. A lot of that content was spread across blogs, forums and personal websites.

The overwhelming motivation behind it seemed to be “I made something, here it is”. Sharing things for the sake of showing them to the world. Somebody had created something, then put it online so you could see it. Visit their website (wait for the dial-up to finish), and it’s yours.

Follow any link on the web today and you’ll likely be met with a different scenario:

• Cookie consent pops up, intentionally confusing.
  (You're tired - just hit "Accept All".)
• App download banner asks you to install the native app.
  (Dismiss.)
• Newsletter modal blocks the site, asking for your email address. (Close it.)
• Start reading a few paragraphs, before another modal requires you to create an account. (Leave site, frustrated.)

Notice how everything about that interaction is designed to extract value from your visit. The goal here is not for you to read an article; it’s to get your analytics data, your email, your phone and your money.

It’s the symptom of a culture that sees the web purely as a business platform. Where websites serve as eloborate flytraps and content as bait for unsuspecting users.

In this culture, the task of the self-appointed web hustler is to build something fast & cheap, then scale it as much as possible before eventually cashing out.

• You see it in email bots, spamming blogs for link placements and sponsored posts.
• You see it in Twitter accounts where grifters try to monetize their “communities” with useless ebooks.
• You see it in crypto, burning the planet for quick profits.

web3 and NFTs are the latest evolution of this culture. The latest attempt to impose even more artificial locks and transactions on users, to extract even more money.

This is the web as envisioned by late-stage capitalism: a giant freemium game where absolutely everyone and everything is a “digital asset” that can be packaged, bought and sold.

---

Don’t bring wall street to a web fight

Permalink to “Don’t bring wall street to a web fight” #

Sure, the web has changed since the 90s. It has “grown up”.

Of course there are lots of legitimate reasons to monetize, and creators deserve to be compensated. It’s not about people trying to make a buck. It’s about those treating the web simply as a market to run get-rich-quick schemes in, exploiting others out of pure greed.

We’ve gotten so used to it that some can’t even imagine the web working any other way - but it doesn’t have to be like this.

At its very core, the rules of the web are different than those of “real” markets. The idea that ownership fundamentally means that nobody else can have the same thing you have just doesn’t apply here. This is a world where anything can easily be copied a million times and distributed around the globe in a second. If that were possible in the real world, we’d call it Utopia.

It’s also a world that can be shaped by the consumer:

Large companies find HTML & CSS frustrating “at scale” because the web is a fundamentally anti-capitalist mashup art experiment, designed to give consumers all the power.

Sorry I didn’t quote tweet anything in order to say that.

— Mia, with valuable secrets 🤫 (@TerribleMia) November 24, 2019

This “mashup art experiment”, as Mia calls it, is what made the web great in the first place. It’s the reason it became a global phenomenon and much of it is centered around the idea that digital content is free and abundant.

Resource Scarcity doesn’t make sense on the web. Artificially creating it here serves no other purpose than to charge money for things that could easily have been free for all. Why anyone would consider that better is beyond me.

Freedom of content

Permalink to “Freedom of content” #

The online game Wordle recently took the world by storm. To the utter shock of many, it is just a free piece of content. A free and open web game millions can enjoy, no strings attached.

Its creator, Josh Wardle, originally built the game for his partner and put it online. “I made something, here it is”. Despite its success, he had no intention to monetize it through apps or subscriptions - and the world is richer for it. When questioned about it, he said this:

I think people kind of appreciate that there’s this thing online that’s just fun. It’s not trying to do anything shady with your data or your eyeballs. It’s just a game that’s fun.

Because the notion that monetization is the only worthwhile goal on the web is so widespread, this is somehow a very controversial take. You can actually stand out of the crowd by simply treating the web platform as what it is: a way to deliver content to people.

Despite what web3 claims, it’s possible to “own” your content without a proof of it on the blockchain (see: IndieWeb). It’s also possible to create things just for the sake of putting them out into the world.

The best growth hack is still to build something people enjoy, then attaching no strings to it. You’d be surprised how far that can get you.

Make free stuff! The web is still for everyone.

👉 Update: On Feb 1, Wordle was eventually sold to the New York Times for upwards of a million dollars. Josh Wardle claims the game will still remain free to play for all.