bakkoting

I don't think there's literally any conforming implementations of modern ECMAScript by that definition.

Google mostly does obey web standards that are set by an industry consortium (WHATWG, W3C, or in the case of JavaScript EMCA).

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.

It doesn't require 2FA in general, but it does for people with publish rights for popular packages, which covers most or all of the recent security incidents.

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

Only in the sense that any other software on the developers' machines adds a certain level of risk.

> And how many dependencies does Hono have?

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 is the approach taken by node's built-in argument parser util.parseArgs.

It also exposes a function which does type stripping (as `import { stripTypeScriptTypes } from 'node:module'`).

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

The 7.2% number is already adjusted for inflation. Historically the stock market has gotten about 10% nominal return, 6.5-7% real.

As far as I'm aware none of those were ever supported in more than one engine (specifically Firefox) and so cannot reasonably be considered to have been part of JavaScript. JS really does make a point of not removing things.

There are some _very_ rare exceptions, but they're things like "support for subclassing TypedArrays", and even then this is only considered after careful analysis to ensure it's not breaking anyone.

It was neither a design choice nor a technical limitation. It was a big complicated thing which necessarily involved fiddly internal work and coordination between relatively isolated groups. It got done when someone (Joyee Cheung) actually made the fairly heroic effort to push through all of that.

Joyee has a nice post going into details. Reading this gives a much more accurate picture of why things do and don't happen in big projects like Node: https://joyeecheung.github.io/blog/2024/03/18/require-esm-in...

Kontext is probably better at this specific task, if that's what Mistral is using. Certainly faster and cheaper. But:

OpenAI just yesterday added the ability to do higher fidelity image edits with their model [1], though I'm not sure if the functionality is only in the API or if their chat UI will make use of this feature too. Same prompt and input image: [2]

[1] https://x.com/OpenAIDevs/status/1945538534884135132

[2] https://i.imgur.com/w5Q0UQm.png

That's not the last progress update. Most recent is https://github.com/tc39/notes/blob/d5b5db6969359fad11b6898b7....

Implementations are ongoing and open source, so you can contribute if you want it to come faster! V8 is currently aiming to use https://github.com/boa-dev/temporal IIRC.

> Apparently it has now finally arrived in ES2026

ES2017 [1]. The MDN docs always link the latest version of the spec; the year in the link doesn't correspond to the version where it was added. The proposal was already mostly done at the time of the incident [2]

[1] https://tc39.es/ecma262/2017/#sec-string.prototype.padstart [2] https://github.com/tc39/proposal-string-pad-start-end

Anthropic's guide to using Claude Code [1] is worth reading.

Specifically, their recommended workflow is "first ask it to read the code, then ask it to make a plan to implement your change, then tell it to execute". That sounds like the workflow you're asking for - you can read its plan and make adjustments before it writes a single line of code.

One of the weird things about using agents is that if they're doing things in a way you don't like, including things like writing code without first running the design by you, you can simply ask them to do things a different way.

[1] https://www.anthropic.com/engineering/claude-code-best-pract...

Both Firefox [0] and Chrome [1] are working on successors which rely on permissions prompts instead of preflight requests.

[0] https://groups.google.com/a/mozilla.org/g/dev-platform/c/B8o...

[1] https://groups.google.com/a/chromium.org/g/blink-dev/c/CDy8L...

The service worker jank, while conceptually hacky, is actually remarkably un-janky and not really noticeable to users! It's very much fire-and-forget unless you also wanted to have another service worker (in which case it's time for suffering; service workers aren't even a little bit composable).

For anyone wondering: https://github.com/gzuidhof/coi-serviceworker or https://github.com/WebReflection/mini-coi

For readability I'd recommend using DisposableStack instead of making an object, though either works:

    using disposer = new DisposableStack;
    disposer.defer(yourCallbackHere);

Yup, or to transfer them anywhere else. One use case is for classes which allocate resources in their constructor:

    class Connector {
      constructor() {
        using stack = new DisposableStack;
        
        // Foo and Bar are both disposable
        this.foo = stack.use(new Foo());
        this.bar = stack.use(new Bar());
        this.stack = stack.move();
      }
      
      [Symbol.dispose]() {
        this.stack.dispose();
      }
    }

