Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

chiragswadia.medium.com

Post reply on HN
Print view View original

141–150 of 400 posts

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

#141

Post by ysavir »

blacktriangle wrote: post #61
oblio wrote: post #8

Earlier quoted context omitted.

Naming is incredibly hard, though. And refactoring is hard. It's a pain in the neck when something starts out as bla_list or whatever and you discover that after half a decade of changes bla_list isn't actually a list anymore, it's a dictionary, and that it doesn't only hold Bla these days, it can also contain Foo or Bar. This type of stuff is immediately obvious with modern static typing.

This feels more like developers learning that any variation on Hungarian notation is a bad idea.

This feels less like a case of Hungarian Notation being a bad idea and more like a case where developers are making irresponsible updates to their code. If a variable/function/class/whatever is being updated, the naming should be updated as well, if appropriate.

Blaming the original author for the actions of the maintainer is not fair.

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

#142

Post by vbsteven »

nobody0 wrote: post #74
exhaze wrote: post #49

Earlier quoted context omitted.

> Like you have a react hook and some components that you can compose, and the typedefs just become unwieldy and impossible to get right. Often they end up not even catching what should be compilation errors. I’m curious - how do Elm and Kotlin solve these problems in a way that balances the often competing goals of “add types to reduce errors” vs “have a high productivity environment where it’s quick and easy for en…

Elm and other ML-family languages have type inference, it does not ask a major part of human annoation of types while catches errors in compile time nonethelessly

Kotlin has type inference as well so typically you only write types in function signatures. It's rare that you write a type in a function body. Coupled with good IDE support for showing you the type of x in `var x = myFunc()` when you need it.

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

#143

Post by madeofpalk »

cosmotic wrote: post #85
madeofpalk wrote: post #2

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

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…

The author actively describes themselves as being "Anti-Typescript" and "hating" something they have no experience with. That's not skepticism.

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

#144

Post by victorbojica »

cosmotic wrote: post #85
madeofpalk wrote: post #2

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

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…

Being skeptical shouldn't mean being ignorant. Being skeptical should mean Trying to understand the pros and cons and believing it's not worth it.

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

#145

Post by tomca32 »

jdxcode wrote: post #114
btbuildem wrote: post #89

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…

assuming you meant let myColor: Color | undefined; I don't understand what the problem is. Native JS would require you to define the starting scope of the variable (unless you're relying on global scope!). Then you declare what the type is: Color or undefined. The state of the variable can be one of two things. Perhaps I've been writing TS for too long but I think I'm missing the problem here.

The problem is that if anything can be undefined, then you don't really have a big typing advantage over regular JavaScript.

It's just like being in Java land where typing adds a lot of boilerplate to the code, but you still have to do null checks everywhere.

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

#146

Post by [deleted] »

pjmlp wrote: post #72
arcturus17 wrote: post #45

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.

[deleted]

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

#147

Post by lhorie »

madeofpalk wrote: post #129
lhorie wrote: 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…

> you still need to have good developers writing good code, but TS will make it easier

Very true. Typescript is still immensely helpful in the sense that it will complain if you pass a Thing to a function expecting a Foo, regardless of the fact that Thing is meant to be a thing but is actually an error.

But IMHO, by sticking to a decision to be lean in terms of transpiled JS, TS suffers greatly from cases like the one I showed. It would be great if the compiler enforced that these types of unsafe casts had to be explicitly specified (even if via some strictness flag), and even better if it could do a better job at refining types through runtime constructs like `if (typeof thing.name == 'string')` (it does do it to some limited extent, but not enough to cover many common scenarios, due to the curse of targeting Javascript, as you mentioned)

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

#148

Post by damagednoob »

lhorie wrote: post #122
madeofpalk wrote: post #2

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

#149

Post by joshAg »

lhorie wrote: post #122
madeofpalk wrote: post #2

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…

If you're not using a bunch of generics, check out typescript-is [1]. It takes little work to get it setup, but it generates run time type checks for you. I understand why typescript decided to not add this functionality to the core of the language, but it's starting to feel like the largest missing piece of typescript is a built-in way to generate run-time type-checks for user-defined types from just the type definition.

The happy medium we've found with that module is using the runtime type-check on anything "unsafe" to bless the result using typescript-is's equals functionality, but still allowing programmers to use casting with a comment justifying its necessity. For us our list of unsafe is results pulled from the db, anything parsed from JSON, and incoming request bodies (which can be a special case of parsing from JSON, but not always).

[1]: https://github.com/woutervh-/typescript-is

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

#150

Post by prophesi »

lhorie wrote: post #122
madeofpalk wrote: post #2

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…

Just a quick tip that helped my team with such issues:

- For every call to an API, or input from the user, there should be a few tests checking for unexpected data

This rule alone forces us to fix the majority of runtime errors such as this example (since JSON.parse() is usually called when handling an API response)

Post reply on HN