|
|
|
|
|
|
by tekkk
2559 days ago
|
|
|
Well, as a someone who had the same initial feelings with TypeScript when it came "oh it slows me down, these types are just a waste of time", I get where you're coming from but think that you have some other issues than TypeScript with your team and project. First of I'd want to say that most of your complaints about "no runtime type validation" in the context of TypeScript/JavaScript is just how unreliable JS is as a language. You just can never be sure and even with TS you can get all the boilerplate of TS with zero benefits if you resort to using `any` anytime you feel too lazy to add difficult types. Which leads to my next point, the slowness of writing TS compared to JS. I don't know how you maintain your code bases but from my experience any time a new programmer comes in who doesn't know anything about the code, they'll be from time to time wondering, in their heads or aloud, what the hell is the type of some parameter or why something fails on some weird undefined value bug. There's just so much trial and error with JS whereas with TS I don't have to look up at the broken website to see all the errors hitting me as it's all caught with the compiler. Pretty basic static typing stuff but it all comes down to more time writing code, sure, but less time over time maintaining it. And overall the readability of your code is just night and a day with special emphasis towards young programmers or those unfamiliar with the codebase. What I think has happened is, that you've been bitten by some weird problem regarding API endpoints and incorrectly assumed your typings would hold with an external data source. That just sounds poor programming (don't you use validation libraries such as Joi?) and frankly, a problem entirely of JS itself that such anomalies would happen. If my API starts returning arrays instead of objects sure as hell I'd be angry too but that's just not how it should work. Not a problem of TypeScript, at all. About the other problems - haven't faced those myself. Most problems I've had have been with writing the correct types especially when they get complex with generics. Sometimes TSC has been annoying and also exporting types into a single typing file seemed quite laborious last time I tried. |
|
|
In OOP, passing complex instances to functions across different files is dangerous because the different files may all end up affecting the same instance's internal state and you don't know which file is responsible for what change (and it can lead to conflicting states/bugs). The absence of types in JavaScript tends to discourage this design precisely because it makes it difficult to express those kinds of complex/rigid class relationships.
JS encourages developers to keep each kind of "live" instance in a single file and only return raw data from that file. For me, restricting all instance mutations to one file is the secret to writing good OOP code which has clear separation of concerns.