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 ;).

I'm one of the big haters for "True Shit".
Why I would use a language that is just a new layer to generate the main language?
For auto completion and type definition? JSDoc is enough.
To prevent runtime errors? not totally guaranteed, and it was better instead of developing True Shit script, to develop something to parse JSDoc while compiling to achieve the same thing without the need to develop a new language.
But as MS behind it, and clients will pay more for nothing, we'll use it.

"people who don't like typescript have just received a bad education on the subject." nope these are legit criticisms, stop the hate, TS is a tool its definitely ok not to like it.

Defending TS or Hating TS by using emotion, tolling, or logical fallacy doesn't help anyone. It's a signal that you are in a cargo cult. Bring logic and reason. I don't like TS, but I understand the problems it solves; some value those solutions and are willing to take trade-offs, while others don't like it and take different trade-offs. Types and languages and frameworks, statistically, have no significance on the success of a company or a development team or an individual developer.

"people who don't like typescript have just received a bad education on the subject."

@djmisterjon This is not true. and i agree with kevinlbatchelor. I love TypeScript, use it everyday. But i hate the TypeScript specific syntax. So you could say that i only hate some parts of typescript. there is still things i don't like about typescript. like the total lack of WebIDL conversion.

TS have at least done something good and provided us with a better IDE intelligence and type inferences.
But i prefer to use build-less setups that runs instantly anywhere and dose not have to be compiled or executed under a buggy ts-node with buggy experimental modules and adding unnecessary build tools on top of things
I have actively been written TS syntax for 3y (b/c of the stupid job where i was forced to) so i know a lot of how typescript works. and i still don't like it.
I share pretty much the same viewpoint as Rich from the svelte team mention in their youtube video about ts vs jsdoc.
i rather stick to having JSDoc + checkjs & allowjs

typescript dose not magically give you runtime type safety. if someone said that then it's a lie. TypeScript is nothing more than a type annotation
I also think that type annotations (previously referred to as types as comments) sucks. it would just break backward compatibility when introducing new syntax.
that proposal dose not bring in any value what so ever into the language itself something truly better would be if we actually hade stronger static types in javascript instead so that we had things such as float, int etc.

The explicit goal of this proposal is to not just to give developers static type checking. It's to offer information to engines to use native types and optimize callstacks and memory usage. Ideally engines could inline and optimize code paths that are fully typed offering closer to native performance.

https://github.com/sirisian/ecmascript-types

this is in my opinion better then type annotation.
Type annotation don't solve anything. it only gives developer a piece of mind to understand what something is described as and what things are expected.

Let’s be honest, TS advocates don’t really care about type safety. They just want their IDE to help them understand function signatures.

☝️ Could not agree more.

Let’s be honest, TS advocates don’t really care about type safety. They just want their IDE to help them understand function signatures.

+1 👍

Let’s be honest, TS advocates don’t really care about type safety. They just want their IDE to help them understand function signatures.

But that's the one of the key reasons types exist. They're giving you crucial metadata about your app, which helps all LSPs and IDEs to give you hints, autocompletion and error highlighting when needed
Also if "don't really care about safety" argument would be true, then "TS Advocates" would not have any problems with switching to JSDocs with Types.
But yet here we are - JSDocs are not as advanced as TS is, so having TS is still very beneficial

Say that you develop a debug library that uses typescript syntax and d.ts file are included. it gives you hints, autocompletion and error highlighting and that's all fine and danny. but then someone comes along who wants to use your package and dose not use vscode or npm,
the person might be using vim or builtin text editor. or the person is importing something from a CDN instead from npm and don't have any local d.ts to do any kind of inferences

So here is what you have come up with:

type LogMethod = 'log' | 'info' | 'warn' | 'error';

class Debug {
  constructor (method: LogMethod) {
    this.logger = console[method];
  }

  greet (name: string) {
    this.logger(`Hello ${name}!`);
  }
}

here you would give pre-early warning when doing this:

new Debug('dog')
// Argument of type '"dog"' is not assignable to parameter of type 'Debug'

but it's not a runtime type checker
your code dose not do any type validation or instanceof checks anywhere and you don't make sure that the kindof x is of the correct type

// This should really be included
if (!['log', 'info', 'warn', 'error'].includes(method)) {
  throw new TypeError('method must be one of log, info, warn, error');
}

TS developer tends to skip this extra validation cuz they have it in type annotation instead. but it's not always true, sometimes they do a good job at having both runtime validation and type intelligence.
So you could say that TS Advocates type safety hints but not runtime type safety. which is essentially just saying:

"TS advocates don’t really care about type safety. They just want their IDE to help them understand function signatures."

