I'm old enough to have worked on two different large enterprise applications which predated TypeScript and it was a nightmare.
Personally I've found that JavaScript lends better to a functional style of coding but there are no protections in the language to enforce this and both codebases I saw had a weird mismatched set of object oriented and functional style principals. Defined classes, prototypical inheritance, modifying the prototype chain directly, a factory pattern here, a weird "constructor" there, just figuring out the shape of the data was difficult to do.
The lack of guardrails in JavaScript also empowered people writing "clever" code which technically works but was insanely hard to parse and understand, especially when you're 20 function calls down a stack trying to understand what's happening.
I agree the TypeScript compiler's error messages are confusing but you should have see the types of stack traces JavaScript produces.
I worked many years before TS too and happened to have been working on very neat codebases back then, though I did have the luck of working with a really talented set of people.
I conceed that perhaps you are correct about this - it does force people to write less strange code. JS gives you so much freedom that if you don't keep it simple you can really hang yourself. However if you put care into your code and keep it simple, I don't think TS helps all that much.
There have also been situations where I have had to do something a little bit strange, and TypeScript made it an absolute mess. And if you do enough JS you'll know that sometimes you do need to write a function that needs to leverage dynamic typing pretty hard, even if it's quite rare.
IMO TypeScript nudges you away from bad patterns. If it’s a mess to type it, it’s probably a mess in general.
If you are in a very rare situation and think you know better then there’s “any”, although at that point you really need to think “I’m risking runtime errors and this code is confusing, is it worth it or is there another way?”
They might’ve meant the type errors, rather than runtime errors. TypeScript’s type errors can get flat out unreadable when you’re dealing with moderately complicated types. Even errors with generics can get ugly.
I think type checking helps with that both directly and indirectly.
It helps directly by making it much easier to know what type or shape everything is. Without types, all you have are variable names and tracing the code back up the stack yourself. Sometimes good naming conventions are enough. More often than not, a variable called `product` can be one of 3 different types and you have no idea why unless you go up the call stack to figure it out.
I find it also helps indirectly by making clever code harder to write. The dynamic nature of JavaScript encourages a degree of cleverness and meta-programming that makes things harder to understand. While you can do the same in TypeScript, making the complier happy makes it much harder to do so, which encourages more straightforward code.
Of course, you can write clever type definitions that are impossible to follow. Sometimes you do want to do some meta-programming without fighting the compiler. But in my experience, the path of least resistance when writing TypeScript is fairly straightforward OOP that tends to lead to clearer code.
> I find it also helps indirectly by making clever code harder to write. The dynamic nature of JavaScript encourages a degree of cleverness and meta-programming that makes things harder to understand. While you can do the same in TypeScript, making the complier happy makes it much harder to do so, which encourages more straightforward code.
Interesting.
Not having to define types makes JS feel very fluid to me when using it to jump into a problem and quickly test out ideas.
You can figure out solutions fast, and I suppose with that power comes irresponsibility for those who don't care to clear up the chaos they are able to leave behind in the fast iterations towards discovering the implementation they seek. In short - it takes discipline, and your argument it seems is that typescript enforces a certain degree of discipline... pros and cons to both.
It's not necessarily about the time it takes to type the type definitions.
static typing leads to developers trying to represent the "real" world in a bunch of categories and arbitrary boxes. Thats not necessarily a good thing because you can loose much time in bike shedding discussions like "Is a person class still a valid person class if it has no Surname" which do not provide actual value to your product.
Recommended watch: https://www.youtube.com/watch?v=YR5WdGrpoug
You don’t need to do runtime inspection to see what the structure of everything is if it’s well typed which reduces the mental burden when debugging deeply nested problems. You can also be reasonably sure that there isn’t a different call stack with an entirely different structure lurking out there which also helps with confidence in pin pointing problems.
Because you don't have to use the debugger or mentally map the code all the time to see the (actual) shape of the objects at any point in the call chain?
Nothing prevent you from writing mixed paradigms code with TS as well, you still can mix functional and OOP, factory and direct modification to prototype chain, all that and more..
Personally I've found that JavaScript lends better to a functional style of coding but there are no protections in the language to enforce this and both codebases I saw had a weird mismatched set of object oriented and functional style principals. Defined classes, prototypical inheritance, modifying the prototype chain directly, a factory pattern here, a weird "constructor" there, just figuring out the shape of the data was difficult to do.
The lack of guardrails in JavaScript also empowered people writing "clever" code which technically works but was insanely hard to parse and understand, especially when you're 20 function calls down a stack trying to understand what's happening.
I agree the TypeScript compiler's error messages are confusing but you should have see the types of stack traces JavaScript produces.