Hacker News Reader

Comment by jimmychoozyx | Hacker News Reader

I agree-- in terms of it being almost exclusively overhead.

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.

View on HN

The extra typing is all worth it when I can fearlessly refactor a function or component. I've seen fear of breakage paralyze larger vanilla JS codebases.

Exactly this. I love being confident in making changes to code. Especially once a project grows and other people are working on it.

That actually makes the most sense, of any reasons for using Typescript, that I've heard. Good point.

`let foo = "bar"` makes foo a string

`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 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 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

> Hey, let's just write the same thing 4 times so you know it's a string! Because quotation marks aren't clear enough!

I dont follow. Can you provide an example of what you mean?

The entire industry has lost it's fucking mind.

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.

Yeah but - it’s nice to be able to do that. Like what you’re describing -

> . 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?

If I understand you correctly, you are saying a real programmer would always know exactly what objects are passed to a function, just by reading the code.

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.

I don't mind TS but sometimes it kinda feels like a cult. Certain personalities love to overcomplicate things for zero actual value other than they get to feel like shamans or something

Agreed, and it’s extremely difficult to have any objective TS discourse in TS communities. They are extremely dismissive of criticism, constructive or not.

TS is definitely not zero actual value. The decrease in bugs my team has seen since migrating our JS apps to strict-mode TS is remarkable. It’s been ~5 years since then and I can’t imagine going back.

I did not say TS is if no value. I said overdoing it is of no value. Perhaps I should have phrased that better.

Reply on news.ycombinator.com