If typescript had better errors then I probably would support it more as a development language. As it stands it exists almost exclusively as overhead on most user interfaces.
Personally, I hate typescript. So much redundancy. It's not insanely awful, but just awful and unnecessary enough (except large corporate projects with significant developer churn) that it's a pet peeve of mine.
"Hey, let's just write the same thing 4 times so you know it's a string! Because quotation marks aren't clear enough! Yay!!" "I must redundantly ensure you know this number is a number! Even though you can easily convert it to one if you need to, and move on! Yay"
I'm bummed that it is becoming so common and popular in the industry.
`const foo = "bar"` makes foo a constant string "bar"
Where are you having the redundancy?
I can think of one place that causes me problems, which is typing and destructuring at the same time in function parameters. But there's no type redundancy there, the redundancy is having to write variable names twice.
I don't get where you're coming from. Yeah you can easily convert something to a number[1], so isn't it a good idea to force a dev to do that easy conversion by emitting a compile-time error if they don't? Because if they don't, and the value doesn't get coerced correctly, then the code blows up at runtime.
[1] Except when you can't and you get NaN
I dont follow. Can you provide an example of what you mean?
Object.keys returns an array of strings. Non-ennumerable properties and Symbol-keyed properties aren't included (on the off chance that's even relevant). That's it. It's not rocket science.
This article is complete nonsense. "What if there's no e-mail validator!", then write one? Or don't try and validate an e-mail? Like ?????? How do you not know what properties the object you're validating can have? Is this seriously how these devs operate? Just write some code with no idea what data is coming into it and no desire whatsoever to iron that out before continuing?
6 months with a dynamic language, if you actually bother to learn how to code, and you'll start reading and writing code in such a way that it's blatantly obvious what every type is. I cringe when I see people say stuff like "Typescript forces you to think about types!", in practice it's the complete opposite. There's a basically perfect correlation between devs I've worked with that like TS and those that have no idea what's going on with their code and constantly need to bug the other developers for help.
I was gobsmacked the first time I looked over a TS dev's shoulder and saw them trying to make changes without actually reading any of the code first. Zero idea what variable is defined where or what it holds, nah fuck that, just jump to line 148 and hover over a couple of things to try and pick up the thread from there, she'll be right.
> . I cringe when I see people say stuff like "Typescript forces you to think about types!", in practice it's the complete opposite … make changes without actually reading any of the code first. Zero idea what variable is defined where or what it holds, nah fuck that, just jump to line 148 and hover over a couple of things to try and pick up the thread from there, she'll be right.
Why should you need to do anything else than that? If TS enables better hinting, and you can just make a change without having to sit down and digest and entire codebase first, then why not enjoy taking advantage of that? How is that not desirable? Why make things more complicated for yourself than they need to be, when you can let your tools do that work for you?
This would only be true for very simple code written in a top-down manner. For library code, you dont know how what code will call the library.