Reading List

The most recent articles from a list of feeds I subscribe to.

Educational Products: Month 9

Highlights

  • I look for ways to limit the number of half-complete tasks I’m juggling.
  • I brainstorm ways to talk with more of my early readers.
  • I have trouble accepting a design decision in the Gleam language.

Goal grades

At the start of each month, I declare what I’d like to accomplish. Here’s how I did against those goals:

Offer a lower-friction way for users to pre-order my book

  • Result: Switched from Kickstarter pre-orders to Stripe payment links.
  • Grade: A

I ran the initial pre-sale through Kickstarter, so I decided to just stick with it for subsequent pre-orders. After a couple of months, I realized Kickstarter requires customers to create an account to buy the book, which adds a lot of friction and discourages people from buying.

Day Zero Activities of WeAreDevelopers World Congress tomorrow

Hi there, I am currently slightly freaking out as this week is the WeAreDevelopers World Congress in Berlin and I am moderating the main stage with 23 talks in two days and still have to write the closing keynote. Officially the event starts on Thursday, but if you are already in Berlin tomorrow, I put […]

Influence the State of HTML 2025 Survey!

State of HTML 2025
Mamma mia, here we go again!

Two years ago, I was funded by Google to design the inaugural State of HTML survey. While I had led State of … surveys before (also graciously sponsored by Google), that was by far the most intense, as 0→1 projects often are. In addition to the research, content, and analysis work that goes into every State of … survey, the unique challenges it presented were a forcing function for finally tackling some longstanding UX issues with these surveys. As a result, we pioneered new survey interaction UIs, and validated them via usability testing. This work did not just affect State of HTML, but had ripple effects on all subsequent State of … surveys.

The results made it all worth it. Turnout was the highest ever for a new Devographics [1] survey: 21 thousand participants, which remains a record high for State of HTML. The survey findings heavily influenced Interop 2024 (hello Popover API and Declarative Shadow DOM!) and helped prioritize several other initiatives, such as stylable selects. Despite lower 2024 participation, the survey still significantly influenced Interop 2025; notably, View transitions was added after being prominent in the survey for two years in a row.

This is the goal of these surveys: to drive meaningful change in the web platform. Sure, getting a shareable score about what you know and seeing how you compare to the rest of the industry is fun, but the reason browser vendors pour thousands of dollars into funding these surveys is because they provide unique vendor-neutral insights into developer pain points and priorities, which helps them make better decisions about what to work on. And this ultimately helps you: by getting your voice heard, you can directly influence the tools you work with. It’s a win-win: developers get better tools, and browser vendors get better roadmaps.

State of HTML 2025

Last year, I was too busy to take the lead again. Wrapping up my PhD and starting a new job immediately after, there was no time to breathe, let alone lead a survey. I’m happy to be returning to it this year, but my joy is bittersweet.

When I was first asked to lead this year’s survey a few months ago, I was still too busy to take it on. Someone else from the community accepted the role — someone incredibly knowledgeable and talented who would have done a fantastic job. But they live in the Middle East, and as the war escalated, their safety and their family’s well-being were directly impacted. Understandably, leading a developer survey became the least of their concerns. In the meantime, I made a few decisions that opened up some availability, and I was able to step in at the last minute. It’s a sobering reminder that events which feel far away can hit close to home — shaping not just headlines, but the work and lives of people we know.

Web Platform Features at the verge of Interop

A big part of these surveys is “feature questions”: respondents are presented with a series of web platform features, and asked about their familiarity and sentiment towards them. At the end, they get a score based on how many they were familiar with that they can share with others, and browser vendors and standards groups get signal on which upcoming features to prioritize or improve.

You can see which features were included in last year’s survey here or in [2] the table below.

