5 ms·
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 JavaS
by CSMastermind 4y ago
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.
- roberttod 4y agoI 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.
- atom_arranger 4y agoIMO 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?”
- tomxor 4y ago> especially when you're 20 function calls down a stack trying to understand what's happening. Yeah I hate code like that too, but it's not clear to me how type checking would help.
- meheleventyone 4y agoYou 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.
- domk 4y agoI 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.
- tomxor 4y ago> 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.
- fergie 4y ago> I agree the TypeScript compiler's error messages are confusing but you should have see the types of stack traces JavaScript produces. Non-transpiled js produces fairly sane and useful stack traces. Its just a shame that non-transpiled js is so rare these days.
- goodoldneon 4y agoThey 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. That said, I still love TypeScript
- serverlessmania 4y agoNothing 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..