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

Remove TypeScript

github.com

Post reply on HN
Print view View original

101–110 of 127 posts

Re: Remove TypeScript

#101

Post by Hrun0 »

whoknowsidont wrote: post #57
monkpit wrote: post #51

Earlier quoted context omitted.

> untold damage > 10x dev time > bugs > pointlessly painful > it’s a mistake Your comment seems very emotional and doesn’t add any concrete counterarguments.

Counter arguments to what exactly? What arguments are being proposed? Where? By Whom? Can you quote them? The burden of proof is not on anyone else to prove that TS is making a beneficial difference. The fact that more and more experienced teams are moving _away_ from TS and not towards it certainly cannot and should not be ignored. This is just a repeat of the "Surely OOP will solve all these different class of prob…

> The fact that more and more experienced teams are moving _away_ from TS and not towards it certainly cannot and should not be ignored.

I highly doubt that this is the case. I also doubt that you can back this up.

Re: Remove TypeScript

#102

Post by sensanaty »

I'm a Rubyist at heart like DHH so I get not liking types, but after being involved in a pretty large Rust codebase where everything was typed and having my editor be able to know exactly what I'm trying to do in 99% of cases, I find it hard to go back to Ruby, especially if we're talking about a team setting where you're working with other devs. If I'm doing something solo I still prefer Ruby since I can just write the code and forget about it.

I've also had the pleasure of working on a JS-only project, and I would've killed to have typescript there. It was anyone's guess what any method call would be doing, what arguments were being passed around etc. I can't imagine working in a large JS codebase, especially with other contributors, without types to back you up.

Re: Remove TypeScript

#103

Post by celrod »

xgdgsc wrote: post #98
celrod wrote: post #34

Earlier quoted context omitted.

> 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... After years of writing Julia (dynamic) and C++ (static), I'm willing to die on that hill too. But I've encountered more people who disagree with me than agree, so I'm not surprised by seeing a PR like this.

Just tried the latest Cthulhu.jl and vscode integration. Dynamic by default and can infer and show types might be perfect.

Doesn't scale to large projects and your dependencies. Requiring `map` to be type stable when calling dependencies is a maintenance nightmare in Julia.

Re: Remove TypeScript

#104

Post by TehShrike »

tuukkah wrote: post #40
TehShrike wrote: post #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.

What do you use for type checking in dev - tsserver? https://github.com/microsoft/TypeScript/wiki/Standalone-Serv... Regarding this, it's a pity there's no officially maintained support for the language server protocol in TypeScript, and the last update from MS on the issue is from two years ago ("We've had personnel changes"): https://github.com/microsoft/TypeScript/issues/39459#issueco...

Yeah I use LSP-typescript in Sublime Text, which uses typescript-language-server, which is backed by tsserver.

Re: Remove TypeScript

#105

Post by kstrauser »

happyraul wrote: post #99
kstrauser wrote: post #60

Earlier quoted context omitted.

I've written maybe a couple thousand lines of TypeScript. I'm an utter neophyte there. I didn't hate the experience, though. I've written maybe a few hundred thousand lines of Python. I didn't use type annotations until recently because they didn't exist. My first forays into playing with them were painful: it revealed a whole lot of unfound bugs in my code. In most cases they were minor and probably wouldn't have ca…

I can relate to this when it comes to Python. Type annotations & mypy have undeniably caught bugs and forced me to write better & more correct Python. However, it's also true that I've felt a lot of frustration with them at times when I was nagged about something that was impossible, and fixing the mypy error felt like makework that didn't actually improve anything. I'd argue the result in those cases was worse. So i…

That’s valid. I’m pretty rigorous about typing new code, but don’t make any heroic efforts to go back and retrofit old, well-tested code. `mypy --check-untyped-defs` gives a lot of bang for the buck for checking existing code without going all-in.

I’m also OK with liberal use of Any for things like returning JSON fetched from an API. How should I know what it’s going to return this time? I’ll deal with that mess in the function that parses those results, not the one fetching them.

