Kevin Gibbons

My most idiosyncratic JS opinion is that we should all write `0, { x } = y;` instead of `({ x } = y);` so you don't have to jump to the end of the line to add the parenthesis. If only I could convince tooling to support this... (i.e. get prettier not to add the parentheses)

@sergeantsup @GeneralAntilles @acesounderglass has an article about this acesounderglass.com/2022/10/13/my-…

@GeneralAntilles ahhhh yep :/

it is absurd how much my body is changing in a clean environment 1. lower HR 2. much easier to fall asleep and stay asleep 3. not getting migraine symptoms so often 4. light doesn't bother me anymore 5. sound bothers me much less 6. eyes not even a little itchy 7. nose way less congested when lying down 8. eating protein feels much less mysteriously-difficult 9. no longer uncomfortably tight "down there" (if you know what I mean (am I right ladies)) 10. rosacea going away I am shocked I didn't even realize all of these symptoms started after moving into that apartment. these symptoms started at very different times — it wasn't like "I just moved in somewhere new and now my body is doing a ton of weird things" *all* of these symptoms are things that I put a lot of time into debugging individually. I saw many doctors. did so much LLM research. I found partial solutions to most of them and now none of that is relevant because everything is resolving itself. I just noticed the rosacea thing today, wtf. I thought "hmm I feel like my face looks pale" til I realized plus there's the downstream effects of all this... like of course my mental health is way better without insomnia, of course everything feels nicer without inflammation all over my body

@robpalmer2 @proxy_vector @jarredsumner Base64 shipped in stable Safari 9 months before it shipped in stable Chrome (2024-12-11 vs 2025-09-02), for example. And because bun picks up JSC faster than node picks up V8, it shipped in Bun on 2024-08-07 and in Node not until 2025-10-15.

@proxy_vector @jarredsumner Node already supports `using`. Bun could follow. Are there past examples of Bun shipping unflagged ECMAScript features before Node? For the last few years, JSC has generally not shipped features ahead of V8.

Guess the new JavaScript feature we’re adding support for in Bun v1.3.9

@simonw For the Random button, sessionStorage would be more appropriate. That'll be specific to the current tab.

I wrote about a localStorage trick I've been using to add dynamic per-user features to my blog despite it being served behind a 15 minute Cloudflare cache meaning everyone gets the exact same HTML simonwillison.net/2026/Jan/28/dy…

@as0355 @robpalmer2 @matteocollina @nodejs V8 uses a lot of libraries and increasingly the libraries it would want to use will be written in Rust. Porting this and other such libraries to C++ would be a lot of work for little gain and significant downsides. And Temporal is user-exposed, so safety matters a lot.

@bakkoting @robpalmer2 @matteocollina @nodejs Chrome and V8 are different things. Using multiple languages in a big application makes sense, less so for a library. Plus, memory safety ends at the language border. This is only one API, so it doesn't safeguard against a great deal.

📜 "Date is out, Temporal is in" An article by Mat Marquis on problems found in the ancient JS Date API and how they are solved in the modern Temporal API - available now in Chrome 144 🎉 It focuses on immutability & ergonomics of calculations. Love the kicker. 🔗👇

@as0355 @robpalmer2 @matteocollina @nodejs It is very very large. Also, Chrome already uses Rust libraries elsewhere, and I expect V8 will want to do so in the future as well. Had to happen sometime, might as well happen now. (Plus memory safety is nice, especially for JS engines.)

@robpalmer2 @matteocollina @nodejs Is there a compelling reason not to just reimplement temporal_rs in C++? Bringing in multiple languages to V8 seems risky and hard to maintain.

@_rafaelgss I think LavaMoat/SES is pretty solid actually!

People should understand they will never be able to run untrusted code on any JavaScript runtime

@jarredsumner @izs You could download a top 10000 npm packages and check their package.jsons, I would bet there's 0. If you want to be really safe, do `a:platform=win32` or some other slightly more obscure string.

@izs I like the convention and agree it’s the most obvious choice But people might already have scripts that do that and this would break those? like if the script expected the unnamespaced one to be called

