[throw49sjwo1]

> And nobody uses most of it!

Everybody who does Express, React, or any other popular advanced libraries with TypeScript is using these features. Some things are simply more useful to libraries than line of business code - that's fine. The line of business code is much better thanks to it.

[leetharris]

> Everybody who does Express, React, or any other popular advanced libraries with TypeScript is using these features.

This is very true and my original post was short sighted. You could, of course, make most upstream dependencies without modern language features. However, their complex jobs get much easier with these features.

Downstream, business logic is much easier to implement without these features compared to complex, low level functionality.

[anon7000]

For sure! In a basic API endpoint, I don’t need advanced typescript features.

But if I’m writing a module that a lot of other consumers in the codebase will use, and I want to make their lives easy, I might use a lot of advanced TS features to make sure than type safety & inference works perfectly within the module. Whoever consumes it can then rely on that safety, but also the convenience. The module could have some convoluted types just to provide really clean and correct auto-complete in a certain method. But most people don’t need to worry about how that works

[nosefurhairdo]

Yeah I was confused by this point as well. Especially because many of the recent Typescript releases are just improving performance or handling more cases (without needing to learn new syntax).

[tannhaeuser]

React and Expressjs predate typescript, Expressjs considerably so.

[throw49sjwo1]

Doesn't matter, I'm talking about the type definitions - @types/react, @types/react-dom and @types/express.

[authorfly]

No, those are optional for the enduser to ever encounter.

[throw49sjwo1]

I never said it's required. The typings are really useful if you want to use these libraries "with TypeScript" as I said in my first comment... The typings are the whole point - that's where the advanced type features are used, and every user benefits - their own code can be much simpler and safer thanks to it.

[authorfly]

"Everybody who does Express, React, or any other popular advanced libraries with TypeScript is using these features. Some things are simply more useful to libraries than line of business code - that's fine. The line of business code is much better thanks to it."

I think your model of how people use modules is flawed.

I doubt most people using those modules are using typescript to mostly interact with them, because of the perceived subjective benefit you see of typing everything.

For example, I use many typescript-written modules without using typescript in the code that uses them, and am better off for it. Because I and my R&D work does not want the advanced features of typescript. We can switch to it, or a OOP server language if that is useful later.

Exposing types to me usefully in libraries to use "with Typescript" as you claim means my own code has to be typescript. In that case, to avoid compile errors and a wall of "any" types, I reasonably have to switch my own code to use Typescript classes etc, even where this is just bloat etc. Another reason I have libraries is to do things without ever interacting with them other than input props (e.g. a drag'n'drop library with JSX components). In that case, the type (JSX Component) is irrelevant to me to include, and for experienced developers, approximately 0% are going to give something other than a JSX component as an input to a drag'n'drop library, etc.

In other words - I derive benefit from them using Typescript without having to use it myself. Pushing Typescript as "necessary" because popular libraries have interfaces is exactly the kind of thing that slows down R&D and fast processes.

I have used many languages with types for many years. I understand their value. However, much of the value is code coherence, working with other people, and domain models being embedded in the code. These benefits are not always useful in small web applications.

Typing is one of those things... you love it to make your life learning code easier and for big projects, and for certainty when you are coding boring things. For other things in life, there's more to life than writing type definitions and overloading methods. You can be much more productive just using primitives in some scenarios and make research discoveries faster and with more flexibility.

What I have seen is every generation of coders, a new type-heavy language/framework becomes popular (.NET, Java, Typescript), then it becomes "uncool" because people realize how bulky and useless most of it is - especially for anything small/research-y, then it loses adoption and is replaced by another.