Live data from Hacker News

Remove TypeScript

github.com

11–20 of 127 posts

Re: Remove TypeScript

#11
> Fully recognize that TypeScript offers some people some advantages, but to my eyes, the benefits are evident in this PR. The code not only reads much better, it's also freed of the type wrangling and gymnastics needed to please the TS compiler.

This is such a terrible take. The same could be said about removing tests. It does simplify things, and not having to please the damn test suite is indeed a boon for productivity. You get to drive at full speed towards the cliff.

Strong typing is a hill I'm willing to die on, and at Svix we encode everything we humanly can in the type system. Let the compiler catch our mistakes...

Re: Remove TypeScript

#12
Regardless of if you like TS or not, merging this changeset without addressing a single concern/comment in less than 2 hours shows that obviously DHH doesn't give a shit about contributors.

Not to mention adding 0 comments or written documentation in places where the types were literally the only documentation on what the arguments should have been. (For example string literal typed arguments ('on' | 'off'), places where only certain types of elements were expected, etc)

If I were a contributor to this, this would be my last day as one.

Re: Remove TypeScript

#13

After years of being resistant to “extra layers of complexity that slows me down” I adopted TS and now I can’t live without it. So as a fanboy, when I read things like this I try my darnedest to have empathy and try to understand it from their point of view. And I’m just really struggling to in this case. I get that it adds some complexity. But what are you actually getting without it? It’s not like types go away. Th…

One advantage of going to JsDoc type annotations for some libraries is that you don't need to deal with sourcemaps. People can use the source code as-is and they can bundle and minify it if they like.

That doesn't seem to be what this is about, though.

Re: Remove TypeScript

#14
I've found the TypeScript tooling story to be a bit clunky (protip: use tsc --noEmit for type checking in CI, but don't use tsc for anything else).

But TypeScript the language is great – I spent 3+ years each working with C++ and Java, and TS's type system is much more expressive and useful.

I wish people would distinguish whether or not they object to the tooling, or the language.

Re: Remove TypeScript

#16
post #11

> Fully recognize that TypeScript offers some people some advantages, but to my eyes, the benefits are evident in this PR. The code not only reads much better, it's also freed of the type wrangling and gymnastics needed to please the TS compiler. This is such a terrible take. The same could be said about removing tests. It does simplify things, and not having to please the damn test suite is indeed a boon for product…

[deleted]

Re: Remove TypeScript

#17
post #4

Remove TypeScript, change linting rules, remove Prettier, breaks all PRs ... seemingly with no discussion and merged within 2 hours of the PR. Sounds like a project I'd stay away from. With comments like "Also, TypeScript hurts to write. Good riddance." What exactly is the problem here? Do we have too many developers who grew up on JavaScript and aren't seeing the benefits of static typing? Is a tiny compiler (transp…

I grew up on JavaScript and usually enjoy it, and also adopted TypeScript and usually get along with it.

I'd find it difficult to contribute to an enterprise Angular project without static typing, and definitely found the refactor to static typing/react from a legacy Angular 1.x project quite challenging. But, I don't know that it's ever truly helped me move faster, and does often get in the way. It's a formality, and formality adds latency. When you go out for dinner, you can go casually and all you have is transit time. When you go out formally, you need to dress up, put on a tie perhaps, do your makeup, hair, all this extra stuff. You might find it's worth it, maybe you enjoy the whole production, and otherwise they'd not let you into a fancy place. Likewise with static typing, you might get the benefit if someone changing your code or integrating finds that the path is more clear because of the type hints. Maybe you introduce less bugs because you've been alerted to missing null checks. But not necessarily, you trade time for a hopefully more consistent experience.

Re: Remove TypeScript

#19
Meh, this debate is already long over. Every TypeScript alternative/competitor is dead. Most developers who are staunchly against TS types and compile steps for their JS code still probably end up relying on TypeScript via their editor's intellisense/language support even if they don't know it.

Re: Remove TypeScript

#20

After years of being resistant to “extra layers of complexity that slows me down” I adopted TS and now I can’t live without it. So as a fanboy, when I read things like this I try my darnedest to have empathy and try to understand it from their point of view. And I’m just really struggling to in this case. I get that it adds some complexity. But what are you actually getting without it? It’s not like types go away. Th…

> After years of being resistant to “extra layers of complexity that slows me down” I adopted TS and now I can’t live without it.

TS isn't an extra layer of complexity.

Walking through the entire path an object takes through a library's source code to find out what fields the object has is an extra layer of complexity.

Having to rely on looking at unit tests to have some idea of what to pass to a function is an extra layer of complexity.

Hoping documentation is kept up to date (hint: it isn't) is an extra layer of complexity.

Having code break after updating to a point release because some field got renamed or removed and there is no safety mechanism to keep chaos from happening, is an extra layer of complexity.

Typescript makes you pay up front to remove a LOT of complexity down the line.

Post reply on HN