State of HTML Features
Feature 2023 2024
<datalist>
autocomplete attribute
HTML Media Capture
input.showPicker()
FormData API
<selectlist>
contenteditable="plaintext-only"
<dialog>
<details> and <summary>
Exclusive Accordion
Popover API
inert attribute
Lazy loading
srcset and sizes attributes
Resource Hints
Content-Security Policy (CSP)
fetchpriority attribute
blocking="render"
<model> for AR/VR/3D content
controlslist attribute
<template>
Using Custom Elements
Defining Custom Elements
Scoped Custom Element Registries
Shadow DOM
Declarative Shadow DOM
Named slot assignment
Imperative slot assignment
ElementInternals API
DOM Parts
HTML Modules
Landmark elements
tabindex attribute
focusgroup attribute
<search>
File System Access API
Badging API
Web Share API
Launch Handler API
File Handling API
Window Controls Overlay API
Isolated Web Apps
Customizable Select
EditContext
caretPositionFromPoint
Clipboard API
CSS Custom Highlight API
setHtmlUnsafe()
parseHtmlUnsafe()
Intl.Segmenter API

I believe that co-designing these surveys with the community is the best way to avoid blind spots. While the timeline is tighter than usual this year (the survey is launching later this month!), there is still a little time to ask:

👉🏼 Which upcoming HTML features or Web APIs are currently on your radar? 👈🏼

What does “on your radar” mean? Features you’re excited about and would love to see progress on.

Why focus on upcoming features? The best candidates for these surveys are features that are mature enough to be fleshed out (at least a mature proposal, ideally a spec and WPT tests), but not so mature they have already been implemented in every browser. These are the features for which a survey such as this can drive meaningful impact.

If it’s so early for a feature that it’s not yet fleshed out, it’s hard to make progress via initiatives such as Interop. Interest is still useful signal to help prioritize work on fleshing it out, but it’s a bit of a longer game. And for features that are already implemented everywhere, the only thing that can improve things further is passage of time — a problem for which I unfortunately have no solution (yet).

Obviously we’re looking at all the usual suspects already, and initiatives such as webstatus.dev and Web platform features explorer provide a treasure trove of data which makes this task infinitely easier than it used to be. But this kind of preliminary signal is also useful for filtering and prioritization — to give you a sense, my list of candidate new features to ask about already has 57 items (!). Given that State of HTML 2024 asked about 49 features, that will need some very heavy pruning.

While the title is “State of HTML”, anything that wouldn’t fit better in State of CSS or State of JS is fair game. This includes topics such as accessibility, browser APIs, web components, templating, static site generation, media formats, and more. This may seem strange at first, but is no different than how the HTML specification itself covers a lot more than just HTML markup.

Any way to reach me works fine. You can post in the comments here (preferred), or reply on BlueSky, Mastodon, Threads, LinkedIn, or . Make sure to check the other replies first, and 👍 those with features you care about. Looking forward to your ideas and comments!


  1. Devographics is the company behind “State of …” surveys. ↩︎

  2. As an Easter egg, this widget is just a <details> element with custom CSS. Inspect it to see how it works! It works best in Chrome and Safari, as they fully support ::details-content. Chrome also supports calc-size(), which enables a nice animation, while the interaction in Safari is more abrupt. In terms of a11y, the summary gets spoken out as a regular <summary> element, with “Show more” or “Show less” at the end of its content. It seems ok-ish to me, but I’d love to hear from those with more expertise in this area. ↩︎

We tend to overestimate computing

I love computers, and I love what they can do. The possibilities are endless. At the same time, tech leaders like to make big promises. They don't always come true. As humanity, we tend to overestimate computing. While underestimating things that matter more, arguably.

In 2013, Elon Musk said he'd build a hyperloop connection between two US cities within 5 years. “If it was my top priority, I could probably get it done in one or two years”, he added. His hubris isn't unique. Also in 2013, Jeff Bezos promised same day package delivery by autonomous drones, in “four, five years”. In 2004, Bill Gates promised to end spam “in two years”. Nike promised NFTs that would last forever. Ten years ago, Geoffrey Hinton said AI would replace radiologists within 5 years. If you've worked in tech for a while, you've probably seen your fair share of examples of technology that got overpromised by its creators.

