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…
How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan
151–160 of 400 posts
Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan
#152Earlier 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.
Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan
#153Earlier 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.)
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
#154It'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…
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
#155Earlier 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.
Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan
#156Earlier 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.
Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan
#157Earlier 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…
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
#158Earlier 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.
Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan
#159Earlier 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…
Re: How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan
#160Earlier 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.