hate-typescript.md

Why I hate TypeScript

Warning: These views are highly oppinated and might have some slightly incorrect facts. My experience with typescript was about 2 weeks in Node and a week in angular2.

Not Standard

TypeScript is implementing their own take on JavaScript. Some of the things they are writing will likely never make it in an official ES* spec either.

Technologies that have competing spec / community driven development have a history of failing; take: Flash, SilverLight, CoffeeScript, the list goes on. If you have a large code base, picking TypeScript is something your going to be living with for a long time. I can take a bet in 3 years JavaScript will still be around without a doubt.

Its also worth noting that they have built some things like module system and as soon as the spec came out they ditched it and started using that. Have fun updating!

It should also be worth mentioning that this language has been around for a long time and only recently gotten popular because of Angular2.

Not Community Driven

There is no community really driving the language itself. From what I see, random new things end up there with little to no community feedback. I could be wrong here, but I just don't see it much.

Types in a non-typed language is hard

Its like trying to fit a square into a circle hole. A lot of the ES6/7 things I try to do don't work at all and will likely never work with the way some of the types work. I think it should be JS first and then types not the other way around.

It probably doesn't help that the main people that wrote this weren't big JavaScripters before they started but thats just my personal thought.

Babel is way better

Babel is the ****! The plugin architecture system is amazing idea! I love being able to get community driven plugins ( Even if they might not be standard thats the risk I accept and am ok with ). I can target multiple environments ( node 4,5 / browser ). Plus, they are implementing specs and even if they are stage-0 and change, they are atleast some spec and i can run that plugin until I can update too.

I've been watching some of the targeting issues and they are pretty far out, TS on Node seems like a great fit, why not get that going asap?!

Babel is just SOOO far ahead ... The fact that people are using Babel and TypeScript together is a huge flag that TS needs to up their game.

TypeScript Definitions

Um, why do I need to mock fake TSDs for things that aren't TypeScript!? Your creating more headache, work, etc. This should have been addressed in v0!

No idea what language features I can use

I hit this all the time, I had no idea what ES* features I could use and what I couldn't. I spoke about this on a issue and they said they are only doing stage-3 but they have other things that are stage-0?

They lie

I think I've heard about 100x you can use as much or as little of it you want. Ya, good luck. Having to put any everywhere is not my idea of that statement.

What about flow?

I do generally like the approach FlowType is taking.. they put JS first and then lay types on top. Also, I can use babel to compile it and its not as much of a plunge into a java/c# like language.

TS and Babel are doing similar type declaration syntax so its a safer bet that might be included in a upcoming spec and if it doesn't you can always use babel-remove-flow-types ;).

if you @joetidee are referring to: https://github.com/tc39/proposal-type-annotations then i can say that it honestly sucks
it dose not bring in types to the language, it's just annotations / comments

it would just slow down the parser.

🧨 Why proposal-type-annotations Is Fundamentally Flawed

The current proposal-type-annotations adds new syntax to JavaScript without adding any semantic value — and comes at significant cost. Below are key reasons why this proposal is problematic, and why ecmascript-types represents a far better direction.

---

❌ Issues with proposal-type-annotations

1. No Runtime Value

Type annotations in this proposal have no runtime effect. They do not enforce type safety or throw errors. Developers may be misled into thinking their code is safer, while bugs (e.g. passing undefined where a string is expected) still happen.

2. Zero Performance Benefits

Unlike proposals like ecmascript-types, this proposal cannot be used by engines to optimize code. Instead, it adds overhead — the engine must parse and discard type information, wasting CPU cycles with no payoff.

3. Breaks Backward Compatibility

Using this syntax in .js files makes code fail to run in all current and older JavaScript engines. This forces developers to use a build step even when types are semantically ignored — a contradiction in terms of progressive enhancement.

4. Redundant with JSDoc

JSDoc already allows developers to specify types in .js files:

• Works in all engines (types are comments).
• Supported by IDEs and static analyzers.
• Requires no new parsing rules or engine complexity.

This proposal brings no improvement over JSDoc, while creating compatibility and tooling headaches.

5. Increases Parser Complexity for No Semantic Value

Engines and linters will be forced to support a new grammar that produces no runtime result. This goes against the design principles of JavaScript — simplicity and gradual evolution.

6. Blocks Future Real Type Systems

Locking in a syntax that explicitly discards type information may make it harder to later introduce a real, meaningful type system. It bakes in the idea that “types do nothing” into the core language.

7. No Path Toward Runtime Safety

There’s no mechanism in this proposal to evolve toward runtime validation or enforcement. It’s a dead end for anyone hoping JavaScript will eventually support native, enforceable types.

---

✅ Why ecmascript-types Is a Better Direction

1. Runtime Enforcement

ecmascript-types introduces types that are validated at runtime. Passing a wrong type throws a TypeError, just like other core JS errors — providing real safety without tooling dependencies.

2. Performance Gains

Engines can use the type information for:

• JIT optimizations
• Dead code elimination
• Inline caching

This makes typed code potentially faster, unlike the type-annotations proposal.

3. Optional but Meaningful

Developers can choose where and when to use types. When they do, the types actually mean something. This aligns with JavaScript’s opt-in philosophy.

4. Real-Time Feedback

With runtime types, developers get immediate feedback when something goes wrong — even outside of an IDE. That’s powerful for debugging and correctness.

5. Evolvable and Future-Proof

ecmascript-types lays the groundwork for future improvements:

• Gradual typing
• Optional type inference
• Static analysis enhancements

It doesn’t block further progress — it enables it.

---

💬 Summary

The type-annotations proposal:

• Adds syntax without semantics.
• Brings no safety, no performance, and no clarity.
• Requires new engine complexity for zero benefit.
• Solves no new problem (JSDoc already works).
• Risks blocking a future where types can be powerful and meaningful.

By contrast, ecmascript-types provides:

• Real runtime safety
• Potential performance improvements
• Better tooling support
• A solid foundation for the future of typed JavaScript

We don’t need types that do nothing.
We need types that do something.