I love vanilla JavaScript, but I always try to switch to TypeScript if the codebase becomes larger than 100-200 lines of code. Or otherwise I may regret, and I know it too well from previous experiences.
When I hire devs, I don't care much about their previous stack experience, but if they've actively chosen JS over TS, it tells me their philosophy/priorities are completely backward.
This is a superficial take. TypeScript is not free. You are adding a compilation step that takes time, slowing down feedback in certain workflows, as well as a rather large dependency. It certainly can be worth asking why they chose JS given some of your perceived benefits of TS but not using it doesn't mean that their philosophy is backwards.
A one sentence comment about how the author is bad at programming says more about you than the author. People have been writing text editors like that for decades. They aren't bad programmers.
Also, using esbuild to transpile your TS will not actually check the types. It just transforms it back to JS. For typescript, you really need the official library which is slow and bloated.
It is free if your IDE uses the TypeScript language server and gives you errors integrated with your code editor. You don't have to transpile if you don't want to. You can, as you said, just use esbuild to strip away the type information.
> For typescript, you really need the official library which is slow and bloated.
See above. You absolutely don't. And it's not slow or bloated at all. It has incremental builds, which are essentially instantaneous after the initial build.
Indeed it will not check your types, but as stated elsewhere your IDE can do this for you. This is actually beautiful because it allows you to get correctness feedback on your code but your code will never fail to run due to arbitrary type complaints. If you later feel like you want the full correctness of TS, maybe during CI/CD, you can run the slower compiler and get a gatekeeper telling you if you are doing something fishy.
IMO every JS engine should just consume typescript (without type checking). AFAIK TypeScript is designed to be easily consumed by JS engines. It's a pity that V8 ignores that property.
I don't think it does, it comes with a TS compiler built-in, and "can run TS" by compiling said TS to JS and evaluating that. Deno is still using V8, so unless Deno has changed recently, it does not "consume TS" and no mainstream JS engine does.
There likely will never be an actual TypeScript runtime because that doesn't make sense as a concept, and it's against the philosophy of the project. TypeScript is metadata for devs.
That's fine, doesn't make the truth any different that it doesn't actually read TS without compiling it, as parent said.
> There likely will never be an actual TypeScript runtime because that doesn't make sense as a concept [...] TypeScript is metadata for devs
It does make sense to have a runtime for TypeScript directly. There is bunch of optimizations that can only happen after the runtime understands the type of the values, and if you keep switching the type of the variable value it'll be able to do less of those optimizations.
So you could probably end up skipping a lot of inference if the types gets shipped to the runtime as well as the rest of the source, vs just the source.
I've been using TypeScript in server-side, client-side, and hybrid projects for 8 years. Since then, I've inherited JS projects and felt like I was being forced to use a rock when I was used to having hammers. My take isn't superficial.
> You are adding a compilation step that takes time
The entire project is compiled only when testing or deploying. As far as testing goes, having static types dramatically reduces the number of times you have to run a program before shipping it. The net is that there's less time waiting for builds, not more.
And anyway, most projects compile in 2 seconds or less. There is a huge net time saving no matter how you look at it.
> slowing down feedback in certain workflows
This is incredibly vague. Which workflows? And why does it matter in those workflows?
The majority of feedback given by TypeScript is during the editing process, and that feedback is instantaneous because it comes from the language server and doesn't require recompiling.
> a rather large dependency
No. It's a dev dependency and doesn't ship with your code. You have to install it locally at some point, so I guess if a few MB of space is important to you, it's a problem. Otherwise it isn't.
O(1) setup cost for O(n2) productivity gains.
I think starting in JS and then migrating to TS is a very good strategy that lets you develop fast but once you figure what you needed to wrtie let's you get additional assurances and conveniences about what you wrote.
I would take Emacs Lisp over Typescript any day, but that's just me.