Paul Cowan
Jan 15, 2020 ⋅ 4 min read

Is TypeScript worth it?

Paul Cowan Contract software developer.

Recent posts:

How To Integrate WunderGraph With Your Frontend Application

How to integrate WunderGraph with your frontend application

Unify and simplify APIs using WunderGraph to integrate REST, GraphQL, and databases in a single endpoint.

Boemo Mmopelwa
May 17, 2024 ⋅ 5 min read
Understanding The Latest Webkit Features In Safari 17.4

Understanding the latest Webkit features in Safari 17.4

The Safari 17.4 update brought in many modern features and bug fixes. Explore the major development-specific updates you should be aware of.

Rahul Chhodde
May 16, 2024 ⋅ 10 min read
Using Webrtc To Implement Peer To Peer Video Streaming In A Node Js Project

Using WebRTC to implement P2P video streaming

Explore one of WebRTC’s major use cases in this step-by-step tutorial: live peer-to-peer audio and video streaming between systems.

Oduah Chigozie
May 16, 2024 ⋅ 18 min read
Htmx Vs React

htmx vs. React: Choosing the right library for your project

Both htmx and React provide powerful tools for building web apps, but in different ways that are suited to different types of projects.

Temitope Oyedele
May 15, 2024 ⋅ 9 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.


  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