Say we wanted `bun run <my script>` to support os-specific package.json `"scripts": {

@cramforce @apaprocki @styfle That is a bad summary. The key part of the second set of notes is "several implementers have been expressing some hesitation to being the first to ship decorators, and so it’s kind of a -- a little bit of a standstill at the moment" Nothing has changed since then.

@apaprocki Thanks so much! chatgpt.com/share/68fc0ce7… @styfle Did you end up assuming Vercel's TC39 seat? We should collaborate on this

Huge miss in TS/JS that decorators don't work on functions. Is that in the works at all?

@CanadaHonk @rkirsling has written this blog post! dev.to/rkirsling/tale… although there are more edge cases not covered here (IIRC, switch)

the rabbit hole grows so deep

what do you think this js logs? function foo() { console.log('foo'); } foo(); { function foo() { console.log('bar'); } foo(); } foo();

Several people blamed the recent npm incidents on JS's minimal standard library. I think that's wrong: the affected packages are mostly either already covered by node or could not reasonably be in a standard library. But! I'm always taking suggestions for new stdlib features.

@ljharb @sawyerhood I suspect we'd still find a lot of stuff before the threshold is reached, but even if not, everyone doing this would still help with stuff like the recent worm, because it would add a 1-day delay before the worm to jump from one package to another.

@sawyerhood until enough people do this, and it takes an extra day to discover problems

Do yourself a favor and set this in your pnpm config

@matteocollina @nodejs I feel like this has gotten much better since ~14 or so. Used to be every time I updated Node something broke, but that's mostly not the case lately. Having more builtins (sqlite, etc) also helps tremendously, since those keep working.

This is probably the key reason people don’t update @nodejs. Among other reasons, old libraries don’t work with new @nodejs versions (and viceversa).

@jarredsumner You're not bound by web platform rules, but fwiw W3C has a design principle for this, which implies `stripANSI`

which one

@CanadaHonk @bradleymeck The implementation of the hex/base64 functions can be simd in engines though! It is in V8/JSC via the simdutf library for example. I'm sure someone has done a base64 decoder using wasm's simd instructions, but if not it would be a fun exercise.

@bradleymeck there is no tc39 simd proposal (anymore)

Porffor's status of these TC39 proposals! ✅ Math.sumPrecise 🆕 Uint8Array ↔️ base64/hex ❌ Iterator Sequencing ✅ Upsert ❌ Immutable ArrayBuffer ❌ Intl Era/Month Code ❌ Import Bytes ❌ Module Global 🏗️ Array.getNonIndexStringProperties 🏗️ Object.getOwnPropertySymbols opts

@styfle @robpalmer2 @TC39 Once node bumps V8 to 14.0.167 or later, anyway.

@robpalmer2 @bakkoting @TC39 This is really nice! We no longer need to rely on Node.js Buffer 😌

ECMAScript excitement 😉 Congrats to @bakkoting on advancing UInt8Array ↔️ Base64/Hex to Stage 4 @TC39 this week 🎉 UInt8Array.prototype. toBase64 toHex UInt8Array. fromBase64 fromHex It lets you convert directly between binary data and Base64/Hex strings 👍

@matthewcp @rbuckton @ljharb "People thought their name would be more understood than it was" is a completely correct criticism. But it is a different criticism from "people cared about theoretical correctness over understandability".

@matthewcp @rbuckton @ljharb The argument was that globalThis was not inside-baseball. I disagree and disagreed at the time. But people did quite sincerely think that developers would understand the name because they would already have experience with what "this" did at the top level.

I still can't believe they called it globalThis.

@matthewcp @rbuckton @ljharb Perhaps you're misreading me? The argument was explicitly "we think people will probably understand it". That argument was mistaken, IMO. But that's what the dominant argument was. This is not an argument based on "correctness".

@bakkoting @rbuckton @ljharb Sounds exactly like what I said, a bunch of out of touch engine devs who cared more about "correctness" than dev understanding.

@matthewcp @rbuckton @ljharb As one of the people who fought hardest against "globalThis" (I had a whole bonus presentation about it after we'd already got consensus): this isn't accurate. The arguments for it were all of the form "people hopefully know what `this` is". No one cares what the spec looks like.

@rbuckton @ljharb That's my point, engine devs care more about how things look in their spec document than about how it makes sense to developers using their product.