One way I think typing has made my code better is that I tend to use more dataclasses and namedtuples now. It’s easier to say List[Person] than List[dict[str,Union[str,float,int,Email]] etc. That also makes IDEs a lot happier because now I can say Person.bir and tab-complete it to .birthday. It’s a little more effort to set up, but a lot nicer in the long run.

But again, I find that fun and productive on new code. Darned if I wanna jump through those hoops on stuff that’s been running in production for a decade. I’m more of a fan of “type it as you touch it”.

Re: Remove TypeScript

#106

Post by wk_end »

whoknowsidont wrote: post #88
digging wrote: post #64

Earlier quoted context omitted.

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.

>Yes that's valid TypeScript, but is it good TypeScript? If the implication is that this code should be refactored, then how would you refactor it and why does this class of code show up across many different teams?

Some combination of:

* Javascript devs tend not to be good Typescript devs, and don't always know how to build tasteful or easy-to-type interfaces.

* ...or maybe they're perfectly fine Typescript devs, and they've made the deliberate choice to have a nasty type in order to have a particular interface. For better or for worse Typescript offers that flexibility.

* Types were added after the fact and it was deemed better to have some kind of gross type for the existing difficult-to-type interface than rebuild the interface and/or implementation.

Re: Remove TypeScript

#107

Post by digging »

whoknowsidont wrote: post #88
digging wrote: post #64

Earlier quoted context omitted.

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.

>Yes that's valid TypeScript, but is it good TypeScript? If the implication is that this code should be refactored, then how would you refactor it and why does this class of code show up across many different teams?

I don't actually know off the top of my head how to refactor it - I've never had to write or deal with a type that complicated. It might actually be the best way of writing that specific type, in which case yes that kind of sucks, but I feel like it's probably not based on how hard it is to parse.

Re: Remove TypeScript

#108

Post by digging »

whoknowsidont wrote: post #71
digging wrote: post #67

Earlier quoted context omitted.

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

>It should seem strange - that's not what's happening. I just went through the thread and I classified 93% of the comments as snarky, editorial, and abrasive to the maintainers. The others are just memes. Presumptuous is a word that comes to mind. The majority of the commenters there have never contributed anything to the project (or any other project for that matter).

> I just went through the thread and I classified 93% of the comments as snarky, editorial, and abrasive to the maintainers. The others are just memes.

But, they're responding to the behavior and the intentions as much as the decision itself. That's my point. It's disingenuous and pretentious to insult the lot for simply reacting to the decision to remove a tool because that's not what they're reacting to, not entirely.

> The majority of the commenters there have never contributed anything to the project (or any other project for that matter).

Fair, but a totally separate point.

Re: Remove TypeScript

#109

Post by vlod »

gardenhedge wrote: post #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…

If seen a lot of code like this and I f.hate it. Devs try and be too clever. With great power... etc

Even if you don't like TS that much, nobody would have that much of a problem (IMHO) with having 'simple' types on function parameters or objects. It's not really that hard to understand that it helps the IDE let you know when you're missing a mandatory attribute or misspelled it. Attribute completion is nice. I love anything that makes me lazy.

However when something like the above generates a huge error which takes significant effort to debug and derails all the delicate logic in my head, I generally reach for my notebook of significant harsh swear words/insults to throw at TS. It makes Java full page exception errors trivial in comparison.

Back in the day when I was doing Java, it was pretty much like this and with a good IDE (like IntelliJ) it was awesome and I coded like a bat out of hell. You couldn't do all this fancy stuff of picking just the keys of types/interfaces, making them optional and changing the type something wierd. Madness.

The approach of TS preaches (AFAIK) is to generate derivative types from previous types/interfaces, so when you screw around with a type in the hierarchy (e.g. rename an attribute), child types know immediate that something is wrong and an error is thrown. You really can't do this with raw Javascript and for it to be picked up by the compiler.

I personally use TS now (most jobs require it) and I do see the benefits, but man can it be a PITA sometimes. (I just got through a painful process of using TS w/ d3 in a non trivial graph).

Re: Remove TypeScript

#110

Post by vlod »

rcarr wrote: post #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 sh…

> very quickly realise the higher end vehicle is infinitely better and you never want to go back to driving a heap of shit again.

I fixed our 2006 Saturn Ion lots of times and it runs very well. It's generally simple and the parts are relatively cheap.

I've been tempted to get a fancy Land Rover, Audi, BMW, Telsa. I want shiny things like lane positioning assistance, blind spot monitoring and even self-driving etc.

But they always seems to need a lot of maintenance, need fancy high grade fuels and when they break down, it's rarely fixable for the average person.

Post reply on HN