Our great sponsors
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
mini-typescript
A miniature model of the Typescript compiler, intended to teach the structure of the real Typescript compiler
http://kangax.github.io/compat-table/es6/
This page lists features from es6 (and newer versions linked at the top) along with compliance to the spec. First column is the current browser, second is babel+corejs polyfills.
Overall, babel gets about 70% of the way there.
> no pattern matching/switch expressions
They're still waiting on the do expression proposal for that (https://github.com/tc39/proposal-do-expressions), which has been in the bikeshedding stage for the past five years.
Very much apropos:
Going between Rust and TS it is painfully obvious how much sth like tagged enums are missing, which can also be seen in this post.
I know of this [1] proposal for ADT enums which looks like it has stalled. Anyone know of other efforts?
[1] https://github.com/Jack-Works/proposal-enum/discussions/19
As the post nicely demonstrates, TypeScript is definitely not OK for compilers (and not surprising at all!)
It doesn't even have destructuring pattern matching!
At this point, even Java is better [1].
[1] https://github.com/tomprimozic/caya/blob/master/src/caya/Int...
> MHO typescript could just cut loose from its javascript compatibility. Why not compile it to wasm instead of transpiling it to javascript?
Check out AssemblyScript which is exactly that:
https://www.assemblyscript.org/
Wonder no more: https://github.com/dudykr/stc
Written in Rust by the (lead?) dev of SWC
SWC (speedy web compiler) compiles TS to JS
With how powerful the type system is you can implement pattern matching via a library pretty convincingly, https://github.com/gvergnaud/ts-pattern is definitely the go-to. That being said pattern matching is hardly a requirement for being ok for implementing compilers.
The proposal for pattern matching syntax seems more akin to what they're looking for.
https://github.com/tc39/proposal-pattern-matching
Or maybe just start using Results as return type and get ValueOrDefault :) But when it comes to handling exceptions, I think it explodes there with ifs and processing IENumerables: https://github.com/altmann/FluentResults
But then again, simpler Results wrapper may be used perhaps. But it is a different way of coding and takes some mental shift on how to think about errors and distinguish between error results and true exceptions.
https://github.com/altmann/FluentResults
The future isolated declaration mode promises great improvements: until 75% of reduction in compilation time! [0]
[0] https://github.com/microsoft/TypeScript/pull/53463#issuecomm...
That depends on how many changes it requires. If its just a matter of don't do these 3 things and your code suddenly becomes more predictable its like being slapped with a magic wand. Everybody wins. All you have to do to ensure 100% of your code compiles in a JIT is be predictable. Predictable code is, on its face, always less confusing.
> The performance benefits are likely to be minimal
This makes me cry, but not a cry of joy or ecstasy. People guessing about performance is perhaps the most frequent anti-pattern in all programming. Please read this document, you can skip to the end but it may not make much sense if you do. https://github.com/prettydiff/wisdom/blob/master/JavaScript_...