Live data from Hacker News

Ask HN: Is TypeScript worth it?

news.ycombinator.com

141–150 of 469 posts

Re: Ask HN: Is TypeScript worth it?

#141
This post is a joke right? The world has moved on. JS *is* the target, but it is *no longer* the source.

There is so much more to software development than the how quickly one can vomit code into their editor of choice. If typescript is slowing you down, your code is *bad*. End of story.

Continually pretending that types don’t matter is laughable. The thousands of dynamic language projects with littered with type-hints, type-assertions, and type-verifying unit tests proves otherwise.

Re: Ask HN: Is TypeScript worth it?

#142

As i said before, a lot of people expect that writing typescript is as easy as writing js, which is not. I estimate the typescript tax to be around 40-100% more time, especially if you want to do typescript right and not use `any` all over the place. And besides, typescript is a poor fit for someone who is used to writing highly dynamic, lambda based code, which is one of the main niceities of js. My guess is that a…

These estimations are pure imagination. I doubt you have `any` real data to support it. Also, that is not the reason why Typescript was created, nor the reason why people adopt it, not even what Typescript really is. Today, almost every Node.js framework supports Typescript out of the box. I challenge you to provide a modern framework that doesn't provide types. And this is not an opinion, nor it is wishful thinking,…

Strongly typed languages already did take over the software development paradigm. It happened when Java, C++ and C were the dominant languages. Then it regressed back to dynamically typed languages as ruby, php, python and js skyrocketed into popularity.

With the advent of typescript and other things like it... types are now back in vogue but for how long?

The universe is a four dimensional loop. Programming, like history, like life, moves in an endless flat circle. It's all so predictable... Because This ENTIRE thread represents a precursor to the inevitable and impending oscillation back to the beginning of the circle. Types will fall out of vogue and history will repeat.

Re: Ask HN: Is TypeScript worth it?

#143

100% worth it to me. I love typescript. Working on large enterprise applications where one function calls other function and it goes 10+ layers deep I don't know how I would work without typescript. Just being able to see this function takes argument of type FOO and returns type BAR[] is incredibly valuable.

That's a lot of layers for a codebase... I see that it could be useful in that situation, but since you presumably need to test and QA your code anyway you could also throw in a console log statement.

There is also JSDoc.

Although these solutions might not be quite as nice, I'd wager they'd save quite a bit of headache and time.

Re: Ask HN: Is TypeScript worth it?

#144
I love TypeScript in the right places, but I think it’s often used for things where other tools would be a much better fit.

On the backend it can be nice if you’ve got a monorepo including the front ends it supports. Maybe you’ve got graphql happening and you can share types. That seems great sometimes, and there are cases where it’s super handy and efficient.

I don’t know for sure, but it doesn’t seem worth it after a certain point. I’d much rather keep typescript to the front end where I find it really shines. I’ve worked on a lot of projects where it was full stack typescript and there were always these common, nagging, very typescript-and-JavaScript-specific problems.

Fundamentally the build and development tool chains in general tend to be awful. I can accept it on the front end out of necessity, but on the back end it gets egregious quickly unless you’re using micro services and builds stay quick by default.

Any time I work on something statically typed with nice tooling I realize how much better life can be. It feels like the minor gains I get from fullstack TS are quickly negated by the plethora of advantages to using something like Go or Rust where I can purpose-build applications with absolutely crazy performance, reliability, and portability.

So, TS in the browser is awesome. I think you’d be crazy not to. On the backend on the other hand — unless you’ve got like a perfect fit for using something like Next.js or a static site generator where the backend can be dead simple, I’m pretty tired of dealing with its deficiencies.

And even then it’s not the language so much as the cruft built up in tooling over the years. It’s slow and awkward. NPM is plain old awful. Basics like linting are painfully slow. Testing libraries feel like a house of cards. And so on.

Re: Ask HN: Is TypeScript worth it?

#145
post #114

#1 – You don't have to upgrade TypeScript versions till you are ready, and newer versions never have breaking changes anyways. The syntax remains strictly compatible with ES6 and beyond. Packages you consume publish compiled JS and aren't dependent on specific TypeScript versions at all. #2 – If libraries haven't published types, just use them as pure JavaScript (which is what you would have done anyways). Lack of do…

[deleted]

Re: Ask HN: Is TypeScript worth it?

#146

This post is a joke right? The world has moved on. JS *is* the target, but it is *no longer* the source. There is so much more to software development than the how quickly one can vomit code into their editor of choice. If typescript is slowing you down, your code is *bad*. End of story. Continually pretending that types don’t matter is laughable. The thousands of dynamic language projects with littered with type-hin…

Good code takes a lot of thought and care, and won't materialize just because you use static typing.

So why am I spending so much time applying static typing instead of thinking about how the code should flow, about what's the best abstraction, writing thorough documentation.

Typescript comes at a much higher cost than built in static typing, and I don't think it's worth the investment.

Re: Ask HN: Is TypeScript worth it?

