Live data from Hacker News

How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan

chiragswadia.medium.com

1–10 of 400 posts

Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan

#2
It's probably worth taking a step back and interrogating why the actual "Why was I Anti-TypeScript?" a little bit more and use it as an opportunity for broader self development.

The author didn't use and understand something, and rather than trying to they instead just defaulted to rejection. It's midly disapointing seeing this in people who label themselves as "Senior".

Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan

#4
For me, I can handle the lack of static typing when I'm doing small scripts, like if it's going to be 100 lines or so of Python (my go-to language if I need to test some math out in a sandbox or do some file manipulation on my system). I might actually be a little faster in writing those scripts because of the lack of typing.

Once it starts getting any bigger than that, though, static typing really catches and points out a lot of problems before I even launch the program, that I'd otherwise be spending time debugging and looking for anyway, most likely.

I also think static typing has the benefit of enforced self-documentation a bit, so other developers know just by checking the type what sort of data they should expect to see in there, and not trying to give it garbage to begin with. Granted good variable naming and proper documentation would alleviate that, but that's never been fully consistent at any organization I've ever worked for.

And considering I mostly work with relational SQL databases, there's no escaping typing on the database end for that, so I might as well have models that map to the typing of what's in the database so I don't have to keep checking the database tables to make sure I'm giving it good data.

Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan

#5

It's probably worth taking a step back and interrogating why the actual "Why was I Anti-TypeScript?" a little bit more and use it as an opportunity for broader self development. The author didn't use and understand something, and rather than trying to they instead just defaulted to rejection. It's midly disapointing seeing this in people who label themselves as "Senior".

Agreed, though at least there's one less developer writing about the "TypeScript Tax".

Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan

#6
I think a large part of the support for Typescript comes from being able to create good tools for the language.

But, I still have an aversion to front-end development itself, because it just feels too _involved_. You have to set up so much, and it has become a lot more difficult since you need to install webpack, postcss, and many other plugins just to do a hello world app.

It's still bearable if you have to do all of that, and you _understand_ what is going on, but most of the time, especially when it comes to front-end, I do things "because that's how it's done".

This makes me feel very insecure about my code.

Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan

#8

For me, I can handle the lack of static typing when I'm doing small scripts, like if it's going to be 100 lines or so of Python (my go-to language if I need to test some math out in a sandbox or do some file manipulation on my system). I might actually be a little faster in writing those scripts because of the lack of typing. Once it starts getting any bigger than that, though, static typing really catches and points…

Naming is incredibly hard, though. And refactoring is hard.

It's a pain in the neck when something starts out as bla_list or whatever and you discover that after half a decade of changes bla_list isn't actually a list anymore, it's a dictionary, and that it doesn't only hold Bla these days, it can also contain Foo or Bar. This type of stuff is immediately obvious with modern static typing.

Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan

#9
Don't want to oversimplify since the article has some useful insights, but overall it reads like a typical transition from thinking static typing is a burden to realizing type safety can be incredibly useful.

I distinctly remember that in college I believed the history of programming languages is purely evolutionary in the sense that newer languages are objectively better than older ones. As in - people wrote assembly until C came along and gave them if clauses and for loops and then came Java where you didn't need to manually manage memory anymore and could use classes and then with Python you didn't even need to specify types anymore!

I.e. the newest language with the most everything is the best!

Nowadays it feels like I'm replaying that in reverse - doing less and less OOP, loving statically typed languages, wanting to learn some Rust etc.

Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan

#10
post #8

For me, I can handle the lack of static typing when I'm doing small scripts, like if it's going to be 100 lines or so of Python (my go-to language if I need to test some math out in a sandbox or do some file manipulation on my system). I might actually be a little faster in writing those scripts because of the lack of typing. Once it starts getting any bigger than that, though, static typing really catches and points…

Naming is incredibly hard, though. And refactoring is hard. It's a pain in the neck when something starts out as bla_list or whatever and you discover that after half a decade of changes bla_list isn't actually a list anymore, it's a dictionary, and that it doesn't only hold Bla these days, it can also contain Foo or Bar. This type of stuff is immediately obvious with modern static typing.

I agree, naming can be incredibly hard. I periodically spend a long time trying to decide the best name for variables, and at times whatever I come up with isn't satisfactory to me even then (and I usually try to explain it better in a comment at its declaration).

I don't always change the names if their use drifts a bit either because I know the other developers might be used to the code where it's named something else and it might confuse them, and/or I have to rename it in a bunch of places that might make a merge particularly messy, especially if I'm working in the same place that I think another dev might be working on at the same time (it's happened more often than you'd expect actually, I've had to do some particularly gnarly merges at times).

Post reply on HN