2026-05-02 [22:28:38.0415] added your suggestion 2026-05-04 [03:40:52.0387] Which VSCode ecmarkup extension should I use: "rbuckton.ecmarkup-vscode", 1421 downloads, by rbuckton, last updated 9 years ago, or "magicworks.ecmarkup", 150 downloads, last updated 7 months ago, by "Magic Works", who seems to publish a lot of language extensions [03:42:41.0130] I use the latter which is supposed to have a couple extra features [03:42:50.0122] and supports newer patterns that we use a lot [03:44:49.0456] oh magic works is Jack Works I believe [04:02:03.0913] > <@usharma:igalia.com> oh magic works is Jack Works I believe that's correct 😇 [05:35:49.0252] Mine is fairly out of date and I haven't had much time to update it. [05:37:40.0092] akin to TCQ this could be perhaps benefit from some love from other committee members... [05:37:49.0236] * akin to TCQ this could be perhaps benefit from some love from more committee members... [08:12:22.0156] stuff like this markup extension, tcq, esvu, etc... would be nice if we had them under shared ownership. no requirement from anyone in particular to maintain them, just some sort of way to keep things flowing as people and their availability come and go. [08:29:05.0057] ecmarkup lives under the tc39 org [08:29:21.0140] (and ecmarkdown, which is a distinct project for some reason) [08:31:03.0812] if you want to transfer esvu to the tc39 namespace I would be supportive! [08:34:39.0013] what's the difference between esvu and jsvu? [08:36:07.0892] Trademark opinions, clearly [12:33:49.0059] Chris de Almeida: jsvu has arbitrary rules for what engines they will accept. whereas esvu is more open to anything. [12:34:08.0327] although take that with a grain of salt, i haven't tried to add an engine to jsvu in many many years so maybe they're nicer about it now [12:35:37.0890] esvu is also used for test262 infra though, so its somewhat within the scope of things tc39 could theoretically be responsible for. 2026-05-05 [07:56:20.0237] in hindsight I don't think the test262-harness/eshost transfer to the tc39 org was a good idea. they're increasing unfit for purpose and fail a number of tests due to bugs and outdated assumptions about fixture files [07:56:35.0467] they're effectively official-looking abandonware [08:22:55.0896] we went from a situation where it was not possible for anyone but an ex-delegate to maintain them, to a situation where any of us could step up but no-one has. I think that's still an improvement [09:27:18.0613] I'm happy to upstream my patches if anyone will actually review them or give me write access đŸ€· [09:28:18.0950] there's some useful stuff on the test262.fyi fork as well but that's >100 commits [09:48:29.0241] please do! [09:51:02.0355] I would love for us to adopt esvu as well! [13:41:59.0815] first PR is up, repo needs actions enabled I think 2026-05-06 [07:03:11.0288] neat https://github.com/v8/agents/tree/main/extensions/ecma262_state_machine [10:03:45.0209] this is what engine262 does heh [10:24:52.0777] Hi. I am a community member, working on Stage 0 proposals JSON.parseBinary and ArrayBuffer.prototype.detach. Matteo Collina at Fastify has given positive feedback, Daniel Minor at V8 suggested I bring them here to find a potential champion, readme on GitHub of TC39 mentions this specific Matrix channel. Happy to answer questions and end one month streak of stage 0. Use-cases: receiving payload by servers (not only http), receiving payload by clients, jsonwebtokens, filesystem manipulations, memory-constrained environments, high-throughput network communication. Most of the applications out there. Links to the repositories with Open-Source benchmarks and examples: https://github.com/Guthib-of-Dan/proposal-json-parse-binary https://github.com/Guthib-of-Dan/proposal-arraybuffer-detach [10:30:00.0914] On json-parse-binary, I find it surprising that the explainer does not appear to make any reference to the `{type: 'json'}` import attribute, or Fetch's `Response.json()` method. Is that intentional? [10:30:37.0081] I have a hard time understanding what problem json-parse-binary is solving. The only times I ever have a byte array containing JSON are when reading from the network or disk. From the network there's already `.json()`, and from disk there's `type: 'json'` imports. So... what's the remaining use case? [10:33:06.0103] for `.detach`, I think if you are in a situation where you are allocating and detaching a bunch of arraybuffers, something has already gone wrong. You'd generally be doing `encodeInto` or `setFromBase64` or similar, to avoid allocating the arraybuffers in the first place. So it is difficult for me to imagine a situation where the overhead of `.transfer(0)` is relevant [10:59:20.0242] There is nothing to imagine, but see the benchmarks. Literally speed boost. I didn’t mention imports or Response.json, because that might look as rude that I want to change something, before I even found a delegate. But yes, asking WhatWG to use JSON.parseBinary in Fetch and also making use of it in json imports were one of my subsequent ideas, just not listed. So yeah, intentionally. [11:00:32.0891] Microbenchmarks are almost never convincing without a story for why a real application might do something anything like as frequently as a microbenchmark [11:01:24.0272] Browsers could already implement `.json` and `type: "json"` imports as parsing over binary; I don't think they've done so but there's nothing stopping them [11:01:25.0895] Saying that “it saves cpu time and memory” doesn’t convince you? [11:01:34.0910] Not on its own, no. [11:03:00.0364] Basically any possible standard library functions would save nonzero cpu and memory for nonzero programs. There needs to be more than that, such as an argument that it would save significant cpu and memory for many programs. [11:05:37.0047] Parsing over binary json saves us from constant reallocations + UTF16 upgrade of a string. By avoiding Error we potentially hide stack trace from unintentional leakages. If browser had implemented this, it would be even easier to expose such JSON parser, so nothing stops them, and nothing stops us. [11:06:00.0605] * Parsing over binary json saves us from constant reallocations + UTF16 upgrade of a string because of a single emoji. By avoiding Error we potentially hide stack trace from unintentional leakages. If browser had implemented this, it would be even easier to expose such JSON parser, so nothing stops them, and nothing stops us. [11:06:49.0722] What I mean is: if your argument is "reading json from the network is slow because it goes through a string", then the solution is to convince browsers to implement a faster `.json()`, not to add a feature to the language [11:08:12.0056] .json() belongs to Response, but in the case of node:http, we receive payload as chunks and not as a Response object [11:10:17.0132] For things to be worth adding to the language, they need to at minimum be useful in browsers, not just in node. but fwiw node already vendors simdjson so they might be open to exposing it to userland if you ask. [11:10:55.0809] Concerning the “detach” and avoiding allocating ArrayBuffer, in the same node:http these chunks are allocated by the framework, not us. By using “detach” we would optimise our handlers. If not everyone, then libraries we use every dat can adopt it. [11:12:17.0135] I would think an additional ArrayBuffer allocation is ~never going to be a relevant amount of CPU time when the network is involved, but I could be wrong about that. [11:12:30.0235] * I would think an additional zero-length ArrayBuffer allocation is ~never going to be a relevant amount of CPU time when the network is involved, but I could be wrong about that. [11:12:31.0634] Not only node, but Bun, Deno as well. I am proposing this to a language because there is a wide choice of instruments. [11:12:42.0747] * Not only Node, but Bun, Deno as well. I am proposing this to a language because there is a wide choice of instruments. [11:12:59.0229] WinterTC is the appropriate venue for server-runtime-only features [11:13:30.0774] Although IIRC bun and deno do expose `Response`-based HTTP servers, so they could just use `.json` already [11:14:36.0303] By using Response.json we restrain ourselves from handling either network error, or parsing error. One method throws for both cases [11:15:05.0635] also wait node's request does have `.json` [11:15:18.0698] so they could all do this [11:15:38.0672] * ~also wait node's request does have `.json`~ nope, thinking of something else [11:15:44.0586] * ~~also wait node's request does have `.json`~~ nope, thinking of something else [11:15:54.0511] * also wait node's request does have `.json` nope, thinking of something else [11:16:05.0060] So it can adopt these language features. Or I should spend much more time asking each of them, while there is a centralised place like ECMAScript specification? [11:16:52.0426] `.json` already exists. If what you want is for it to be more performant, that needs to be done by the implementors of it. [11:17:47.0910] If what you want is a different thing, TC39, WhatWG, or WinterTC might each be reasonable, depending on the thing you want. If you have a use case for parsing binary json that isn't just "I want `.json` to be faster" then it might be reasonable to do it in TC39 [11:18:01.0847] But still thanks for this discussion. I literally spent previous week in solitude. Making changes to existing APIs is much more likely to be avoided, as the changes are not backwards-compatible. [11:19:00.0612] `.json` could operate on raw bytes, without an intermediate string, with no user-visible changes [11:19:14.0564] So yes, for me it is reasonable to propose my ideas to TC39, because they are new, clearly express developers’ intentions, can be used in browser and on the backend, improve performance [11:20:37.0535] For some framework like uWebSockets.js, where data comes only in chunks, using Response.json() would be possible if we could create Response from binary chunks. Can we? [11:21:40.0647] Oh, wait. We actually can [11:21:42.0898] The Response constructor can take a Uint8Array, yes [11:21:47.0062] Just a minute [11:22:12.0180] or a Blob if you have multiple Uint8Arrays [11:22:48.0276] (sidebar: it _is_ a little weird that Blob doesn't have `.json`, but whatever) [11:30:18.0780] Made a quick microbenchmark (I believe that they tell a story) where 1 mil times in for loop of “await new Response(nodeBuffer).json()” takes 6 seconds, and 1 mil of “JSON.parse(nodeBuffer.toString())” takes 300ms [11:30:41.0959] So async parser - not really worth modifying [11:31:33.0689] Json is small - {“key”: “value”, “key2”: 123123 } [11:32:00.0375] * Json nodeBuffer (Buffer.from() result) is small - {“key”: “value”, “key2”: 123123 } [11:33:22.0313] But since Blob was mentioned, probably JSON.parseBinary would also benefit from accept it. An additional extension, thanks [11:33:34.0800] * But since Blob was mentioned, probably JSON.parseBinary would also benefit from accepting it. An additional extension, thanks [11:36:07.0503] In Bun results are 230ms for JSON.parseBinary and 550ms for Response.json [11:36:18.0560] Still a gap [11:36:28.0296] * In Bun results are 230ms for JSON.parse and 550ms for Response.json [11:42:40.0322] That does suggest there is substantial room for engines to optimize .json, yup [11:43:22.0460] Adding a parseBinary to the language wouldn't cause them to do that work, though. [11:44:01.0716] Yes. And again, I propose not only eliminating intermediate js string, but also stop throwing SyntaxError [11:44:08.0316] So return-type is different [11:45:09.0081] What's the use case where the performance of the error handling of JSON parsing is actually relevant? [11:46:04.0218] Literally every DDoS attack. I don’t think that attackers try to generously obey the rules of JSON syntax [11:46:39.0647] Finding a weak spot here means using the worst case for the server [11:46:57.0385] By using JSON.parseBinary we prevent these incidents [11:47:47.0891] All SyntaxError does is it generates a stack trace. We need that for debugging. But we can’t debug payload that came from who-knows-where [11:48:02.0482] I don't see that represented in the explainer at all. [11:48:25.0215] Because imagine me writing everyone “you can DDoS every backend out there” [11:49:02.0016] That was a precaution. Now in this environment I can share it with you [11:49:18.0075] * Because imagine me writing everyone “you can DDoS every js backend out there” [11:54:26.0062] I don't really buy the argument that a savings of about 3”s (according to the benchmark results in the explainer) while dealing with a single network request is worth the cost of not throwing a SyntaxError. [11:55:31.0956] Stack traces are generally created lazily already [11:55:55.0698] So if you don't read .stack they're almost free [11:55:56.0194] errors.mjs shows 2-3 seconds of difference [11:56:33.0990] “throw” also has its drawbacks in performance [11:56:37.0655] Yeah, for 1 000 000 iterations. [11:56:40.0694] 500ms [11:56:59.0401] DDoS is about 3 requests? [11:58:23.0603] My point is that you're showing that there is a potential for saving 3”s per network request by not throwing an error. That's such a minuscule fraction of the total time spent on that request that it's not worth the cost of having e.g. `JSON.parse` and `JSON.parseBinary` have different APIs. [11:59:17.0624] Is 3us from only errors, or from string as well? [11:59:35.0648] I don't know, i'm quoting your own data. [11:59:38.0455] * Is 3us from only errors, or from strings as well? [12:01:16.0453] Hang on, what does "DDoS is about 3 requests" mean? [12:02:09.0725] I mean that those attacks imply dozens of requests, not 3 (exemplify low quality) [12:02:22.0581] * I mean that those attacks imply dozens of requests, not 3 (exemplify low quantity) [12:05:14.0750] I looked again into the closest benchmark to real scenarios a https://github.com/Guthib-of-Dan/proposal-json-parse-binary#parsing-benchmark Not 3us, but 3us -> 2ms. [12:05:24.0445] * I looked again into the closest benchmark to real scenarios a https://github.com/Guthib-of-Dan/proposal-json-parse-binary#parsing-benchmark Not 3us, but 3us - 2ms. [12:05:44.0418] * I looked again into the closest benchmark to real scenarios a https://github.com/Guthib-of-Dan/proposal-json-parse-binary#parsing-benchmark Not 3us, but 3us - 2ms per call. [12:05:53.0081] * I looked again into the closest benchmark to real scenarios a https://github.com/Guthib-of-Dan/proposal-json-parse-binary#parsing-benchmark Not 3us, but 3us - 2ms per parsing. [12:09:15.0202] I have mentioned in the repo “secure-json-parse” package which uses Error.stackTraceLimit = 0 trick before parsing. Their benchmarks show 7900avg / 3500avg latency [12:09:44.0461] * I have mentioned in the repo “secure-json-parse” package which uses Error.stackTraceLimit = 0 trick before parsing. Their benchmarks show 7900avg for JSON.parse / 3500avg latency [12:11:02.0370] How long would you consider it to take for the server to deal with a single request? Not just the JSON parsing, but all the work involved before that? [12:14:23.0027] Is there any special benchmark (not a microbenchmark) I can make which would convince you? With all work invlolved [12:14:35.0714] * Is there any special benchmark (not a microbenchmark) I can make which would convince you? With all work involved [12:20:20.0818] Probably not, tbh. As far as I see, you're making an argument that the JS language itself needs to be changed for performance reasons, primarily to deal with hypothetical DDoS attacks, by avoiding throwing a SyntaxError from JSON parsing. This seems like an extraordinary claim, for which I'm not seeing the commensurate extraordinary evidence. Or an indication for why this problem really needs to be solved at the JS spec level. [12:23:56.0126] To conclude, you see my ideas as ones optimising for rare edge-cases, which save roughly several milliseconds? [12:26:46.0297] To amend that: ... which might in certain cases (according to your benchmarks) save some _microseconds_ in the context of operations that are liable to consume in total at least multiple _milliseconds_. [12:28:48.0235] Still, I am grateful for this discussion, I learned a ton of internal functionality and don’t regret at least trying. I consider these ideas closed from now on. Well, I tried. [12:33:59.0549] Wait. What about ArrayBuffer.prototype.detach? [12:35:01.0938] * Wait. What about ArrayBuffer.prototype.detach? By now we have dealt only with JSON.parseBinary 2026-05-07 [22:36:25.0541] Daniel Dyryl: just fyi your proposal has not been rejected by the committee. there are many delegates and you spoke to only two of them here so far. and as your proposal was not officially discussed at a meeting it was not officially decided on one way or another. [22:40:57.0555] there's also been a lot of discussion about the TextEncoder api in the past, about where it belongs and whether it would be faster if it were implemented directly in js engines. might be good context to look into. [22:41:32.0542] * @mitrax-of-dan:matrix.org: just fyi your proposal has not been rejected by the committee. there are many delegates and you spoke to only two of them here so far. and as your proposal was not championed and considered for advancement at a meeting yet it was not officially decided on one way or another. [23:03:57.0221] Phew. Just kind of emotional, my apologies. These are my first ever proposals, I am not used to the rules of “several rejections != stop promoting ideas”. [23:25:45.0219] Reminds me that when I was in a brass quintet and we were off to our first conference, our directors made sure we understood that the adjudicators don’t waste feedback if they don’t think you have potential. The more the better. A dearth of criticism is not what it seems. 2026-05-08 [18:45:02.0457] If only we'd had the foresight to be ECMA-007 then it'd be so much funnier. 2026-05-09 [01:43:30.0134] What's the status of ShadowRealm these days? I see that the repository hasn't been updated for over a year. [02:38:45.0918] * Still, I am grateful for this discussion, I learned a ton of internal functionality and don’t regret at least trying. I consider these ideas closed from now on. (Actually, look below). Well, I tried. [13:13:20.0365] my understanding is that it's waiting for implementations (or perhaps that it recently got implementation feedback from v8 that hasn't been addressed yet?) 2026-05-10 [21:52:14.0234] Outside of the repository? Cause I checked for recently updated issues too 2026-05-11 [21:37:51.0540] possibly? i haven't seen an issue, but i heard something about it the other day [06:29:51.0393] My understanding is that the proposal can't advance at TC39 without positive statements of interest on the DOM side (https://github.com/whatwg/html/pull/9893) and no implementers have expressed an interest. [06:30:54.0314] I'd certainly be opposed to it advancing again without support for the DOM changes. [06:32:06.0221] Yeah that makes sense. I'm wondering if we should clean up WPT as ShadowRealm currently adds a bunch of noise. Maybe I should just do it as it can easily be reverted once interest is expressed. [06:32:46.0271] That makes sense to me, I've also encountered that while working on other JavaScript features that have WPT. [07:08:21.0517] For similar noise related reasons [we removed our prototype](https://bugzilla.mozilla.org/show_bug.cgi?id=2014919) while things gel [08:25:35.0101] I think it's OK to revert the ShadowRealm harness changes in WPT for now. it's disappointing to have put so much work into it, but such is standardization in the big city 😄 [08:26:00.0655] I'll see if I can find time to make the repo reflect the current status [09:39:09.0786] FYI: https://github.com/web-platform-tests/wpt/pull/59794 2026-05-14 [11:01:45.0852] 👋 Hello, My name is Benny Powers, I'm a web developer at Red Hat with a particular interest in web components and associated tooling. I'm a member of the Web Components community group, the Open WC collective, and maintain my own set of web components tools. I'd like to share with you some work I've done recently regarding decorators, in the hope that this is relevant to the upcoming meeting 1. [Add decorators tests](https://github.com/tc39/test262/pull/5048) PR to test262 which expands on the work done by pzuraq 2. [LibJS: Implement TC39 stage 3 decorators](https://github.com/LadybirdBrowser/ladybird/pull/8709) PR to Ladybird, implementing the spec acc'd to those tests Thanks for keeping this proposal moving forward and best of luck at the upcoming meeting. [14:44:22.0662] Benny Powers: the test work is much appreciated 😄 I continue to be pressed for time, but I'm hopeful that I'll be able to contribute to the proposal again soon and the extra help is encouraging 2026-05-15 [21:48:08.0979] it did seem there were one or two ambiguities in the spec. the test suite largely follows v8's implementation. 2026-05-18 [09:59:12.0066] Hi Benny, would you mind flagging these ambiguities. Background is that I was reviewing parts of the CL you are referring to and I would not put my hands into the fire that the CL is following the spec. [10:00:10.0270] So I think it would be pretty unfortunate if we would base the tests upon our implementation and not the spec, when the purpose of the test should be to validate our implementation... [10:06:47.0858] * Hi Benny, would you mind flagging these ambiguities. Background is that I was reviewing parts of the CL you are referring to and I would not put my hands into the fire that the CL is following the spec (given how complicated the spec is). [10:13:37.0106] Thanks Olivier Begging your forgiveness that I'm not deep in the code at the moment, but IIRC the two major areas of ambiguitry related to: x [10:14:34.0962] * Thanks Olivier Begging your forgiveness that I'm not deep in the code at the moment, but IIRC the two areas of ambiguitry related to: 1. the correct order of operations when applying initializers 2. ... (one moment) [10:22:32.0740] ok, there are already a couple of open issues at https://github.com/tc39/proposal-decorators/issues . would be good to check if it's one of these or something new [10:23:55.0307] yes i think they're all identified 1. initializer ordering 2. IsCallable vs IsConstructor 3. access.set on private methods I'm not here to introduce new problems. My motivation is _as a web developer_ with a special interest in web components and decorators. [10:26:12.0964] that is appreciated :) but it's good to find the problems here before we try to ship something. so surfacing problems is good. we don't want to end up landing tests which are not actually testing what is written in the spec. [10:27:20.0731] there may be further intent-vs-text gaps that i was unable to identify [10:27:28.0041] so if you think the spec says something which contradicts the v8 implementation, then we need to resolve that, by either changing the implementation or the spec. [10:28:32.0332] right, the spec basically has to have the textual authority. it must be unambiguous and match the intent. [10:28:50.0247] the tests are an artifact of the spec text, not a spec itself. [10:29:01.0663] * the tests are an artifact of the spec text, not a spec themselves. [10:29:03.0332] ye [10:29:05.0253] * yes [10:31:19.0781] in my day job, we ship (transpiled) decorators for our design system web components. at the moment, we're unable to decorate private methods (the stage 3 downlevel is too onerous to foist on end users), so we opt for this typescript ```ts @decorated(whatever) private shouldBeEcmaPrivateMethod() { foo; } ``` rather than targetting stage 3 [10:46:36.0255] not 100% sure I follow, but are you saying you are hitting issues with the babel transpilation of decorators in combo with private methods? [10:47:47.0459] yes. the current typescript desugarring for stage 3 decorators would bloat our bundle sizes, so we intentionally opt for [10:48:08.0137] * yes. the current typescript desugarring for stage 3 decorators would bloat our bundle sizes, so we intentionally opt for `experimentalDecorators: true` which implements an older version of the spec [10:48:23.0577] this prevents us from decorating `#privateMethod` [10:49:05.0568] NB: we're happy to continue doing this until "real" decorators land baseline - we don't have strong opinions on spec internals [10:49:41.0731] our primary goal is to continue to write decorators, while using something like bloomberg's whitespace types processor to emulate "types as comments" [10:49:54.0839] i hope that's clear [10:50:42.0904] I see. thanks for the explanation. so I guess the problem is not decorating private methods per se, but just in general that the babel output is too large. [10:51:16.0180] but decorating private methods would be your usecase for which you would like to switch to the spec decorators [10:54:54.0357] yes. we don't use babel, but typescript our cases for decorators: - annotating custom element classes - this one has a tag name , this one is themable, this one has a specific set of theme attributes applied - annotating class fields as custom element attributes (lit properties) - metaprogramming on methods - this lifecycle method runs when a given property changes - run this method when a custom element upgrades - time this async method and log results - when debug mode is configured, log the params and return of this method - run this method when the custom element receives a given event name [10:55:29.0913] https://github.com/patternfly/patternfly-elements/tree/main/core/pfe-core/decorators in addition to the library decorators which ship with lit [10:55:36.0240] thank you kindly for your attention 2026-05-19 [03:56:38.0487] I hope it's ok to share this here, but I just published the results for the recent State of Web Dev AI survey: https://2026.stateofai.dev/