(I am on TC39 and while this isn't my highest priority I did bring the topic for discussion at the last meeting [2], and there was support from the rest of committee.)

[1] https://github.com/tc39/proposal-concurrency-control/issues/...

[2] https://github.com/bakkot/structured-concurrency-for-js

[1] https://docs.google.com/presentation/d/1inTcnb4hugyAvKrjFX_X...

But Observables really do not solve the problems being talked about in this post.

[1] https://github.com/WICG/observable [2] https://github.com/WICG/observable/issues/216

Terence Tao maintains a list [1] of AI attempts (successful and otherwise). #205 is currently the only success in section 1, the "full solution for which subsequent literature review did not find new relevant prior partial or full solutions" section - but it is in that section.

As to speed, as far as I know the recent results are all due to GPT 5.2, which is barely a month old, or Aristotle, which is a system built on top of some frontier LLMs and which has only been accessible to the public for a month or two. I have seen multiple mathematicians report that GPT-5.2 is a major improvement in proof-writing, e.g. [2]

[1] https://github.com/teorth/erdosproblems/wiki/AI-contribution...

[2] https://x.com/AcerFur/status/1999314476320063546

[1] https://github.com/YoWASP/vscode

It's true that there are a few people who publish packages on npm including polyfills, Jordan among them. But these are a very small fraction of all packages on npm, and none of the compromised packages were polyfills. Also, he cares about backwards compatibility _with old versions of node_; the fact that JavaScript was originally a web language, as the grandparent comment says, is completely irrelevant to the inclusion of those specific polyfills.

Polyfills are just completely irrelevant to this discussion.

`npm install` will always use the versions listed in package-lock.json unless your package.json has been edited to list newer versions than are present in package-lock.json.

The only difference with `npm ci` is that `npm ci` fails if the two are out of sync (and it deletes `node_modules` first).

Chrome has the best compliance with standards of any of the big three (see wpt.fyi) - which is not surprising, because they also have the most engineering time dedicated to their browser, and the most people working on standards.

These bodies require buy in from multiple vendors, but generally not unanimity. That said, browsers can and do ship things which haven't been standardized (e.g. WebUSB, which is still only a draft because only Chrome wants to ship it). In a lot of cases this pretty much has to happen pre-standardization, because it is difficult to come up with a good standard from the ivory tower with no contact with actual use. Chrome is unusually good about working in public to develop specifications for such features even when other browsers aren't currently interested in shipping them.

I don't know what problem you think this proposal would solve.

https://github.blog/changelog/2022-11-01-high-impact-package...

Zero.

I'm guessing you're looking at the `devDependencies` in its package.json, but those are only used by the people building the project, not by people merely consuming it.

This lets you build simple web apps (i.e., those with no frontend dependencies) as pure TypeScript, including the frontend, by stripping the types out from your frontend scripts as you serve them: https://github.com/bakkot/buildless-ts-webapp