Live data from Hacker News

Remove TypeScript

github.com

81–90 of 127 posts

Re: Remove TypeScript

#81
post #72
post #25

This is the correct move. A hot take I recently posted that has caused me zero issues over the past few years: [1]. [1] https://twitter.com/cheatcodetuts/status/1692256529628512667

Do you have multiple people collaborating with you? If I’m writing code that only I need to understand then yes, typescript may be overkill (though I prefer types even then), but working on any meaningful codebase without types is… challenging. Types aren’t that hard are they?

I have, yes. From a team perspective, there's zero technical difference between TypeScript types and a combination of default args and type checker functions. The same ends are achieved, but in a far less kludgy way that's overt. In the event a type checker is missing, it can be added/documented quickly with zero time wasted on trying to answer "what's the TypeScript way to do this?"

Types aren't the difficult part, it's TypeScript that's difficult. The documentation is a nightmare and in my experience I saw "any" types being used far too often (which literally defeats the purpose of using TypeScript).

Re: Remove TypeScript

#82

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…

I know you said don't get me started on the bugs TS caused, but I would like to hear about them if you don't mind.

I personally only had one bug that was caused by TS itself (https://github.com/microsoft/TypeScript/issues/40726) so I'm curious to hear about the issues you encountered.

Re: Remove TypeScript

#83
post #75

Earlier quoted context omitted.

I was looking at the bigger picture, and didn't clarify that point enough. What I mean to say is that web development was more accessible during simpler times. People from all walks of life would develop websites, flash stuff, and even dynamic sites, i.e. LAMP. They could do that because it was simple enough to learn. Front-end development as we typically do it today has turned into a hardcore engineering discipline…

Those are very fair points! You use to be able to write a credible site with a text editor and an FTP client, but that's a long time gone. (Bystanders, don't "correct" me with "technically you still can...", etc. I know. It's all just text, right? But the parent poster is absolutely right about the general state of things.)

Thanks for a reasonable discussion.

Whilst hobbyists can still use whatever they want, including simple options, I in particular empathize with those new to the field or looking to turn a hobby into a job.

You need to know React/Typescript/CLIs/Docker/Git/Unit testing/IDEs/CSS/5 million other things. Or there's simply not going to be a job for you at all.

So "just don't use it" doesn't apply.

On the upside, once you do master the unwarranted complexity, pay is great. Fiddling around with toys and a Frankenstein tech stack whilst continuing to produce outcomes with worse UX than 15 years ago is somehow richly rewarded. It paid for my quality of life so let's add some more "absolutely essential" tools.

Re: Remove TypeScript

#84
post #81
post #72

Earlier quoted context omitted.

Do you have multiple people collaborating with you? If I’m writing code that only I need to understand then yes, typescript may be overkill (though I prefer types even then), but working on any meaningful codebase without types is… challenging. Types aren’t that hard are they?

I have, yes. From a team perspective, there's zero technical difference between TypeScript types and a combination of default args and type checker functions. The same ends are achieved, but in a far less kludgy way that's overt. In the event a type checker is missing, it can be added/documented quickly with zero time wasted on trying to answer "what's the TypeScript way to do this?" Types aren't the difficult part,…

Fair enough if you have another way that works!

Re: Remove TypeScript

#85

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.

Hmmm you got me thinking. I wonder if there’s a sensible story for ts to “compile” to JS with jsdoc annotations.

I know you can make it emit perfectly legible, formatted JS, but I’m not aware of the docs.

Re: Remove TypeScript

#86
post #32

Earlier quoted context omitted.

Javascript and type annotations in comments go a long way, too. Not the whole way, a bit annoying to write at times, but 95% of the value is there. Just getting rid of types after you already authored your software with them in mind just seems like the worst of both worlds. I have trouble making any sense of it.

> Javascript and type annotations in comments go a long way, too. Not the whole way, a bit annoying to write at times, but 95% of the value is there. I'd say that "5%" is where some really nasty devils lay though. Plus, if you're going through the effort of documenting types in comments, why not use TS and prove that they're correct + up-to-date?

You are using Typescript to prove that they're correct.

https://www.typescriptlang.org/docs/handbook/jsdoc-supported...

Re: Remove TypeScript

#87
post #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 feed…

The majority of people complaining are not contributors to the project at all, or for the one or two I saw that are, had a handful of commits.

Just like in this thread -- lots of people whinging about how something they don't contribute to is built, by the team that builds it. Which is both obnoxious and arrogant.

Glance at the contributors page and you'll see who has earned the right to have an opinion on how turbo is built.

Re: Remove TypeScript

#88
post #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.

>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?

Re: Remove TypeScript

#89
> letting the rest of us enjoy JavaScript in the glorious spirit it was originally designed

Pretty funny, considering one of Eich's regrets about JavaScript is allowing things like `1 == "1"`

Re: Remove TypeScript

#90
post #81
post #72

Earlier quoted context omitted.

Do you have multiple people collaborating with you? If I’m writing code that only I need to understand then yes, typescript may be overkill (though I prefer types even then), but working on any meaningful codebase without types is… challenging. Types aren’t that hard are they?

I have, yes. From a team perspective, there's zero technical difference between TypeScript types and a combination of default args and type checker functions. The same ends are achieved, but in a far less kludgy way that's overt. In the event a type checker is missing, it can be added/documented quickly with zero time wasted on trying to answer "what's the TypeScript way to do this?" Types aren't the difficult part,…

>there's zero technical difference between TypeScript types and a combination of default args and type checker functions

I may be missing something, but aren't your type checker functions called at runtime whereas Typescript would be doing static type checking at compile time?

Post reply on HN