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:

Guide to Using TensorFlow in Rust

Guide to using TensorFlow in Rust

We explore the fusion of TensorFlow and Rust, delving into how we can integrate these two technologies to build and train a neural network.

Rosario De Chiara
Feb 22, 2024 ⋅ 8 min read
Using Signaldb With React

Using SignalDB with React: A complete guide

SignalDB enables automatic data synchronization between your components and a local in-memory or persistent database.

Antonello Zanini
Feb 20, 2024 ⋅ 6 min read
Guide To Next Js Layouts And Nested Layouts

A guide to Next.js layouts and nested layouts

Understanding how layouts, nested layouts, and custom layouts work in Next.js is crucial for building complex, user-friendly projects.

Ibadehin Mojeed
Feb 19, 2024 ⋅ 12 min read
Extracting YouTube Video Data With OpenAI And LangChain

Extracting YouTube video data with OpenAI and LangChain

Extract YouTube video data using OpenAI and LangChain for quick, cost-effective insights without watching the videos.

Carlos Mucuho
Feb 16, 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.

    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