How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan • Hacker News Board

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

#281

Post by selfmodruntime » Tue, Mar 02, 2021, 10:35 PM UTC

Barrin92 wrote: post #249

danielrhodes wrote: post #183

The other benefit is refactoring. That saying which goes along the lines of: "you're going to be reading a lot more code than writing it" is very true. After your project gets to a certain size, and it need not be large, you start making smaller changes and moving code around -- having some guard rails there is a huge productivity boost. Being able to read code and know that it does what it says because you know the…

I don't really buy this argument about readability because the sort of information stored in types very quickly becomes pretty meaningless for humans. I remember working on a Haskell codebase and getting into an argument about this with a developer who was very much in the typed language camp. Then I saw a function that had like 8 parameters, some were just String, or Int, some where synonyms, and I asked him what it…

The magic is in the combination of types and proper names. What use is a variable that‘s nicely named when you don‘t know what it holds?

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

#282

Post by selfmodruntime » Tue, Mar 02, 2021, 10:37 PM UTC

seph-reed wrote: post #168

gamesbrainiac wrote: post #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 o…

I've spent the last two years writing my own framework because I hated React so damn much. It really doesn't have to be that complicated. Granted, I still use a bundler, but it's really easy to set up. I had my friend walk through it all... he seems to think it's great. I should probably release this project some day.

Why did you hate react? It‘s really one of the less complicated frameworks out there.

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

#283

Post by throwaway894345 » Tue, Mar 02, 2021, 10:47 PM UTC

mdoms wrote: 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…

I've worked with a lot of people in the Python world who just wanted to move tickets across the kanban board as fast as possible, and they'd do a quick check of the happy path and call it a ticket. They'd be praised for their output and we (rightly, I think) didn't try to trace bugs back to a developer. They would do all sorts of dynamic-typing hacks to get the immediate task at hand done with little regard for the mess that was made, and they strongly disliked static types because they made those error prone, unmaintainable hacks really difficult to express.

Let me pull that out into a block quote:

> [types] made those error prone, unmaintainable hacks really difficult to express

This is, in my mind, the most valuable feature of static types, and one that at least some dynamic typing enthusiasts can't easily get their heads around. Types are like rails that guide you to code which is maintainable. Another very valuable feature is that they serve as documentation that would otherwise never be written or quickly fall out of date in a dynamically typed language. Lastly in importance is that the compiler/type-checker precludes certain errors.

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

#284

Post by luuio » Tue, Mar 02, 2021, 10:49 PM UTC

mekoka wrote: post #278

mdoms wrote: 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…

> As far as "engineering" goes, specifying your types is about as low-hanging, basic a step as you can take. How do you come to such a conclusion when there have been many languages whose success was specifically tied to the fact that they were dynamically typed? Doesn't that indicate a pain point? > If this is "over-engineering" then I think that says a lot about how much thought, design and engineering goes into so…

> there have been many languages whose success was specifically tied to the fact that they were dynamically typed

Language success does not mean product success. A language is just one of the many things in your toolbox. There's a reason why when many products grew larger, they all are migrating to statically/strictly typed languages.

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

#285

Post by runarberg » Tue, Mar 02, 2021, 10:50 PM UTC

recursive wrote: post #270

tenaciousDaniel wrote: post #255

Earlier quoted context omitted.

Yup. I don't find myself using classes much, but some of the other new features remove the vast number of issues you tend to face. Is scoping an issue for you? Just use arrow functions! Is callback nesting an issue for you? Just use `async/await`! I love it so much.

I use classes a fair amount, but there's still some weird stuff in the language I'd take out if I could. Sparse arrays, all object keys are strings (or symbols), crazy coercion rules, the existence of `null`, weird float vs int rules.

You can use `Map` instead of object which allows keys of any type, or typecheck your objects with `Record` and let typescript warn you about any weirdness. Typescript can also warn you if you do some weird implicit coercion. You can typeguard against `null` (although I admit it is annoying, I just want to use an optional†). And if you really want to use integer types there is always `BigInt`.

---

†: I haven’t checked, but I bet there are some libraries out there that provide proper optionals using Proxy.

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

#286

Post by lhorie » Tue, Mar 02, 2021, 10:51 PM UTC

damagednoob wrote: post #241

qw3rty01 wrote: post #152

Earlier quoted context omitted.

It's actually the opposite. This would throw an exception in a strongly typed language. It would silently return the wrong thing in javascript because it's not strongly typed.

The point of the argument is catching errors at compile-time. Typescript doesn't make (and can't make) any guarantees at runtime.

