TC39 General
2024-11-06
plaintext logs
prev next
source on github
00:44
<Sacha Greif>
I had an idea for another question to help get perspective on the JS0/JSSugar thing without asking about it directly
00:44
<Sacha Greif>
I suspect that the answers will skew very much to the right but we'll see!
13:11
<littledan>
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”?
15:42
<Mathieu Hofman>
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)
15:52
<nicolo-ribaudo>
The difference would probably be "do you use a single command to compile+execute, or do you use two separate commands?"
16:13
<Mathieu Hofman>
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?
16:29
<bakkot>
that definitely sounds like a build step to me
16:30
<bakkot>
ts-blank-space is also what I would consider to be a build step
16:30
<bakkot>
anything that you do to transform your code before executing it is a build step
16:31
<nicolo-ribaudo>
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?
16:31
<bakkot>
no, that is not something you do before executing your code
16:32
<bakkot>
deno transforms the code before executing it in exactly the same sense that v8 transforms the code before executing it
16:33
<nicolo-ribaudo>
Yeah ok that matches my opinion of what is a what is not a build step
19:46
<Ashley Claymore>
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` ?
19:54
<Justin Ridgewell>
If it were shipped as part of node, not a buid step.
20:17
<Chris de Almeida>
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.
21:29
<shu>
what is the workflow you have that you would consider 0 or 100 depending on context?
21:42
<Jan Olaf Martin>
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”.
21:43
<Jan Olaf Martin>
From the JS0 perspective, I’d argue it is one
21:54
<bakkot>
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.
21:54
<bakkot>
and yes if you're running it on a browser then you definitely have a build step
22:03
<Chris de Almeida>
what is the workflow you have that you would consider 0 or 100 depending on context?
as an example, transpilation vs minification
22:04
<shu>
and you consider minification to be not a build step (0), but transpilation to be a build step (100)?
22:05
<bakkot>
minification is also fully a build step, it's just an optional one
22:17
<kriskowal>
Yeah, CommonJS modules are function body. new Function('require', 'exports', 'module', '__filename', '__dirname', source) isn’t really a build step, in my opinion.
22:17
<kriskowal>
Or at least, it’s a build step iff new ModuleSource(source) would qualify as a build step.
22:20
<kriskowal>
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.
22:22
<kriskowal>
Also, anything you would do beyond dumping the source in an S3 bucket when running to production, is a build step.
22:23
<kriskowal>
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.
22:24
<shu>
would you consider "vscode invokes toolchain on save" fair game to include in the "change a source file" step?
22:25
<kriskowal>
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.
22:25
<kriskowal>
I also don’t mind if you use regular expressions to edit in vim.
22:25
<shu>
what about, like, a watch daemon?
22:26
<kriskowal>
Watch daemon is a build step.
22:26
<shu>
interesting distinction
22:26
<kriskowal>
Well, to be precise, watch daemons are usually used to invoke a build step.
22:27
<kriskowal>
If you’re using a watch daemon to eslint --fix, that’s not a build step.
22:27
<kriskowal>
The distinction is whether it’s source to source or source (edit) to object (build)
22:27
<shu>
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
22:28
<shu>
are those two things different in your mind?
22:28
<kriskowal>
It’s also definitely possible to run CommonJS on the web without a build step. I wasted a lot of my life on that.
22:28
<kriskowal>
The distinction is whether it’s source to source or source (edit) to object (build)
This is the distinction👆
22:29
<kriskowal>
If the toolchain is editing your sources, that’s just editing.
22:30
<shu>
but transpilation is always source-to-source
22:30
<bakkot>

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

22:30
<bakkot>
that is not what I would consider a build step, despite it consuming your source
22:30
<kriskowal>
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.
22:30
<bakkot>
the other kind is running typescript or something, where the output file is not overwriting the input file
22:30
<bakkot>
that is a build step
22:30
<shu>
ah i see
22:30
<shu>
that clarifies for me, thanks
22:49
<Ashley Claymore>
Sounds like we need to add typescript support to `python3 -m http.server` 😎
22:51
<kriskowal>
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. 😉
22:53
<Ashley Claymore>
oh cool! Btw there is an ASI issue I need to fix. Issue on repo. I'll get on it tomorrow
23:16
<Chris de Almeida>

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"

23:17
<shu>
why is that a better phrasing?
23:18
<shu>
personally i'd be interested to know what people do today, regardless of whether they need to
23:19
<Chris de Almeida>
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
23:19
<shu>
i think that's also what i'm saying
23:20
<Chris de Almeida>
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
23:20
<shu>
my contention is that you in fact would not be impacted
23:21
<Chris de Almeida>
because I simply would not use JSSugar features?
23:21
<shu>
no, because you're already using a build step, you can add another tool in there
23:21
<Chris de Almeida>
no...
23:22
<shu>
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?
23:22
<Chris de Almeida>
I don't have a build step in the dev/test cycle. the build step is in release
23:23
<shu>
so your issue with the question is clarifying whether it means dev/test cycle or release?
23:25
<Chris de Almeida>
my issue with the question is clarifying whether it means the code must be transformed to run correctly in the destination environment
23:25
<bakkot>
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
23:26
<Chris de Almeida>
that's a big if
23:26
<Chris de Almeida>
and I agree, if you were already doing that
23:27
<bakkot>
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"
23:27
<shu>
yes, i agree with that
23:28
<shu>
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
23:28
<Chris de Almeida>

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?

23:29
<Chris de Almeida>
because I would simply say no to that question
23:29
<shu>
because you'd interpret it to mean "i do it for release, but not for test/dev, therefore, i don't always run it"?
23:30
<shu>
it'd be nice to get a super nuanced answer like when people do it for what workflows
23:30
<shu>
but i don't think state of js is set up for that
23:30
<bakkot>
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
23:31
<Chris de Almeida>
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
23:31
<shu>
well look
23:31
<bakkot>
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
23:31
<shu>
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
23:32
<Chris de Almeida>
I mean... or just ask two questions?
23:32
<shu>
which two questions?
23:32
<Chris de Almeida>
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
23:32
<shu>
how do you get data on the multidimensional different projects, different workflows, etc, if you also disagree on the dev/prod distinction
23:32
<shu>
which i agree a dev/prod distinction would be good
23:33
<Chris de Almeida>
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
23:33
<shu>
also like, i feel like you are setting this up so the data is best set up to confirm your priors?
23:35
<Chris de Almeida>
the question is ambiguous and difficult to answer for me as originally written
23:36
<shu>
i think "compiler" itself is going to throw people off
23:36
<shu>
do people think of babel as a "compiler"?
23:36
<Chris de Almeida>
absolutely agree
23:36
<Chris de Almeida>
I don't like that phrasing either - it doesn't help
23:37
<shu>
we don't have a better word
23:37
<shu>
but yeah
23:37
<shu>
like that is actually the correct word, i don't mean to suggest it's an ambiguous word
23:37
<Chris de Almeida>
build process, even.. I can go on
23:37
<shu>
i think the main conclusion here is that survey signal will remain tricky
23:38
<shu>
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"
23:38
<bakkot>
thoughts on "transformation step, such as Babel or removing TypeScript types"?
23:39
<shu>
wfm
23:39
<shu>
i'd add "bundling"?
23:39
<Chris de Almeida>
yes to transformation step, but I think I disagree with bundling
23:40
<Chris de Almeida>
it's in the same class as minification to me
23:40
<bakkot>
I am interested in whether people are, in practice, always transforming their JS before running it
23:40
<Chris de Almeida>
if all you're doing is taking 10 files -> 1 file, but no further transformation, is that meaningful for this question?
23:40
<bakkot>
yes
23:41
<Chris de Almeida>
at release time only?
23:41
<bakkot>
"only in prod" vs "even in dev" is a different axis than release time vs dev time
23:41
<bakkot>
if we care about that distinction, we can ask about it explicitly
23:42
<Chris de Almeida>
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
23:42
<bakkot>
 I am interested in whether people are, in practice, always transforming their JS before running it
23:42
<bakkot>
what is the thing you are interested in?
23:42
<Chris de Almeida>
I am interested in that too, but allowing for a non-binary answer choice, and also depending on what is considered transformation or not
23:43
<kriskowal>
folks, if you want me to blog a screed, you can just ask 😉
23:43
<bakkot>
I consider minification and bundling to be transformations
23:43
<bakkot>
which is why I'm trying to wordsmith a question which would include them
23:44
<Chris de Almeida>
I would be interested to know if there are differences between the types of transformations -- those are interesting data points
23:44
<shu>
(btw we have data on this)
23:44
<shu>
or at least chrome does
23:44
<bakkot>
I guess? But I don't think those differences are that relevant to the JS0 question
23:44
<shu>
i feel like that data was dismissed for some reason
23:45
<kriskowal>
i feel like that data was dismissed for some reason
the people are asking for faster horses again?
23:45
<Chris de Almeida>
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
23:45
<shu>
the people are asking for faster horses again?
wat
23:46
<kriskowal>
wat

“If I had asked people what they wanted, they would have said faster horses.” — Allegedly Henry Ford but probably not actually.

23:46
<shu>
oh, no, the data is like, people use frameworks
23:46
<bakkot>
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
23:46
<shu>
people use typescript
23:46
<kriskowal>
that’s certainly consistent with my intuition
23:47
<Chris de Almeida>
big if true
23:47
<shu>
and by frameworks, specifically react, which has JSX, which requires to be transformed
23:47
<shu>
this isn't some hypothetical chris
23:47
<shu>
i am not issuing a revolutionary call for people to start using tools that do transformations
23:50
<bakkot>
(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)
23:53
<Rob Palmer>
Bakkot, Deno users often ship TS in prod.
23:53
<kriskowal>
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.
23:53
<bakkot>
sorry, I left off the "in browsers"
23:56
<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?