> If that is your problem, why don't you just avoid importing typings for libraries?
Yes? That's exactly what people are doing when they import a dependency written in Typescript into a pure JS project.
> A whole lot of the time, especially in Javascript land you will join projects where libraries are being used, and where documentation is lacking. Your advice here is basically to not be part of those projects? Instead of developing and using tooling that will ensure that these situations no longer happen?
My claim is that Typescript does not solve the problem of joining a project with poorly written, undocumented libraries.
I'm not bashing on Typescript. If the primary way you use it is as an organizational tool to reduce cognitive load and make interfaces more explicit, then that's great. You're using Typescript as intended. And there are some scenarios where a compile-time type-checker is just obviously the right tool for the job.
You started this thread by asking how JS devs could manage 3rd-party interfaces without Typescript. I assume you genuinely want an answer to that question. The answer is that for some people on some projects, using well defined interfaces and keeping a reference page open with documentation is about as fast and about as easy as using Typescript, and that following that process doesn't increase their bug count or cognitive load to the point where they feel the need to introduce a compilation step.
> Yes? That's exactly what people are doing when they import a dependency written in Typescript into a pure JS project.
Except that in this way they also lose good typings for any other library and for their own code as well. I understand an outdated definition file can be annoying, but there can be various ways to only ignore type definitions for that specific library.
> My claim is that Typescript does not solve the problem of joining a project with poorly written, undocumented libraries.
That is a problem that no language or tool can solve.
> You started this thread by asking how JS devs could manage 3rd-party interfaces without Typescript.
No, I didn't, you're confusing me with someone else. Inertiatic asked at the beginning of this thread
"Who are these mythical people? [the developers who never make typings mistakes] Do they just magically decipher what interface an argument conforms to? What methods are accessible on a returned result from any random library they're using?"
Then the thread proceeded by 1) ignoring the first part of his question, about having to remember signatures in general, including of your own code; 2) interpreted "random" in a strictly negative way, as if it meant "any junk library" instead of "every library".
> 1) ignoring the first part of his question, about having to remember signatures in general, including of your own code; 2) interpreted "random" in a strictly negative way, as if it meant "any junk library" instead of "every library".
The answer to 1) is that remembering type signatures in general (or primarily referencing them through a separate spec sheet) turns out to be about as easy as Typescript for some projects and some people. The answer to 2) is that not "every library" is complicated enough to need extensive bindings, and that since Typescript doesn't help you with junk libraries anyway, the benefits to well-documented libraries turn out to be relatively minor.
I mean, I don't even use an IDE for development. I'm on Vim/Emacs, so the immediate documentation benefits of Typescript you describe literally just don't apply to me. And there are plenty of JS devs in the same position, where their only interaction with the type checker will be during a compile.
The short answer to how people magically know the type signature of random methods is they don't. They use documentation, or they look at source code, which is something I still regularly have to do in the projects where I use Typescript.
----
> Who are these mythical people? [the developers who never make typings mistakes]
In general, typings mistakes aren't a major source of bugs in most of my projects. I only observe them to be a major source of bugs in large orgs where lots of teams are coordinating on large interfaces. And that's not because I'm a genius programmer or have a magic power, there are normal programmers who will find themselves in that situation.
> Do they just magically decipher what interface an argument conforms to?
No, I look at the documentation. In general, I also spend a lot of time on interface design so my interfaces are small enough and consistent enough that I can hold the entire API in my head without much cognitive load and without needing to check documentation very often.
> What methods are accessible on a returned result from any random library they're using?"
I look at the documentation, or the source code if I don't trust the documentation.
You are always going to be able to make the argument that I just don't understand how much time I could be saving. I don't know how to prove to you that this isn't a massive drop in productivity for me, in the same way that I don't know how to prove to you that it's not a massive drop in productivity for me to write DOM manipulation code in Vim instead of Webstorm with tab-completion. All I can say is, I use both JS and Typescript on an almost daily basis, and I pay attention to the cognitive loads, bugs, and time-sinks I have in each environment. The JS environments aren't any slower to program in.
Yes? That's exactly what people are doing when they import a dependency written in Typescript into a pure JS project.
> A whole lot of the time, especially in Javascript land you will join projects where libraries are being used, and where documentation is lacking. Your advice here is basically to not be part of those projects? Instead of developing and using tooling that will ensure that these situations no longer happen?
My claim is that Typescript does not solve the problem of joining a project with poorly written, undocumented libraries.
I'm not bashing on Typescript. If the primary way you use it is as an organizational tool to reduce cognitive load and make interfaces more explicit, then that's great. You're using Typescript as intended. And there are some scenarios where a compile-time type-checker is just obviously the right tool for the job.
You started this thread by asking how JS devs could manage 3rd-party interfaces without Typescript. I assume you genuinely want an answer to that question. The answer is that for some people on some projects, using well defined interfaces and keeping a reference page open with documentation is about as fast and about as easy as using Typescript, and that following that process doesn't increase their bug count or cognitive load to the point where they feel the need to introduce a compilation step.