Live data from Hacker News

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

chiragswadia.medium.com

151–160 of 400 posts

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

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

You're not wrong. That's a good example of why someone might have beef with typescript. But as others have been saying, tooling enabling faster dev is one of the main reasons people use typescript. Safety comes second for most folks. And the tooling works just fine in that example.

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

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

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.

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

#153

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

> red flag is a bad description, because he ended up being self-reflective and looking deeper

No, red flag is fair since it's just a warning sign. Even if we take it as a mark on the guy, it's true that he ought to get outside the scripty bubble.

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

#154
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 particular example is close to my heart: the definition files for things like JSON.parse() were written before the "unknown" type was introduced as an alternative to "any"

And because this "any" is coming from an external definition file, it can't be caught by tsc's --noImplicitAny nor eslint's no-explicit-any

Those two rules allow us to protect us from our own code, but not external definitions/libraries. Relevant GitHub issue here — https://github.com/microsoft/TypeScript/issues/26188

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

#155

Earlier quoted context omitted.

I mean, Coffeescript was fairly widely used at its peak, and now it's all but dead. Front-end fads are fickle. At least TypeScript has Microsoft backing it so they'll likely continue to support even if the rest of the webdev world moves on to the next shiny object.

I also have fond memories of painstakingly converting hundreds of coffeescript files back to JS. There's something to be said for using the native language.

In my private projects I always write in JavaScript and provide static typing using JSDoc comments (which typescript can check). Then I run the type checker with `--noEmit`. I have yet to run into a problem with this approach.

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

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

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?

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

#157

Earlier quoted context omitted.

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

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…

1) TypeScript has local type inference, meaning that `let x = returnsComplicatedThing();` will work, where in Java it would be `Complicated> x = returnsComplicatedThing();`. (At least up until the last few years)

2) TypeScript has type aliases, meaning you can write `type MyTable = List>` and not have to repeat yourself everywhere.

3) TypeScript has anonymous unions and tuples, so instead of writing `Triple` you can just write `[number, string, Foo]`, and likewise instead of `OneOf` you can write `number | string | Foo`. These are also built in and very ergonomic, so you don't have to write a OneOf4 class whenever you want to have one of 4 things, and you don't have to write helper methods to convert between different sized OneOfs.

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

#158

Earlier quoted context omitted.

Senior probably means they've been doing JS for decades before TS was invented. They got along just fine without it for so many years, why rock the boat now? Or maybe it is more of a Senior person has a ton of work to do and not enough time to do it in so there isn't time left to learn a whole new way of writing JS. Or maybe many of the errors TS is meant to catch, the Senior developer has already learned over the de…

I cannot wait to be the type of developer who just never makes typos.

Your IDE should be catching any typos. But it's not about typos, it's about understanding the quirky nature of JS and knowing what things not to do. For instance, an inexperienced developer might try to use .sort() to sort an array of numbers. It wouldn't even occur to an experienced developer to try that since they know from vast past experience that it won't work (or, at least, won't do what the inexperience developer is thinking it might do).

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

#159

Earlier quoted context omitted.

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

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…

[deleted]

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

#160

Earlier quoted context omitted.

I mean, Coffeescript was fairly widely used at its peak, and now it's all but dead. Front-end fads are fickle. At least TypeScript has Microsoft backing it so they'll likely continue to support even if the rest of the webdev world moves on to the next shiny object.

CoffeeScript served a purpose, and was not a fad. It got deprecated by an ECMAScript that adapted most of the good parts. TypeScript brought something good for the JS ecosystem (although Flow did it too, in a different way) and it doesn't look like anything will be able to replace it at what it does anytime soon.

I am really hoping TC-39 starts considering optional static types (similar to python), using a simpler syntax then TypeScript (e.g. no enums). However I don’t have high hopes they will any time soon.
Post reply on HN