proposal-type-annotations VS proposal-record-tuple

After almost a decade of TypeScript my recommendation is to not use TypeScript enums.

Enums is going to make your TypeScript code not work in a future where TypeScript code can be run with Node.js or in browser when typings are added to JavaScript[1]

Enums results in runtime code and in most cases you really want type enums. Use `type State = "Active" | "Inactive"` and so on instead. And if you really want an closed-ended object use `const State = { Active: 1, Inactive: 0 } as const`

[1] https://github.com/tc39/proposal-type-annotations

Maybe as part of the Flutter/Dart sales story?

Here is the current status of the standard proposal.

https://tc39.es/proposal-type-annotations/

So read the Github of TC39: https://github.com/tc39/proposal-type-annotations

Yes. That is noted in the PR:

> There is a TC39 proposal for type annotations

Which links to https://github.com/tc39/proposal-type-annotations

It is a long ways off though.

IMO the game changer in your scenario is when type annotations are added as a standard JS feature:

https://github.com/tc39/proposal-type-annotations

At that point you'd be able to run your TS code directly without any transpiration necessary. I'd love to remove all the build process junk from my projects and have them run quicker.

That proposal is not fully compatible with Typescript: https://github.com/tc39/proposal-type-annotations?tab=readme...

They held a meeting a few months ago so it's alive but probably still years away.

https://github.com/tc39/proposal-type-annotations/issues/184

I particularly like this thread in the TC39 types proposal. TypeScript IS a development trojan horse and locks you into the Microsoft Way of being a JS developer.

Edit: There is a proposal to extend JavaScript with type annotations, which would allow ("a reasonably large subset") of TypeScript to run directly in the browser. Yay!

https://github.com/tc39/proposal-type-annotations

Records and tuples are unlikely to ever ship, or at least are extremely unlikely to ship with the semantics around equality people want. My understanding is that browser vendors already have pretty strong opposition to introducing new primitives at this point. Reading this thread[1] will give some explanation as to the hiccups with how equality would behave. It sucks, because while I wouldn't have expected BigInt to have gotten much adoption in the first place, I constantly run into cases where I'd want records or tuples.

[1] https://github.com/tc39/proposal-record-tuple/issues/387

The next big step is dependent on JS language/runtime features. Specifically the Record-Tuple proposal (https://github.com/tc39/proposal-record-tuple)

TL;DR: It's a way to designate data as being immutable.

JS doesn't currently have a good way to do this, so everything built for it tries to assume that data hasn't changed since it was last set. This leads to headaches for developers and wasted cycles for runtimes.

When JS has a proper way to make data immutable, it makes it easier for libraries/frameworks to make guarantees about the underlying data and makes it possible for runtimes to better optimize code.

relevant issue, which is at the crux of this problem: https://github.com/tc39/proposal-record-tuple/issues/387

There are still so many basic things that aren't in the JS stdlib, though. A good example is Map - if you need to use a tuple of two values as a key, you're SOL because there's no way to customize key comparisons. Hopefully we'll get https://tc39.es/proposal-record-tuple/ eventually, but meanwhile languages ranging from C++ to Java to Python have had some sensible way to do this for over 20 years now.

If you’re reaching for structuredClone, what you really want is native immutable Record and Tuple syntax, and the companion “deep path properties” syntax which allows for efficient and ergonomic immutable updates:

- https://github.com/tc39/proposal-record-tuple

It will be called "record" in JavaScript which will swing the popularity back the other way I guess (currently a language proposal)

I suspect considering the strong desire to maintain consistency with JavaScript, we will eventually see something that when the Record proposal passes through tc39

I hope the Record and Tuple proposal makes it through

I mean, I'd love some real immutable/persistent data structures in JS by default, or even some Immer-like syntax sugar. Something like the record/tuple proposal would be awesome.