TC39 General
2024-11-07
plaintext logs
prev next
source on github
00:00
<Chris de Almeida>
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)
00:00
<bakkot>
 *

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.

00:00
<shu>
for the JS0 discussion, why is it interesting to get server-side data?
00:01
<bakkot>
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
00:01
<shu>
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
00:01
<shu>
ah
00:01
<bakkot>
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
00:02
<shu>
fair
00:12
<Rob Palmer>
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.

00:15
<bakkot>
Very few babel transforms have ever required whole-program analysis, IIRC
00:15
<bakkot>
except bundling, of course
00:15
<shu>

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
00:15
<shu>
which it doesn't
00:15
<bakkot>
I would be surprised if that changes even in a JS0 world
00:15
<shu>
i know the TC39 discussion was focused on "is there meaningfully more optimization opportunity here", but that's not the primary motivation at all
00:18
<shu>
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?"
00:27
<Rob Palmer>
I wonder what generators would have looked like if that goal existed back then. The transpilation is huge (regenerator).
01:31
<bakkot>
regenerator was not setting out to be small
01:31
<bakkot>
TS does a much better job generating reasonable-sized downleveling for generators
05:06
<Ashley Claymore>
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?
05:12
<Ashley Claymore>
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.
06:05
<Sacha Greif>
that's certainly a lot of feedback…
06:09
<Sacha Greif>
for me the core of the question is "do you use a build step", independently of what that build step might be
06:09
<Sacha Greif>
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
06:13
<Sacha Greif>
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
06:20
<Sacha Greif>

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.

06:23
<Sacha Greif>
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?
06:24
<Sacha Greif>
or I suppose I could just leave it as "0%" and "100%" but then it's a little more ambiguous
06:31
<Chris de Almeida>

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 ?

06:32
<Sacha Greif>
so in which form does the code hit the browser?
06:33
<Sacha Greif>
in its final use case I mean
06:33
<Chris de Almeida>
all of the above
06:34
<Chris de Almeida>
in production some is minified and/or bundled, some is not
06:35
<Sacha Greif>
I mean, at some point we have to be ok with the fact that a survey is just an imperfect proxy for reality
06:35
<Chris de Almeida>
absolutely
06:35
<Sacha Greif>
it can still be useful despite that
06:37
<Chris de Almeida>
I am not disputing the utility of the information 🙂
06:37
<Chris de Almeida>
and how would you like me to answer that question?
06:37
<Sacha Greif>
you can click the "skip" button ;)
06:37
<Chris de Almeida>
lmao
06:39
<Sacha Greif>
I mean, we basically need to make sure the question is not ambiguous or misleading for a majority of respondents
06:39
<Sacha Greif>
not that it covers every possible edge case
06:39
<Chris de Almeida>
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
06:40
<Sacha Greif>
oh ok
06:40
<Sacha Greif>
sorry for misunderstanding your intent
06:40
<Chris de Almeida>
because later could be anything at all, pretty much
06:41
<Chris de Almeida>
I mean, we basically need to make sure the question is not ambiguous or misleading for a majority of respondents
💯
06:44
<Chris de Almeida>

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

08:43
<Ashley Claymore>
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."
08:45
<Ashley Claymore>
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
13:22
<littledan>
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
17:55
<shu>
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?
17:55
<shu>
like, the state of the art isn't great but i don't think it's foggy
18:24
<Ashley Claymore>
The problem already exists, but is currently scoped to a smaller set of features. The problem gets worse the more this applies to 
18:28
<Ashley Claymore>
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.
18:54
<shu>
makes sense
19:00
<shu>
is it time for EcmaDWARF
19:04
<shu>
skin disease × fantasy race collab
19:06
<kriskowal>
wouldn’t be complete without EcmaELF and EcmaROFF.
19:07
<shu>
brother i think we (JS) are EcmaELF already
19:07
<kriskowal>
I get that, but that doesn’t help me to get to the manpage pun.
21:35
<littledan>
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
23:42
<shu>

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
23:43
<shu>

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
23:44
<shu>
oh i missed some closing braces, you get what i mean