TypeScript 5.0 (devblogs.microsoft.com)

From the outside, it seemed a fantastic example of collaboration between two separate (competing?) teams. It took humility and pragmatism for the Angular team to abandon AtScript and recognise TS as the better long-term bet.

Still pushing for it. TS is like make-up on a pig, compared to Elm.

> I do know one company that uses ReasonML (or isn't it called Rescript now?)

Re* is also a better alternative imho. Better interop with JS/TS is very nice. But in place one could use Elm, I'd say it certainly wins in the "clean" reward.

One company outside Meta?

Typescript was started at Microsoft by the guy who designed Turbo Pascal and C#, so completely independently from Google's Angular team. Angular had its own "AtScript" and eventually ditched that. Typescript had experimental decorator support well before Angular Team moved from AtScript, because it was a ECMAScript proposal.

Angular had zero influence in the design or success of Typescript. Typescript however does support JSX optionally so one can claim that React DID influence Typescript's design decisions.

Ironically, I think that angular is the framework that benefits least from actually using TypeScript. There is a separate templating language that's only type-checked if you set the right compiler options. JSX is much better suited for that. Being OOP like angular, it often requires opting out of null-safety or init-checks, because something is late-initialized. Having mutable instance state results in less opportunities to be more strict with typing.

Its good that the TS team decided to align with the ES standards. Initially (talking like v0.8.0), I had the impression that they're building a "C# for the web", being incompatible with ES. Maybe that's why enums and namespaces were added and initially, the boolean was named bool.

> TypeScript 5.0 has a minimum version requirement of at least Node.js 12.20 and later

https://devblogs.microsoft.com/typescript/announcing-typescr...

They don't have the same features. The new one are based on the upcoming EcmaScript decorators.

If you like them, you're probably already drowning in them. Me, personally, I could take them or leave them.

Decorators are syntactic sugar for higher ordered functions. They fundamentally have the same capability, just with better ergonomics.

    @GET("/users/{id}")
    function loadUser(id: int): Promise<User> {}

    @PUT("/users/{id}")
    function updateUser(id: int, user: User): Promise<User> {}

For mature projects with experienced, cohesive teams, that’s a good thing. You want a DSL that blends right in with your fully capable base language.

But yeah, just like with any powerful feature, people can get excited and carried away.

Yes, decorators are not evil by themselves, but they allow people to make poor choices easier. Having to debug decorators, fiddling with order of execution + scope binding/closures when setting multiple decorators, can (not sure!) become a nightmare; depending on the code base. Or we just go straight to the hibernate spaghetti. Imagining having to use three decorators with the same name, but different functions, makes me not to want to work with this.

Having worked with (old) Java EE and Jakarta code bases, I've seen decorators being abused in 300 ways and breaking ABI in 600 ways, so let's hope we stay sane this time.

Namely, I have an Nx monorepo full of standard TypeScript code, but that code works with a many things: Node, Electron, frontend apps with Angular or Svelte or whatever, etc.

I want to use Deno for some new stuff, but Deno couldn't import any of that code without modifying that code so it no longer worked with all the non-Deno stuff.

For a quick test, I made a new default Nx monorepo and a regular TS library and a Deno library and a Deno app.

I changed all imports to use '.ts', and added this to the tsconfig.json:

    "moduleResolution": "bundler",
    "allowImportingTsExtensions": true,

Haven't tested anything else yet, so I am not sure what, if any, issues those two changes above, plus including the .ts extension, might cause for other existing TypeScript projects.

Personally, I found all the `npm` integration stuff to be a bit overkill for what we were looking for, and honestly Deno's network requests while installing from npm were constantly flaking out in our CI. We ended up just disabling it via Deno's `--no-npm` flag (https://github.com/denoland/deno/issues/17916) and reverting back to a simple set of import_maps to get the node deps we needed. Works like a charm!

Feel free to reference if it's useful:

https://github.com/arktypeio/arktype

TS also lets you do what Babel is for, translate the JS to earlier versions of JS. However, that has nothing to do with TypeScript itself, if your target runtimes support all the ECMAscript features you use you don't need to transpile, you only need to remove the type annotations, none of which are code (apart from the leftovers from early days mentioned above).

So you would need to complain about ECMAscript. The decorators in this release, for example, are there because it moved to a stage 3 ECMAscript proposal last year, which means TypeScript must implement it now - because TS ECMAscript and not its own language. So they need to support all of at least stage 3 proposals of ECMAscript.

If isInteger was marked as a type guard, then you could write code like this:

  function f(s: string | number) {
    if (!Number.isInteger(s)) {
      console.log(s.substring(0, 0));
    }
  }

There's an open feature request for a new kind of "one-sided" type guards that don't cause narrowing when they return false.

Want structural/duck typing? No problem; that's the default. Define new interfaces that old classes happen to implement without having to wrap them. I always wanted that feature!

Want nominal types? No problem; just declare a field indicating the type name!

  interface Square { classRef: "http://example.com/Shapes/Square"; width: number; }
  interface Circle { classRef: "http://example.com/Shapes/Circle"; diameter: number; }
  type Shape = Circle|Square;

Since TypeScript types don't runtime checks, you can even do it on atomic types!

  type USDollars = number & { [Symbol.for("http://ns.nuke24.net/Synx/unit")]: "USD" }
  type CanadianDollars = number & { [Symbol.for("http://ns.nuke24.net/Synx/unit")]: "CAD" }
  
  const someAmount : CanadianDollars = someExpressionReturningUsDollars; // Compile error!  Try doing that in Java!  I OFTEN WISH I COULD

By comparison, JavaScript (and by extension, TypeScript) is still lacking fundamental features and the library ecosystem situation is pretty bad.

I wish there was a modern language that took all the good non-manual-memory-management things from Rust and added a GC and some immutable data structures. Error handling, enums, macros (with compile_error! / diagnostics API), traits / approach to OOP, embedded tests, doctests and the relentless determination to add examples in the docs in general... Everything in Rust feels like "oh, they got this right too", which hasn't been the case for any other typed lanuage I've used in the past 15 years (including typescript, my previous favorite; purescript; go; haskell)

Typescript types don't exist at run time, at all. So it's easy to be better when your language is merely about static analysis as it will not enforce any sort of type system during runtime. Java, Go or C++ have different constraints.

And it would speed up the TypeScript Compiler.

My bet is:

TypeScript typechecker in Rust:

https://github.com/dudykr/stc

The big problem is the gap between TS and JS. User defined typeguards are a usable work around but it would be nice to be able to use a native isMyType function.

Also would be nice to have constraints natively in types. Like string lengths or max ints.

- for functional programmers TS offers lots of flexibility and power many other languages including statically typed and pure don't

- TS functions or methods that throw don't show up in the type system (they do in Java)

I hope TS keeps getting stricter.

> 5.0 is not a disruptive release, and everything you know is still applicable. While TypeScript 5.0 includes correctness changes and some deprecations for infrequently-used options, we believe most developers will have an upgrade experience similar to previous releases.

The only other argument being “no compile step” which is a non-argument in the age of modern bundlers.

docs: https://www.typescriptlang.org/docs/handbook/2/narrowing.htm...

``` arr.filter((a: A): a is A & { kind: 'bar'} => a.kind === 'bar') ```

If you define:

``` function isKind<K extends A['kind']>(kind: K): (a: A) => a is A & { kind: K } { return (a): a is A & { kind: K } => a.kind === kind; } ```

Then you can write:

``` arr.filter(isKind('bar')) ```

and get a properly narrowed return type array

They have to follow the other current and future ECMAscript proposals and implement them though, so new features to be supported has for quite some time dependent almost entirely on the ECMAscript process. On the pure TypeScript side there was only minor tweaking and small corrections (for example, TS 4.8 brought "Improved Intersection Reduction, Union Compatibility, and Narrowing", clearly not a new feature but improvements to an existing one).

Felt a bit like the wait for a const generics in Rust (except here, it didn't take long at all)!

Not saying it's your case, but I noticed that a lot of people who hate TS like to use techniques and patterns that are usually considered bad practices, which often trigger errors in TS. Mutating an object to add a new property, mutating an array to add an element of a different type, processing apples and oranges in the same function without using generics or the correct union type, etc. Code works but TS doesn't like it and forces them to rewrite it properly and it feels like a hassle with no benefits.

I also noticed that lot of people who don't like TS think they need to type everything (every variable, every function's return... which is obviously inconvenient) instead of relying on types inference. There is usually very little to type in TS (compared to Java or C# for example). The two main things are the parameters of your named functions and your external data (i.e. the fetch responses). Almost everything else can be inferred.

I also observed that some people refuse to use VSCode (or any code editor with a good TS support). So they don't see any of the benefits while coding and think it's totally useless.

That said, I absolutely love TypeScript, even just for small personal projects. The value I get from VSCode typeahead, and being able to look up the expected fields on, for example, parameters or return values of a function is invaluable, never mind its power in refactoring.

I guess I would recommend that, if in the beginning, you feel a bit overwhelmed by TS and can't yet see its value, just give it some time. At least, that's what happened to me.

For me, I was out of the JavaScript cinematic universe for a long time (from about 2011 to 2018) and TypeScript was my entree back in. What got me deeply into it, and has kept me there, is not that it's better than JavaScript, but that, for my purposes, it's better than my at-the-time common languages: Ruby, Java, and C#. It gives me most of the linguistic flexibility that I'm used to with Ruby, while preventing me from dealing with the worst thing about it (Other People's Ruby being high on my list of terrible things). At the same time, it provides a level of "fall into the pit of success" structure around the type system that's superior to Java or C#, while not being as difficult to access as Rust can be.

(I like Rust, too! But the level of experience and skill necessary for somebody to be a "TypeScript operator" remains low, while letting those folks leverage really nice tooling built by folks like me who write TypeScript tools and libraries.)

Is there a good library for this currently?

I've been looking for one and a Maybe library. The Maybe one I use is pretty small.