domenicd

I'm not sure this is a winnable game for programming languages.

- Keep a small stdlib, like JavaScript (especially earlier JavaScript): everyone complains about missing features, warring communities form around jQuery promises vs. Promises/A+ vs. callbacks, supply chain attacks, left-pad/is-even dependencies, etc.

- Grow a big stdlib while keeping backward compatibility, like C++: lots of cruft left around that must never be used, sitting next to newer stuff with similar names. People complain about the bloat.

- Grow a big stdlib and then break backward compatibility, like Python 2 -> 3: everyone is sad, the ecosystem churns for years.

I admit there are probably better and worse versions of each strategy, e.g., it seems to me like JavaScript's slow-but-steady accretion of primitives over time has gone OK, and it seems like apart from Python 2 -> 3 some of the PEPs I see for deprecations and replacements are reasonable. But no language has ever hit on a strategy that everyone loves, as far as I can tell.

What type of project actually uses C++ 23 modules in real life? What kind of toolchain enables that? When I worked on Chromium, they were indefinitely in the "maybe in 5-10 years the tooling will be ready" camp.

Fascinating to see that Chromium/Gecko/WebKit are now more "open" browser engines than Ladybird, at least in one important respect.

(Servo is arguably in the middle, accepting outside contributions as long as you don't use AI.)

It's understandable that a team without much funding would have to close off contributions to spare on labor costs. But, it makes me feel that people don't give Google/Mozilla/Apple enough credit for the economic resources they put into enabling openness.

(Personal bias/experience alert: I'm currently retired, but formerly worked at Google on Chrome. I saw many of my coworkers nurture outside contributors, and did some of that myself, both informally and through programs like internships.)

Fingerprinting concerns here are really overblown. At least in Chrome's implementation, the model version / responses will give you ~2 bits over the browser major version: whether the machine can support the model, and whether the model is downloaded yet or not. (Really <2 bits, since these ratios aren't 50/50 in the population.)

This is discussed in detail in https://webmachinelearning.github.io/writing-assistance-apis....

I was formerly the design lead / spec editor for this API while I worked at Google. I retired in 2025-09, before it got shipped. The following contains no inside knowledge.

I am sympathetic to all of Mozilla's concerns here, even though on balance I believe Chromium's decision to ship was the right one.

---

On interoperability, I agree that this is a tough case. But I am more optimistic than Mozilla that developers will use this API in a way that can work across different models.

First, they will be somewhat forced to, because Chrome will change the model over time. (It already changed from Gemini Nano 2 to 3, and I suspect it'll change to 4 soon if it hasn't already.) Edge is already shipping a Phi-based version. A small number of users are using other models via extensions like https://aibrow.ai/. And it's very possible Safari might join the party, exposing the Apple Foundation Models that ship with iOS via this API. (When the Foundation Models API came out, we were struck by how similar it was to the prompt API designs that preceded it, and were hopeful that Apple was going to do a surprise announcement of shipping the prompt API. It hasn't happened yet, but I still think it might soon.)

Second, we designed the API to steer developers in that direction as much as possible, e.g. encouraging the use of structured output constraints. There are also lots of clear error paths, that almost force developers to use this as a progressive enhancement. (E.g., the existence of low-memory/disk space devices.) So it's very unlikely we'll see developers build sites that are gated on this API existing. It'll mostly be used to sprinkle some AI magic, or let users do cool things without entering some cloud API keys.

I made similar arguments for the writing assistance APIs at [1]. As I said there, the prompt AI is trickier than the writing assistance APIs. But I believe it's a difference of degree, not kind. The web has many nondeterministic APIs that access some underlying part of the system, from geolocation to speech recognition/synthesis, all the way up to these AI-based ones. The question is where you draw the line. Mozilla seems to be giving some signals (not yet definite) that translation is on the OK side of the line, but summarization/writing/rewriting/prompting is not. That's a very reasonable position for them to take on behalf of their users. I imagine the Chromium project is hoping that over time, in-the-wild experience with these APIs shows that the benefits outweigh the risks and costs, and so Mozilla (and Apple) follow in shipping them as well. That's definitely happened in other cases, e.g., Mozilla recently indicating interest [2] in implementing WebBluetooth, WebHID, WebNFC, WebSerial, and WebUSB after years of taking a wait-and-see attitude.

You can learn more about my general thoughts on this question of shipping APIs first, and how the Chromium project takes on first-mover risks, at [3], which I wrote during my time on the Chrome team.

---

On the prohibited use policy, I agree that this is just absurd on Chrome's part. This is not how web APIs should work. It smacks of lawyers trying to throw something out there to cover themselves, or of corporate policy being set at the top level for "all AI uses" and then applied even for web APIs where that makes less sense.

The only saving grace is that I suspect it won't actually trigger. Because, as Mozilla points out, it's quite impractical to enforce. But it's still wrong.

I hope Chrome changes this, although I'm not holding my breath.

I did find it interesting that Gemma seems to have a similar terms of use [4]. (Open-weights, not open-source!) As do the Apple Foundation Models in iOS [5]. So unfortunately if the Chrome team were to push for a no-TOS API, they might be forging new ground, which is always difficult in a large company.

---

On the issue of insubstantial developer signals, I think this is just a failure of the current Chrome team in terms of collecting and collating signals. If one pokes around and knows where to look in various threads, you can find a lot more positive signals than the outdated ones in [6]. I wouldn't have let that Intent to Ship get out the door without properly updating that section of the explainer, for sure. (But hey, not my job anymore!!)

[1] https://github.com/mozilla/standards-positions/issues/1067#i... [2]: https://github.com/whatwg/sg/pull/264 [3]: https://www.chromium.org/blink/guidelines/web-platform-chang... [4]: https://ai.google.dev/gemma/terms [5]: https://developer.apple.com/apple-intelligence/acceptable-us... [6]: https://github.com/webmachinelearning/prompt-api/blob/main/R...

(Former Chrome team member who worked on this API, now retired.)

There was such a process! They shipped as first Dev Trial around 2025-04, then Origin Trial in 2025-05. Since then a number of people tried it and gave lots of feedback, leading to model quality improvements, language support expansion, API additions like structured responses and tool use, etc. You can find a lot of feedback and case studies if you search around.

(I wrote those words originally.)

Wow. I had no idea that people would misinterpret what I was saying in this way. I was not meaning to imply it was an expectation of users or developers. I was meaning it as a statement of what was currently a growing industry trend by OS and browser vendors, of shipping or preparing to ship LMs.

By now the statement could probably be amended from "expected to gain access to" to "shipping with".

I hope the team maintaining the project now makes such an update, since apparently it's confusing so many people!

Something similar happened with another API recently. https://github.com/w3ctag/design-reviews/issues/1198#issueco...

(Former Chrome built-in AI team member here.)

This is part of it, and also we just didn't want to use up the last of the user's disk space! It's disrespectful to use up 3 GB if the user only has 4 GB left; it's sketchy if the user only has 10 GB. At 22 GB, we felt there was more room to breathe.

One could argue that users should have more agency and transparency into these decisions, and for power users I agree... some kind of neato model management UI in chrome://settings would have been cool. But 99% of users would never see that, so I don't think it ever got built.

I no longer have any inside knowledge, but from my time on this team they were very quick about getting the latest small (Google) models into Chrome. I expect that if Gemma 4 (or its equivalent Gemini Nano) isn't already in Chrome, then it will be soon.

Note that the article here was last updated 2025-09-21, and as of that time it was already on Gemini Nano 3.

I can't speak for "you guys" anymore, as I'm retired, but from my personal perspective/recollection:

The target usage for the prompt API is anything that would benefit from the general capabilities of a language model, and can't be encompassed by the more-specific APIs for summarization/writing/rewriting. Realistic use cases currently are things like sentiment analysis, keyword extraction, etc. I have a number of ideas on how to integrate it into my current retirement project around Japanese flashcards, e.g. generating example sentences. If the small (~10 GiB) model class keeps getting smarter, the class of things possible on-device in this way gets larger and larger over time.

We definitely communicated with other browsers. There were the standing WebML Community Group meetings at the W3C every few weeks. There were async discussions like https://github.com/mozilla/standards-positions/issues/1213 and https://github.com/WebKit/standards-positions/issues/495 . (Side note, I love the contrast between Mozilla's helpful in-depth feedback and WebKit's... less helpful feedback.) There was also a bit of a debacle where the W3C Technical Architecture Group tried to give "feedback" but the feedback ended up being AI-generated slop... https://github.com/w3ctag/design-reviews/issues/1093 .

But overall, yeah, the goal with the prompt API, as with all web APIs, is to put something out there for discussion as early as possible, and get input from the broad community, especially including other browsers, to see if it's something that they are interested in collaborating on. https://www.chromium.org/blink/guidelines/web-platform-chang... (which I also wrote) goes into how the Chromium project thinks about such collaboration in general.

I led the design effort on this API, before retiring. Here's my writeup on some of the considerations that went into it: https://domenic.me/builtin-ai-api-design/

As some others have indirectly pointed out, this article conflates two things:

- URL parsing/normalization; and

- Mapping URLs to resources (e.g. file paths or database entries) to be served from the server, and whether you ever map two distinct URLs to the same resource (either via redirects or just serving the same content).

The former has a good spec these days: https://url.spec.whatwg.org/ tells you precisely how to turn a string (e.g., sent over the network via HTTP requests) into a normalized data structure [1] of (scheme, username, password, host, port, path, query, fragment). The article is correct insofar that the spec's path (which is a list of strings, for HTTP URLs) can contain empty string segments.

But the latter is much more wild-west, and I don't know of any attempt being made to standardize it. There are tons of possible choices you can make here:

- Should `https://example.com/foo//bar` serve the same resource as `https://example.com/foo/bar`? (What the article focuses on.)

- `https://example.com/foo/` vs. `https://example.com/foo`

- `https://example.com/foo/` vs. `https://example.com/FOO`

- `https://example.com/foo` vs. `https://example.com/fo%6f%` vs. `https://example.com/fo%6F%`

- `https://example.com/foo%2Fbar` vs. `https://example.com/foo/bar`

- `https://example.com/foo/` vs. `https://example.com/foo.html`

Note that some things are normalized during parsing, e.g. `/foo\bar` -> `/foo/bar`, and `/foo/baz/../bar` -> `/foo/bar`. But for paths, very few.

Relatedly:

- For hosts, many more things are normalized during parsing. (This makes some sense, for security reasons.)

- For query, very little is normalized during parsing. But unlike for pathname, there is a standardized format and parser, application/x-www-form-urlencoded [2], that can be used to go further and canonicalize from the raw query string into a list of (name, value) string pairs.

Some discussions on the topic of path normalization, especially in terms of mapping the filesystem, in the URL Standard repo:

- https://github.com/whatwg/url/issues/552

- https://github.com/whatwg/url/issues/606

- https://github.com/whatwg/url/issues/565

- https://github.com/whatwg/url/issues/729

-----

[1] https://url.spec.whatwg.org/#url-representation [2]: https://url.spec.whatwg.org/#application/x-www-form-urlencod...

We tried a few times. We got as far as gating the ability to push into the "real history stack" [1] behind a user activation (e.g. click). But, it's easy to get the user to click somewhere: just throw up a cookie banner or an "expand to see full article" or similar.

We weren't really able to figure out any technical solution beyond this. It would rely on some sort of classification of clicks as leading to "real" same-document navigations or not.

This can be done reasonably well as long as you're in a cooperative relationship with the website. For example, if you're trying to classify whether a click should emit single-page navigation performance entries for web performance measurement. (See [2].) In such a case, if the browser can get to (say) 99% accuracy by default with good heuristics and provide site owners with guidance on how to annotate or tweak their code for the remaining 1%, you're in good shape.

But if you're in an adversarial relationship with the website, i.e. it's some malicious spammer trying to hijack the back button, then the malicious site will just always go down the 1% path that slips through the browser's heuristics. And you can try playing whack-a-mole with certain code patterns, but it just never ends, and isn't a great use of engineering resources, and is likely to start degrading the experience of well-behaved sites by accident.

So, policy-based solutions make sense to me here.

[1]: "real history stack": by this I mean the user-visible one that is traversed by the browser's back button UI. This is distinct from the programmer-visible one in `navigation.entries()`, traversed by `navigation.back()` or `history.back()`. The browser's back button is explicitly allowed to skip over programmer-visible entries. https://html.spec.whatwg.org/multipage/speculative-loading.h...

[2] https://developer.chrome.com/docs/web-platform/soft-navigati...

Nice. I hope it eventually hits Japan.

This is covered in the article:

Turning them off will cause Windows to spasm for several seconds and throw all your current window positioning out of whack.

This is discussed in the article, including why I tried it and ended up reverting to normal P/Invoke.

They are both mentioned in the article. But I appreciate the extra experience and details, beyond what I got from browsing their landing pages and GitHub repos.

A lot of people complain about this, but there seemed to be a reasonable XAML designer when I was making my WinUI 3 app. I didn't really use it (my app was simple enough that hand-crafting the XAML felt worthwhile to ensure everything was nicely aligned and not full of any unnecessary designer gunk). So I suspect it does suck, since otherwise people would not complain as much. But one does exist.

US and Canada residents only, sadly.

From what I understand, Win32/MFC/WinForms inherently are stuck around Vista visuals, with no dark mode support. Win32/MFC also have no high-DPI support, so you get gross upscaling. (WinForms supposedly has some support for high DPI, but with many open issues. [1])

Now, I'm not 100% sure, since there are so many commenters in this thread saying "just use Win32/MFC like a real man". (Most of them ignoring the memory safety angle.) I might do a follow-up asking Claude to reproduce my UI in the various frameworks to test. But my strong guess is that we just have a bunch of HackerNews curmudgeons who are happy to foist pixelated Vista-era light-mode-only UIs on their users.

[1] https://github.com/dotnet/winforms/issues?q=is%3Aissue%20sta...

Id be interested in a source for both this and the parent's comment. How do we know which settings pages use which tech? Have people been decompiling them?

I was actually part of a team at Barnes & Noble.com which tried to use WinJS for a serious application. (We were previously using Chromium Embedded Framework, or our own hand-rolled WebKit integration, for the desktop e-reader.)

It didn't go great. I gave a talk about it. https://youtu.be/HySQR0t_7CI?si=5sfKbb-7u-qqD65R . (Be gentle to my 2012 self's speaking skills.)

