2020-01-15
1245
#typescript
Paul Cowan
12532
Jan 15, 2020 ⋅ 4 min read

Is TypeScript worth it?

Paul Cowan Contract software developer.

Recent posts:

Nx Adoption Guide: Overview, Examples, And Alternatives

Nx adoption guide: Overview, examples, and alternatives

Let’s explore Nx features, use cases, alternatives, and more to help you assess whether it’s the right tool for your needs.

Andrew Evans
Mar 28, 2024 ⋅ 9 min read
Understanding Security In React Native Applications

Understanding security in React Native applications

Explore the various security threats facing React Native mobile applications and how to mitigate them.

Wisdom Ekpotu
Mar 27, 2024 ⋅ 10 min read
Warp Adoption Guide: Overview, Examples, And Alternatives

warp adoption guide: Overview, examples, and alternatives

The warp web framework for Rust offers many enticing features. Let’s see when and why you should consider using warp in your projects.

Ukeje Goodness
Mar 26, 2024 ⋅ 8 min read
Integrating Next Js And Signalr For Enhanced Real Time Web App Capabilities

Integrating Next.js and SignalR to build real-time web apps

In this tutorial, you’ll learn how to integrate Next.js and SignalR to build an enhanced real-time web application.

Clara Ekekenta
Mar 25, 2024 ⋅ 8 min read
View all posts

11 Replies to "Is TypeScript worth it?"

  1. TypeScript’s type system isn’t sound, but it sure is pragmatic. I love the balance they strike with it tbh.

  2. Great article. Just one small nit… You say

    You can blast the types out of anything with an any cast

    Typescript calls these Type Assertions, not casts, as they are slightly different. From their docs:

    Type assertions are a way to tell the compiler “trust me, I know what I’m doing.” A type assertion is like a type cast in other languages, but performs no special checking or restructuring of data. It has no runtime impact, and is used purely by the compiler. TypeScript assumes that you, the programmer, have performed any special checks that you need.

    https://www.typescriptlang.org/docs/handbook/basic-types.html#type-assertions

  3. yep agreed, not having runtime checking is a huge weakness but if you remember JS world before FlowJS and TypeScript it’s definitely a huge leap in the right directionb.
    Give https://elm-lang.org/ a go, you might be pleasantly surprised 🙂

  4. “TypeScript does not guarantee any runtime type checking”

    This is also true if you rely on external Javascript libraries which are delivered with inaccurate types (not auto generated). Another true negative in safety.

  5. I’m concerned that it is dividing our community and adding to workflow (JS repos needing to add TS constructs).

    I think the right solution will eventually be WASM, where TS would cleanly separate from JS.

  6. > I think this is possibly the biggest problem with TypeScript, as soundness is not a goal. I still encounter many runtime errors that are not flagged by the tsc compiler that would be if TypeScript had a sound system.

    You’re basically alluding to having the same capacity as Rust’s borrow checker. This is a tall order when ultimately the runtime model of the tsc output is JS (…..a dynamically typed language). I’m not a compiler engineer, but I don’t even know if that’s possible to do at all.

    Obviously tsc was never going to be sound. It was a nonstarter from the beginning.

  7. the failing examples are basically “typecasts” e.g. let x: number = a.x; // unsound. best to use type inferrence instead. if you use typescript’s type inferrence to the maximum extent, you will catch more errors. doing explicit typing forces typescript to say “ok you’re the boss”. one big complaint I have is @typescript-eslint has a default called “explicit-function-return-type” https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/explicit-function-return-type.md it’s actually better if you don’t specify the explicit return type, because you will literally fail to create a better explicit return type in your code than the typescript’s inferrence can. furthermore, if you do need it explicitely somewhere, you can say ReturnType

  8. > What this means is that there is no guarantee that a variable has a defined type during runtime.

    Kind of a difficult thing to blame TypeScript for. After all, it’s based on the abomination called JavaScript, which doesn’t give a shit about any practice established decades ago. Now the web dev community is rediscovering these things instead of just throwing the bullshit language out of the window once and for all.

    bUt MaH bAckWarD cOmPatIbIliTy aNd bReAkInG thE wEb!!!11 Imagine where the gaming industry would be today and what kind of games we’d play if we cared that they worked on Commodore 64. Because, you know, 0.001% of people might still use it and you need to be inclusive in your design and all that. You have system requirements for certain type of things. Wanna play this game? You need at least 4GB of RAM, a solid GPU and (probably) Windows. Or a console. But you wanna look at this website on your Internet Explorer 11 and Windows XP? Sure, lemme completely destroy the code in order to allow you to open it!

    Drop JavaScript, create a proper language which supports what UI development needs and we’ll stop having a blog post every day about TypeScript vs Flow, React vs Angular, etc. Instead we’ll simply use the thing, instead of building a whole bunch of tools just to forget the fact that under the hub it’s all JavaScript.

Leave a Reply