You are putting words in my mouth. I do not believe that you can write perfect code or avoid bugs. Just like I do not believe there is this perfect programming language or framework out there that magically creates clean code.
> you could still argue that type checking the codebase in your head is time consuming
This again, depends on the particular history and skill-set of your team. For example, TypeScript fits very well if you are familliar with C#, while CoffeeScript fits very well to those comfortable with python/ruby, ClojureScript for those who like clojure, ESLint for those comfortable with JS ... etc
> I do not believe that you can write perfect code or avoid bugs.
I don't think anyone (including you) does. I don't think typescript pretends to be a perfect programming language that magically creates clean code either, but I think it gets us closer to that unrealistic goal.
> This again, depends on the particular history and skill-set of your team. For example, TypeScript fits very well if you are familiar with C#.
I very much disagree with this.
If you want to compare Typescript with another language, you have to remember that its typesystem is optional. So all you are left with basically Javascript. How much of the typesystem you want to use is up to you and your team.
Personally I try to let typescript infer the types as much as possible. I only explicitly annotate function arguments and foregin data.
Sometimes there are cases where the typesystem won't work. Usually it's because I want to dynamically create something instead of verbosely defining everything. If the dynamic way is easier to maintain I choose that way and may lose some type information. (often you can tell the typesystem that "this dynamic blob" results in "this explicit type" though)
I'm not very fond of C# but I enjoy Typescript. I think the reason I don't like C# is because it forces you to make classes of everything which to me adds a lot of friction.
TS may compile down to JS, but that does not make it the same language. TS done the proper idiomatic TS way is just very different from JS done the proper functional + dynamic way. How you structure your code using a dynamic, functional language should be very different from how you structure your code in a static, object oriented language. If your code structure looks more or less just the same between the two, then you are doing one of them wrong.
> you have to remember that its type system is optional
Doesn't opting out of the type system defeat the purpose of using TYPE-script in the first place?
As a “life long” web/JavaScript developer, ESLint is nowhere near comparable to Typescript. One is a language, and the other is an (overused and over configured) linter. They’re two different things.
I’m no C# developer, but the only way it is familiar to Typescript in the sense that it is a typed language.
Typescript is a superset of JavaScript, and is remarkably close. If you know JavaScript, typescript will be exceptionally similar because it’s literally the same, just with types added on top.
No, I would not say that a type system is an "extremely opinionated" linter because TypeScript is about proving correctness and safety, not enforcing style guidelines.
A linter and a type system are two extremely different things. The only thing they have in common is that they statically analyse code.
You are putting words in my mouth. I do not believe that you can write perfect code or avoid bugs. Just like I do not believe there is this perfect programming language or framework out there that magically creates clean code.
> you could still argue that type checking the codebase in your head is time consuming
This again, depends on the particular history and skill-set of your team. For example, TypeScript fits very well if you are familliar with C#, while CoffeeScript fits very well to those comfortable with python/ruby, ClojureScript for those who like clojure, ESLint for those comfortable with JS ... etc