#147
Having spent the last two years back in JavaScript, and in the process of moving a >10y project to TS as a part of a larger refactor, emphatically yes it’s been worth it. I have been hanging on to tsserver to bridge the gap for two years, and well… it’s night and day.

I can add ~95% of the same safeguards without it, but I’ll spend a lot more time doing so and it’s a lot harder to get buy in to make them stricter than my own editor.

> For example, a new package you install can require a new TypesScript version. Once installed, you then may need to update your source code. This can place quite a high tax on the developer, where perhaps a 10 minute change becomes hours long.

If your project is already strict and if you generally have a good sense of the areas TS doesn’t cover, you probably wouldn’t need to update anything for the last couple years. If your project isn’t strict, you’re probably benefitting from updates more closely matching the semantics you wanted in the first place.

> Most libraries do not document their types, or have no examples using TypeScript. Some worst offenders: Apollo, Protobufjs. The type definitions exported by these libraries can be large and complex, and the error messages emitted by TypeScript are so long and cryptic the result is often a drawn out process of trial and error along with trawling through source files.

It’s fairly trivial to add local type defs if you’re at all interested in the type safety it brings. They’re almost universally easy to transfer to PRs for DefinitelyTyped (which admittedly I should do more often, and I should open a few after I land this work in my project).

> Errors are long and don't provide enough detail. They will explain a type mismatch referencing many types you may not have ever seen, and are not documented anywhere. Except for simple errors, many of them are very hard to follow to a remedy.

This is true. You’re right. If you want a little helpful pointer:

  type Debug = [AnyType] extends [never]
    ? 'My understanding of AnyType failing'
    : AnyType
Edit: this ^ was typed on my phone from recall and I’m tired and might not be quite right. I’m happy to revise it tomorrow if that’s the case.

It’s not great but it’s basically a very slow way to walk up the type resolution stack until you find what doesn’t behave the way you expect.

> Transpilation takes time, and always adds a burden to developers. I didn't mind so much with ES6 etc because eventually many functions were included in a broad set of browsers. There doesn't seem to be much progress including TypeScript in a browser, and feels like these complicated transpilation steps could be with us for a long time.

ESBuild, Vite, SWC and such have basically made the build step instantaneous. They’re not without config woes, but they’re worlds better than what came before. So much so I will volunteer to help you set up a project’s build if you do the very easy legwork to find any number of ways to contact me.

Re: Ask HN: Is TypeScript worth it?

#148
For ii.) Typescript is a superset of javascript. If it annoys you to try to translate JS documentation into TS, then don't. Just use the JS example and use ts-ignore or something similar. Why throw out TS when you can literally suppress those one-off instances?

iii) You should see C++ template errors if you think the TS errors are bad. The TS errors do suck sometimes, but when I see which line of code it's complaining about, it's usually enough to clue me in to what the problem is. And once again, ts-ignore exists for a reason ;)

iv) The majority of the frameworks I use allow you to skip transpilation while developing. So you can supply the TS files directly, and then transpile when you're done.

TS has some problems sure, but these all seem like very surface level complaints that you have to deal with in any other language. Which language has dependency management solved? Or clear and concise error messages all the time? Or super fast compile times? I don't see any alternatives that don't host some or most of all of these warts.

Additionally, when I code using Javascript I feel like I'm blindly groping my way through the magical forest of dynamic code. Typescript gives me a clear and concise road map and helps me avoid a lot of traps laying around that are obscured by that dynamic magic.

Is typescript worth it? 100% yes.

Re: Ask HN: Is TypeScript worth it?

#149

Earlier quoted context omitted.

> ii) Lots of libraries are extremely well documented and typed. This is the same in any language not just for types but also for docs, capability, perf etc. This argument applies to all software everywhere so it doesn't make sense to single out TS I am singling out TS because although most good libraries have documentation for all of their methods, along with examples, many useful and popular libraries do not includ…

> many useful and popular libraries do not include full documentation of their types > but many authors choose to show their examples in JS, in order not to be too opinionated This is certainly true sometimes, but I don't see why it's a reason against using TypeScript? If you're calling a TypeScript API, the way you use it should look basically the same as the way you'd use it in JavaScript. You usually don't have to…

I am thinking of the case where you are passing an object or class to an API that needs to be shaped a certain way. In this case you need to know which type to import/use to pass it through.

For many simple libraries it's not too much of an issue, but for more complex things like Apollo (which also doesn't include much TS in their docs) it's a lot of hit and miss until you get it right.

Re: Ask HN: Is TypeScript worth it?

#150
post #81

Earlier quoted context omitted.

Same here, I've found it very useful in projects where I don't have a lot of dependencies. In another project with more exotic dependencies, it has become a hassle somewhat. I've found learning the .d.ts syntax to help easily get out of a situation, but it was a learning curve I still run into sometimes.

I find that I just make the .d.ts files any types I could document types for that module, but I don't, and instead assume types as the output of code I have that interacts with them

I add more thorough types for dependencies than for my own code, specifically so I don’t oops myself on other people’s code I’m less familiar with.
Post reply on HN