[sebazzz]

> Would code written in those TypeScript versions compile unmodified in today’s TypeScript compiler (version 5.1 at the time of writing)? Maybe, maybe not.

Definitely not. Typescript upgrades are nearly always breaking in some way. But the fun really starts when upgrading typings (type definitions), or when a library that used to have no typings starts including typings which are more often than not not compatible with the 3rd party typings causing a whole headache by itself.

I love the concept of Typescript but I’m glad I left it behind in favor of Blazor (laugh if you want). It allows me to focus on the customer problems in the limited time I have rather than fixing my build for the Nth time.

Also, lately the Typescript type system has become more complex and the typings itself have also grown more complex, with things like:

     export type SomeType = IPickOne<SomeOtherType,SomeProperty> | IPickExcept<SomeOtherType2,SomeProperty2>;

Utterly insane and you need to pre-compile the types in your mind or rely on auto-complete to understand them.

I get idea that some parts of the front-end ecosystem are designed to be busy work, or at least usually turn out to be. But not all of us work in a SaaS development team that can affort 30% or 40% to just play with front-end build systems. Some of us work for clients instead, and need to make the best of the time we have. And more often than not, that means excluding risk factors like large parts of the NPM ecosystem. Limiting things to some simple gulp, dart-sass and some terser to “build” the front-end.