Live data from Hacker News

Ask HN: Is TypeScript worth it?

news.ycombinator.com

21–30 of 469 posts

Re: Ask HN: Is TypeScript worth it?

#21
I'd say for most people, beyond small scripts/cli/micro-microservices, the ceremony of setup/environment overhead for it is worth it, and continually pays dividends. You can usually copy-paste a common config file around to bootstrap.

Most of your (pretty good actually) critique are points to make the least-bad way of doing JavaScript even better, and I'd agree could be improved.

Others have taken notice.

"Native support" of TypeScript is done by Deno. And tight TypeScript (and other adjacent tooling) integrations with VS Code and WebStorm.

And transpilation is being worked on by various builders. Stripping types and running through esbuild or swc is fast. For typechecking part, was a proposal to have TypeScript be rewritten in Rust for performance.

We can lament that JavaScript went from being a web document enhancer to being shoehorned into a full application compilation toolchain, but the old Jquery thru Expressjs era of doing things has significant drawbacks for full sized applications/APIs/etc.

Re: Ask HN: Is TypeScript worth it?

#22
I'm with others (it's worth it when there are more people / the code needs to be correct), but the example of Protobufjs is unfair: I expect it to be super complicated to work well with Typescript. TRPC is growing for a good reason.

Re: Ask HN: Is TypeScript worth it?

#23

> I want to skip over the static typing benefits argument, because I think it is well understood that static typing is a good thing and if we could bless JavaScript with a built-in and robust typing system then I don't think many people would be against that. My issue is with the amount of extra work it places on developers, much of it the "dumb" kind of work which can eat up hours and doesn't deliver all that much v…

Doesn't your counter-argument beg the question whether it is indeed 20% BS vs. 80% value? I think the OP is asking about pretty much that percentage. Personally I feel it's more like 70% BS vs. 30% value. Types, after all, are a very weak ontology, i.e., you still cannot know for sure that just because your code compiles it interprets the values it's getting from other party's code correctly. I would even argue that it may create a false sense of safety -- just think of the Mars satellite that crashed because some developer thought a number was in imperial units when, of course, it was in SI.

Re: Ask HN: Is TypeScript worth it?

#24

Of course, there's more than one way to build a good product. Personally speaking, I'd say that adding another layer of abstraction onto your stack shouldn't be a dogmatic thing that you just reflexively do without considering the actual needs of a particular project. TypeScript offers some benefits for certain types of complex projects, but also some costs and problems that might not be worth dealing with for certai…

Could you describe the costs and problems that might be considered not worth dealing with?

Re: Ask HN: Is TypeScript worth it?

#25
The whole shtick (and beauty) of Javascript is that it is a dynamic language. In some point in time corporate Java people started using JS, and now we have this : "is well understood that static typing is a good thing". It's not. But as always you have a vocal minority, influencers and evangelists shouting their BS, about how TypeScript has terraformed theirs lives and they can't imagine life without it.

Use your head, if you don't like TS, don't use it.

Re: Ask HN: Is TypeScript worth it?

#26

    I want to skip over the static typing benefits argument, because I think it
    is well understood that static typing is a good thing and if we could bless
    JavaScript with a built-in and robust typing system then I don't think many
    people would be against that.
Well, yes. That's what Typescript is. If a built-in and robust typing system were added to Javascript, it would be the same thing as integrating Typescript into the ECMA spec. for Javascript.

EDIT (some more thoughts):

    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.
Yes, that's not very different than upgrading to a new version of e.g. Python or Ruby on the back end. The problem is that you're seeing Typescript as "just a framework", rather than a compiler/interpreter. If you view upgrading Typescript versions the same as e.g. upgrading Python or Ruby versions, and plan for it accordingly, then you'll at least have the correct expectations regarding the scope of work, even if the actual work to do isn't any less.

    Most libraries do not document their types, or have no examples using
    TypeScript.
If a type system were integrated into Javascript itself, it would have to be optional, in order to maintain backwards compatibility with the vast untold billions of lines of Javascript that are out there. Thus, you'd have exactly the same problem. It's very difficult to add a typesystem to a language after the fact.

    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.
