[moomoo11]

Have you worked on any project that had more than you on it?

More than 5?

What about an org of hundreds of people? What about thousands?

I think your sentiment of not wanting to use TS is fine if you are working on hobby code or at a small company that’s fine being in their lane. Where you are the guy, or you and a few others are the “dev team”.

When you cross into organizational efficiency concerns because you have hundreds of people across geographies, where you can’t just go get coffee with them to talk about how something can be refactored to be like the 10x engineer you follow on dev.to (sarcasm btw).

TS works for these kinds of companies. TS is great for enterprises.

JS is a shitty language if you never graduate past the realization that almost all languages and technologies are shitty in many ways. You’re being hired to fuel a business, not your ego. And without this business you’re not earning a living, and probably not one as great as the one you’d have yolo-wrangling horrible code only you understand. Your goal is to build something optimal given a bunch of limitations.

You mentioned Rust and Haskell. I don’t know if you’ve worked with these professionally, but the number of candidates for these roles is far less than TS/JS. I’ve never met a Rust engineer who was making peanuts. I’ve also not met a Rust engineer who was dumb. Nobody is going to use Rust (except hobbyists) to do what they would use something like node for. What problem are you solving? IO bound? CPU bound? Distributed workloads? Come on..

So understand why enterprises choose particular technologies. I can tell from your post you don’t have the level of experience you think you have.

And yes if I sound triggered it’s because I’ve interviewed too many combative people like this who can’t back up anything beyond feels or what someone else said. It’s nothing personal against you, it’s me.

Best,

[seattle_spring]

Exactly my sentiment. The only people I've met who are anti-TS are one of the following:

* Extremely opinionated people that are difficult to work with.

* Engineers who have only worked on smaller projects or codebases, and therefore haven't seen firsthand the real benefits of a typed codebase

* Non-FE engineers who just generally hate all JS-related stuff, and frequently opine that FE engineers aren't real engineers and have to re-learn the "latest fad framework" every year.

If I am interviewing someone and they start (likely unprompted) ragging on Typescript, there's a 95% chance one or more of the above bullet points describes them. Safer to move on to another candidate rather than take the chance that they're the other 5%.

[runnr_az]

I'm a senior dev who works on an app you've almost certainly used. Some of us just think the overhead of typescript is silly when you have react propTypes and whatnot.

In general, I'm an alpinist. Bring only what you need.

[satvikpendem]

Indeed. If I were interviewing a candidate like OP who starts ragging on TypeScript, I'd move them immediately into the "do not hire" pile. What you do in your own time programming-wise is vastly different to what you need to do working in an enterprise with many others.

[alldaysintoone]

The above experience is production experience where the decision to use JSDocs allowed us to focus on features over a TS rewrite, maintaining two codebases for multiple years with that strategy whilst vastly improving the type safety and documentation - from no types to full coverage and validation on the backend.

And prior to my current role I've used TS in production too.

Your response is exactly the sort of snap decision that I might have experienced.

And it's one that I find confusing in light of passion for type safety and type checking.

[satvikpendem]

TypeScript is also incrementally adoptable, not sure how you were able to add JSDoc comments for types to a function for example while also being unable to convert that same function to TypeScript. JSDoc is strictly less powerful than TypeScript in general. For example, more complex types as well as template literal types are impossible to have in JSDoc. It is simply more ergonomic to use TypeScript instead of JSDoc, and therefore, I stand by my snap decision.

[moomoo11]

Agree on all points.