Democratising dev

I met up with a supersmart programmer friend of mine a little while back. He was describing some work he was doing with React. He was joining up React components. There wasn’t really any problem-solving or debugging—the individual components had already been thoroughly tested. He said it felt more like construction than programming.

My immediate thought was “that should be automated.”

Or at the very least, there should be some way for just about anyone to join those pieces together rather than it requiring a supersmart programmer’s time. After all, isn’t that the promise of design systems and components—freeing us up to tackle the meaty problems instead of spending time on the plumbing?

I thought about that conversation when I was listening to Laurie’s excellent talk in Berlin last month.

Chatting to Laurie before the talk, he was very nervous about the conclusion that he had reached and was going to share: that the time is right for web development to be automated. He figured it would be an unpopular message. Heck, even he didn’t like it.

But I reminded him that it’s as old as the web itself. I’ve seen videos from very early World Wide Web conferences where Tim Berners-Lee was railing against the idea that anyone would write HTML by hand. The whole point of his WorldWideWeb app was that anyone could create and edit web pages as easily as word processing documents. It’s almost an accident of history that HTML happened to be just easy enough—but also just powerful enough—for many people to learn and use.

Anyway, I thoroughly enjoyed Laurie’s talk. (Except for a weird bit where he dunks on people moaning about “the fundamentals”. I think it’s supposed to be punching up, but I’m not sure that’s how it came across. As Chris points out, fundamentals matter …at least when it comes to concepts like accessibility and performance. I think Laurie was trying to dunk on people moaning about fundamental technologies like languages and frameworks. Perhaps the message got muddled in the delivery.)

I guess Laurie was kind of talking about this whole “no code” thing that’s quite hot right now. Personally, I would love it if the process of making websites could be democratised more. I’ve often said that my nightmare scenario for the World Wide Web would be for its fate to lie in the hands of an elite priesthood of programmers with computer science degrees. So I’m all in favour of no-code tools …in theory.

The problem is that unless they work 100%, and always produce good accessible performant code, then they’re going to be another example of the law of leaky abstractions. If a no-code tool can get someone 90% of the way to what they want, that seems pretty good. But if that person than has to spend an inordinate amount of time on the remaining 10% then all the good work of the no-code tool is somewhat wasted.

Funnily enough, the person who coined that law, Joel Spolsky, spoke right after Laurie in Berlin. The two talks made for a good double bill.

(I would link to Joel’s talk but for some reason the conference is marking the YouTube videos as unlisted. If you manage to track down a URL for the video of Joel’s talk, let me know and I’ll update this post.)

In a way, Joel was making the same point as Laurie: why is it still so hard to do something on the web that feels like it should be easily repeatable?

He used the example of putting an event online. Right now, the most convenient way to do it is to use a third-party centralised silo like Facebook. It works, but now the business model of Facebook comes along for the ride. Your event is now something to be tracked and monetised by advertisers.

You could try doing it yourself, but this is where you’ll run into the frustrations shared by Joel and Laurie. It’s still too damn hard and complicated (even though we’ve had years and years of putting events online). Despite what web developers tell themselves, making stuff for the web shouldn’t be that complicated. As Trys put it:

We kid ourselves into thinking we’re building groundbreakingly complex systems that require bleeding-edge tools, but in reality, much of what we build is a way to render two things: a list, and a single item. Here are some users, here is a user. Here are your contacts, here are your messages with that contact. There ain’t much more to it than that.

And yet here we are. You can either have the convenience of putting something on a silo like Facebook, or you can have the freedom of doing it yourself, indie web style. But you can’t have both it seems.

This is a criticism often levelled at the indie web. The barrier to entry to having your own website is too high. It’s a valid criticism. To have your own website, you need to have some working knowledge of web hosting and at least some web technologies (like HTML).

Don’t get me wrong. I love having my own website. Like, I really love it. But I’m also well aware that it doesn’t scale. It’s unreasonable to expect someone to learn new skills just to make a web page about, say, an event they want to publicise.

That’s kind of the backstory to the project that Joel wanted to talk about: the block protocol. (Note: it has absolutely nothing to do with blockchain—it’s just an unfortunate naming collision.)