Poor error messages are an issue with any type system that allows generics. Typescript's error messages are, at least in my experience, better than C++'s error messages. I find this remarkable, given that C++ was designed as a typed language from the beginning, and Typescript has, as one of its design constraints, strict backwards compatibility with Javascript.

    I referred to TypeScript as a framework which it isn't. However it feels
    similar to me in that you are at the whim of TypeScript developers and how
    they decide to progress with the language.
That's true of any programming language, Javascript included. If you're writing Java, you're at the whim of Oracle. If you're writing C#, you're at the whim of Microsoft. If you're writing C++, you're at the whim of the C++ standards committee. If you're writing Python, you're at the whim of the Python Steering Council (and you used to be at the whim of Guido Van Rossum). Every programming language has some person or committee that's in charge of it, and if you're choosing to use that language, you're implicitly accepting the decisions made by that person or committee.

Re: Ask HN: Is TypeScript worth it?

#27

> It's a framework, with all the usual framework downsides > 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. No. It's a language compiler. You can upgrade it safely without changing a single line in your codebase. If there is…

> No. It's a language compiler. You can upgrade it safely without changing a single line in your codebase. If there is a breaking change (sometimes, regarding the strictness) there's also a configuration option that lets you keep the previous behavior. I am currently stuck on a very difficult issue because of a TypeScript upgrade. The upgrade caused a type mismatch with a dependency that wasn't previously an issue, a…

Did you upgrade Typescript (and if so, why), or did you upgrade some project dependencies, or type definitions?

> No documentation of types means going into source code to see what is there. Sometimes there could be multiple types that could be used for something, and it's not clear which should be used.

I haven't had this experience, and I'm not super experienced with Typescript. Are you using VS Code? It typically makes it trivial to find the definitions of things I'm interacting with in the editor.

Re: Ask HN: Is TypeScript worth it?

#28

I find TypeScript very helpful! As a self taught developer I always used to just use JavaScript, but after joining a big company and working with TypeScript I prefer it now. I like how I always know "what's in the box" now when working with different objects and whatnot.

I think you need to be very careful there. Only because something is, e.g., a number, does not mean you know what it represents. I think Typescript might actually create a false sense of safety.

Re: Ask HN: Is TypeScript worth it?

#29
post #16
post #9

I don't have a lot to add except that my experience with it has been very positive; your complaints are mostly valid, but for me those pain points disappear in the shadow of all the things I no longer have to spend time stressing about or debugging

So much this. If you’re learning JavaScript or any components of the language, you’re better off just starting with typescript (given the technical acumen up front). It’s absolutely a no brainer, long term roi. If presented the opportunity to integrate or use now vs later. The community is also very active, and it’s under Microsoft - and has been well maintained and quite active. Lots of libraries.

> you’re better off just starting with typescript

It depends. The tooling is still a barrier (even though it's gotten smaller); the cost is small for a real project, but for someone who's learning and knows nothing about the ecosystem, it could be a real obstacle to dive all the way in at once. The exception would be if you're starting with something like Deno that integrates TypeScript seamlessly. Outside of that, tools like esbuild have significantly lowered the bar vs a few years ago when you had no choice but to configure webpack + babel. But even esbuild isn't quite zero-configuration

Re: Ask HN: Is TypeScript worth it?

#30
The question of whether it's "worth it" really boils down to you and your specific requirements.

Even within the same project, there are times when I don't want typechecking - when I am prototyping something out and want to move fast.

And there are other times, when I want typechecking - when I am finalizing a feature implementation or doing integration with existing logic etc.

It's not a framework. It definitely is a language in its own right.

But from personal experience, the group productivity goes way up with larger codebases with many ICs working on it. Unit tests become type checks. It opens up a lot of extra bandwidth for more sophisticated functionality or better tests.

Solo IC, working on a small project, with no intention of ever writing tests - you might see TS be an overhead.

To sum up, your requirements decide whether it's worth it.

Post reply on HN