Keith Wagner

Notes

Here you'll find short blurbs about interesting articles or blogs from others I've read and wanted to note.

The Importance of Investing in Soft Skills in the Age of AI

The path to becoming a truly great developer is down to more than just coding. It comes down to how you approach everything else, like communication, giving and receiving feedback, finding a pragmatic solution, planning — and even thinking like a web developer.

So much of working in the real world involves trade-offs between the various departments. Being able to communicate well is so important to be able to work with the other teams so you can get the best solution deployed while keeping everyone (mostly) happy.

Boring Tech is Mature, Not Old

Boring tech behaves in predictable ways. It’s a well trodden path others have evaluated, optimised, troubleshooted, and understood. Using tech that has been subjected to all those people hours of use means you’re less likely to run into edge cases, unexpected behaviour, or attributes and features that lack documentation or community knowledge. In other words, when something goes wrong, can you turn to someone or something?

There's sometimes something to be said about using technology that's been around for a while. Chances are, someone has run into the same problem you're facing and knows a solution or work-around.

This isn’t to say there isn’t room for innovation, or that staying put is a guaranteed recipe for success. What it does teach is that it pays to make informed decisions, and that often times the understood, reliable, boring tech will get you there over something new, shiny or propped up with marketing spin.

Also true, be mindful of the choices you make. New isn't necessarily bad, but it isn't always better.

HTML Is Actually a Programming Language. Fight Me

But underestimating HTML is a mistake.

HTML is the most significant computing language, programming or otherwise, ever developed. Every other programming language has to grapple with how HTML has redefined computing over the past 30-plus years. So many “pure” programming languages automate the production of more and more HTML.

I remember playing with HTML first with Geocities, I never thought of it as anything other than programming.

What other programmers might say dismissively is something HTML lovers embrace: Anyone can do it. Whether we’re using complex frameworks or very simple tools, HTML’s promise is that we can build, make, code, and do anything we want.

The Twitter Files Playbook Comes For The US Government

This pattern of manufactured outrage points clearly to what’s coming next. I fully expect that we’ll get a functional equivalent of “The Twitter Files.” Just as when Musk took over Twitter, and insisted that the old management was up to all sorts of no good, from being infused with “woke” ideology to government infiltration.

His playbook then was simple: hand-pick credulous journalists, give them selective access to internal documents, and let confirmation bias do the rest.

We reported extensively on what was revealed in “The Twitter Files” and the answer was abso-fucking-lutely nothing. The documents revealed thoughtful policy discussions and principled content moderation approaches, not the scandal Musk promised.

Yet thanks to relentless repetition by right-wing media and congressional allies, many remain absolutely 100% convinced the Twitter Files exposed massive wrongdoing on an epic scale.

Now, we should expect the same with this government takeover. These rumors and nonsense about USAID and other agencies will lead to some of the most absolute bullshit reporting in a long while. Elon will have little trouble finding willing amplifiers for his narratives.

Just as the Twitter Files transformed routine content moderation into imaginary censorship campaigns, mundane government operations will become evidence of sinister plots.

Meanwhile, mainstream media will likely fall into their familiar trap of false equivalence, wrapping obviously false claims in the careful language of “allegedly” and “according to reports,” rather than directly challenging the premise.

This is sadly what I expect as well, Musk promoting his bullshit, and the media just repeating it without any critical thought.

There Is No Going Back

To describe the current situation in the executive branch as merely a constitutional crisis is to understate the significance of what we’re experiencing. “Constitutional crisis” does not even begin to capture the radicalism of what is unfolding in the federal bureaucracy and of what Congress’s decision not to act may liquidate in terms of constitutional meaning

And the conclusion is what gets me.

And so the president’s opponents, whoever they are, cannot expect a return to the Constitution as it was. Whatever comes next, should the country weather this attempted hijacking, will need to be a fundamental rethinking of what this system is and what we want out of it.

Anything less will set us up for yet another Trump and yet another Musk.

Build for the Web, Build on the Web, Build with the Web

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.

Learning HTML is the Best Investment I Ever Did

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.

Who Killed Google Reader?

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.

If Not React, Then What?

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.

Creativity Cannot Be Computed

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.

Why Is It So Hard to Go Back to the Moon?

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.

Harpercollins wants authors to sign away AI training rights

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"

Legacy Code

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.

On being a "JavaScript framework developer"...

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.

Web Components are Okay

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.

C# Compiler and Language Design at Microsoft with Jared Parsons

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.

The Neverending Story

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.

Web Components are not Framework Components — and That’s Okay

Web platform features operate under a whole different set of requirements and constraints:

  • They need to last decades, not just until the next major release.
  • They need to not only cater to the current version of the web platform, but anticipate its future evolution and be compatible with it.
  • They need to be backwards compatible with the web as it was 20 years ago.
  • They need to be compatible with a slew of accessibility and internationalization needs that userland libraries often ignore at first.
  • They are developed in a distributed way, by people across many different organizations, with different needs and priorities.

Usually, the result is more robust, but takes a lot longer. That’s why I’ve often said that web standards are “product work on hard mode” — they include most components of regular product work (collecting user needs, designing ergonomic solutions, balancing impact over effort, leading without authority, etc.), but with the added constraints of a distributed, long-term, and compatibility-focused development process that would make most PMs pull their hair out in frustration and run screaming.

Someone Put Facial Recognition Tech onto Meta's Smart Glasses to Instantly Dox Strangers

A pair of students at Harvard have built what big tech companies refused to release publicly due to the overwhelming risks and danger involved: smart glasses with facial recognition technology that automatically looks up someone’s face and identifies them. The students have gone a step further too. Their customized glasses also pull other information about their subject from around the web, including their home address, phone number, and family members.

Oh boy. Having read Your Face Belongs to Us by Kashmir Hill last year, this doesn't surprise me. The genie is out of the bottle and I'm not quite sure how best to go about protecting ourselves from stuff like this.

I feel like a federal privacy law is a definite need, but I'm not sure how much that would go about stopping the dangers associated with this.

Personal Websites Are As Vulnerable As Us

I look at some people’s personal websites and think, “Stupendous! If I ever reach that zenith of personal web design, I will call it quits.”

Then I read a post by them later and they say something like, “Gah! I just really don’t like where I’m at with my personal website.”

I'm not a design wizard. I can often tell good design from bad, but I'm always wishing I could do better, and try to.

It’s like our personal websites are a mirror to ourselves — a place where the mind’s eye must reconcile with the optical eye’s perception of reality.

It’s a torturous affair, to be sure.

And yet, people still publish those personal sites, those redesigns, those half-baked ideas.

I love this. Personal sites are awesome and I'm always trying to better mine. I love seeing others do the same.

Older Notes →