4 ms·

Wouldn't it make more sense for some of these features to be implemented as a desugaring step in the runtime itself? i.e. if implementing them directly as new l

Wouldn't it make more sense for some of these features to be implemented as a desugaring step in the runtime itself? i.e. if implementing them directly as new language features doesn't make sense, then preprocess them away before executing the scripts. You could even do this for past features that made it into ECMAScript but haven't turned out to be useful, instead of ossifying a specific moment in time's tooling.

wrs 2y ago
If there’s still going to be a standard JSSugar, yes, seems like it should be desugared in the runtime. On the other hand, if we want to make it easier to fragment the high-level language into incompatible sugared versions, this seems like the way to go. (Hard to believe that would be the TC’s goal.)
gary_0 2y ago
> Wouldn't it make more sense for some of these features to be implemented as a desugaring step in the runtime itself? I think if it was that simple, it would be done that way already (maybe it is, for some features). Two big arguments for doing the "desugaring" offline are the (1) speed, and (2) security of the browser. Those two things also conflict somewhat if addressed on the client, since faster but more complex compiler code increases the surface area for potential exploits. But if you do this compile step offline, you don't need to worry about compromising the performance or security of the browser.
sshine 2y ago
> features to be implemented as a desugaring step in the runtime itself The problem is distributing the runtime(s). By having developers transpile to a small core, anyone can freely invent new language features without waiting for the rest of the internet to download support for them.
3np 2y ago
Why wouldn't you take the complexity and performance hit involved once at buildtime rather than offloading it to the client at runtime? If you read the original slides from the proposers, they're presenting a framing where there is an inherent tension between "serving the user" and "helping the developer". They argue that there is too much of the latter, and that a formalized splitting should push more to the former. From an end-user perspective, it definitely makes more sense that the js doesn't have to be transformed locally before it can interpreted. I think your suggestion is not compatible with the motivations of the proposal.
singularity2001 2y ago
This is a very good at important point: JS0 should be a subset of current JS JS1 should be current JS JsSugar should be current JS plus future features
ec109685 2y ago
If it’s not implemented as a built-in feature of the browser, wouldn’t half the internet break if features were removed that people were counting on?

wrs 2y ago

If there’s still going to be a standard JSSugar, yes, seems like it should be desugared in the runtime. On the other hand, if we want to make it easier to fragment the high-level language into incompatible sugared versions, this seems like the way to go. (Hard to believe that would be the TC’s goal.)

gary_0 2y ago

> Wouldn't it make more sense for some of these features to be implemented as a desugaring step in the runtime itself? I think if it was that simple, it would be done that way already (maybe it is, for some features). Two big arguments for doing the "desugaring" offline are the (1) speed, and (2) security of the browser. Those two things also conflict somewhat if addressed on the client, since faster but more complex compiler code increases the surface area for potential exploits. But if you do this compile step offline, you don't need to worry about compromising the performance or security of the browser.

sshine 2y ago

> features to be implemented as a desugaring step in the runtime itself The problem is distributing the runtime(s). By having developers transpile to a small core, anyone can freely invent new language features without waiting for the rest of the internet to download support for them.

3np 2y ago

Why wouldn't you take the complexity and performance hit involved once at buildtime rather than offloading it to the client at runtime? If you read the original slides from the proposers, they're presenting a framing where there is an inherent tension between "serving the user" and "helping the developer". They argue that there is too much of the latter, and that a formalized splitting should push more to the former. From an end-user perspective, it definitely makes more sense that the js doesn't have to be transformed locally before it can interpreted. I think your suggestion is not compatible with the motivations of the proposal.

singularity2001 2y ago

This is a very good at important point: JS0 should be a subset of current JS JS1 should be current JS JsSugar should be current JS plus future features

ec109685 2y ago

If it’s not implemented as a built-in feature of the browser, wouldn’t half the internet break if features were removed that people were counting on?