cuz that statement is said with a point of view of someone who is coding things in plain vanilla javascript.
type annotation is just striped out when releasing. so type annotation !== type safety
the only thing typescript allows you to do is to annotate things

Not specifically a criticism of Typescript, but everything that uses a babel pipeline has been a huge boondoggle (other than for app packaging), now that browsers finally have decent ES6 import support, it's amazing how few ES6 import codebases are actually import compatible and which wholly rely on transpile via babel and not actually are 1) importable themselves 2) have an import compatible dependency tree. instead of 1 migration... why not have 2?

Often TS maintainers only generate the dist artifacts on publish and do not document the various interfaces (babel rendered ES5, babel rendered ES6 + modules, commonjs, AMD - returnExports, etc) So I'm left trolling CDNs to find out which target I need and hoping the developer doesn't suddenly deprecate that target :P (it totally happens).

The "build 5 targets model" only further encourages fragmentation, when so much work was put into unifying codebases we're left with close-ish yet still incompatible junk by the powers that be. How much of everyday JS programmers jobs are normalizing between environments that the standards body's JOB was to make uniform? How much work are we doing to support code-time type hints for APIs we all should know?

It totally precludes buildless development. even if I want NOTHING to do with TS I need a build system to compile jsdoc to .d.ts (though this locks you to old versions because the jsdoc transformer has fallen out of date).

"But surely it saves us work... I can just use those types to push out wire formats (proto, thrift etc)"... well, no. "But it makes everything more secure by preventing type mismatches?" well, at the compile time it forces you to use it makes sure any of the linked code doesn't declare passing the wrong type (not the kind of security that makes you secure, but the type that can help not ship a broken build, AKA what tests already do). "Look dude, Typescript encourages adoption of modern standards right?" Not the actual ones that finally land, just a new language target invented by the maintainers and configurators of babel. In the end TS does 2 things really well: 1) provide type hints 2) serve as a transpile base for other meta languages to compile to (Google used this for Dart, MS for C#).

If your code fits those use cases by all means use it, but if you're in the vast majority of people using it on a small to medium sized project because you don't like to sit down and design your approach (and instead like to freeform select from dropdowns) and you don't like to write tests... deep inside you know what you're doing is wrong.

Runtime typed function with VanillaJS concept (if you really have to).
Will throw error if wrong argument or return types, wrong number of arguments, etc... Would be very easy to add editor support for too.

let concat = fun('string', 'number', (a, b) => {
  return a + ' ' + b
}, 'string')

let result = concat('luv', 'js')

No need to invent a whole new language. This concept will even let you define your own types as functions so you can have an email type or a domain type or whatever. Max flex.

BTW, React, Svelte, and the lot, is 100% unnecessary. It's much easier to create components with regular template strings. No need for Babel or any lib at all really. It's the "blazingly" fastest too, and won't have a new syntax every week.

With gpt assistants etc. coming up TS is even more pointless.

js rock !!!
ok then open you project with 250 modules.
Got to a ref with ~500 links, press F2 and rename.
Than cry and look your project destroyed.

TS is cancer.

TS is waist of time, I thought that it would be as pleasant of a language as actionscript 3/ ECMA 4, once was, but no it is mix little bit of everything.. I will not use typescript for my future projects anymore.. back to vanilla javascript for react and RN.

I fight with the types more than I code. The console logs are just a wall of useless warnings for 10 rows about missing one comma. Everything is slow and laggy on an expensive laptop. The files are miles of code, it's always a maze to find what you need. I spend multiple more time on stuff I would do much quicker in js.

"Types are worth of every additional hour you spend on them. There is no evidence, just believe me bro."

Several years later and my daily job is Clojure and it's a bless. But in rare times of frustration I visit this page to remind myself what a circus frontend development has been since TS introduction.

a very good point. I recently discovered that one could write js in a lispy way. Just use normal functions and call them ordinarily. And there is a repl in the browser already running! And you can do live coding and changing stuff on the fly. And there are events that look almost like emacs hooks!!! So why is nobody using it like that? well..... well.... Some like to tinker for hours in brainless activities as a relaxation exercise, that's what i thinki. This typescript fetish is almost as destructive for the psyche as discalculia.

…

