Live data from Hacker News

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

chiragswadia.medium.com

341–350 of 400 posts

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

#341
post #174

> I always felt that adding types to the functions/variables and satisfying the TypeScript compiler is an over-engineering and not providing any meaningful benefits. I honestly find this attitude horrifying. I'm glad the author was able to move on from this, but it is utterly pervasive in some parts of our industry. As far as "engineering" goes, specifying your types is about as low-hanging, basic a step as you can t…

If a majority of software developers had your attitude towards static types all dynamic typed languages (maybe except for JS) would have died out by now.

> If this is "over-engineering" then I think that says a lot about how much thought, design and engineering goes into some of these code bases.

Does that mean no thought and design went into all the huge protects like Instagram, Netflix and Whatsapp (that use dynamically typed languages)? Design and engineering is much more then just adding types. Clean design patterns, good code, tests and docs are pretty important too. In fact they are much more important then just static types.

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

#342
post #301
post #174

> I always felt that adding types to the functions/variables and satisfying the TypeScript compiler is an over-engineering and not providing any meaningful benefits. I honestly find this attitude horrifying. I'm glad the author was able to move on from this, but it is utterly pervasive in some parts of our industry. As far as "engineering" goes, specifying your types is about as low-hanging, basic a step as you can t…

Types make little sense to me. I guess I'm not welcome in your world.

Types do make sense to me, but they didn't always. You're certainly welcome in my world. You're also welcome to reach out if you want to gab and learn a little about how learning static types has improved my engineering life and skills. Easy to find contact from my profile.

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

#343

Earlier quoted context omitted.

Sure, like all systems, there are overhead costs involved. But with something like a typed system, the overhead costs are minimal compared to the benefits you reap from them. One of the projects I worked on during my transition to typescript was to convert an existing project into it. Sure there was a lot of head banging against walls at some point to get the types to work out, but during that process I finally reall…

You are either going to catch the bugs in the type checker or you are going to have to write unit tests to catch them. For me, typed python saves me a bunch of time.

Typed python takes ages to validate, and Python is much slower to run than Node.js, even with hacks like uvloop.

I've barked up that tree so many times, I don't think I'll ever go back to Python for that stuff in the future.

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

#344
post #174

> I always felt that adding types to the functions/variables and satisfying the TypeScript compiler is an over-engineering and not providing any meaningful benefits. I honestly find this attitude horrifying. I'm glad the author was able to move on from this, but it is utterly pervasive in some parts of our industry. As far as "engineering" goes, specifying your types is about as low-hanging, basic a step as you can t…

Interesting characterizing engineering as honestly, horrifying, low-hanging and regarding one approach to typing as translatable to all practices and the underlying assumption it conveys a guarantee of reliability. I don't find any of those things to be true (in isolation or together). Of course I only know so much so there's that.

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

#345

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

I can't speak for the author, but I can speak from a similar path. Speaking for myself, I was self taught, and to even have a toehold in any kind of career I had to learn to prioritize advancement. Not having an educational or theoretical background, that meant evaluating "what seems most effective right now". I was late to adopt TDD, late to static types, late to FP, late to a zillion things... because I was prioritizing not being sent back to broke/poverty life. Once I had enough air to breathe I realized all of these things help serve me staying out of that misery, but the urgency of learning in the field doesn't always give room for that analysis.

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

#346
post #212

Earlier quoted context omitted.

As a "senior" I'm still not sold. Running across bugs in the type checking that blocked us for a while (trying to avoid Broken Windows to boot) and the fact our development times skyrocketed (including on personal projects) or that the answer to poor tooling was "just use VSCode" is not something that really screams "developer friendly".

Sure, like all systems, there are overhead costs involved. But with something like a typed system, the overhead costs are minimal compared to the benefits you reap from them. One of the projects I worked on during my transition to typescript was to convert an existing project into it. Sure there was a lot of head banging against walls at some point to get the types to work out, but during that process I finally reall…

The problem is, Javascript was never meant to be typed. It was never meant for what we use it for, even. When you start adding guard-rails to a language that already has guard-rails, what are you left with?

We spent more time screwing around with our Typescript types, getting the compiler to be happy, working around bugs with type assertions, etc. than we did focusing on the app logic at some points.

This kind of stuff, to compare, never really happens with C++. The type system is simple enough (compared to TS) that you can pretty confidently fix type errors quickly. I don't like Rust, but I know that the same occurs with Rust's type errors, too. Why is TS so difficult?

Because Microsoft created a type system that is so complex it can represent (almost) any type in a dynamically typed language. It's impressive, but not at all practical.

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

#347

Earlier quoted context omitted.

I'm in neither camps (I don't have anything against types in places but I also don't try to put them everywhere). Could you explain how TypeScripts types would be more/less verbose than the types from Java? At a glance, TypeScript looks a bit more flexible, but mostly the same. Then Java is a verbose language in general (forced directory structure, one-class-per-file and yadda yadda) but that's besides the point as y…

This BS made me want to tear my hair out: VerboseTypeName foo = new VerboseTypeName();

The reading or the writing part? The reading is easier with explicit types. The writing is a non issue considering tooling auto completes the second instance almost always. modifying later can be cumbersome but the tooling makes it somewhat easier too.

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

#348
post #167

Earlier quoted context omitted.

Being skeptical shouldn't mean being ignorant. Being skeptical should mean Trying to understand the pros and cons and believing it's not worth it.

Or alternatively waiting it out a bit until it's more obvious what the pros and cons are (because others have tried it out in depth and shared their experience). Still a far cry from actively dismissing it.

Also more efficient. There's an endless, constant supply of new things not yet worth fully exploring.

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

#349

Earlier quoted context omitted.

That’s a problem with your codebase, not with TS.

That's the crux of this entire debate. The benefit of a type system is that it provides an organizational framework for code bases that need it (i.e. multi year projects involving a rotating set of developers). That's the only argument for a type system that I agree with (I don't believe it reduces bugs or anything like that, and from what I've seen there are zero studies that conclude such nonsense... this is a 40+…

> If you so much as have a single @ts-ignore or "any" in your code base, then all bets are off on correct behavior.

I've been writing a ton of TS since 2016 and in most of those projects we've had liberal use of 'any' or even incorrect types (!). It's still far better than vanilla JS. The argument that "it doesn't work all the time therefore it's worse" makes no sense to me.

Ultimately the issues you're talking about make logical sense academically, but nobody has ever raised them as problems in the real world that I've ever encountered.

Full typing makes my job easy, but a little bit of typing is still better (in most cases) than no typing at all. There is an argument to be made about simplicity for small codebases, but those aren't the ones I'm talking about.

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

#350
post #307
post #302

Earlier quoted context omitted.

> This is the key advantage of dynamic types. You can make a computer do useful things without having to invest the large effort required to learn how static types work. That's one key advantage of dynamic types, but it's not the only one. Sophisticated dynamic type systems like Julia's are difficult to model statically. Some idioms would require dependent types if they're even possible at all.

Yes, there's historically been cases for dynamic typing that went beyond "writing type annotations is hard", although as time has progressed, computers have gotten faster, and compilers have gotten better, the scope has gotten smaller and smaller. (I think a language in Python's niche that was created today would have a simple type system with extensive inference, just because someone developing such a language today…

> I think a language in Python's niche that was created today would have a simple type system with extensive inference

How do you think a “simple type system”, suitable for a Python-like language, would look?

The type systems that have been developed for Python itself, for example MyPy, are far from simple.

Post reply on HN