I like typescript as it fixes a lot of JS quirks - that's good when you have to write code transpiled to JS.

However coming from languages where types are a first element of the language (c++, rust, go...), I often miss a lot of features in typescript (e.g. type conversion overload, generic specialization, etc...)

I know that by design Typescript doesn't want those features and I understand the rationale behind it. I'm just wondering if I'm the only one in that case and if someone would know a language transpiling (not compiling) to JS more appropriate to my tastes (and hence with different goals).

Any pro typescripter have any tips for how best use it in existing Node/React codebase?

This article mentions material-ui and styled-components. My experience with typescript has been cumbersome with these libraries. A lot of time is spent figuring out what ”types” to return. I find this very difficult in most cases and not fun at all.

I figure there must be something wrong in my approach or in my ts config (no explicit any).

In short. How to best handle styled-components/material-ui/other library in ts environment? Or is typescript just to much overhead in these usecases?

Does anybody here know where to go to have conversations with the TypeScript team about adding browser features to better support TypeScript?

A lot was happening back in 2018. A Googler put together a proposal to add ignorable "pluggable" type annotations to JavaScript, which would allow browsers to run TypeScript directly without transpilation (and without type checking). https://github.com/samuelgoto/proposal-pluggable-types

And a member of the TypeScript team at Microsoft put together a proposal to add enums to JS. https://github.com/rbuckton/proposal-enum

Neither one of these seem to be active. What happened? What would it be like to get these landed?

The biggest thing killing me right now with TypeScript is more of a general ecosystem issue. That issue being how TypeScript interacts with the concept of "workspaces" and Yarn's Plug'N'Play system. I use TypeScript with ts-node pretty heavily. I'm also trying to use a shared source package outside the root workspace file hierarchy :/

> @ts-expect-error

I glad to see this. One of the most painful moment was when writing tests in TS. You will have to deal with countless type errors.

Although @ts-expect-error will partially solve the problem, what I have learned is don't write tests in TS - you should test it in the real runtime environment where there is no type checking.

Half of the changes are due to the language server implementing refactoring and other similar stuff.

This shows clearly why the language server protocol is such a bad design decision and so broken — every language has to implement it itself, and there are no shared features or functionality across languages.

Coming from IDEA, where the exact same refactoring functionality and features work no matter if using typescript, kotlin, Rust, C#, golang or dart, exactly identical in all ways, this has been a huge issue for myself.

Languages Servers should just expose a clean standardized AST format, representing standardized nodes, and this should in turn allow the IDE to act upon this (which would immediately be represented in changed source).

undefined

Mixing commonjs requires and imports is nice.

no wasm? they'll miss the revolution, TS could be THE wasm language, knowing Microsoft, they'll be too late..

IMO, until TypeScript gets the following features, it's not worth using:

- Native TypeScript runtime interpreter in Deno (TypeScript alternative to Node.js).

- Native TypeScript runtime interpreter in all major browsers.

- At least 20% performance improvement over plain JavaScript.

The build step has to go away because:

- Source maps are unreliable, bulky, slow and add too much complexity for some environments; many environments fail at using them correctly and this can make it difficult to debug code. Being forced to debug ugly transpiled JavaScript is unacceptable and should never happen.

- It's slow to work with. TypeScript often claims to be 'scalable' but reality is that large projects often take multiple minutes to build for every change. There are no good incremental build solutions which also do proper type checking. There is no runtime type checking.

Native browser support is also essential. The bundling step makes in infeasible to freely mix and match modules written in the two languages in a way which is debuggable.

Microsoft should look into Adobe Flash's ActionScript 3 migration from ActionScript 2 for inspiration (both based on ECMAScript spec BTW, just like JavaScript/TypeScript). I remember ActionScript 3 clearly because it was able to deliver a 40% speedup AND runtime type checking...

In spite of these huge benefits, I remember that some developers were still hesitant to switch to ActionScript 3! This new generation of developers has clearly lost its ability for critical thinking - I find the current complete lack of resistance to TS is very strange.

There are a lot more reasons to resist JS to TS migration compared to AS2 to AS3 migration.

I remember in AS2, most people were not declaring types in their code (even though there was support for compile-time type checking). Only in AS3 people started adding Type annotations to their code.