More than a decade later, we don't have hyperloops or autonomous drone delivery. Spam still exists. Nike's NFTs return an error message as the project switched to a cheaper hosting plan. We are facing history's largest shortage of radiologists, while they've not been replaced by machines. Even while some of the most resourceful people and companies on the planet tried.

Overpromising is part of the toolkit of business people. It can serve purposes like marketing and fundraising. Business goals aren't bad per se, but we owe it to our human intelligence to judge merits with a wider lens. Or we risk undervaluing what makes life special, including creativity and the arts. We're capable of more than transactions.

The undervaluing of arts is often monetary. When Mark Zuckerberg was asked if he didn't think creators should be paid for their work, he said:

I think [creators] tend to overestimate the value of their specific content in the grand scheme of this.

(From: Why Mark Zuckerberg thinks AR glasses will replace your phone (The Verge, 2024))

And sometimes it all seems a big misunderstanding. In an interview, Sam Altman said “creativity has been easier for AI than people thought”.

What could he mean by that? And what output did he see… the “creative” things I've seen LLMs produce, I found dull, bland, unsurprising and not creative. Which made me think… what exactly has been easier for AI? Do we have a different definition of creativity?

In the interview, Altman continued:

You can see Dall-E generate amazing images, write creative stories with GPT-4, whatever…

(From: interview with Sam Altman at WSJ Tech Live (2025))

Ah, okay. This positive remark isn't as much about AI in principle, or about creativity. It's about that the output of products he sells. Fair enough. But do you see how, for his purpose, he diverges quite a bit from what creativity really is?

We'll talk more about creativity in the other posts, let's focus on computing first. What is computing?

Computing numbers

For long, “computing” has merely meant the manipulation of numbers. This activity goes back to 2000 BC, when in Babylonia (~present-day Iraq) calculation happened on clay tablets, like this one:

if that looks like a pie-chart, this kind of resembles an Excel-sheet:

This comparison isn't far fetched, computer science started as mathematics, which started as philosophy. Today, computing is much more about the manipulation of data. Computing is often completing tasks, automatically. Computing is, more generally, to throw technology at a problem.

Computing provability

Throughout computer science history people set out to compute a lot of things. Charles Babbage wanted to make an engine to compute mathematical equations and, after that, a machine that could also store information, the Analytical Engine. They existed as concepts in essays only, and later were documented and use case-ified by Ada Lovelace. She warned:

it is desirable to guard against the possibility of exaggerated ideas that might arise as to the powers of the Analytical Engine

Years later, people tried to solve more mathematical problems with machines. Alan Turing wanted to make a machine that could decide for any mathematical equation whether it was provable or not (see Turings' Vision for more on that).

A few years later, then assistant professor John McCarthy at Dartmouth College in the US, decided to propose a summer project on a new field that he, in that proposal, called “artificial intelligence”, allegedly because it would be more intriguing than “automata studies”. A marketing phrase, in other words, as Karen Hao explains in Empire of AI.

McCarthy suggested 10 men should get together (yeah, I know). They got together for six weeks and some didn’t even stay the full six weeks. The plan was to solve computer science and some of its major problems. They listed 7 in the proposal, the 7th being “creativity” (true story).

They made some progress, but of course, the field wasn't done. Decades more research would follow. Grace Hopper invented COBOL and compilers, Karen Spärck-Jones invented inverse-document-frequency (used by search engines), and we're still in the middle of it.

Throughout the history, there's been plenty of overestimation. Maybe it is

Today, when some claim artifical intelligence is going to this or that, I think about what Ada Lovelace said: ideas about capabilities may be exaggerated. This still happens.


Originally posted as We tend to overestimate computing on Hidde's blog.

Reply via email

goHardDrive Leaked Personal Data for Thousands of Customers

I recently returned a product to goHardDrive, a merchant that specializes in selling used hard drives. During the return process, I discovered that they were accidentally publishing details about thousands of their customers, including their full names, mailing addresses, email addresses, and order details.

The leak

When I requested a return from goHardDrive, they assigned me a return merchandise authorization (RMA) number ending in five numeric digits. I’m not publishing my actual RMA number, but you can imagine that it was a number like this: