From the agenda for the 104th meeting of Ecma #TC39 (https://github.com/tc39/agendas/blob/main/2024/10.md#agenda-items). Longer or open-ended discussions: JSSugar/JS0: https://docs.google.com/presentation/d/1ylROTu3N6MyHzNzWJXQAc7Bo1O0FHO3lNKfQMfPOA4o/mobilepresent?slide=id.g30432c5cd9c_0_688. Slide 40 onward 👀:
Let's standardize as the ecosystem uses it:
JS0: the language implemented by the engines
JSSugar: features that must be compiled by tools to JS0
@tomayac Honestly I don't hate this. I sympathize with JS engine authors trying to balance security/perf with ergonomics. Given the CVE count and dumb perf bugs like "var is faster than const/let", it seems like a losing battle.
JS is already quite good, and it would be sad IMO if it became like Perl where there are 20 ways to do everything. And of course if perf/security suffer. JS0/JSSugar seem totally reasonable to me.
@sil @tomayac You're not wrong; there are tradeoffs here. I guess the question is: would "dark-matter developers" benefit from types in the language? Pattern matching? These are pretty advanced features, and the people using them are probably also going to be using tooling.
BTW I don't have a dog in this fight. I'm just saying that on the face of it, I'm not shocked by the proposal.
@sil @nolan @tomayac as a professional developer of ridiculously complicated web apps, I can with extreme prejudice say that anything the platform can do to *remove tooling* would be a good thing for my teams development.
Tooling is without doubt the biggest drag on the JS ecosystem today. I spent a disproportionate amount of time making transpiling, bundling, testing and debugging work reliably and every 'upgrade' brings a new suite of weird bugs and time sink.
@bendelarre @sil @tomayac I feel your pain, but there are ways you can eliminate tooling today:
- Use JSDoc comments instead of TS. Or no TS at all!
- Use compile-less frameworks like Lit/Vue instead of React/Svelte/etc
- Go #NoBuild - remove bundlers/minifiers and serve direct ESM
Not saying this is easy or ideal, but people are doing it. I've started doing it in many of my projects.
And what's the alternative? Standardize TS/JSX?
@nolan @sil @tomayac I think the Type Annotations proposal was a good one tbh.
For the complexity of app we work on I don't think I could imagine using jsdoc style comments for our types, it would be excessively verbose given the amount of interface and generics typing going on.
We do already use Lit, but we couldn't go bundleless because direct serving of esm has waterfall effects that are prohibitive of performance, as well as other build time optimizations we would lose.
@bendelarre @nolan @sil @tomayac The Type Annotations proposal only proposes a syntax for specifying type data on function arguments, function returns, variable declarations and such – it does not specify the type language itself
When doing JSDoc typing you can still use type files (.d.ts) to define your complex generics etc and you need to use them for interfaces. Then you import them into your JS-files and apply them with JSDoc. It doesn’t get very verbose even in very complex setups
@bendelarre @sil @nolan @tomayac
I can't wait for 5 different build tools that all transpile slightly different and have subtly different behavior. Bundlers can't even agree on a glob syntax...so we're just gonna push the standard to build tools...what could go wrong...
Thomas Steiner 
Nolan Lawson
Stuart Langridge
Jan Lehnardt 
Caolan McMahon
Ben Delarre
Pelle Wessman
Munawwar Firoz
Trygve Lie
Alper Çuğun-Gscheidel
Konnor Rogers
Gerrit van Aaken