Hacker News Reader

Comment by 0x0nyandesu | Hacker News Reader

Not really. You can't replicate experience. Everything you just wrote about with data types, invariants, and decorators is just flavor which you only have control over in your own personal code however as soon as you interact with web browser APIs, nodejs, and 3rd party libraries all that goes out the window and you end up conforming to other people's patterns.

In my honest opinion Typescript is a fad. You're still just coding JavaScript with an alternative syntax. Since you're borrowing dependencies from JS you need to know both and context switching between the two slows you down. From a CS perspective I get why TS syntax is better but from a functional perspective it's harder to find engineers that actually want to work with it because every TS project I've ever seen is really a mix of TS and JS.

View on HN

Web browser API's usually do keep their invariants. I wouldn't use libraries which don't. Libraries which do not support TypeScript will vanish. See, all your experience (in a limited field) is telling you the wrong thing.

And it is quite obvious to me that you need to know BOTH TypeScript and Javascript, of course, you cannot just learn TypeScript, because it is just a thin layer on top of Javascript without many runtime guarantees otherwise.

> See, all your experience (in a limited field) is telling you the wrong thing.

You seem to be conflating objective wrong/right with your own personal stance. Do you have an objective argument in favor of your assertion about the longevity of non-TS libs?

> And it is quite obvious to me that you need to know BOTH TypeScript and Javascript

That's a reasonable strategy on the assumption that TypeScript will be used, but the very fact of its being so is actually an argument in favor of the point made by gp which has been left unaddressed (RE context-switching).

Obviously, there is no objective wrong/right here, as only the future can tell. My subjective experience tells me, it will be that way.

There is no need to context-switch. Just accept Javascript as part of TypeScript, because it really is. The argument is clear: TypeScript drastically reduces the amount of errors you will be making when coding, and the amount of time you need to think about stuff that is really trivial.

The rule of thumb on how to do this is also simple: Keep your types simple, use them to make your life easier, not more complicated. If you cannot model something simply using types, don't try to do so, just use the dynamic typing escape hatch that Javascript provides.

I'm just explaining to you how it plays out when a business is deciding whether or not to use TS at all. Mistakes and errors are checked for by linters and unit tests automatically in the background so that's not a benefit anyone cares about. The liability of having to find coders that want to work on your TS project decreases potential candidates and makes hiring more difficult. Large organizations can deal with it cause when you have 500 engineers on staff you can find 50 that will use TS for you. For smaller orgs it's a pain.

These are concerns that will arise in some organisations, for sure. Personally, I don't have a need to work together with people who cannot be bothered to learn TypeScript. A nice type system is something you really want, and which improves code quality. No need not also to use linters and unit tests. These things do not oppose each other, they work together nicely.

Reply on news.ycombinator.com