Just addressing the very first point as this is no different to any other strongly-typed language. When you have to deal with external sources and boundaries in any language, you don't have type safety to support you. You must always sanitise your external data. The point of TS and any strongly-typed language is that once you've validated your incoming data at runtime, you can be pretty confident that your data types in your own code are correct. If you feel like typescript doesn't give you more confidence in your own code then isn't that more of a statement about your confidence in your own ability to write clean code?
I got to the second point about messiness where you trawled and found 2 very specific examples of typescript being awkward (which could also probably have been solved in cleaner ways than that!). I can't say I've ever had to write anything like that in the last 4 years. And when I have had to "hack" typescript, it was usually because I didn't understand what I was doing at the time. If anything, when I have to work with vanilla js now I find it much harder to follow because I don't have any way of knowing what argument types are or what a function's return type is.
A lot of this post feels like classic stubborn anti-typescript attitude that I have fought against for years, and probably the same attitude I had myself at one point.
I'm firmly Team TypeScript and Team Static Typing, but there's a definitional problem here I want to flag.
Just addressing the very first point as this is no different to any other strongly-typed language. When you have to deal with external sources and boundaries in any language, you don't have type safety to support you. You must always sanitise your external data. The point of TS and any strongly-typed language is that once you've validated your incoming data at runtime, you can be pretty confident that your data types in your own code are correct.
TypeScript is not strongly typed. It can't be because JavaScript is weakly typed. What TypeScript brings is static typing, which is different than strong typing, though often they are casually used interchangeably, but in the comment you're responding to the distinction is important.
I don't have time to write up full examples for both but I highly recommend looking into it.
Fair point. Although I think this doesn't really affect my actual point: Whether it's a statically-typed or a strong-typed language, you must sanitise incoming data at runtime, and then you can trust your static typing from then on.
This isn't something that only typescript has to deal with.
As an aside - of course, with typescript you can at any point just go "I don't care about what type this thing is" which means you lose that trust - but this is why you should avoid any or at least follow it up immediately with some form of type guards.
A developer with M.Sc. in Computer Science. Working professionally since 2010. In my free time I make music and cook.
Also I don't and after the recent events will not have Twitter.
Location
Budapest
Education
Eötvös Loránd University (ELTE - Budapest Hungary) Computer Science M. Sc.
In my own "teachings" I say as and any should only be used with external sources: either a shitty library lacking typing definitions or not knowing how to handle generics or data not yet sanitized.
When you shortcut and in fact "lie" to the type system you are setting up a bug basically.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
Aren't you able to read the function implementation where should be some kind of documentation about which args it needs and which output it throws?
Something like:
/*
* The includes() method determines whether an array includes a certain value among its entries, returning
* true or false as appropriate.
* Parameters: searchElement (The value to search for), fromIndex (Optional; The position in this array at
* which to begin searching for searchElement).
*
*Note: When comparing strings and characters, includes() is case-sensitive.
*
* Return value: Boolean
*/
"Self documenting code" without typing any documentation like this is even worse than the lack of strong static typing on big projects.
I'd argue that this adds extra maintenance as you have to ensure the documentation matches up to the implementation. There's no way to enforce the two to stay in sync.
At least with something like typescript you can't change the implementation without the types being updated/corrected.
This is kind of the whole point of self-documenting code regardless of typescript. With comments you have to remember and be responsible for updating the comments whenever you change any kind of implementation detail. It'd only take a quick hotfix or two developers working on different features, and the comments can so easily become outdated.
This of course is assuming that your third party javascript libraries even bother to write jsdocs for their functions. If you use a library with no jsdocs and no ts definitions, you're forced to refer back to the actual documentation, and no dev worth their salt ever actually reads the docs right? 😂
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
I can agree and disagree with some points. Reading the documentation makes your work more efficient and reliable. You can use multiple functions you entire life without even knowing they have optional params that can save you some good time, i've seen that many times hahaha
Overall this is a fascinating debate that probably doesn't have a 'right' answer but I wanted to add to this 'write docs or don't' point. Writing documentation helps me clarify that I've built what I wanted to design. Sometimes I do it first as a rubber duck exercise and I always gain something from it when I do.
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.
Just addressing the very first point as this is no different to any other strongly-typed language. When you have to deal with external sources and boundaries in any language, you don't have type safety to support you. You must always sanitise your external data. The point of TS and any strongly-typed language is that once you've validated your incoming data at runtime, you can be pretty confident that your data types in your own code are correct. If you feel like typescript doesn't give you more confidence in your own code then isn't that more of a statement about your confidence in your own ability to write clean code?
I got to the second point about messiness where you trawled and found 2 very specific examples of typescript being awkward (which could also probably have been solved in cleaner ways than that!). I can't say I've ever had to write anything like that in the last 4 years. And when I have had to "hack" typescript, it was usually because I didn't understand what I was doing at the time. If anything, when I have to work with vanilla js now I find it much harder to follow because I don't have any way of knowing what argument types are or what a function's return type is.
A lot of this post feels like classic stubborn anti-typescript attitude that I have fought against for years, and probably the same attitude I had myself at one point.
I'm firmly Team TypeScript and Team Static Typing, but there's a definitional problem here I want to flag.
TypeScript is not strongly typed. It can't be because JavaScript is weakly typed. What TypeScript brings is static typing, which is different than strong typing, though often they are casually used interchangeably, but in the comment you're responding to the distinction is important.
I don't have time to write up full examples for both but I highly recommend looking into it.
Fair point. Although I think this doesn't really affect my actual point: Whether it's a statically-typed or a strong-typed language, you must sanitise incoming data at runtime, and then you can trust your static typing from then on.
This isn't something that only typescript has to deal with.
As an aside - of course, with typescript you can at any point just go "I don't care about what type this thing is" which means you lose that trust - but this is why you should avoid
anyor at least follow it up immediately with some form of type guards.In my own "teachings" I say
asandanyshould only be used with external sources: either a shitty library lacking typing definitions or not knowing how to handle generics or data not yet sanitized.When you shortcut and in fact "lie" to the type system you are setting up a bug basically.
Aren't you able to read the function implementation where should be some kind of documentation about which args it needs and which output it throws?
Something like:
"Self documenting code" without typing any documentation like this is even worse than the lack of strong static typing on big projects.
I'd argue that this adds extra maintenance as you have to ensure the documentation matches up to the implementation. There's no way to enforce the two to stay in sync.
At least with something like typescript you can't change the implementation without the types being updated/corrected.
This is kind of the whole point of self-documenting code regardless of typescript. With comments you have to remember and be responsible for updating the comments whenever you change any kind of implementation detail. It'd only take a quick hotfix or two developers working on different features, and the comments can so easily become outdated.
This of course is assuming that your third party javascript libraries even bother to write jsdocs for their functions. If you use a library with no jsdocs and no ts definitions, you're forced to refer back to the actual documentation, and no dev worth their salt ever actually reads the docs right? 😂
I can agree and disagree with some points. Reading the documentation makes your work more efficient and reliable. You can use multiple functions you entire life without even knowing they have optional params that can save you some good time, i've seen that many times hahaha
Overall this is a fascinating debate that probably doesn't have a 'right' answer but I wanted to add to this 'write docs or don't' point. Writing documentation helps me clarify that I've built what I wanted to design. Sometimes I do it first as a rubber duck exercise and I always gain something from it when I do.