My issue is the simplistic notion among TypeScript devotees that TypeScript makes their code "safe" - often because they haven't been exposed to anything better than Java or C#.
Any remaining explicit or implicit any are punching holes into their safety net.
Even if all explicit or implicit any have been eliminated they are still dealing with the equivalent of a leaky barrel in terms of type safety (A Note on Soundness: "TypeScript’s type system allows certain operations that can’t be known at compile-time to be safe.").
Anybody who thinks that TypeScript "has their back" is living an illusion (and needs to try Rust for comparison).
Anybody who is actually serious about "type safety" would dismiss TypeScript out of hand and move to something like ReScript:
Has no pitfalls, aka the type system is "sound" (the types will always be correct). E.g. If a type isn't marked as nullable, its value will never lie and let through some undefined value silently. ReScript code has no null/undefined errors.
But there is a cost - JavaScript interop with something like ReScript is a lot more work.
But if interop is the primary concern, why did TypeScript introduce its own non-compatible syntax extensions? The limited value that TypeScript can actually offer can be easily derived from type annotations in comments (a la JSDoc TS - Reference) for occasional static analysis, leaving the (no-build-step-required) ECMAScript syntax intact.
I could see how the introduction of typing would feel more like C# OOP than Javascript OOP. But make no mistake, Javascript is very much OOP and Typescript is not like C#.
Javascript is very much OOP and Typescript is not like C#.
From the horses mouth: TypeScript began its life as an attempt to bring traditional object-oriented types to JavaScript so that the programmers at Microsoft could bring traditional object-oriented programs to the web.
Java and C# implement (traditional) "class-based object-orientation" - class membership is static for the lifetime of the class instance (object). In JavaScript classes are a mere "template for creating objects", i.e. during its lifetime an individual object's spec can be changed to align with completely different classes without changing its identity.
In situations where a function is dealing with a parametric type (generics) but it isn't interacting with the actual type value it's sometimes useful to use unknown as a type value.
I read a paper [0] that analyzed how much bugs TypeScript really found and it stated something about ~15%, which isn't that much when take the struggles people have while actually using TS in their daily work.
Would be interesting to do these tests with ReScript.
Sorry QA perspective, I don't really care that it is a struggle, I'll take 15%. Again how I feel about Typescript suggests I don't like it either, that doesn't mean I want javascript instead.
I think web developers brought this on themselves. Type systems are showing to be valuable in reducing bugs and the hatred for working with types means the winning system is the one that straddles both worlds so it can claim you can gradually add types.
Sorry QA perspective, I don't really care that it is a struggle, I'll take 15%.
That "struggle" does diminish "return on investment". And opportunity cost means that effort invested in the struggle may be more effectively spent elsewhere.
Then there is the risk of adopting a technology that could be "end-of-lifed" at the drop of a hat. Microsoft and Google regularly stop supporting their technologies. Flutter is the only thing keeping Dart on life-support - so while the TypeScript user-community seems large enough it isn't clear that there is enough will, enthusiasm and critical mass to continue the product if Microsoft bows out.
Then there is the issue that while there may be a sufficient body of developers singing the praises of TypeScript in terms of "Developer Experience" only very few people seem to be evaluating the quality, volume, and performance of the code generated by the compiler even though they directly affect the non functional aspects of the end product - which can enhance or diminish the end product's core functionality.
Using type-aware tools doesn't replace learning about type-driven development (classes are no substitute for types) which typically requires working with something like OCaml or Haskell. Once you've been through that ringer even your JavaScript should be better (though type annotations and static analysis should be helpful).
My first post seemed to disregard tho concept of deminishing returns. I do think their is a limit but that isn't what I'm seeing with Typescript. My initial return is surely beyond reasonable, but that doesn't the end result isn't.
Many would probably consider the return on functional languages to have a demished return, especially now that so much has been brought into our more frequented languages. I straddle that fence as I have yet to dive deep into one.
But if we had a company push to switch to Haskell with a few developer buy-in, I would not be complaining about the struggle it puts me in to learn those languages.
Many would probably consider the return on functional languages to have a diminished return, especially now that so much has been brought into our more frequented languages.
Again that is another one of those fallacies - functional programming isn't about the presence of features but sometimes the absence of features and more to the point an adjustment in thinking.
While OO is supposed to be about class, responsibility and collaborator functional programming is about solving problems through data transformation.
From that perspective learning a new paradigm in a multi-paradigm setting is problematic because of the familiarity trap - you will always tend towards familiar patterns of thinking unless the constraints of a single paradigm force you to change your thinking. This is most dramatically reflected in the Scala community - teams using Scala as "a better Java" who have no hope of understanding/maintaining code written by the "I'd rather be working in Haskell" teams.
I found the easiest way to learn functional programming was through something like the Erlang MOOC (simply because you didn't have to to worry about types, type classes, laziness etc.) and later the OCaml MOOC for statically typed functional programming. (In the absence of those Learn Functional Programming with Elixir might be worth it).
But if we had a company push to switch to Haskell with a few developer buy-in, I would not be complaining about the struggle it puts me in to learn those languages.
That's not how it works from what I've seen. Typically the leadership of an organization is already convinced that a particular language is their "secret weapon" and then they hire people already competent with it or who show enough promise to be successfully trained in it.
Unfortunately this familiarity trap is the driving force around user interface design. Due to familiarity we got C, C++, Java, C#, ORM, Typescript.
And while typically the language is chosen early on and the company forms around it, the context here is with Typescript and this very much can come through as a push onto the majority of existing devs (hiring to Typescript for replacement of those who choose to leave). My example of Haskell was not realistic but used as it is my parallel to what javascript devs would be going through.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
My issue is the simplistic notion among TypeScript devotees that TypeScript makes their code "safe" - often because they haven't been exposed to anything better than Java or C#.
anyare punching holes into their safety net.anyhave been eliminated they are still dealing with the equivalent of a leaky barrel in terms of type safety (A Note on Soundness: "TypeScript’s type system allows certain operations that can’t be known at compile-time to be safe.").Anybody who thinks that TypeScript "has their back" is living an illusion (and needs to try Rust for comparison).
Anybody who is actually serious about "type safety" would dismiss TypeScript out of hand and move to something like ReScript:
But there is a cost - JavaScript interop with something like ReScript is a lot more work.
But if interop is the primary concern, why did TypeScript introduce its own non-compatible syntax extensions? The limited value that TypeScript can actually offer can be easily derived from type annotations in comments (a la JSDoc TS - Reference) for occasional static analysis, leaving the (no-build-step-required) ECMAScript syntax intact.
The trouble with TypeScript:
FYI: there is actually an article on dev.to: The Trouble with TypeScript
I haven't used Typescript enough, I can't even articulate what is wrong with Typescript, and it has nothing to due with it not being sound.
At one point I was converting a type to any then to the type I wanted and I haven't dived in to what was wrong with my understanding.
To me, it's mostly that TS makes JS look like C# and I was quite happy with how JS looked like before.
TS codebases are too OOP heavy for my taste.
I could see how the introduction of typing would feel more like C# OOP than Javascript OOP. But make no mistake, Javascript is very much OOP and Typescript is not like C#.
Could be.
But I really think JS OOP is the right way and chipping away from it goes in the wrong direction.
From the horses mouth: TypeScript began its life as an attempt to bring traditional object-oriented types to JavaScript so that the programmers at Microsoft could bring traditional object-oriented programs to the web.
Java and C# implement (traditional) "class-based object-orientation" - class membership is static for the lifetime of the class instance (object). In JavaScript classes are a mere "template for creating objects", i.e. during its lifetime an individual object's spec can be changed to align with completely different classes without changing its identity.
JavaScript's "prototype-based dynamic object-oriented programming" is based on Self. I tend to think of JavaScript as Function-Oriented (Yes, JavaScript is a Lisp).
In situations where a function is dealing with a parametric type (generics) but it isn't interacting with the actual type value it's sometimes useful to use unknown as a type value.
Furthermore you typically narrow types with type assertions, user-defined type guards or assertion functions.
Rust
unsafeis analog to TypeScriptany🤷♀️ doc.rust-lang.org/book/ch19-01-uns...(But I do not know or claim that those 2 type systems are equivalent)
My opinion too.
I read a paper [0] that analyzed how much bugs TypeScript really found and it stated something about ~15%, which isn't that much when take the struggles people have while actually using TS in their daily work.
Would be interesting to do these tests with ReScript.
[0] earlbarr.com/publications/typestud...
Sorry QA perspective, I don't really care that it is a struggle, I'll take 15%. Again how I feel about Typescript suggests I don't like it either, that doesn't mean I want javascript instead.
I think web developers brought this on themselves. Type systems are showing to be valuable in reducing bugs and the hatred for working with types means the winning system is the one that straddles both worlds so it can claim you can gradually add types.
I'm not saying static typing is bad. ReScript seems like a step in the right direction.
That "struggle" does diminish "return on investment". And opportunity cost means that effort invested in the struggle may be more effectively spent elsewhere.
Then there is the risk of adopting a technology that could be "end-of-lifed" at the drop of a hat. Microsoft and Google regularly stop supporting their technologies. Flutter is the only thing keeping Dart on life-support - so while the TypeScript user-community seems large enough it isn't clear that there is enough will, enthusiasm and critical mass to continue the product if Microsoft bows out.
Then there is the issue that while there may be a sufficient body of developers singing the praises of TypeScript in terms of "Developer Experience" only very few people seem to be evaluating the quality, volume, and performance of the code generated by the compiler even though they directly affect the non functional aspects of the end product - which can enhance or diminish the end product's core functionality.
Using type-aware tools doesn't replace learning about type-driven development (classes are no substitute for types) which typically requires working with something like OCaml or Haskell. Once you've been through that ringer even your JavaScript should be better (though type annotations and static analysis should be helpful).
Very good points.
Thank you!
My first post seemed to disregard tho concept of deminishing returns. I do think their is a limit but that isn't what I'm seeing with Typescript. My initial return is surely beyond reasonable, but that doesn't the end result isn't.
Many would probably consider the return on functional languages to have a demished return, especially now that so much has been brought into our more frequented languages. I straddle that fence as I have yet to dive deep into one.
But if we had a company push to switch to Haskell with a few developer buy-in, I would not be complaining about the struggle it puts me in to learn those languages.
Again that is another one of those fallacies - functional programming isn't about the presence of features but sometimes the absence of features and more to the point an adjustment in thinking.
While OO is supposed to be about class, responsibility and collaborator functional programming is about solving problems through data transformation.
From that perspective learning a new paradigm in a multi-paradigm setting is problematic because of the familiarity trap - you will always tend towards familiar patterns of thinking unless the constraints of a single paradigm force you to change your thinking. This is most dramatically reflected in the Scala community - teams using Scala as "a better Java" who have no hope of understanding/maintaining code written by the "I'd rather be working in Haskell" teams.
I found the easiest way to learn functional programming was through something like the Erlang MOOC (simply because you didn't have to to worry about types, type classes, laziness etc.) and later the OCaml MOOC for statically typed functional programming. (In the absence of those Learn Functional Programming with Elixir might be worth it).
That's not how it works from what I've seen. Typically the leadership of an organization is already convinced that a particular language is their "secret weapon" and then they hire people already competent with it or who show enough promise to be successfully trained in it.
Unfortunately this familiarity trap is the driving force around user interface design. Due to familiarity we got C, C++, Java, C#, ORM, Typescript.
And while typically the language is chosen early on and the company forms around it, the context here is with Typescript and this very much can come through as a push onto the majority of existing devs (hiring to Typescript for replacement of those who choose to leave). My example of Haskell was not realistic but used as it is my parallel to what javascript devs would be going through.