Live data from Hacker News

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

chiragswadia.medium.com

191–200 of 400 posts

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

#191

Earlier quoted context omitted.

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

Don't know about the other two, but the first one is available in java 10 and later.

Worked on a project with an old (12+ years?) - but still being developed/used - Java system. Just last year a move was made up to Java 11 (from 8). Decent test coverage, but moving multiple systems is still a big task, but... they did it. Java 11. Yay.

But... teammates were running in to issues with 'new' stuff - like, using 'var'. There were others, but this was sort of the archetypal argument. "Well, it doesn't match the rest of the style of the file/app - it'll make it hard to read". Well... hrm... any new feature literally doesn't match the style of what came before it, because you have new keywords/features/syntax to handle processes a new way. It's definitional. But just because there's a new feature doesn't mean it'll be adopted (for better or worse, I supposed, depending on your stance).

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

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

JS the language isn't great but it's JS the culture that is the real problem.

There is a subset of JS codebases that are good, well engineered and written by people that understand the languages faults and limitations but the list is incredibly small and even smaller still now Joyent isn't really around anymore.

If there was one ecosystem I wish I never needed to touch again it would be JS but unfortunately it's become so pervasive that isn't really a tenable position anymore.

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

#193

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…

The issue that broke the camel's back for me was when I saw "cstomerName is not defined" in production. I just could not accept that it is OK to live with tools that let that happen.

> broke the camel's back for me was when I saw "cstomerName

Truly the camelcase's back...

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

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

Sure, but you also should never just blindly trust a JSON.parse, and if possible you should avoid typing functions for exactly this reason, and let their return types be implied instead. If you didn't type `getThing` then its return type would be `any` and you'd get an error in your IDE on the last line.

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

#196

Earlier quoted context omitted.

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.

I think everyone except JS devs wishes they could write something other than JS for the browser.

Maybe eventually with WebAssembly...

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

#197
My aha moment with TypeScript was when I realized that, in spirit, it's the same thing as ActionScript - a superset of ECMAScript with a stricter type discipline.

I had no issues with that back when I was a teenager trying to put together flash games, so apparently the only thing preventing me from writing exclusively in TypeScript was a lack of a decent toolchain.

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

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

Check out io-ts — it can take a minute if you’re not familiar with functional programming, it’s built on top of fp-ts.

Being able to encode/decode IO safely has been a huge blessing when working with JSON.

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

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

> Coffeescript in particular, are good historical references to what will happen to TS in a few years.

The thing is that many good ideas of Coffee ended up being integrated in newer versions of JS, so of course the need for it decreased; one could argue that Coffee's legacy lives in ES201x.

But there are no types in JS, and none planned.

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

#200
My problem with TypeScript is the lack of runtime benefits. Yes, you get some benefits of static checks during compile time, but at the cost of huge additional effort. This effort maybe makes sense for a large project with many team members pushing code, but for small hobby projects I think this just makes quick iteration far more difficult. To me this defeats the whole purpose of using a dynamic garbage-collected language to begin with.

If TypeScript was a first-class language, you could do all sorts of great runtime optimizations (perhaps a v8 fork will do this eventually?). In this case I would absolutely jump all over it, even for small hobby projects.

As it is, going from JS -> TS, one might as well just skip the extra translation step and just start writing everything in Go or Rust, especially for back-end nodejs/deno projects. In these languages the runtime benefits makes the abstractions worth the effort.

Post reply on HN