robpalmer.bsky.social
JavaScript Infrastructure & Tooling at Bloomberg. Co-chairing TC39. Likely to tweet tech stuff about JS & software performance. Opinions are my own.
300 posts
3,790 followers
680 following
Regular Contributor
Active Commenter
comment in response to
post
For more information on verbatimModuleSyntax, please see the TypeScript docs.
(Though in my opinion reading the docs will not be necessary in future, because the new behaviour is easier to understand than the old behaviour.)
www.typescriptlang.org/tsconfig/#ve...
comment in response to
post
The mental model for verbatimModuleSyntax:true is simple.
🔷 Design-time import
import type { ... } from "mod"; // no runtime import ❌
🔷 Runtime import
import { ... } from "mod"; // runtime import preserved ✅
The `type` keyword controls if an import statement of binding will be erased.
comment in response to
post
IMO it's best for the author to explicitly decide what level of compatibility their app needs.
comment in response to
post
It's just a trade-off of opt-in vs opt-out for compatibility.
Defaulting to excessively high compatibility results in inefficient output that is harder to read/debug. This is rarely corrected.
Defaulting to no-transform may result in compatibility issues. This is often obvious & easily corrected.
comment in response to
post
Normally "down-leveling" only refers to syntax conversion (not APIs)
Normally "polyfill" only refers to installing missing APIs (not syntax)
Some people just call it all polyfilling.
comment in response to
post
Essence of Babel.
It's about taking your modern JavaScript source and emitting an older version to run on engines that don't yet support it, preserving as many semantics as possible.
`target: esnext` means no down-leveling. What you see is what you get.
`target: es20xx` down-levels.
comment in response to
post
It can be hard to appreciate how much empathy and consensus building skills are needed to successfully drive change like this.
Configs are naturally opinionated. And the bigger the project, the more opinion-havers there are.
I'm pleased with (& grateful for) the direction this moves towards 👍
comment in response to
post
I like being strong on this point, because I've done a bunch of benchmarking and investigated several counter-claims that turned out to be false.
Happy to leverage Cunningham's law in case some one comes up with good evidence to the contrary. It would make a useful benchmark addition!
comment in response to
post
That's my origin story too 😉
The overhead is non-zero. The spec mandates extra checks that must happen at runtime. Even a JIT can only elide some.
For the 99.99% user, time spent worrying about this is almost like worrying about slowness because you wrote excessive "if"s in your function.
comment in response to
post
There is no meaningful performance overhead. At least in real world apps using mainstream engines.
Optimisations happened a long time ago and benchmarks exist to keep it fast.
comment in response to
post
Note: This is only parsing support. It excludes down-leveling.
comment in response to
post
It was a fun day!
Hopefully next time we can visit the India for a real London Indian 😉
comment in response to
post
Jonas Haukenes, Mikhail Barash and @sffc.bsky.social giving case studies of contributing to JS engines…and sharing a third-party library (in Rust!) to simplify implementation of Temporal
comment in response to
post
Slides of my talk @webengineshackfest.org - Bridging CommonJS and ESM in Node.js, or implementor's tales of require(esm)
github.com/joyeecheung/...
comment in response to
post
@kettmeir.dev introducing the governance of JSR..
comment in response to
post
@andreubotella.com and @lcas.dev talking about recent efforts in WinterTC
comment in response to
post
Good question, Tim!
bsky.app/profile/robp...
comment in response to
post
Clarification: These proposals achieved conditional advancement and will auto-progress once the dependent actions have been completed.
4️⃣*️⃣ Array.fromAsync
4️⃣*️⃣ Explicit Resource Management: `using`
comment in response to
post
Thanks to @ryzokuken.bsky.social and @igalia.com for hosting the 108th TC39 Meeting in their offices in A Coruña, Spain 🇪🇸
The full agenda is here. Notes will be published in three weeks.
github.com/tc39/agendas...
comment in response to
post
Ah of course. I incorrectly copied from the repo 🙈
Number.prototype.clamp(min,max)
Thanks for catching!
comment in response to
post
(*) the conditional advancement is dependent on the test262 tests being reviewed & merged and final approval of the ecma262 PR.
comment in response to
post
(*) The reason for conditional advancement is that this is awaiting Editor sign-off.