Live data from Hacker News

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

chiragswadia.medium.com

311–320 of 400 posts

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

#311
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…

"horrifying" is horribly melodramatic. perhaps sigh-worthy, but let's stop short of sensationalism.

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

#312
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…

This comment and many others in this thread seem to be missing something. I see a lot of anger here or blame on the author for deliberately choosing to not use types, but I think the author actually does a very admirable job explaining what's going on in their head: "... concepts like Generics felt very hard to understand ... every piece of code is strongly typed and overwhelming. Even simple code like below scared m…

Around the world millions of people learn Java as their first programming language. It is not hard to learn how to use types or generics.

What appears to be difficult is to go from an untyped language to a statically typed one. Which is why everybody should start with a statically typed language so that the psychological barrier never develops.

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

#313
Came from a statically typed background when I landed with JavaScript and - absolutely loved - the fact that it wasn't. I've been using TypeScript for the better part of four years for my day job, but I'll still use plain old JavaScript when the situation allows for it. TypeScript has become a religion, and I've seen folks screaming in Github issues because a 14 line package didn't export types.

TypeScript has its place and it's nice points. It's got downsides too. Just as using plain JavaScript does. Stop bemoaning people who don't use TypeScript. Stop lauding people who choose it as the default "because types." Right tool for the right job, and all that.

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

#314
post #122

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

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 seems to be an issue with bad typings - ideally `JSON.parse()` would return `unknown` and then it wouldn't lie to you, but that would probably break a lot of people's code.

EDIT: https://github.com/microsoft/TypeScript/issues/26188

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

#315
post #122

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

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…

I've always told folks that no technology will save you from your own developers.

A good application can be written in any technology, just like a bad application can be written in any technology.

Certain technologies will try to guide you to a better place, but it's up to developers to take advantage of it. Or to do crazy stuff like the above. . .

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

#316
post #278
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…

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

The pain point was always tedium, not difficulty. At least that's how it was sold. We haven't seen a new major dynamic language since type inference went mainstream (and existing dynamic languages are putting a lot of effort into enabling static typing), and I don't think that's coincidence.

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

#317
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…

What C has barely counts as typing, frankly. No generics, no polymorphism at all, no sum types, even basic wrapper types are painful...

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

#318

Earlier quoted context omitted.

I think the skepticism of new shiny things is healthy. Of the set of things that exist, most things are worse than the things one already uses/prefers. Most new things solve a specific problem that may not overlap with the problems one is trying to solve. With software development, a huge part of the puzzle is tooling (as the article points out), so even if typescript is obviously superior as a language, the tooling…

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

I built websites and wrote JavaScript for a long time before discovering generics by returning to school and being forced to build data structures from scratch in java. Other than that, there's no way I'd have ever come across them. I was just turned down from a senior position because someone had more years of React experience, so we're not exactly in the most sophisticated hierarchy here. Seniority should probably not depend on your exposure to technical language mechanics, especially those that weren't related to your area of expertise.

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

#319

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.

Strong typing can be both needlessly verbose and useful, or the total opposite. My experience with java compared to Typescript, is that the tools largely compensate for Java's verbosity, while that is less true of TS or JS. For example, generating strongly typed method definitions from field declarations.

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

#320
post #156

Earlier quoted context omitted.

Java would absolutely stop you from returning a JSON object when you're supposed to return a Thing. You could cast it but you'd still get a ClassCastException. Now I haven't written JS or TS, so maybe I'm not understanding what you're saying?

Just like Generics in Java, Typescript only exists at compile time. Talking about what Typescript doesn't do at runtime is moot.

Typescript permits you to write code that does implicit unsafe casts at runtime. Type-safe languages don't. Java Generics don't let you implicitly do unsafe casts[1]; erased generics mean the unsafe cast wouldn't necessarily fail visibly at runtime (though there are warnings and linters to alert you to that, and techniques to work around it), but it would enforce that it was explicit in the code (and you would then know to add extra test coverage etc.).

[1] You can implicitly do unsafe casts using arrays, but arrays aren't really using generics, they're a special-case builtin.

Post reply on HN