iiinova — where your digital self keeps evolving

Yup! You can also do this for IIFEs (which have a similar restriction to avoid ambiguity with FunctionDeclaration) but there's less reason to care in that case.

It's more common when there's more than one property. `({ user, body, message } = getRequest());` is much nicer to read than `const request = getRequest(); user = request.user; body = request.body; message = request.message;`. That said, yes, I also use destructuring for a single property.

100

Only because no one uses it! If we all started doing this then people would recognize this pattern.

Kevin Gibbons @bakkot.com · 28/01/2026

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 back)

490

With this attitude, TS becomes much more pleasurable. You can write the code you were going to write anyway but with types written down instead of in your head, and most of the time TS will validate it or catch real bugs, and in the remaining cases you just tell it the right answer and move on.

021

Kevin Gibbons @bakkot.com · 28/01/2026

I really like to emphasize to people that TypeScript is going to be wrong about things sometimes, and you need to embrace that this is OK and that you can and should use `// @ts-expect-error` or `as unknown as Foo` in cases where you know better than the typechecker. It's fine!

231

Kevin Gibbons @bakkot.com · 15/01/2026

This is such a quintessential "working on JavaScript [and friends]" bug. Dumb compat hacks for engines no one has touched in a decade? Check. Weird parser inconsistencies? Check. Even a BOM mention!

030

Kevin Gibbons @bakkot.com · 16/12/2025

If we go with "visible in else" it's actually pretty hard to get disposal to happen before the else! Try rewriting this without relying on "dispose before else": if (using resource = getResource(); resource.needsUpdate) { resource.update(); } else { await postMessage('no updates required'); }

Kevin Gibbons @bakkot.com · 09/12/2025

Just because that's how you call always `hasOwnProperty` though, it's not something the attacker could actually control. They could have done `Object.hasOwn` if they only cared to work on modern runtimes, and would not benefit from caching in that case.

110

Kevin Gibbons @bakkot.com · 09/12/2025

As a person who says the thing you quoted all the time I am confused about the relevance of this CVE, which does not modify any builtins?

100

Kevin Gibbons @bakkot.com · 06/11/2025

Discworld has good values and was this for me at that age. The Tiffany Aching books especially though he might be turned off by 9yo girl protag. Some of Doctorow's stuff is more explicitly inculcating those specific values, and is good for 13yos. Little Brother is probably a decent first one.

020

Kevin Gibbons @bakkot.com · 18/09/2025

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.

160

Kevin Gibbons @bakkot.com · 13/09/2025

Not exactly stalled; there's just a lot of work which needs to be done first. Activity currently is at github.com/tc39/proposa.... I believe the plan is for module declarations to proceed after this proposal, with the declaration evaluating to the ModuleSource object introduced in this proposal.

github.com

GitHub - tc39/proposal-esm-phase-imports

Contribute to tc39/proposal-esm-phase-imports development by creating an account on GitHub.

030

Kevin Gibbons @bakkot.com · 31/07/2025

That's because this isn't upsert. Upsert does mutation when the value already exists. This doesn't.

130

Kevin Gibbons @bakkot.com · 11/07/2025

Pedantry: you made a quiz about _V8_'s Date parser. Almost none of this is required by spec (although it is allowed), and several of these behave differently in other browsers. Which is even worse!

0100

A sync iterator yielding a rejected promise is not an error in the iterator, whereas an async iterators doing so is. So when lifting sync to async, we need to handle rejected promises from the iterator as if the _consumer_ had an error (by calling `.return`).

Thanks! Further pedantry: "Note that in for of with sync iterators, .return() is always called after .next() throws" - not so. The bug arises because consumers aren't supposed to call .return if the iterator throws, only if the consumer does.

100

So, a break/return/throw inside the loop causes `.return` to be called, but the iterator being exhausted, or throwing, does not call `.return` to be called.

100