Live data from Hacker News

Remove TypeScript

github.com

61–70 of 127 posts

Re: Remove TypeScript

#61

Hi all, I work on the TypeScript team. There's already a lot of feedback on the issue itself from users urging the authors not to make this decision, so I will hold back from adding to the noise on that issue. Every team is entitled to make the decisions that they feel are best for them, and I don't think it'd be productive to change anyone's mind in this case. Instead I'll just mention that I always welcome thoughts…

In our team it's causing a lot of confusion an inconsistency that types and interfaces overlap 90% in functionality, but have different syntaxes.

You can find many articles trying to explain which is best under which circumstances, but there are no correct answers.

I would wish for TS to deprecate one of the syntaxes (probably interfaces because they read as statements rather than expressions), and instead extend the other with the 10% functionality that would be lost.

For instance a type could be declared as open, to make it possible to reopen and extend it.

Re: Remove TypeScript

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

Every time I’ve had to “wrangle typescript” it’s been converting old JS files where someone has done something that neither me nor typescript can work out what is going on.

Re: Remove TypeScript

#63

TS feels like a fever dream. It's as if a concentrated group of people were so convinced of a solution, that despite all available "parol" or academic evidence, they foisted it upon the ecosystem doing untold amounts of damage for years to come. And if you don't use it, well it's because you simply don't understand types and your code base will be riddled with bugs! (lol) The best, most testable, falsifiable argument…

Well that’s certainly a hot take. I’d say TypeScript is the best thing to happen to JS, but that’s just my opinion. It’s not perfect, but it makes working on a large codebase tolerable. To each their own.

Re: Remove TypeScript

#64

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…

Yes that's valid TypeScript, but is it good TypeScript? One should take a ternary nested that deep as a sign that refactoring is needed. You can write terrible code in any language, that doesn't make the language problematic.

Re: Remove TypeScript

#65
post #56

Typescript is divisive. People are passionate in loving it or hating it, not to forget a silent majority that never even tried it. Typescript is totalitarian. It consumes you whole. It makes no sense to partially adapt it as its supposed benefits will then never materialize. The deeper you're in, the more motivated you'll get to go even deeper. This is entirely opposite from writing unit tests. Everybody hates to do…

> He craves the simpler times we once knew, where web/front-end development wasn't such a hot mess.

I strongly disagree. Web/front-end development was always a hot mess. It's just that when we were using Perl to write CGI.pm pages, we didn't have good tooling to tell us all the terrible things we were doing.

Modern tooling just shines a light on our mistakes. It didn't make them for us. Those simpler times only existed in the sense that we were blissfully ignorant of our sins.

Re: Remove TypeScript

#66

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…

But we can hide those utility types in a deep dark util.ts hole and never look at them ever again

Re: Remove TypeScript

#67

The collective meltdown, bullying, pile-on and emotional responses over a team's decision to drop a layer of tooling is strange. Yes, I get it, for most usecases, most people today prefer TS, but in the end, the team weighed their options and they made a decision they are happy with. Open source, as strange as it sounds, doesn't mean that the maintainers need to ask for the approval of everybody who read some tweets…

> The collective meltdown, bullying, pile-on and emotional responses over a team's decision to drop a layer of tooling is strange.

It should seem strange - that's not what's happening.

People are upset about the decision to drop a layer of tooling, yes. People are also upset about a rush job of ripping out that layer, losing information and deleting documentation. People are also upset about a total disregard of feedback and extremely quick decision merging. These are all very normal things to be upset about.

Re: Remove TypeScript

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

Except that most code actually isn't passing around random unnamed objects of unknown type or contents. Their meaning and type are implied clearly enough in many if not most cases by their name and usage.

Hence, the downside is doing a lot of work to describe things we already know whilst making code less readable (or at least longer).

I'm still largely in favor of Typescript, I'm just suggesting to not misrepresent the situation of not having Typescript.

Re: Remove TypeScript

#69
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, an…

> But, I don't know that it's ever truly helped me move faster

It's incredibly helpful to move fast on large projects.

It's not about missing null checks and other simple things. If you change code in one place, that happens to affect code in some far off other place, it won't compile. In JavaScript you would end up with a runtime error and be wondering what is going on. With TypeScript the compiler will tell you right away what the issue is.

I found it incredibly helpful today when we had to completely refactor an Angular service method. I wanted to remove a parameter. It was called in various places, and all I had to do was run the compiler and get back "can't do it, go check XyzComponent.ts line 51" and give me a link to it. I'd click, go right to it, change the call site and repeat. After a few minutes it was compiling again and it was clean.

Sure, you can change function signatures in JavaScript and go and manually find all the places that function is called, but what if you miss one? A really good IDE can probably figure it out, much like they can sort of handle intellisense for raw JavaScript code. But with the compiler you are ensured that you got them all and everything checks out.

That's just one simple example.

Re: Remove TypeScript

#70
post #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 gi…

He does say that he started at 'hate it' and never left so it may just be a preference thing. I think it's fair that a maintainer makes choices that make the project easier to maintain (for them), but I wonder if it's really just that they picked up TS unwillingly and simply never really came around to it.
Post reply on HN