Live data from Hacker News

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

chiragswadia.medium.com

131–140 of 400 posts

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

#131

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…

This argument also holds for backend development. I've spent days trying to get a big Java app working with Jboss at a new place, it was more or less a rite of passage when joining the team. Also setting up some local obscure Microsoft IIS setting because reasons. These days I find frontend tooling quite delightful, Typescript for instance Just Work(tm) our the box.

I can't comment on this, since I haven't really worked with JBoss, and haven't had to touch the .net stack in ages.

The python stack is pretty okay though. You just containerize it, and ship it. Some providers will even allow you to run containers as a function/lambda.

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

#132

I was hesitantly open to TS when the hype was first ramping up. The team I was on (and I've seen this in lots of code elsewhere too) was doing stuff like this: declare let myColor: Color | undefined; Suddenly everything turned into Java with signatures cascading endlessly. I'm not blaming TS, it's more of a.. lack of faith to make the full jump? Or limitation of the underlying Javascript? This problem should be solve…

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

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

#133

Earlier quoted context omitted.

Browser support and consistency got a lot better. JavaScript was a minefield of compatibility problems. Many intentional, cough: Microsoft. Jquery was awesome because it dealt with most of that

JQuery dealt with DOM and browser stuff. Coffeescript dealt with syntactic language stuff. I can't think of a case where Coffeescript helps with the same thing JQuery does, although it may exist.

Yeah as best I can tell, Coffeescript was a thing because Ruby was very popular at the time, and some Ruby devs had to write JS but they wanted to write Ruby.

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

#134

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'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 you're pointing to TypeScripts types being less verbose than Javas.

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

#135
post #33

Earlier quoted context omitted.

Typescript is hardly "new", it's fairly widely accepted now. It might be worth thinking "why do all these people enjoy using Typescript?". or idk just say that no, its the kids that are wrong.

Typescript is not accepted. How AngularJS stuck on 1.* is the best proof, and an illustration for the problem. Pretty serious people are working in Angular community, it's immensely popular in the enterprise webapp space, so I will not take the "Ah, it's just amateurs who are stuck there." It adds to countless attempts of other transpiled *scripts to extend Javascript. They, and Coffeescript in particular, are good h…

I'd really like to hear what alternatives you have in mind for code in the JavaScript family that needs to have types. At my workplace, types are an important part of our workflow.

We've been using Flow as a type checker but are converting our code to TypeScript for the tooling, ecosystem, support, and hopefully improved performance.

TS has been running as a project for quite a while and a whole lot of folks have a stake in it. I think it's a pretty good bet.

Additionally, I was there when Angular 2 was announced, and the community had no idea what to do or when it was coming out and didn't know whether to dig their heels in and stay on 1 or what the migration path to 2 would look like. I think that's a slightly different story given the context.

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

#136

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.

This, and usually Java from 10-15 years ago before the `var` keyword and diamond operator.

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

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

The "curse" of Typescript is that it's built on Javascript, so you can tell it to lie to you all the time. This is the problem with introducing Typescript to a larger group of Javascript developers who arent all on board (because of either experience or being stubborn) - you still need to establish good habits and patterns for how to write typescript. I'm working through the very lie you're showing now because the di…

In the large this curse is true for everything. The difference between 8 u8s and an f64 is thin for all architectures I can think of.

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

#138
post #72

Earlier quoted context omitted.

About 95% of React components I see in the wild are in TypeScript. The most rapidly growing JS backend framework (Nest) is in TS. Deno, the evolution of Node, is based on TS. Pretty much everything in the JavaScript OSS world has TS options or is based on TS. I doubt Coffeescript ever saw this scale of adoption.

We only use TypeScript on frameworks that make it a requirement, the language is starting to look like Haskell. As much as I like Anders work, it is impossible to understand modern TypeScript without looking into tsconfig.json before looking into source code.

This does not align with my experience of writing Typescript at multiple companies of varying sizes and open source projects.

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

#139

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

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

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.

Post reply on HN