Notes

The web platform moves slowly, and I understand that can be frustrating for developers who want to innovate, but over a decade of consultancy experience has taught me time and time again that the alternative is much more restrictive in the long run. What’s brand new today starts to show its age much more quickly than something that’s already stood the test of time.

Every layer of abstraction made in the browser moves you further from the platform, ties you further into framework lock-in, and moves you further away from fast.

At work we have to keep a close eye on the dependencies we use and have to regularly update them when vulnerabilities arise. Some libraries are good about fixing vulnerabilities without any breaking changes. Others, not as much. We should probably rip some code out and do when we can, but tech debt can be a real pain in the ass.

It's really amazing how well HTML, CSS, & vanilla JavaScript hold up. Sites built years ago still work and render today.

One of the running jokes and/or discussion I am sick and tired of is people belittling HTML. Yes, HTML is not a programming language. No, HTML should not just be a compilation target. Learning HTML is a solid investment and not hard to do.

No matter how you create things for the web, the end product will be HTML. Either HTML generated on the server or with JavaScript. With AI search bots not rendering JavaScript yet maybe this is a good time to re-learn what HTML can do for you. It has not let me down in over 25 years, whereas lots of other “magical solutions” did.

Google killed Reader before it had the chance to reach its full potential. But the folks who built it saw what it could be and still think it’s what the world needs. It was never just an RSS reader. “If they had invested in it,” says Bilotta, “if they had taken all those millions of dollars they used to build Google Plus and threw them into Reader, I think things would be quite different right now.”

I used Google Reader quite a bit. I loved it and was sad when Google killed it. It had so much potential. That said, while I might be nostalgic towards it, it’s certainly possible Google would’ve enshittified it if they kept it around and built onto it. Who knows what privacy nightmare we would be in. In the end, I use Feedbin and am quite happy with it and its functionality.

At the end of the day, Google Reader might not be around anymore, but its influence still is.

Code that runs on the client, by contrast, is running on The Devil's Computer.2 Almost nothing about the latency, client resources, or even API availability are under the developer's control.

Client-side web development is perhaps best conceived of as influence-oriented programming. Once code has left the datacenter, all a web developer can do is send thoughts and prayers.

Too many people, including me sometimes, assume everyone has a computer with nearly unlimited computing power.

Frameworkism insists that all problems will be solved if teams just framework hard enough. This is non-sequitur, if not entirely backwards. In practice, the only thing that makes web experiences good is caring about the user experience — specifically, the experience of folks at the margins. Technologies come and go, but what always makes the difference is giving a toss about the user.

I still use React at work, and while I don’t hate it, it’s definitely not the first tool I reach for anymore.

In short, nobody should start a new project in the 2020s based on React. Full stop.

So my advice is two-fold. First, make art. Join a choir or pottery class. Start painting, make weird novelty websites.

And second: enjoy art. Get out to your local theaters, museums, music venues… they are the best thing to spend your money on.

I’d highly recommend reading all the slides, they’re fantastic.

But the plan to use hardware from previous space programs is a bit cobbled together. The Space Launch System, for instance, was originally designed for the Constellation program, a strategy set up under the George W. Bush administration to finish building the International Space Station and to reestablish a human presence on the moon. Congress mandated that the rocket reuse technology from the then defunct space shuttle program. But Obama canceled Constellation in 2010, and in 2017 Trump anointed the Artemis program, with the goal of finally sending people back to the moon and paving the way for exploring Mars. Again, the new plan required that NASA use some of the technology that had been developed for Constellation, which in turn entailed repurposing old space shuttle technology. These mandates were pushed by congresspeople representing regions that housed manufacturing centers for shuttle parts. But the carryover and conversion of those technologies have proved difficult. According to a report from the NASA inspector general, bringing the rocket parts into the modern era—for instance, replacing asbestos parts—and retrofitting them for a new rocket system has cost much more than anticipated.

Leave it to congress to throw a wrench in things.

As Rebecca Giblin and I write in our 2022 book Chokepoint Capitalism, giving more rights to a creative worker who has no bargaining power is like giving your bullied schoolkid more lunch money. No matter how much lunch money you give that kid, the bullies will take it and your kid will remain hungry. To get your kid lunch, you have to clear the bullies away from the gate. You need to make a structural change:

Or, put another way: people with power can claim rights. But giving powerless people more rights doesn't make them powerful – it just transfers those rights to the people they bargain against.

Or, put a third way: "just because you're on their side, it doesn't follow that they're on your side"

But, what does it actually mean to work in an medium that is so temporary? How does it shape us? When your work can literally disappear at any given moment, how do you reason with the effort that went into producing it?

Sometimes our work is fleeting.

It's funny that, as developers, we often talk about "legacy code". For us though, the word "legacy" isn't used in terms of something to preserve the past. More often than not, "legacy code" is something to be refactored, replaced or removed altogether in the name of progress. Without necessarily realising it, we have unconsciously accepted the temporary nature of our work into the language of our industry.

A dev knowing the web platform will produce great websites regardless of the tech stack. At the end, there's "just" web stuff below all the framework magic, right?

A framework developer, on the other hand, might have a hard time switching frameworks, reaching for simple solutions or delivering high-quality websites without the entire JavaScript ecosystem. And I've seen this exact problem plenty of times.

Again, I find these debates a bit tiresome. I think the fundamental issue, as I’ve previously said, is that people are talking past each other because they’re building different things with different constraints. It’s as if a salsa dancer criticized ballet for not being enough like salsa. There is more than one way to dance!

Nolan makes some good points talking about where web components work well, and where they fall short. "It depends" is an oft-used statement and I think far too often we miss the point that there are multiple ways to build things. Some methods and tooling are better than others in certain use cases, some are not. Rather than constantly arguing with one another over the minutia, we should go with what works best for us at the given time.

In terms of the language, which is where I'm more centered up, breaking changes is a very big deal. One of the things I drive home for the compiler team that's very much on my mottos is the number one feature of C# is compatibility. It's like, we very much want the experience of you are not afraid to move to new version of .NET. You're not afraid to buy a new version of Visual Studio, because you know your code is going to keep compiling. We will not break you. We will make sure that unless you have done something absolutely extreme, it's just going to work. That is indeed our number one feature.

As a .NET developer, I greatly appreciate how much work the C# language team puts in to making sure your apps just keep working when you update .NET. The app I work on at work started out as a .NET Core 3.1 Web API. We have since updated it to .NET 6, and now .NET 8. Both updates were smooth with minimal, if any issues.

It really is kind of amazing that we were able to take advantage of all the performance benefits of .NET 6 and then .NET 8 without having to do a lot of work.

Applets. ActiveX. Flash. Flex. Silverlight. Angular. React.

Through all of it, Web Standards continue to thrive. HTML, CSS, and JavaScript have never moved fast enough because collaboration and agreement isn’t easy or fast. Web Standards aren’t thriving because of any magical feature or capability. They’re thriving because of agreement and compromise.

Through it all, HTML, CSS, and vanilla JavaScript have been constant. The ease with which any human on the planet can reliably access and read a web document from thirty years ago on any device with a browser today is beyond beautiful.

On the other hand, when creations from less than a year ago require making changes to the original document, untangling and upgrading a rat’s nest of conflicting dependencies, installing a specific version of a runtime or build tool, and then figuring out how to open it on a device that may or may not support it, isn’t a formula for success.

Libraries come and go. HTML standards roll out slowly but better stand the test of time.