Live data from Hacker News

Remove TypeScript

github.com

41–50 of 127 posts

Re: Remove TypeScript

#41
post #23

> it's also freed of the type wrangling and gymnastics needed to please the TS compiler. If you're fighting typescript that much, then what's the point? The point of using things like types is correctness that can be statically checked. Imagine writing java (or any static typed lang) code where you just pass around a base class( e.g. "Object") and explicitly cast up to what you want, there'd be no point in using that…

> If you're fighting typescript that much, then what's the point?

Agreed - I find these "wrangling" situations to be uncommon, and roughly half of the time they happen because our code is bad and we need to change it. The other half - well, sure, it can be a pain in the ass, but there's no such thing as code so elegant that it never has some irritating high-effort corner cases. I'll take deterministic type wrangling over raw untyped JS.

Re: Remove TypeScript

#42

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…

Merging this PR honestly just seems like a 'political move' in terms of forcing their opinion about TS on everyone else as the "best decision". If they actually cared they would have at least addressed the comments, and added written documentation/jsdoc comments in places where literally theres no way to know what is going on without the types that were given.

To be fair, open source is not a democracy. The project owners/authors/maintainers can do things because they feel like it or prefer it, without having to justify it to anyone - even if everyone else openly hates it and the project loses users or contributors as a result.

Some big projects have governance rules and committees where you could expect more through some bylaws or similar, but that is not the norm. The only right given to others in traditional open source is the ability to fork if you feel enough for it.

Also note that many of the votes and comments are from HN, which might distort the view of the original disagreement.

(I like neither JS nor TS, so eh.)

Re: Remove TypeScript

#43
Many people in the PR mentioned the complexity that Typescript brings. But wasn't it an over simplification from the language from the beginning?

I mean, in the context of JS 10 years ago, Typescript in indeed overly complex, but in the context of today's JS running servers and very complex apps at scale, it just seems sane to back up the code with types, just as most other languages would do..

In my opinion it's now a required complexity to build up a lib with some stability and a safe DX for contributors

Re: Remove TypeScript

#44
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've had to deal with a couple other unilateral decisions that DHH drove into the Rails ecosystem (e.g. getting rid of Webpacker) and I think that staying away from his projects is a good idea.

Re: Remove TypeScript

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

On the contrary. Most Rails apps with Turbo and Stimulus enabled only need a sprinkle of JS. It's so minuscule that you don't even need an IDE, even less TS either on the client or the library side. Thus, this PR both makes sense and most users won't even notice something changed. So the reasoning is good.

I see much hate on DHH for doing this, but I sincerely support him on many levels. And I am glad someone was bold enough to do this so publicly. Go team JS!

Re: Remove TypeScript

#46
The analogy I like to use for this is JS is like your first car and TS is like your car ten or twenty years later. When you’re driving in your current car, fiddling with the settings, you might look back with nostalgia at your first car and how simple and fun it was and how free you felt. Then if you ever get an opportunity to drive that car or one like it again, you quickly realise that no, actually it was pretty shit, broke down more, didn’t warn you about things that needed checking or refilling and that it’s missing all the luxury comforts you’ve become accustomed to. Once you’re back in that banger you very quickly realise the higher end vehicle is infinitely better and you never want to go back to driving a heap of shit again.

Re: Remove TypeScript

#47
I often find that types in typescript are bolted on and the whole thing gets pretty messy. I like typed languages like Java where the type system is more built into the language.

Typescript errors are also very annoying to read.

This is TS code - and I think it's crazy.

type DeepPartial = { [P in keyof T]?: T[P] extends (infer U)[] ? DeepPartial[] : T[P] extends ReadonlyArray ? ReadonlyArray> : T[P] extends object ? DeepPartial : T[P]; };

Re: Remove TypeScript

#48
The key thing from David's blog post:

> things that are hard become `any`.

It's a hard problem to solve.

TypeScript excels at informing IDE's and developers. Typing improves my ability to understand APIs both as a library user and contributor. So I see the benefit exceeds the issues of TypeScript.

A better approach would be a more gradual. Perhaps keep the .ts files (or at least develop .d.ts files) for the public API and main components.

Re: Remove TypeScript

#49
post #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…

I had the great joy of learning a massive "legacy" nodejs project a few years ago. The author had used function "arguments" as a bucket all over the place mixed with named parameters. Lots of indirection and "facade" patterns. A few high level integration tests. And to top it all off, none of it worked in isolation, lots of very loose coupling with no documentation that the coupling existed. Took me months to digest it all.

TypeScript hurts to write for people who write code like that. But also, these days, it enables it: you can write that, you just need to leave an actual trail outlining the shape of those dependencies. And if you REALLY like writing lots of flexible dynamic code, typescript can enable that too, and have fun defining those complex generics. You won't.

I understand the pain of typescript. It's the pain that you can either eat yourself in working through exactly what you want the shape of your dynamic things to be; it's the pain that every other developer following you will need to eat if you do the same thing in js without types.

OR- You could just write your code without those "clever" features in the first place, and get the job done in less time to boot.

Re: Remove TypeScript

#50
No one could accuse DHH of being an amateur, and it's true that static typing is an obstacle if it's not a vehicle.

It took me years to "get on the other side" of typing, and wield it productively instead of battling against it. I have heard several developers express the same way about testing, ie when one learns to test first, one no longer resents the tests (or whoever mandates them). Resentment and frustration give way gratitude and elation--but admittedly, it takes more than "five minutes".

Static typing has a similar feel for me (although I am no expert): type-driven design often unfolds fantastically, easily, and beautifully. It has certainly replaced a few categories of unit test. Inability to appreciate static typing as a tool is, for most developers, a "skill issue." It certainly took me more than five years to come around to static typing, although as I explore it deeper (perhaps after another five years), I'll undoubtedly discover areas in which the emperor's showing a little skin.

Again, however, no one could accuse DHH of a skill issue. Perhaps he is looking out for the little guy? Perhaps he's simply invested in an alternate idiom. Perhaps he really is a whole five years of static typing grief ahead of us. I think that's certifiable.

Post reply on HN