Live data from Hacker News

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

chiragswadia.medium.com

171–180 of 400 posts

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

#171
post #122

Earlier quoted context omitted.

Ironically, as someone who has experience w/ both fast-and-loose JS and with "properly" statically typed languages, my beef with typescript is precisely that it allows people to be fast and loose, sometimes in ways that are not super obvious. For example: type Thing = { name: string, }; function getThing(): Thing { return JSON.parse('{"error": "invalid id"}') } const thing: Thing = getThing(); // lie to me! console.l…

This is an argument against strongly typed languages, not Typescript. You could do a similar thing in Java and C#. I don't know of any language that can stop someone from being a sloppy coder.

No, those languages actually enforce type checking at runtime. The libraries for parsing JS that support parsing into a custom type will blow up right there if the provided JSON cannot be parsed into the provided class, not 5 steps later when you try to use something from that class that isn't actually there.

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

#172
post #140
post #122

Earlier quoted context omitted.

Ironically, as someone who has experience w/ both fast-and-loose JS and with "properly" statically typed languages, my beef with typescript is precisely that it allows people to be fast and loose, sometimes in ways that are not super obvious. For example: type Thing = { name: string, }; function getThing(): Thing { return JSON.parse('{"error": "invalid id"}') } const thing: Thing = getThing(); // lie to me! console.l…

It's worth noting that this (good) example is unrelated to unsoundness, too -- it's related to built-in APIs using 'any'. Within Google we include a "strict" d.ts in every compilation that shadows this API (and one other) with one that instead returns "unknown". We have talked about going through the whole TS API and removing all the 'any' in this manner for this reason.

That's a great idea! What's the other built-in that you shadow?

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

#173

Earlier quoted context omitted.

As another lead/senior dev, I've found that onboarding hires that know some TS into a TS codebase is a hugely slicker process than onboarding people into a pure JS codebase, simply because the typechecker can do the overhead of having to check each call etcetera. The issues you are having sound like teething issues but as someone who's worked with TS for years I've found they aren't hugely difficult to overcome, eith…

> I mean that's a personal preference, but if you're a lead dev and you have people starting work on a codebase they have little experience with, it's a godsend because they aren't totally blind. Very much this. I pushed to move the scripting language for our game engine project dot big bang from JS to TS primarily because the typing makes the entire codebase much more discoverable and beginner friendly. Using Monaco…

I'm learning typescript on-the-fly as I migrate an existing React+express codebase to it; Curious if you'd recommend Monaco over VS Code, and if so, why?

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

#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 take. 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.

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

#176

Earlier quoted context omitted.

If "| undefined" is spreading through your code like a virus in cases where it's not actually optional, then I'd argue that the problem is upstream where the data is ingested, and the code should be enforcing "must be defined" at input validation so that you can carry a clean "Color" type everywhere else. If it's about optional parameter weirdness and TypeScript's lack of method overloading, I suspect that's inherite…

TypeScript does have method overloading same as other typed languages (except you have to do runtime checks, but that is a JavaScript limitation).

> except you have to do runtime checks, but that is a JavaScript limitation

IMO not having to do runtime checks is a big part of the value proposition of method overloading the way many languages do it. Whether or not it’s a limitation inherited from JavaScript, it’s still really klunky compared to other mainstream languages.

It’s one of the few things that I actually dislike about TypeScript, despite overall loving it.

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

#177

Earlier quoted context omitted.

Strong typing is not shiny or new and, even if you're a javascript guy, not being remotely familiar with any strongly-typed language (or generics?!) is a red flag. (edit: red flag is a bad description, because he ended up being self-reflective and looking deeper, which is just about the furthest thing from a red flag.)

Agreed. But some people have an attitude of Strongly Typed == Needlessly Verbose. Probably because most developers have only experienced Strong Typing via Java.

I definitely fell in this camp. To be fair I was fairly junior and was used to JS.

It wasn't until I started using Haskell that I saw the benefits of knowing exactly what I was working with. It also helped me be more deliberate and thoughtful as you had to define everything up front.

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

#178
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 worked on one of those code bases. The team thought fixing endpoints where the ORM was being used incorrectly and generating N+1 queries was "premature optimization."

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

#179

Still not a typescript fan here. It feels like a half-baked language because of the insistence of not having a runtime (even though some information makes it through to the underlying js...so this objection of theirs isn't total). In a usual typed language, you could extract the type of an intersection type using pattern matching. But you can't do that in typescript. Instead you get to pick the most relevant ugly hac…

It takes a lot of mental and emotional capital in the creative process to produce something that is truly wonderful. Microsoft is systemically incapable of approaching creative perfection. Very few are.

This is extremely unfair and rude. The TS language designer and lead developer is Anders Hejlsberg, who is also the chief architect of C# and Delphi. C# has been tremendously successful and, in my opinion, is truly wonderful as a general purpose language.

In the case of Typescript the team were working under very difficult constraints - the language must maintain strict compatibility with Javascript, and the output must be executable by a web browser that has never even heard of the language.

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

#180
post #172
post #140

Earlier quoted context omitted.

It's worth noting that this (good) example is unrelated to unsoundness, too -- it's related to built-in APIs using 'any'. Within Google we include a "strict" d.ts in every compilation that shadows this API (and one other) with one that instead returns "unknown". We have talked about going through the whole TS API and removing all the 'any' in this manner for this reason.

That's a great idea! What's the other built-in that you shadow?

The definition of `new Map`:

https://www.typescriptlang.org/play?#code/FDDGHsDsGcBcAJrwLz...

(I still think this is actually due to bug in TypeScript, see https://github.com/microsoft/TypeScript/issues/31990 .)

Post reply on HN