Thomas Steiner Oct 6, 2024

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

For developers, JS = #JS0 + #JSSugar

agendas/2024/10.md at main · tc39/agendas

TC39 meeting agendas. Contribute to tc39/agendas development by creating an account on GitHub.

GitHub
Show threadNolan LawsonOct 7, 2024

@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.

Show threadStuart Langridge
@nolan @tomayac I'm not sure I'm understanding this, but if I get it, presenting "JS" to developers as JS0+JSSugar means that we're baking the idea of tooling into the language now, right? Opening a .js file and writing code into it just won't work any more because there has to be a compiler in the tool stack somewhere (there has to BE a tool stack somewhere). Sure, it'll be possible to intentionally limit yourself to writing JS0 only but now half the articles about JS stuff won't work for you?
Oct 7, 2024 at 7:40amPhanpy
Show threadStuart LangridgeOct 7, 2024
@nolan @tomayac "State of JS development today already requires tooling to be productive & competitive" is, I'm sure, true for people writing complex apps, but not everybody is doing that! "Hey, I would like to add error checking to this form more than pattern/required does". "I want a table to be sortable by clicking the headers". Sure, "professional" full-time JS devs need more, but not everyone does; just the people who don't participate in standards chat and socials. Dark matter developers.
Show threadNolan LawsonOct 7, 2024

@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.

Show threadStuart LangridgeOct 7, 2024
@nolan @tomayac oh, I agree that the extra features -- doable using tooling -- are not useful to people who are not professional or full-time developers. But once those are blessed as being "standard JS", and we wind the clock forward three years, half the "plain JS" articles in the world don't work for them any more. And the division will be arbitrary. Imagine this split was done ten years ago. Now, Array.forEach works in JS; Array.some requires a build tool. This feels confusing to devs to me?
Show threadStuart LangridgeOct 7, 2024
@nolan @tomayac I take your point, and I'm not arguing against you because I think you're a stern defender of this idea, promise :) I do sorta think that there may be no stern defenders of the idea of not doing this, though, because everyone with enough skin in the game to be involved at all thinks that "set up build tools" is a first, critical, and inevitable step of doing anything on the web, a stance I personally do not agree with :)
Show threadJan Lehnardt Oct 7, 2024
@sil you’re not alone :)
Show threadCaolan McMahonOct 7, 2024
@janl @sil it feels like we've been getting closer to a workable no-build-step solution for a few years but I fear this is an admission that bus will never arrive.
Show threadJan Lehnardt Oct 7, 2024
@caolan @sil is love to see us getting to that first.
Show threadBen DelarreOct 7, 2024

@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.

Show threadNolan LawsonOct 7, 2024

@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?

Show threadBen DelarreOct 8, 2024

@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.

Show threadPelle WessmanOct 20, 2024

@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

Show threadMunawwar FirozNov 14, 2024
@bendelarre @nolan @sil @tomayac I too reverted from a build-less setup with importmaps etc back to esbuild, for exactly reason mentioned .. waterfall requests. JSDoc TS and Lit or preact+htm is doable without sacrificing too much.
Show threadTrygve LieOct 8, 2024
@nolan I use the same approach but one need a setup to work this way too. What I feel we are missing are framework(s) which embrace this approach. @bendelarre @sil @tomayac
Show threadAlper Çuğun-GscheidelNov 14, 2024
@nolan @bendelarre @sil @tomayac I look forward to write only TS without tooling and forget that JS exists. (That is if JS doesn’t manage to become competitive in the mean time.)
Show threadKonnor RogersOct 7, 2024

@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...

Show threadGerrit van AakenNov 14, 2024
@bendelarre true