Inconvenient Truths about TypeScript

I strongly disagree. Nothing is worse than developers being forced to work in a language they are not used to - not just because it's inefficient, but because they won't write it in an idiomatic way.

If all you have are TS developers, writing a CLI in TS is not just fine, it's the right decision. Forcing Rust upon them is not going to make anyone involved more happy.

Basically every language is a better option then TS for non frontend tasks.

It's fine if you don't like JS, but it speaks to a bias or lack of experience if you think Zig is a better tool. Maybe it will be one day, but it's a flat out unfinished language with numerous bugs.

I was with you when you said command lines, but servers? JS is a fine choice for servers. I haven't seen Rust do anything on the server but slow people down, and I have found people who think they know Rust don't really

Plenty of people are productive in JS, and when working with ES6, it can even be comparable to immutable functional languages. It's on the team if they aren't reviewing code or are allowing bad habits.

If you use TypeScript on the server and client, you can define object types (interfaces) just once, which makes it a lot faster to write. If you use anything else you lose out on this luxury.

> If you have to use Javascript (you're building the front-end of a web app), then it seems like Typescript is probably a decent solution.

Why choose Typescript over any of the other hundreds of languages that transpile to JavaScript?

A programming language is a tool to get to the desired outcome. The 'best' programming language is one that allows me to get to my desired outcome the quickest, with the fewest bugs and highest maintainability.

For me (and, I would argue, for pretty much everyone), that would probably be whatever programming language I am most familiar with. Unless the language has huge barriers compared to another one I am somewhat familiar but less familiar with.

I wish the dogmatic hate on JS would stop, it was boring 10 years ago, it's still boring.

> Go, Rust even Zig

Of all the languages you could pitch to someone already familiar with JS these would be at the bottom of the list. You want something dynamically typed, well trodden, and with a huge package ecosystem which to me sounds like Python or maybe Ruby. But honestly JS minus mountains of tooling is a really good general purpose language.

Use the right tool for the job, not the meme tool for the job.

Zig may be useful in some contexts but it’s also in beta and it has a bus factor of one.

Rust is unnecessary for most projects that don’t need the extreme degree of efficiency it offers and would rather have a GC do all that work for them.

Go is fine, if you get along with it. Many people don’t like it because the type system is from the 1980s, but if you like that kind of thing then go ahead.

I think, if you write server code / command line apps. It is better to choose for Javascript over Typescript, so you don't have the translation, and you know the system where you running on, and you can build for that Node version. Typescript makes it indeed too complex, keep it simple with just Node.js without a build step, or use indeed another language like Go or Rust.

I have no dog in the game, I love plain Javascript as my second programming language and have limited knowledge of TypeScript. That said, please look at the large set of CLI tools that have already been created in Javascript. It's not inappropriate language for the job by any means. Even portions of NPM and Node are written in Javascript. Grunt, Bower, Angular CLI etc. are just a few examples of CLI tools in Javascript.

> For anything else it (or any form of Javascript) isn't the right tool for the job, in part for the reasons outlined in this post.

I genuinely don't understand how someone could make a statement like this. You mention command line apps and servers, but surely whether TS is the best solution would depend entirely what you're trying to achieve. If there's a great NPM library to help you with the problem you're solving why wouldn't you use TypeScript?

Not to mention the fact that TypeScript servers when paired with web frontends have obvious advantages. One project I worked on involved analysing 3D objects then visualising this on a web app. The simplest solution we found for visualising the analysis we were doing on the backend was just to build it all with Three.js and TypeScript then use common libraries.

I'll also note that good JS developers are generally competent enough to avoid "bad habits" and that "bad habits" in my experience are not isolated to the JS ecosystem.

That you suggest Rust and Zig as alternatives suggests to me that you may not understand the requirements of a typical web application. These aren't usually CPU-bound apps that benefit from running close to the metal: the main bottleneck is DB queries and requests to other services. Adding all the complexity of the borrow checker isn't usually worth it unless your devs are already fluent in Rust, and using an early-stage C replacement like Zig would be an odd choice.

Here are the criteria I'd use for choosing a language for a web server, in order of importance:

1. What does my team already know?

2. What languages have a robust ecosystem of web-related libraries?

3. Static types are better than dynamic if the team is larger than 1 or if the project will last more than 6 months.

Performance considerations might come in after this if there are still two languages left to decide between. But judging from those criteria, I think you can see why TypeScript would not be a bad choice for a full stack web team.

> Go, Rust even Zig are better choices

This is a joke, right?

But do those languages have conditional types and template literal types, two great TypeScript features I now can't imagine programming without?

Wow I'm going to get downvoted for saying this, but Typescript lets me write, scale and maintain apps without writing tests.

It's enough knowing client/server types move together, avoids null/undefined/[]/0/falsy edge case bugs, param/return mismatches, etc.

As he's written a few books about it, unless he exaggerates, the books may look boring but the reality is, JS/TS isn't as bad as he wants to exaggerate.

So, the better advice is, real world can't be perfect, live with it and move on than complain. If you have so much to say, you're better off contributing to the project.

> JSON.parse returning `any`s

How do you type it?

With the way its type inference works, it's probably the least verbose type system out there.

I'm not understanding the point.

In every single decent language with a static type system you'll have to convince the type checker that data coming from outside the boundaries is of a certain shape by parsing it. If you're not doing it, then you are implicitly assuming it's of some type and you risk runtime type errors.

E.g. in Elm you do have to parse every single thing coming in from outside the boundaries both from http requests or other external ports.

It's not a must, you can absolutely model IO and roll your own class validation/serializers methods and get both build time type safety and runtime validations without including a library for it. It's typical old school JS style validation we've done for decades with just some stylistic adaptations to stay type safe.

However, grabbing Zod or io/ts is a lot less work and with tools like https://quicktype.io/typescript or https://transform.tools/json-to-zod you can paste in an API response, copy over a validator and export a type. My homegrown validator classes won't be nearly as clean or as quick.

Only in legacy code we haven’t replaced yet as we switched to TypeScript a few years ago. We don’t upgrade the flow dependency anymore either.

> When you write in Typescript, it generates some Javascript that is sometimes hard to recognize as your code.

Every time I have tried to compare the output of `tsc`, I have reached the opposite conclusion.

It's incredibly faithful most of the time. And when not, it's consistent. So if you understand why it does what it does once, life becomes much easier.

Perhaps you are referring to minified code. Even then, with source-maps correctly setup, I rarely if ever have a reason to leave TypeScript-land.

Without the type-checker, my productivity (and sanity!) would likely be cut in 1/2 or more.

I'd be very interested in examples that resulted in your opinion.

That depends on what you mean by "better". What's your goal here?

Better than what, and in what way?

A single executable would be easier to deploy/version/sign. You could in theory also make a bundle with typescript/javascript files as well. It would be no different from deploying a WAR file on a server running JAVA.

Do what is the easiest for you and your team.

Compiling to a single executable like Go and Rust and Haskell do, has a bunch of benefits for a server. Notably, it used to be the case (before the container revolution) that if you used a scripting language like Python, say, you had to carefully pip install all your dependencies identically between your prod and staging and test environments and your local dev env. Scripting languages have this nasty habit of preferring to not break, they will start a script without having all of its dependencies in the hopes that by the time the dependency is actually used, it will have been installed dynamically. This is also why wizened programmers from those cultures write so many damn tests, because if there is a dependency that does not get exercised at test time then you might have a prod outage on the weekend when some user figures out how to exercise it, etc.

In other words you can view the rise of Docker as saying, “give me your scripts and I will give you this magical unicorn called a container image, which can be used to run your script like a single executable.” People did not use Docker for its security features (the people who cared about that used VMs before Docker and put Docker into a VM after), but for its operational feature. If anyone had understood this before the rise of Docker, I think they would have architected Docker differently: multiprocess containers and weird networking stacks could have been done away with, you would probably not throw all of the OS into the binary because that's overkill (just Terraform-like “providers” or so?) ...also Docker needs to run as root to establish its tentacular spectacular: if you had viewed the goal as packaging the scripting language as a virtual binary you probably wouldn't need this stuff.

If you are running a large enough company then you need something like kubernetes because you have thousands of developers all needing to deploy on to the same prod hardware clusters. Cloud computing generally tries to lump you into this bucket too. In those cases there is no difference.

But if you are running a small dev shop of less than 20 devs at a larger 100-300 person company, now prod is whatever Casey your sysadmin says it is, and Docker is forbidden by some policy that you can't run as root or so, so now it's easiest to just compile static binaries and then build a lightweight gitops thing out of that, put an NginX server in front (except Casey gets mad and makes you use Apache) and some FastCGI and with a bit of luck you can get it so that if the build or tests fail, the system sends you an email via nagios but keeps humming along with the old build. It's a few weeks of work and you'll complain to every dev you onboard “I'm sorry this is all held together by duct tape” but it'll chug along fine until that company becomes 5,000 strong and you have 500 developers and can afford to containerize or shift to cloud for new applications and "do it right".