In this example you want to ensure that if the constructor errors partway through then any resources already allocated get cleaned up, but if it completes successfully then resources should only get cleaned up once the instance itself gets cleaned up.

For APIs which don't support this, you can still use `using` by using DisposableStack:

    using disposer = new DisposableStack;
    const resource = disposer.adopt(new Resource, r => r.close());

This is still simpler than try/catch, especially if you have multiple resources, so it can be adopted as soon as your runtime supports the new syntax, without needing to wait for existing resources to update.

New models suddenly doing much better isn't really surprising, especially for this sort of test: going from 98% accuracy to 99% accuracy can easily be the difference between having 1 fatal reasoning error and having 0 fatal reasoning errors on a problem with 50 reasoning steps, and a proof with 0 fatal reasoning errors gets ~full credit whereas a proof with 1 fatal reasoning error gets ~no credit.

And to be clear, that's pretty much all this was: there's six problems, it got almost-full credit on one and half credit on another and bombed the rest, whereas all the other models bombed all the problems.

No, there are quite a lot of other edge cases. E.g. you also need them before backticks and in many places in class bodies.

JavaScript is being developed with the assumption that wasm will continue to exist. For example, JS is unlikely to get SIMD support because wasm can do SIMD in a cleaner way than JS can. (I am one of the people developing JavaScript.)

Rather, what we're likely to see is work which makes integration between wasm and JS easier - see, for example, the wasm string builtins proposal [1], the proposal for native support for importing wasm from JS [2], or the proposal for fixed-layout JS objects which would allow directly reflecting wasm-GC objects in JS [3].

[1] https://github.com/WebAssembly/js-string-builtins/blob/main/...

[2] https://github.com/WebAssembly/esm-integration/tree/main/pro...

[3] https://github.com/tc39/proposal-structs?tab=readme-ov-file#...

Note that the new disposable protocol in JavaScript is unrelated to garbage collection; it's more like Go's `defer`. The grandparent is talking about JavaScript's somewhat older FinalizationRegistry.

Enabling "compact mode" in the settings helps a lot with that. My discord client looks a lot like my IRC client.

> That's a thing that UTC or timezone-aware Datetimes can't help with.

Modern datetime systems (including Temporal) use identifiers rather than offsets, which are almost as good as a location as long as governments don't redraw the boundaries. And Auckland is in fact the canonical city for the main New Zealand timezone, so specifying your timezone as "Pacific/Auckland" will get you pretty much the thing you want. In Temporal, this would be e.g.

  Temporal.PlainDateTime.from({ year: 2025, month: 1, day: 1, hour: 9 })
    .toZonedDateTime('Pacific/Auckland')

Lots of things are logically timezone-unaware. E.g., I have an alarm that goes off at 6AM every day; it should do so whatever timezone I'm in. Or, some holiday happens on the 14th of the month, not for a specific 24-hour period in a specific timezone.

These aren't "TZ ambiguous". These are "this thing does not logically have a specific associated timezone". For things which do logically have a specific associated timezone, there's ZonedDateTime.

Every version of a browser released after 2011 has supported strict mode.

There's some progress on that proposal, just happening elsewhere. https://github.com/tc39/proposal-esm-phase-imports defines machinery for importing a ModuleSource object which you can instantiate as a Worker, and once that's done module expressions would just be syntax which evaluates to a ModuleSource rather than needing a separate import.

I've been writing JavaScript since I was about your son's age and am now one of the editors of the JavaScript specification. His code is much much better than mine was at his age!

I have one piece of feedback for him about the code itself, in case he's interested (of course the important part is the game, not the code, but I'm more qualified to give feedback on the JS): put `"use strict"` at the top of every <script>.

> I would guess worst case QuickJS probably can compile to WASM

That's actually exactly what Figma is doing for their plugins. [1] Seems to be working ok, though not without some pain [2].

[1] https://www.figma.com/blog/an-update-on-plugin-security/

[2] https://macwright.com/2024/03/29/figma-plugins