The idea behind the project is to create a kind of crowdsourced pattern library—user interfaces for creating common structures like events, photos, tables, and lists. These patterns already exist in today’s silos and content management systems, but everyone is reinventing the wheel independently. The goal of this project is make these patterns interoperable, and therefore portable.

At first I thought that would be a classic /927 situation, but I’m pleased to see that the focus of the project is not on formats (we’ve been there and done that with microformats, RDF, schema.org, yada yada). The patterns might end up being web components or they might not. But the focus is on the interface. I think that’s a good approach.

That approach chimes nicely with one of the principles of the indie web:

UX and design is more important than protocols, formats, data models, schema etc. We focus on UX first, and then as we figure that out we build/develop/subset the absolutely simplest, easiest, and most minimal protocols and formats sufficient to support that UX, and nothing more. AKA UX before plumbing.

That said, I don’t think this project is a cure-all. Interoperable (portable) chunks of structured content would be great, but that’s just one part of the challenge of scaling the indie web. You also need to have somewhere to put those blocks.

Convenience isn’t the only thing you get from using a silo like Facebook, Twitter, Instagram, or Medium. You also get “free” hosting …until you don’t (see GeoCities, MySpace, and many, many more).

Wouldn’t it be great if everyone had a place on the web that they could truly call their own? Today you need to have an uneccesary degree of technical understanding to publish something at a URL you control.

I’d love to see that challenge getting tackled.

Have you published a response to this? :

Responses

Baldur Bjarnason

“Adactio: Journal—Democratising dev” People keep assuming there is no middle ground between no automation and full automation. But I think that Flash and even Director managed to strike a nice balance there for a while adactio.com/journal/19356

1 Like

# Liked by Marty McGuire on Wednesday, August 10th, 2022 at 8:31pm

1 Bookmark

# Bookmarked by James' Coffee Blog on Thursday, August 11th, 2022 at 9:23am

Related posts

CSS Day 2024

A genuinely inspiring event.

Five questions

I gave five answers to Oliver, who’s organising the Pixel Pioneers event in Bristol.

Browsers

Something about a browser that grinds your gears? Share it!

Liveblogging An Event Apart 2019

Seventeen talks from three events.

FF Conf 2019

A report from Brighton’s unmissable annual front-end gathering.

Related links

The 11ty International Symposium on Making Web Sites Real Good - YouTube

I wasn’t able to tune into this live (“tune in?” what century is this?) but I’ve enjoyed catching up with the great talks like:

Tagged with

These are my jams · Paul Robert Lloyd

I like how Paul has recreated his own version of This Is My Jam and I really like how he’s done it with an HTML web component.

Tagged with

Pixel Pioneers Bristol 2023 Speaker Spotlight: Jeremy Keith

Oliver asked me some questions about my upcoming talk at Pixel Pioneers in Bristol in June. Here are my answers.

Tagged with

Web UI Engineering Book - toheeb.com

I like the way this work-in-progress is organised—it’s both a book and a personal website that’ll grow over time.

Tagged with

Changing with the times · Chris Burnell

I think, with the sheer volume of functionality available to us nowadays on the front-end, it can be easy to forget how powerful and strong the functionality is that we get right off shelf with HTML. Yes, you read that right, functionality.

Tagged with

Previously on this day

3 years ago I wrote Resigning from the AMP advisory committee

I gave it my best shot, but I gotta get out.

4 years ago I wrote Influence

An interesting idea from the birth of CSS.

5 years ago I wrote Crossing

I’m off to sea.

5 years ago I wrote Server Timing

Performance sluething.

6 years ago I wrote Flexibility

Web design is a two-way street. And that’s okay.

9 years ago I wrote dConstruct 2015 podcast: Ingrid Burrington

Time travel, terminators, and network infrastructure.

10 years ago I wrote Responding

A pair of responsive design events in London.

11 years ago I wrote August in America, day seven

Philadelphia, Pennsylvania.

12 years ago I wrote Laboratory conditions

The testlab setup.

21 years ago I wrote Reflections

There’s a new picture by Jessica up at The Mirror Project.

22 years ago I wrote Tales of the Plush Cthulhu

"After vigintillions of years plush Cthulhu was loose once more, and ravening for delight. How He slavered and gibbered! And the stuffed animals fled or went mad at the sight of Him."

22 years ago I wrote The Spiders

From E-Sheep comes one of the best comics I’ve read on or off the internet: The Spiders.