Judging from the screenshots, that doesn't produce Windows 11 style UIs, right? I.e. it contributes to the problem exploree at https://ntdotdev.wordpress.com/2023/01/01/state-of-the-windo...

Side by side is what I'm asking for. Just like there's WebView (IE-based) and WebView2 (Chromium-based, evergreen, updated every 4 weeks).

I don't think the rapid development cycle argument holds water, when they're shipping a new WebView2 every month.

Ahah, I knew I missed one!

I originally had ATL in there, but my proofreading squad (Claude and ChatGPT) told me that ATL was a more niche thing for COM, and looking at the Wikipedia article I was convinced they were right.

But WTL was what I was thinking of---the step between the MFC and .NET that I forgot.

Yes, there's definitely a financial gain aspect here. Tidelift provides $50/month for each of these packages. https://tidelift.com/lifter/search/npm/has-symbols

The incentives are pretty clear: more packages, more money.

Very cool! This blog post in general was somewhat eye-opening for me, as someone who set up a mediocre PC-only Ttsu + Yomitan + Anki setup, and then got frustrated enough to start writing my own. Perhaps I should have spent more time researching existing options before going down that route.

I tried unsuccessfully to find your email to chat about the topic of the Japanese language learning ecosystem further. Would you mind dropping me an email to start a conversation? (Mine's in my profile.)

It's terrible that Windows still has nothing good for this built-in. I use https://learn.microsoft.com/en-us/windows/powertoys/quick-ac... which is at least first-party. It's still got a few bugs, but it's a big improvement.

(The bugs I've experienced: it doesn't properly disable itself during video games, despite claiming to do so; sometimes the popup seem to come up when I swear I didn't press the shortcut keys; rarely, the popup gets stuck on screen and needs to be Alt+F4'ed.)

This is an excellent insight.

I think there is still some hope that technical solutions could be developed so that only the "Business Internet" gets access to verified identity, with the user somehow understanding this, while the "Fun Internet" doesn't have such capabilities. This is what stood behind, e.g., Google's proposed WEI [1] that got such huge backlash, or Apple's Private Access Tokens [2] which are essentially the same thing but quietly slipped under the community radar.

Other proposals are Google's in-limbo Private State Tokens [3], or the various digital-wallet/age verification proposals (I think Apple and Google both have stuff in that space).

But even basic stuff, like IP protection, can really throw off the anti-fraud and anti-botnet mechanisms. Your Lego fan site wants to be behind a CDN for speed and protection from DDOS? Well, people using VPNs or in Incognito mode might end up inconvenienced, because the CDN thinks it's dealing with bots. Rough stuff.

[1] https://en.wikipedia.org/wiki/Web_Environment_Integrity

[2] https://developer.apple.com/news/?id=huqjyh7k

[3] https://privacysandbox.google.com/protections/private-state-...