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