On Fri, Sep 1, 2023 at 5:32 PM Vlad Nabatov ***@***.***> wrote: ***@***.**** commented on this gist. ------------------------------ "Types are worth of every additional hour you spend on them. There is no evidence, just believe me bro." Several years later and my daily job is Clojure and it's a bless. But in rare times of frustration I visit this page to remind myself what a circus frontend development has been since TS introduction. — Reply to this email directly, view it on GitHub <https://gist.github.com/amcdnl/b52e9dd11850eeb8de8f#gistcomment-4678496> or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADK23JNKDFALEJMGDBWB32LXYH5ZPBFKMF2HI4TJMJ2XIZLTSKBKK5TBNR2WLJDHNFZXJJDOMFWWLK3UNBZGKYLEL52HS4DFQKSXMYLMOVS2I5DSOVS2I3TBNVS3W5DIOJSWCZC7OBQXE5DJMNUXAYLOORPWCY3UNF3GS5DZVRZXKYTKMVRXIX3UPFYGLK2HNFZXIQ3PNVWWK3TUUZ2G64DJMNZZDAVEOR4XAZNEM5UXG5FFOZQWY5LFVAZTEMRVGY2DSOFHORZGSZ3HMVZKMY3SMVQXIZI> . You are receiving this email because you commented on the thread. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> .

I recently discovered that one could write js in a lispy way. Just use normal functions and call them ordinarily. [...] So why is nobody using it like that?

because javascript is not a functional language. javascript has no tail call recursion, so sooner or later you will hit the "maximum call stack size exceeded" error, and the function call overhead makes functional style slower and more memory-hungry than imperative style... but you can implement lazy functions and trampolines in javascript, and some functional languages are hosted on javascript, like clojurescript

So what? Are people doing rocket science with JavaScript like astronomical calculations of Jupiter's moons orbit bifurcations? Protein unfolding? No? It's just for turning a widget on and off on a webpage? Lisp hasn't been functional either in the beginning. But the repl was. Somehow people did understand even in the 50s,60s that repl is good. Take a look at lisp 1.5 documentation and think a moment how productive these folks were. Without visual code, but with blackboard and paper. Oh yeah, Google and Microsoft need fast JavaScript in order to snoop in people. 1% processing power goes for blinking some widgets, the rest goes for all the evil stuff. People should unlearn all this nasty stuff. You will not go to heaven while still sinning sob., 2 wrz 2023, 7:37 AM użytkownik milahu ***@***.***> napisał:

…

***@***.**** commented on this gist. ------------------------------ I recently discovered that one could write js in a lispy way. Just use normal functions and call them ordinarily. [...] So why is nobody using it like that? because javascript is not a functional language. javascript has no tail call recursion, so sooner or later you will hit the "maximum call stack size exceeded" error, and the function call overhead makes functional style slower and more memory-hungry than imperative style... but you can implement lazy functions and trampolines in javascript <https://stackoverflow.com/questions/33923/what-is-tail-recursion>, and some functional languages are hosted on javascript, like clojurescript — Reply to this email directly, view it on GitHub <https://gist.github.com/amcdnl/b52e9dd11850eeb8de8f#gistcomment-4678923> or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADK23JL3LV7S3GO25ZOIUPDXYLA2DBFKMF2HI4TJMJ2XIZLTSKBKK5TBNR2WLJDHNFZXJJDOMFWWLK3UNBZGKYLEL52HS4DFQKSXMYLMOVS2I5DSOVS2I3TBNVS3W5DIOJSWCZC7OBQXE5DJMNUXAYLOORPWCY3UNF3GS5DZVRZXKYTKMVRXIX3UPFYGLK2HNFZXIQ3PNVWWK3TUUZ2G64DJMNZZDAVEOR4XAZNEM5UXG5FFOZQWY5LFVAZTEMRVGY2DSOFHORZGSZ3HMVZKMY3SMVQXIZI> . You are receiving this email because you commented on the thread. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> .

@mjobuda Don't listen to TS bigots. JS was planned as a Scheme in the browser. It was designed to be a modern functional language by its creator, but OOP fanboys disfigured it with Classes™ and Inheritance™.

Another popular web framework drops TS: hotwired/turbo#971

All for it! 👍
but the way turbo went about it was a bit drastically. they could have done it more cleanly.

@mjobuda Don't listen to TS bigots. JS was planned as a Scheme in the browser. It was designed to be a modern functional language by its creator, but OOP fanboys disfigured it with Classes™ and Inheritance™.

hell yeah, they can't handle javascript's prototype-based programming, so they have to add classes

您的邮件已被接收，我将努力找时间处理。

if you want to check types, just make a function to do it, there is no need for a whole language

Look at this https://dev.to/desone/why-typescript-vs-javascript-discussion-is-still-hot-201l

您的邮件已被接收，我将努力找时间处理。

Let’s be honest, TS advocates don’t really care about type safety. They just want their IDE to help them understand function signatures.

+1

您的邮件已被接收，我将努力找时间处理。