2024-11-01 [22:02:07.0190] follow up on this: what if we split this in two questions, one asking about Stage 3+2.7 features, and one asking about Stage 2 features, while limiting both lists to the top 10 items that are relevant to the broadest section of the JS community? [22:03:58.0418] I know this is a subjective metric, but otherwise that's probably too many items to ask respondents to scan through [22:04:43.0672] the idea behind splitting things between Stage 3/2.7 and 2 is that it offers an opportunity to educate people on what the stages mean as part of the question prompt [22:07:14.0609] so, to recap, I see three ways to formulate the question: 1. a somewhat arbitrary list of the top ~15 features among stage 3/2.7/2 that seem the most promising 2. two somewhat arbitrary lists of the "top" ~10 features split by stage 3. just list the current 15 Stage 3 features [09:18:16.0195] Sacha Greif: we would ask that you not cover stage 0, 1, or 2 things at all. 2.7+ is fine [09:18:53.0140] * Sacha Greif: we would ask that you not cover stage 0, 1, or 2 proposals at all. 2.7+ is fine 2024-11-02 [19:46:37.0380] is it ok if I pick a subset of "most interesting" features myself, or is that introducing too much bias? [19:47:04.0490] I think some human judgement is needed. Why don't you suggest a list here for review? [19:47:04.0644] (in other words taking out features that seem too niche) [19:47:21.0737] ok I'll do that [19:48:16.0730] also is there an "official" definition of what Stage 3 and Stage 2.7 mean? [19:48:28.0755] or should I maybe not mention Stage 2.7 to keep things simple? [19:49:14.0845] there's an official definition in https://tc39.es/process-document/ , you can just link to that. I would avoid a detailed definition inline, but you can say early vs advanced features [19:50:11.0483] ok I'll keep things generic then 2024-11-03 [17:42:49.0176] https://github.com/Devographics/surveys/issues/252#issuecomment-2453242524 [17:58:31.0116] I'll also add descriptions for each item 2024-11-06 [16:44:23.0480] I had an idea for another question to help get perspective on the JS0/JSSugar thing without asking about it directly [16:44:42.0746] I suspect that the answers will skew very much to the right but we'll see! [05:11:13.0153] Yeah that is an interesting question to ask, though it is a little different. Do you want to specify there whether you mean “shipping in production”? [07:42:49.0921] There is a lot of nuance here. For example, is writing in TypeScript with types being stripped by the runtime (e.g. node 23) or by a light transform (ts-blank-space) considered directly executing the code that was written? I personally consider such transforms to not really be a build process, at least not one comparable to transforms that change the part of the code meant to be JavaScript (as long as the intent of the author is clear, to avoid ambiguous TypeScript parsing such as https://github.com/microsoft/TypeScript/issues/33639) [07:52:22.0801] The difference would probably be "do you use a single command to compile+execute, or do you use two separate commands?" [08:13:36.0982] So stripping types before/while uploading to a CDN for example qualifies as a build step in that case? What if there was a bundle format that allowed combining multiple ES modules in a single file / HTTP request without changing any of the source code (assuming it was written in JS), would that qualify as a "build" step? [08:29:06.0389] that definitely sounds like a build step to me [08:30:06.0332] ts-blank-space is also what I would consider to be a build step [08:30:20.0228] anything that you do to transform your code before executing it is a build step [08:31:06.0078] > <@bakkot:matrix.org> anything that you do to transform your code before executing it is a build step Do you consider deno/bun to be a build step, as they transform the code before giving it to V8/JSC? [08:31:26.0312] no, that is not something you do before executing your code [08:32:01.0173] deno transforms the code before executing it in exactly the same sense that v8 transforms the code before executing it [08:33:57.0275] Yeah ok that matches my opinion of what is a what is not a build step [11:46:13.0879] > <@bakkot:matrix.org> ts-blank-space is also what I would consider to be a build step What about `node --import ts-blank-space/register ./path/to/your/file.ts` ? [11:54:11.0559] If it were shipped as part of node, not a buid step. [12:17:52.0887] > <@sachag:matrix.org> sent an image. I don't have a great suggestion right now of how this could be worded differently, but you are going to get a mixed bag of responses because people will not know quite what you mean. For example, because I know what you are getting at here, my answer would be near 0. But if I read this question without the context that I have have, my answer would be near 100. [12:19:37.0389] > <@sachag:matrix.org> sent an image. * I don't have a great suggestion right now of how this could be worded differently, but you are going to get a mixed bag of responses because people will not know quite what you mean. For example, because I know what you are getting at here, my answer would be near 0. But if I read this question without the context that I have, my answer would be near 100. [13:29:54.0656] what is the workflow you have that you would consider 0 or 100 depending on context? [13:42:54.0332] CommonJS is the grayest area maybe. It technically has to be transformed before being a valid JS script but most people wouldn’t consider that a “build step”. [13:43:09.0086] From the JS0 perspective, I’d argue it is one [13:54:25.0493] CommonJS is valid JS. (unless you put a top-level `return`, I guess.) it only needs to be transformed if you're running it in a browser, otherwise it's just using host APIs. [13:54:42.0684] and yes if you're running it on a browser then you definitely have a build step [14:03:33.0110] > <@shuyuguo:matrix.org> what is the workflow you have that you would consider 0 or 100 depending on context? as an example, transpilation vs minification [14:04:17.0555] and you consider minification to be not a build step (0), but transpilation to be a build step (100)? [14:05:19.0273] minification is also fully a build step, it's just an optional one [14:17:06.0902] Yeah, CommonJS modules are function body. `new Function('require', 'exports', 'module', '__filename', '__dirname', source)` isn’t really a build step, in my opinion. [14:17:48.0139] Or at least, it’s a build step iff `new ModuleSource(source)` would qualify as a build step. [14:20:20.0158] Less interesting to me than “whether there’s a build step” is whether I can host a webpage in development with `python -m http.server`, change a source file, and expect reloading a web page to be a sufficient workflow. [14:22:17.0589] Also, anything you would do beyond dumping the source in an S3 bucket when running to production, is a build step. [14:23:58.0532] So, e.g., generating an import map and injecting it into `index.html` qualifies as build step in my book, although the sources need not be transformed, which is a step in the direction of not having a build step. [14:24:33.0284] > <@kriskowal:aelf.land> Less interesting to me than “whether there’s a build step” is whether I can host a webpage in development with `python -m http.server`, change a source file, and expect reloading a web page to be a sufficient workflow. fo you consider "vscode invokes toolchain on save" fair game to include in the "change a source file" step? [14:24:44.0851] > <@kriskowal:aelf.land> Less interesting to me than “whether there’s a build step” is whether I can host a webpage in development with `python -m http.server`, change a source file, and expect reloading a web page to be a sufficient workflow. * would you consider "vscode invokes toolchain on save" fair game to include in the "change a source file" step? [14:25:29.0058] If vscode transforms the source in place, that’s not a build step in my book. Usually the before and after are behaviorally equivalent in those cases anyway. [14:25:48.0879] I also don’t mind if you use regular expressions to edit in vim. [14:25:59.0137] what about, like, a watch daemon? [14:26:07.0495] Watch daemon is a build step. [14:26:14.0289] interesting distinction [14:26:53.0028] Well, to be precise, watch daemons are usually used to invoke a build step. [14:27:08.0232] If you’re using a watch daemon to eslint --fix, that’s not a build step. [14:27:33.0384] The distinction is whether it’s source to source or source (edit) to object (build) [14:27:53.0698] what i meant to compare was: if VSCode has an on-save action that invokes the toolchain, vs a watch daemon that invokes the toolchain [14:28:00.0294] are those two things different in your mind? [14:28:07.0004] It’s also definitely possible to run CommonJS on the web without a build step. I wasted a lot of my life on that. [14:28:26.0817] > <@kriskowal:aelf.land> The distinction is whether it’s source to source or source (edit) to object (build) This is the distinction👆 [14:29:02.0132] If the toolchain is editing your sources, that’s just editing. [14:30:01.0334] but transpilation is always source-to-source [14:30:08.0434] > VSCode has an on-save action that invokes the toolchain there's two relevant kind of on-save actions here. the most common kind is running a formatter or something [14:30:21.0183] that is not what I would consider a build step, despite it consuming your source [14:30:34.0540] Now, if the toolchain is editing your importmap in an index.html every time you save, gosh, you’ve definitely wiggled out of the build step criterion, but in a way that makes people really dependent on their choice of editor and configuration complications in a way I don’t like. [14:30:35.0727] the other kind is running typescript or something, where the output file is _not_ overwriting the input file [14:30:40.0500] that is a build step [14:30:46.0573] ah i see [14:30:53.0826] that clarifies for me, thanks [14:49:42.0525] Sounds like we need to add typescript support to `python3 -m http.server` 😎 [14:51:10.0013] > <@aclaymore:matrix.org> Sounds like we need to add typescript support to `python3 -m http.server` 😎 No, Ashley. It’s bad enough that _as we speak_, I’m integrating your `ts-blank-space` in Agoric’s endo toolchain. 😉 [14:53:31.0559] oh cool! Btw there is an ASI issue I need to fix. Issue on repo. I'll get on it tomorrow [15:16:00.0733] > <@shuyuguo:matrix.org> and you consider minification to be not a build step (0), but transpilation to be a build step (100)? it's not in my development workflow. the actions-on-save and hot reload mentioned above is a helpful illustration. the main point is that the code in my editor is the code that is executed in the browser. maybe a better phrasing of the question could be "what proportion of the JS code you write MUST be compiled through a build process to actually run in the browser" [15:17:31.0593] > <@shuyuguo:matrix.org> and you consider minification to be not a build step (0), but transpilation to be a build step (100)? * for me it would be 0 no build step needed to run my code and 100 if minification for production, but not dev/test is considered it's not in my development workflow. the actions-on-save and hot reload mentioned above is a helpful illustration. the main point is that the code in my editor is the code that is executed in the browser. maybe a better phrasing of the question could be "what proportion of the JS code you write MUST be compiled through a build process to actually run in the browser" [15:17:37.0670] why is that a better phrasing? [15:18:09.0660] personally i'd be interested to know what people do today, regardless of whether they _need_ to [15:19:24.0471] it's better phrasing because my understanding of the intent behind the question is to get a feel for which folks would be impacted by a transpilation requirement [15:19:35.0661] i think that's also what i'm saying [15:20:39.0009] if I answer 100% to that question because minification, that gives the false impression that I would not be impacted by a new transpilation requirement because I'm already minifying [15:20:56.0465] my contention is that you in fact would not be impacted [15:21:25.0458] because I simply would not use JSSugar features? [15:21:42.0456] no, because you're already using a build step, you can add another tool in there [15:21:58.0008] no... [15:22:02.0169] maybe it's unfair to say you're not impacted, but it's a different kind of impact than people who don't have a build step at all? [15:22:22.0535] I don't have a build step in the dev/test cycle. the build step is in release [15:23:07.0399] so your issue with the question is clarifying whether it means dev/test cycle or release? [15:25:15.0833] my issue with the question is clarifying whether it means the code must be transformed to run correctly in the destination environment [15:25:56.0736] if you in fact always run it through a transform before executing it, I don't think it much matters whether you actually _need_ to do that [15:26:26.0179] that's a big if [15:26:43.0173] and I agree, if you were already doing that [15:27:07.0996] well, right. but it means that the important question is "do you always run your JS through a build step before executing it in a browser", not "what proportion MUST you run through a build step" [15:27:52.0268] yes, i agree with that [15:28:41.0543] if the code must be transformed to run correctly, that requires you to run a build step. but if you run a build step for some other reason, you still run a build step already [15:28:55.0620] > do you always run your JS through a build step before executing it in a browser that seems like an oversimplification. you wouldn't mind the loss of data points here for people who do not 100% of the time run their JS through some sort of build step before executing it in the browser? [15:29:07.0309] because I would simply say no to that question [15:29:33.0187] because you'd interpret it to mean "i do it for release, but not for test/dev, therefore, i don't always run it"? [15:30:37.0889] it'd be nice to get a super nuanced answer like when people do it for what workflows [15:30:43.0781] but i don't think state of js is set up for that [15:30:49.0386] if we were going for the most detail I'd ask about dev vs prod, but if we're just doing a binary then, correct, I would classify the people who sometimes don't run their JS through a build step in dev the same as the people who never run their JS through a build step [15:31:11.0937] > <@shuyuguo:matrix.org> because you'd interpret it to mean "i do it for release, but not for test/dev, therefore, i don't always run it"? yes, but also it doesn't allow for the reality that people work on different projects with different pipelines and workstreams [15:31:20.0786] well look [15:31:36.0542] because the "sometimes I do not do a build step" people are still affected by the proposal, in a different way that the "I always do a build step" people are not affected by the proposal [15:31:57.0252] we're arguing how to get the best signal from a survey, and in general it's very hard to get good signal from surveys [15:32:05.0911] I mean... or just ask two questions? [15:32:17.0144] which two questions? [15:32:28.0646] > <@shuyuguo:matrix.org> we're arguing how to get the best signal from a survey, and in general it's very hard to get good signal from surveys sure. but this makes it more important to disambiguate the question [15:32:45.0760] how do you get data on the multidimensional different projects, different workflows, etc, if you also disagree on the dev/prod distinction [15:32:52.0011] which i agree a dev/prod distinction would be good [15:33:42.0621] > <@shuyuguo:matrix.org> how do you get data on the multidimensional different projects, different workflows, etc, if you also disagree on the dev/prod distinction well, for one, offering a range of options is more helpful than a binary choice [15:33:59.0053] also like, i feel like you are setting this up so the data is best set up to confirm your priors? [15:35:54.0372] the question is ambiguous and difficult to answer for me as originally written [15:36:29.0725] i think "compiler" itself is going to throw people off [15:36:36.0833] do people think of babel as a "compiler"? [15:36:38.0941] absolutely agree [15:36:53.0009] I don't like that phrasing either - it doesn't help [15:37:01.0773] we don't have a better word [15:37:03.0861] but yeah [15:37:20.0476] like that is actually the correct word, i don't mean to suggest it's an ambiguous word [15:37:23.0707] `build process`, even.. I can go on [15:37:53.0198] i think the main conclusion here is that survey signal will remain tricky [15:38:30.0771] you can't construct what people actually meant, like in past state of js survey results when the top response for missing features is "types" [15:38:54.0840] thoughts on "transformation step, such as Babel or removing TypeScript types"? [15:39:14.0198] wfm [15:39:18.0388] i'd add "bundling"? [15:39:54.0165] yes to transformation step, but I think I disagree with bundling [15:40:07.0842] it's in the same class as minification to me [15:40:34.0377] I am interested in whether people are, in practice, always transforming their JS before running it [15:40:50.0000] if all you're doing is taking 10 files -> 1 file, but no further transformation, is that meaningful for this question? [15:40:55.0306] yes [15:41:03.0683] at release time onky? [15:41:06.0897] * at release time on;y? [15:41:10.0009] * at release time only? [15:41:38.0000] "only in prod" vs "even in dev" is a different axis than release time vs dev time [15:41:46.0387] if we care about that distinction, we can ask about it explicitly [15:42:03.0526] I mean, ok, now it seems like we have different understandings of what the question is actually asking. which is fine, but then we can't really figure out how to wordsmith it without first agreeing on the One True Question [15:42:23.0845] I am interested in whether people are, in practice, always transforming their JS before running it [15:42:30.0780] what is the thing you are interested in? [15:42:59.0783] I am interested in that too, but allowing for a non-binary answer choice, and also depending on what is considered transformation or not [15:43:07.0402] folks, if you want me to blog a screed, you can just ask 😉 [15:43:23.0176] I consider minification and bundling to be transformations [15:43:31.0260] which is why I'm trying to wordsmith a question which would include them [15:44:01.0172] I would be interested to know if there are differences between the types of transformations -- those are interesting data points [15:44:11.0917] (btw we _have_ data on this) [15:44:16.0392] or at least chrome does [15:44:19.0615] I guess? But I don't think those differences are that relevant to the JS0 question [15:44:31.0934] i feel like that data was dismissed for some reason [15:45:01.0406] > <@shuyuguo:matrix.org> i feel like that data was dismissed for some reason the people are asking for faster horses again? [15:45:05.0699] my view is that bundling/minification at release time only is in a different category than ts or babel during dev/test and boiling all that down to one answer seems sub-optimal [15:45:20.0295] > <@kriskowal:aelf.land> the people are asking for faster horses again? wat [15:46:02.0119] > <@shuyuguo:matrix.org> wat > “If I had asked people what they wanted, they would have said faster horses.” — Allegedly Henry Ford but probably not actually. [15:46:30.0483] oh, no, the data is like, people use frameworks [15:46:30.0840] I don't think that there is a meaningful difference between bundling/minification and babel/TS, except that someone might sometimes not do bundling/minification during dev. but then the distinction you want to draw is "do you always do a transform before running your JS, do you do it only in prod, or do you do it not even in prod", rather than asking about what kind of tools you run [15:46:34.0598] people use typescript [15:46:57.0930] that’s certainly consistent with my intuition [15:47:06.0496] big if true [15:47:06.0973] and by frameworks, specifically react, which has JSX, which requires to be transformed [15:47:16.0282] this isn't some hypothetical chris [15:47:31.0550] i am not issuing a revoluntary call for people to _start_ using tools that do transformations [15:47:40.0705] * i am not issuing a revolutionary call for people to _start_ using tools that do transformations [15:50:39.0215] (in principle it is possible to ship TS in prod, even, by the same trick people use to ship Python in prod https://latitudetechnolabs.com/pyscript-run-python-code-in-html) [15:53:04.0280] Bakkot, Deno users often ship TS in prod. [15:53:05.0296] yeah, this is all occurring on a backdrop of some understanding that standards groups are always trying to close the gap so that, at the limit, people eventually have what they need and also don’t have to run a build step, but for the last ten or so years, the cat and the mouse have paced each other. there’s a pretty vocal minority that strives to live within their means and avoid the “struggle stack”. i like that folks have options on this spectrum. [15:53:17.0836] > <@robpalme:matrix.org> Bakkot, Deno users often ship TS in prod. sorry, I left of the "in browsers" [15:53:32.0400] > <@robpalme:matrix.org> Bakkot, Deno users often ship TS in prod. * sorry, I left off the "in browsers" [15:56:21.0023] anyway continuing to workshop question wording: > What fraction of the time do you use a transformation step, such as Babel, bundling, removing types etc, before running it in browsers in production? > As above, but during development? > As above, but for running JS server-side? [15:57:51.0187] * anyway continuing to workshop question wording: > What fraction of the time do you run your code through a transformation step, such as Babel, bundling, removing types etc, before running it in browsers in production? > As above, but during development? > As above, but for running JS server-side? 2024-11-07 [16:00:09.0507] yes. I think that gives more insightful data. you could also give `select all that apply` for the different types of transformation. (if those distinctions are interesting to the surveyor in a similar way as the lifecycle distinctions) [16:00:14.0214] * anyway continuing to workshop question wording: > What fraction of the time do you run your code through a transformation step, such as Babel, bundling, removing types etc, before running it in browsers in production? > As above, but during development? > As above, but for running JS server-side? If your runtime supports stripping TS types automatically as part of executing, that doesn't count. [16:00:38.0735] for the JS0 discussion, why is it interesting to get server-side data? [16:01:25.0093] The server-side one is mostly just because once you've asked about half the time then you might as well ask about the other half [16:01:31.0098] since the server runtimes _can_ just run transforms on startup since the performance tradeoff space is so different, and that they're already doing so today, a JSSugar/JS0 distinction doesn't apply to servers [16:01:31.0782] ah [16:01:57.0554] and some fraction of people will not have read the "in browsers" part from the first question until they get to the third question and notice that they're being asked again [16:02:03.0221] fair [16:12:03.0859] > <@shuyuguo:matrix.org> for the JS0 discussion, why is it interesting to get server-side data? The interesting part here, as I mentioned in plenary, is that JS0 potentially makes a big difference to server-side runtimes based on the category of compilation we are pitching. Asking runtimes to do whole-program analysis prior to executing any code is a big ask they may not be prepared to accept. An interesting question would be how many server-side users wait for whole-program compilation prior to running today. As opposed to minimal on-demand transpilation, e.g. TS-node or Deno. [16:15:03.0999] Very few babel transforms have ever required whole-program analysis, IIRC [16:15:09.0244] except bundling, of course [16:15:13.0690] > <@robpalme:matrix.org> The interesting part here, as I mentioned in plenary, is that JS0 potentially makes a big difference to server-side runtimes based on the category of compilation we are pitching. > > Asking runtimes to do whole-program analysis prior to executing any code is a big ask they may not be prepared to accept. > > An interesting question would be how many server-side users wait for whole-program compilation prior to running today. As opposed to minimal on-demand transpilation, e.g. TS-node or Deno. agreed that'd be interesting, but that reads to me like JS0 requires whole-program analysis or something [16:15:18.0708] which it doesn't [16:15:19.0106] I would be surprised if that changes even in a JS0 world [16:15:50.0763] i know the TC39 discussion was focused on "is there meaningfully more optimization opportunity here", but that's not the primary motivation at all [16:18:27.0191] i also think the whole-program analysis thing may be a distraction anyhow. if i could represent i'd reframe it as "if we designed new features with good transpiler output as a goal, what's the likelihood we'll get new features with good transpiler output?" [16:27:26.0930] I wonder what generators would have looked like if that goal existed back then. The transpilation is huge (regenerator). [17:31:20.0864] regenerator was not setting out to be small [17:31:31.0148] TS does a much better job generating reasonable-sized output for generators [17:31:38.0382] * TS does a much better job generating reasonable-sized downleveling for generators [21:06:44.0836] the part that is most foggy to me is how interactive debugging will work. Suppose private fields had landed as JSsugar and were always transformed to weakmaps (ignoring that the performance of this is subpar vs real fields). when stopped on a breakpoint how would the repl handle the sugar? To transform it needs to align with how the original transform worked. Two different transforms could be in compatible. suggesting we need a standard emit and/or standard metadata that allows transforms to align. All doable, but is that what tc39 will do? [21:07:35.0029] * the part that is most foggy to me is how interactive debugging will work. Suppose private fields had landed as JSsugar and were always transformed to weakmaps (ignoring that the performance of this is subpar vs real fields). when stopped on a breakpoint how would the repl handle the sugar? To transform it needs to align with how the original transform worked. Two different transforms could be incompatible. suggesting we need a standard emit and/or standard metadata that allows transforms to align. All doable, but is that what tc39 will do? [21:12:18.0976] Similar thoughts for repl auto-complete. Engines do a great job today of proving auto complete on half written repl input. Similar challenge here to keep this DX in a more sugared world. Again solvable but not a given it would be definitely be solved. [21:12:29.0657] * Similar thoughts for repl auto-complete. Engines do a great job today of proving auto complete on half written repl input. Similar challenge here to keep this DX in a more sugared world. Again solvable but not a given it would definitely be solved. [22:05:37.0171] that's certainly a lot of feedback… [22:09:15.0543] for me the core of the question is "do you use a build step", independently of what that build step might be [22:09:39.0112] and I think we can restrict it to code that runs in the browser and in production if we want to narrow down the contexte [22:12:02.0177] * and I think we can restrict it to code that runs in the browser and in production if we want to narrow down the context [22:13:08.0894] I would like to keep the "0 to 100" format if possible, currently these questions don't have any special visualization but if I have enough of them I might create a dedicated chart [22:20:59.0483] so, with all that in mind I would suggest something like: > What proportion of the JavaScript code you write for the browser goes through a build step? With a clarifying line of: > Any bundled, minified, or otherwise transformed code, as opposed to code directly executed by the browser. [22:23:05.0495] I do think I will need to leave the term "compiled" in the legend though, as in "0% compiled" and "100% compiled". "0% built" just sounds weird? [22:24:07.0059] or I suppose I could just leave it as "0%" and "100%" but then it's a little more ambiguous [22:31:13.0049] > <@sachag:matrix.org> so, with all that in mind I would suggest something like: > > > What proportion of the JavaScript code you write for the browser goes through a build step? > > With a clarifying line of: > > > Any bundled, minified, or otherwise transformed code, as opposed to code directly executed by the browser. let me ask you this question: NB: this is _not_ hypothetical. if I write code which, for months, is not 'compiled' in any way, we're developing, testing, internal deploying, and so on. but no 'build'. then, when we are all done and dusted, there is a build. bundle, minify, packaged into debian, onto an OS disk image, and devices reimaged with the build how would you like me to answer your question? 100% compiled because at some point in the SDLC we generated an OS build ? [22:32:34.0915] so in which form does the code hit the browser? [22:33:28.0279] in its final use case I mean [22:33:50.0485] all of the above [22:34:17.0948] in production some is minified and/or bundled, some is not [22:35:23.0637] I mean, at some point we have to be ok with the fact that a survey is just an imperfect proxy for reality [22:35:37.0473] absolutely [22:35:52.0565] it can still be useful despite that [22:37:02.0850] I am not disputing the utility of the information 🙂 [22:37:40.0911] and how would you like me to answer that question? [22:37:49.0952] you can click the "skip" button ;) [22:37:53.0213] lmao [22:39:25.0370] I mean, we basically need to make sure the question is not ambiguous or misleading for a majority of respondents [22:39:31.0662] not that it covers every possible edge case [22:39:52.0606] to be perfectly clear -- it's not my intention to modify the question you are asking. I just find it to be profoundly interesting: the distinction between what tooling and transformation is happening during the development process vs... later [22:40:04.0837] oh ok [22:40:26.0614] sorry for misunderstanding your intent [22:40:29.0410] because `later` could be anything at all, pretty much [22:41:03.0343] > <@sachag:matrix.org> I mean, we basically need to make sure the question is not ambiguous or misleading for a majority of respondents 💯 [22:44:23.0435] ultimately, I think your latest version: > What proportion of the JavaScript code you write for the browser goes through a build step? > (Any bundled, minified, or otherwise transformed code, as opposed to code directly executed by the browser.) is an improvement. I still struggle with it a bit from a dev vs release perspective, but completely understand if that distinction isn't important or relevant for what you're trying to glean [00:43:40.0700] If someone is predominantly writing TypeScript they may misinterpret the use of "JavaScript" in the question. In one mind: "all of the JavaScript I write is embedded within a .ts file and is built", another mind: "oh I mostly wrote TypeScript but when I do occasionally write pure JS within a script tag that does not get built." [00:45:17.0375] Though I guess this will be paired with a similar question to the previous survey asking how much of the code they write is TS vs JS [05:22:28.0068] One way to get at the stuff Chris is talking about would be to have two questions, do you use a build step in development/debugging vs do you use a build step in production [09:55:19.0648] > <@aclaymore:matrix.org> the part that is most foggy to me is how interactive debugging will work. > > Suppose private fields had landed as JSsugar and were always transformed to weakmaps (ignoring that the performance of this is subpar vs real fields). > > when stopped on a breakpoint how would the repl handle the sugar? To transform it needs to align with how the original transform worked. Two different transforms could be incompatible. > suggesting we need a standard emit and/or standard metadata that allows transforms to align. All doable, but is that what tc39 will do? this is an existing problem today, no? [09:55:32.0757] like, the state of the art isn't great but i don't think it's foggy [10:24:58.0654] The problem already exists, but is scoped to a smaller set of features that this hits. The problem gets worse the more this applies to [10:25:18.0101] * The problem already exists, but is currently scoped to a smaller set of features. The problem gets worse the more this applies to  [10:28:18.0690] For example there was a period of time where I couldn't use `??` in the debugger but it was in the code because I was using a build transform to handle the new syntax. But then that became a thing of the past as it was then in the runtime. if things never make it to the runtime then the current way devtools are implemented then the set will keep growing, without catching up. [10:54:18.0340] makes sense [11:00:54.0814] is it time for EcmaDWARF [11:04:25.0586] skin disease × fantasy race collab [11:06:24.0730] wouldn’t be complete without EcmaELF and EcmaROFF. [11:07:11.0963] brother i think *we* (JS) are EcmaELF already [11:07:43.0276] I get that, but that doesn’t help me to get to the manpage pun. [13:35:38.0213] yeah we discussed in TG4 whether we should do a different binary format, and the answer was, "maybe (much) later, if there are significant perf advantages", but no one has presented a clear idea of how a different format would become more reliably available for the debugger [15:42:10.0419] quick survey of debugging expectations around exceptions thrown by `using`. suppose i have the following code: ``` { using x = { [Symbol.dispose]() { throw 1; }; using y = { [Symbol.dispose]() { throw 2; }; } ``` if you check "Pause on uncaught exceptions" in the debugger, what do you expect? 1) Pause on `throw 1` and `throw 2` in addition to pausing on the implicit throw of the `SuppressedError` 2) Do not pause on `throw 1` and `throw 2`, only on pause on the implicit throw of the `SuppressedError` [15:43:31.0936] relatedly, suppose i have the following code: ``` { using x = { [Symbol.dispose]() { throw 0; }; } ``` if you check "Pause on uncaught exceptions", do you expect 1. Pause on `throw 0` in addition to the implicit re-throwing of `0` by the dispose semantics 2. Do not pause on the `throw 0`, only pause on the implicit re-throwing of the `0` [15:44:01.0236] oh i missed some closing braces, you get what i mean 2024-11-08 [18:19:58.0069] First case: 1 - pause on the throws + rethrow Second case: 1 again. [18:29:26.0027] I'm almost tempted to say do not pause on the rethrow, as the rethrow position will be on the stack of the original throw (the block close I assume). The drawback is that for a suppressed error you don't have a chance to pause with the thrown suppressed error in the debug context. [18:30:35.0260] So I'd say 1 for suppressed and 3-only pause on original throw if the error is just rethrown [23:45:20.0509] by the way, are there other places besides here and the Web-Platform-DX chatroom where I should be asking for feedback on the surveys? [00:05:51.0430] Sacha Greif: if these are the web developer surveys (didn't read scrollback), maybe #whatwg:matrix.org [08:12:58.0155] > <@sachag:matrix.org> by the way, are there other places besides here and the Web-Platform-DX chatroom where I should be asking for feedback on the surveys? #tg5:mozilla.org and #wintercg:matrix.org [08:15:42.0199] > <@sachag:matrix.org> by the way, are there other places besides here and the Web-Platform-DX chatroom where I should be asking for feedback on the surveys? also the OpenJS Foundation Cross Project Council (reachable on Slack, GH, or public meetings), who could also perhaps (maybe) help publicize the survey(s) [08:16:17.0398] > <@sachag:matrix.org> by the way, are there other places besides here and the Web-Platform-DX chatroom where I should be asking for feedback on the surveys? * also the OpenJS Foundation Cross Project Council (reachable on Slack, GH, or public weekly meetings), who could also perhaps (maybe) help publicize the survey(s) [08:19:24.0207] maybe also: https://www.w3.org/groups/wg/webappsec/ https://www.w3.org/community/swag/ [08:19:33.0636] * maybe also: `https://www.w3.org/groups/wg/webappsec/` `https://www.w3.org/community/swag/` 2024-11-13 [22:11:29.0194] the State of JS 2024 survey is now officially open, thanks to everybody who contributed! if you are able to share it, it would be great if you can add a `?source=xyz` parameter at the end, such as: https://survey.devographics.com/en-US/survey/state-of-js/2024?source=tc39_chat [22:11:41.0948] this helps us track where respondents are coming from 2024-11-14 [17:50:02.0345] I'm probably searching for the wrong keywords here. If you can use a record with Map and Set, why can't it be used as a key in a record? #{ #{ a: 1 }: 2 }? [18:23:29.0278] Related: https://github.com/tc39/proposal-record-tuple/issues/203 [18:26:09.0001] The main spec complexity is that the spec would also need to define an ordering for R&T because their keys are sorted [18:27:58.0207] I also imagine it would add considerable implementation complexity to allow more types as keys, relative to "only strings". [18:31:41.0915] It did come up in conversations, as it kind of provides a kind of immutable set. But overall did not seem motivated enough to include in the proposal, which was trying to be maximally minimal [19:48:42.0314] yeah, not having a kind of sort is why there aren't sets or unordered tuples it seems. Just realized both ways would solve what I was trying. I was basically trying to use records as keys to make a set.