bakkoting

You'll only be able to use that if you are using the non-default `--noEmit` configuration, which requires the use of some other tool to strip types. Even after that change, using `tsc` to strip types will still force you to write `.js` in your imports.

There's a proposal for syntax to help with this in JS, incidentally: https://github.com/tc39/proposal-explicit-resource-managemen...

It is, actually. Well, "class" and "super" were never legal even before they became keywords, because the language was designed to evolve and those were obvious things which might be useful later. But "await" still works as a variable name outside of an async function, even today, precisely so that old code still works as it used to. There are some contortions in the specification (and implementations) required to make this work, but it does work. (I am one of the current editors of the JS specification.)

Mozilla is absolutely thinking in terms of the nightly version of the spec. I agree that public messaging sometimes talks about annual editions, but this is mostly because it's a convenient way to talk about when features were added to the language, not because it reflects any underlying reality.

Anyway, that's not really the relevant thing. What I'm addressing is:

> deno has done is removed native support for older js specs and instead makes you transpile to an earlier spec. And by removing support for the earlier specs, they are able to drop support for deprecated features.

And that's just not a thing. That has no relationship to the ES specification works. The __proto__ accessor was never mandatory; it was added in browsers a long time before it was specified, and then specified as optional (Annex B) when it was first added to the specification, and has been optional since then. This is true whether or not you think of there being a single specification or annual editions.

So, with that said, to address the specific topic of annual editions:

> "OK, ESlint understands new features A, B and D, but babel only implements B, C, and D, but library X doesn't support feature D yet, so since we want to use that we have to use bluebird instead of the native feature D for now" and on an on.

That's exactly how it works. eslint implements proposals at stage 4. Babel implements proposals as they come out and people contribute, but only adds them to preset-env at stage 3. The output for present-env is based on what's actually supported in the browsers you're using. They both take a variable amount of time to land features once they hit the appropriate stage. Neither of them gates anything on annual editions. Neither do browsers. And browsers will frequently not have implemented features from multiple editions ago; for example, regex lookbehind was added in ES2018 and is still not implemented in Safari.

> That's why each change to the spec results in a new version. It's a self-fork of the previous spec.

That's not how it works, no. There is just the spec [1], which is updated frequently. I am editor of the specification. (There are annual editions as well, but no one should pay attention to these.)

> I'm sure they'd add in support for freezing protoype chains, even if just as an option that can be toggled, but i doubt they'd ever want to break the spec just because they don't like parts of it.

Well, like I said, if Deno's only concern is breaking with the spec here, I expect the spec could be updated to allow this behavior.

[1] https://tc39.es/ecma262/

Deno has already made similar changes, like https://github.com/denoland/deno/pull/4341. That particular change happens to be allowed by the JS standard. The change discussed here isn't currently allowed, but I suspect TC39 would be open to making it allowed (though obviously it would not be allowed for browsers, in the same way the linked change to __proto__ is not allowed for browsers).

If you change something that most code isn't relying on, most code will still work. This change is plausible because it's very rare for code to be mutating built-ins. That's not true for most other possible "fixes". And most other changes would not have a benefit to consumers of the application (who cares if the library you're using has `var`s?), so they're much less well motivated.

o/ Luca! Fellow TC39 delegate here.

> It is unlikely that freezing all intrinsic prototypes and objects is even enough. People will find ways to exfiltrate tokens.

This is probably true, but frozen intrinsics would make it a _lot_ harder. Right now it's not reasonable to ask a library to be defensive against capability exfiltration, since it means not using any built-ins, but I think with frozen intrinsics it would be reasonable to treat a library leaking its capabilities as a security bug. There would still absolutely be leaks - most significantly in libraries which export classes and don't freeze the class prototype - but things would no longer be completely insecure by default. It would make malicious code have to work a _lot_ harder.

I think it's worth a shot. Deno removed the __proto__ getter/setter, and that did require a bunch of libraries to update, but it worked out OK.

Node already has --frozen-intrinsics, if anyone feels like experimenting with whether that would break your code.

> I've got some free time this summer so let me know if you have any advice about what else to add.

If you're taking nitpicks: some of your example calculations don't track units, like the ones on https://landgreen.github.io/physics/notes/momentum/1-intro/i.... I think they should: encouraging students to always track units in intermediate steps is really helpful for getting them to think about what they're doing and catch errors early, in my experience.

No, there isn't. I am on TC39.

Briefly: there's _tons_ of style things eslint can't even warn about which prettier will just automatically fix. Most dramatically, eslint doesn't know how to wrap long lines.

Also, though, eslint offers a bunch of non-style code correctness checks, which is something prettier doesn't even try to do. So the general advice is to use eslint with all the style rules off, and use prettier to handle style.

I'm not making a case for or against TypeScript; I'm just concerned that people be aware what is and is not part of JavaScript.

You said that TypeScript had no additional features except types. That's all I'm responding to: I'm pointing out this isn't the case. Class fields are, currently, not part of JavaScript. Neither are decorators.

(We're working on it - but actually a concern which has come up is that we might end up with something which breaks TypeScript, because the proposals are still in the early stages and therefore subject to radical changes.)

Decorators, and class fields, are pre-stage-4 ES proposals. That means they are not part of JavaScript. Moreover, what ends up eventually landing, especially in the case of decorators, is unlikely to work quite the same as what TypeScript implements.

So "Typescript has no additional features over (ES6+) JavaScript that are not part of the type system." is just false.

(Babel has plugins for all kinds of things that aren't part of JavaScript. The team is working on expressing more clearly which plugins are for experimental features and which are settled.)

> Wanted to show that you could do stupid, hard to analyze things in ES6 modules too. But maybe you can't !?

You can't, at least not in this way. A module's imported and exported names are statically determined. Of course, you can just export a single object, and then make that object arbitrarily complex depending on runtime behavior.

> Like being able to require modules locally

Not sure what this means.

> It doesn't impact destructuring at all because destructuring lines start with let

That's just not true. You can have destructuring assignments, not just declarations: `[a, b] = [b, a];` is perfectly legal ES2015.

I think the main draw is that Triplebyte will get you past the initial screening mechanisms. This is particularly useful if you can write good code but have no formal education or otherwise cannot put together a resume.