In case it wasn't clear, that example compiles without error, whereas a more strict compiler would complain that a any is not a Thing, or some similar error.

The code doesn't even throw runtime errors, but you wouldn't be able to tell something is wrong unless a) a request providing the json string actually responded with the error string in the example (an edge case that is very easy to overlook during regular development) and you managed to catch the problem in tests, or b) you specifically went digging into the file that defines getThing looking for the implicit any cast that the compiler didn't tell you about or c) there's a compiler update that turns that any cast into an error

What others are saying is that Java and friends do c) (throw compilation errors when implicitly casting between incompatible types)

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

#287

Post by fendy3002 » Tue, Mar 02, 2021, 10:54 PM UTC

madeofpalk wrote: post #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".

Senior here. I was afraid if typescript will follow C# or Java's type checking. Both are too strict, verbose and inflexible.

I was afraid to introduce complex generic types because it isn't easily represented in typescript, or to change a struct from "person" to "employee" will need to map each properties individually.

Thankfully that wasn't the case.

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

#288

Post by deckard1 » Tue, Mar 02, 2021, 11:02 PM UTC

symlinkk wrote: post #182

tomca32 wrote: post #145

Earlier quoted context omitted.

The problem is that if anything can be undefined, then you don't really have a big typing advantage over regular JavaScript. It's just like being in Java land where typing adds a lot of boilerplate to the code, but you still have to do null checks everywhere.

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+ year debate we're talking about).

Structural type systems with type inference don't do that. I can't look at your code on Github and know what the code is doing. There is not enough information there. Contrast that with nominal type systems where everything I need to know about a function is right there. I don't need an IDE or external tooling to guide me. It's a true mystery how people think they are reviewing pull requests written in TypeScript and actually doing their job correctly. If you so much as have a single @ts-ignore or "any" in your code base, then all bets are off on correct behavior.

TypeScript diminishes the point of type systems by giving the developer too many escape hatches. You ever see a developer abuse the non-null assertion operator in a case where it's not at all true that the value is not null, but the developer doesn't care because they just want to make the compiler happy? Yeah. I have. Then you have to explain the purpose of the non-null assertion operator and that goes about as well as you can imagine.

If a type system isn't helping you understand your code or organize your code, then it's all rather pointless. TypeScript is incredibly complex. How many people using TypeScript can tell you something as basic as the difference between "interface" and "type"? And try to describe the difference without using sentences such as "well, originally..." and "back in 2017...".

edit: Oh, and in case anyone thinks I'm being pedantic on that last point, check out this absolute shit show:

https://stackoverflow.com/questions/37233735/interfaces-vs-t...

Keep scrolling down for ultimate depression.

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

#289

Post by ChrisRR » Tue, Mar 02, 2021, 11:04 PM UTC

mdoms wrote: 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…

As a c developer, I've always found the lack of typing to be one of the things I dislike about python.

If you're calling a function in C, a lot of the time just knowing the type and argument name is enough to call functions without resorting to documentation

In python, you have the argument name and then... what do you want? A number? Are floats or integers alright? Is it a string? And object? An enum? Are there any bounds on the input data that a data type would've instantly told me? Fine, I'll go read the documentation

Adding types gives you so much more information in so few characters

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

#290

Post by akiselev » Tue, Mar 02, 2021, 11:09 PM UTC

rovek wrote: post #219

jpgvm wrote: post #192

Earlier quoted context omitted.

JS the language isn't great but it's JS the culture that is the real problem. There is a subset of JS codebases that are good, well engineered and written by people that understand the languages faults and limitations but the list is incredibly small and even smaller still now Joyent isn't really around anymore. If there was one ecosystem I wish I never needed to touch again it would be JS but unfortunately it's beco…

> JS the language isn't great but it's JS the culture that is the real problem. This is the money quote of the thread for me. From the perspective of someone whose main language has been JS or TS for about 8 years, it's getting worse since some of the biggest names in the discipline just seem to be people with large social followings giving terrible advice. This advice is then eaten up by hoardes of bootcamp alumni w…

The fact that it's getting worse says to me that we're just returning to the human mean. For decades programming was seen as the purview of nerds and geeks so the only people who turned to it tended to genuinely like it and master their craft as much as exploit it. Now everyone and their grandma use software so programming has become one of those semi-prestigious professional career paths but without the crazy expensive barrier to entry or restrictions in supply that doctors, lawyers, etc have. Even though programming is largely problem solving and "intellectual" rather than menial physical labor, the field has become so accessible with the internet that the distribution of engineering ability is starting to look a lot more like the usual bell curve centered on "just average".

It was great while it lasted.