Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?

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

@Ganbin

This comment has been minimized.

Copy link

@Ganbin Ganbin commented Jun 3, 2016

Thank you. I have found somebody with sense in this world.

You didn't mention the nightmare to debug on the browser. I'm a fan of pure Javascript. I use to always debug my .js files in my chrome browser with the debugger tools. Now I'm using a library which is written in typescript. What a shame that we have to so much trick until we can debug the code.

For me typescript is just a sugar for the develpers who come from Java or C#. But for me it kill javascript. It introduce concepts that are stranger to javascript inside javascript. So new comers will never understand the true strength of javascript. And they will still continue with the popular myth that javascript is a poor language which need top language to write good code. Where the truth is that people don't want to learn the deep sense of the architecture of javascript, understand his good and bad parts, and know what they are writting.

So for me typescript and the class statement in ES6 are really not a good turn for Javascript and I think, we, real Javascript lover, should fight against this rebellion against Javascript. We don't want javascript to become a Java 2.0 language. We want to keep Javascript for what we love it.

My 2 cents. Thanks

@kevinlbatchelor

This comment has been minimized.

Copy link

@kevinlbatchelor kevinlbatchelor commented Jun 16, 2016

lols maybe I'll fork your project.

@avesus

This comment has been minimized.

Copy link

@avesus avesus commented Jul 5, 2016

Thank you.

@MrGRA

This comment has been minimized.

Copy link

@MrGRA MrGRA commented Sep 22, 2016

I totally agree! Thanks!

@imskojs

This comment has been minimized.

Copy link

@imskojs imskojs commented Sep 25, 2016

TypeScript is a tool and a language that is a superset of JavaScript(ECMA2015 which is superset of ES5 which is not sure if it's superset of ES3).
That is if you do not believe in using features that is not ECMA standard(I believe it's called ECMA-262) then simply don't use it.

Sure I do not currently use TypeScript on projects other than Angular 2, such as Express, Koa 2, hapi, etc. (but hey, Clover.js)

But for Angular 2, for > medium projects, as a number of components increases, it helps to have Sublime Text or any IDE tell you what is expected as an input(data) and output(event) for each component.

As for typing any for everything, we can simply set noImplicitAny: false in tsconfig so anything that does not have type specified will be treated as Any type.

I believe TypeScript will last as long as Angular 2 lasts. In that it's little bit different to other languages that compiles/transpiles to JavaScript which do not last long.

I believe Google's Angular 2 team knows that any JavaScript project written in a language other than JavaScript has a history of not having many support and mostly fail. Nevertheless they chose TypeScript. This says that Angular 2 is not just a web framework. It is almost like an SDK that is designed to be used across all platforms(hence the total seperation from DOM).

my 2 cents, thanks


Seunghoon Ko
www.svcoding.com

@svaza

This comment has been minimized.

Copy link

@svaza svaza commented Sep 26, 2016

I do not agree writing too much JavaScript client side

@type-hater

This comment has been minimized.

Copy link

@type-hater type-hater commented Dec 1, 2016

Hate Typescript
why ?
Did you ever heard anything about TypeScript before? But now you know that for sure, thanks google.
And I do not think it's a mistake. I think that especially promoted Typescript, because no one was interested in it.
And if JS community will do nothing. They will just kill my so beloved JS. You will not see ES7. You will get Typescript 2 as the only choice.

@max-favilli

This comment has been minimized.

Copy link

@max-favilli max-favilli commented Dec 8, 2016

+1

@mikepc

This comment has been minimized.

Copy link

@mikepc mikepc commented Jan 17, 2017

+4

Modern Javascript is vastly complicated, every framework/package that gets added to "standard" projects makes it worse and worse, and to add the gigantic complexity of a superset of the language.. Is insane.

I've compiled the following list of why I left Angular2 and why I refuse to adopt TypeScript:

1 - With all the interpretation/interpolation code has to go through before being executed, the call stack becomes utterly unusable.
2 - The "handling" of typescript has such a high Cost/Benefit ratio, it makes 0 sense for anyone to actually use it. Syntax differences and other requirements that are wholly unnecessary.
3 - Debugging typescript apps is nightmarishly difficult. Got breakpoint? Hah.
4 - If typescript was so awesome, then why don't browsers interpret it natively? IE used to interpret VBScript for God's sake. The browsers won't do this because.. It's stupid. And risky. So few people actually like it, then the browsers won't deal with it.
5 - Since one can use the "any" keyword, and operate on generic objects, the sum benefit of typescript is lost. Lazy developers will not use typed objects, because.. they're lazy. Or ignorant. Or both. And then you have the burden of all the other drama of typescript, on top of having an app that only uses types it imports. And this will happen because most developers hate typescript.
6 - There is no implicit casting of JSON objects into classes, this makes working with JSON either a clusterfuck, OR you lose type safety. Why not just use javascript and skip the bullshit?

There is a lot more than this, but this is enough for me to walk away from the Angular ecosystem in lieu of other technologies. TypeScript made angular 2 awful.

@nicholas-johnson

This comment has been minimized.

Copy link

@nicholas-johnson nicholas-johnson commented Feb 2, 2017

TypeScript is JavaScript for people who know Java and C#. As such is has a place. Just like Java, it is useful for large distributed teams of mixed ability developers. Type safety stops any lone developer from breaking things too much.

JavaScript and Java are of course, not related languages. They're not even that similar. They have a different definition of variable scope for example, and of what constitutes an object. JavaScript has no real concept of instantiation, only inheritance, and any object you like can act as a "class", just by setting up the prototype chain. We use constructor functions instead of classes, and pretend we're writing classical code, but we're not. It's functional.

Because it gives you classes, interfaces and generics, TypeScript encourages a much tighter, more formal way of thinking. This will slow you down. If you are a loan dev or a small agile team, TypeScript might not be a good choice (unless you really love Java and don't want to learn something new).

In a large team or a bank where tight deadlines are less important than guaranteed correctness and outsourceability, TypeScript is absolutely the right choice.

@jimmywarting

This comment has been minimized.

Copy link

@jimmywarting jimmywarting commented Mar 8, 2017

I hate everyone that is trying to invent there own scripting language that really isn't a language at all cuz it doesn't run anywhere unless you compile it first to javascript anyway
I hate those who think javascript is a bad language or don't know javascript at all. It feels like they are invading our platform and trying to fit a square in to our circle.

Javascript is changing a LOT now, so they have no way of keeping up the speed with the new specification.

If you are going to make something that is meant for the web or NodeJS - Learn JAVASCRIPT not something else

@cyberwillis

This comment has been minimized.

Copy link

@cyberwillis cyberwillis commented Apr 29, 2017

@imskojs

I believe TypeScript will last as long as Angular 2 lasts.

HAhahahaaa
Man I laugh, angular 4 is already here... It's a shame angular 4 still keep going on TS direction.
Would be nice to see TS gone as Angular 2 will be gone in next months.

TS just propose a DOGMA in everything being typed, and forgetting about the diversity
Future of programming

The Agile initiative is just becoming worst, like everybody needs delivery a system/application like a pizza.

If the author of TS was really interested in diversity, he probably would have thought something about
Node based programming (Like Unreal Engine Blue Prints).
That would be so much more appreciated.

@chris-kobrzak

This comment has been minimized.

Copy link

@chris-kobrzak chris-kobrzak commented May 10, 2017

+100, thanks for this article, Austin.

@WolfieWerewolf

This comment has been minimized.

Copy link

@WolfieWerewolf WolfieWerewolf commented May 13, 2017

I'm happy to have found others who share my hatred of TypeScript. I'll never be comfortable with a language that doesn't have a run-time of it's own. Unless it compiles to some kind of byte-code or executes in an interpreter I just can't understand how it could possibly be useful for anything. Is JS really so bad? Sure it has wrinkles but at least it's standards based. Just write it in JS folks... please!!!

@jeffmcmahan

This comment has been minimized.

Copy link

@jeffmcmahan jeffmcmahan commented May 15, 2017

@ghost

This comment has been minimized.

Copy link

@ghost ghost commented Jul 17, 2017

^^^ That is hilarious

@art-grig

This comment has been minimized.

Copy link

@art-grig art-grig commented Nov 13, 2017

cry of my heart !!!

@JoseBalado

This comment has been minimized.

Copy link

@JoseBalado JoseBalado commented Dec 13, 2017

@JoseBalado

This comment has been minimized.

Copy link

@JoseBalado JoseBalado commented Dec 24, 2017

@JoseBalado

This comment has been minimized.

Copy link

@JoseBalado JoseBalado commented Jan 10, 2018

Why we moved from Angular 2 to Vue.js
https://medium.com/reverdev/why-we-moved-from-angular-2-to-vue-js-and-why-we-didnt-choose-react-ef807d9f4163

The main thing we didn’t like and we still don’t like about Angular 2 is Typescript. I know Angular 2 can be used with Javascript but again, the decision to use Typescript was already taken and from what I understand, using pure Javascript with Angular 2 is not the ideal way you should be using Angular 2. In any case, getting rid of Typescript meant a full rewrite of the project.

I didn’t feel Typescript added substantial value and even worse, we noticed that our coding speed was reduced. With Typescript things that were really easy to do on Javascript like defining a simple object were more complicated to do on Typescript. I highly recommend you to read the following articles before you start using Typescript. It is not the right solution for everyone.

@zannet

This comment has been minimized.

Copy link

@zannet zannet commented Jan 12, 2018

true words, thanks, typescript feels so fake.

@yanzou

This comment has been minimized.

Copy link

@yanzou yanzou commented Feb 7, 2018

+1

@jfernandezcorral

This comment has been minimized.

Copy link

@jfernandezcorral jfernandezcorral commented Feb 19, 2018

I hate typescript too

@codeaholicguy

This comment has been minimized.

Copy link

@codeaholicguy codeaholicguy commented Apr 23, 2018

I don't know why people like writing a thing (TS) that compiles into a thing (JS) which they can write at start. I don't hate TS, but I can stay with it.

@yessky

This comment has been minimized.

Copy link

@yessky yessky commented Jun 17, 2018

+10086, Hah!!! Today there are too many 'language'/'preprocessor', it makes FE project becomes more and more complex. Many developers lost patience to learn the data-structure/algorithm/desgin-mode, they spent most of time to learn these proprocessors, write awful code

@kukiron

This comment has been minimized.

Copy link

@kukiron kukiron commented Jul 3, 2018

Oh, man! TypeScript drives me nuts. It makes me feel suffocated.

@chiqui3d

This comment has been minimized.

Copy link

@chiqui3d chiqui3d commented Jul 12, 2018

It's like you're telling me that I have to program in ASP to compile in PHP.

@nmyers217

This comment has been minimized.

Copy link

@nmyers217 nmyers217 commented Jul 31, 2018

Typescript to me feels like Microsoft finally just realized nobody wants to code in VBscript, and they cannot kill JS by getting their own scripting language running in the browser. It is just not going to happen. Nobody even wants to use Internet Explorer, or Edge.

So, inspired by the Trojan Horse they have decided to simply sneak a bunch of tools like Typescript and Vscode into the JS ecosystem. Initially these tools will seem like a gift, and will be welcomed by many, but they will probably just end up bringing Microsoft closer to hijacking the future of web development.

Personally, I am having PTSD flashbacks of VBscript, Classic ASP, .NET, Web Forms, etc... I don't want to touch this stuff with a 10 foot pole. I think I'll be sticking with flow, or something more closely integrated with babel, if I am even going to do any transpiling at all (which is already complicated enough).

Remember, always KISS.

@iamrommel

This comment has been minimized.

Copy link

@iamrommel iamrommel commented Sep 12, 2018

Anything that came from MS is shit, this typescript is another proof of that. If there is a legion of developers hating typescript, count me in

@tiefling

This comment has been minimized.

Copy link

@tiefling tiefling commented Oct 18, 2018

Thank you for this. I'm a 20 year veteran Microsoft .net developer and also a proper JavaScript developer too (since digging into Backbone many years ago). I love C# - I think it's one of the nicest languages out there and, with the advent of dotnet core, it now partners itself with a really nice, high performing and flexible framework too (less of a fan of the classic .net Framework these days).

In my opinion Microsoft have always had some of the best IDEs (The new VSCode is outstanding - It makes me sad every time I have to go back and use Visual Studio, it's dated) and have written some of the best server side development stuff out there (@iamrommel - check out dotnet core - is very nice) but, when it comes to front end web it's always been a disaster. I remember doing some work with knockout a while back and watching it completely kill my browser and having no way to make it any better and I'm not even going to dignify Silverlight with the time of day (I could say the same about Flash, but that's off topic).

TypeScript is just plain wrong. The goal of any good programming language should be to enable developers to write highly maintainable solutions with the smallest amount of code possible. TypeScript simply requires you to write far more code which it then convert into less. Why? It requires you to learn a new language to achieve something that you can already do well. Why?

It's all well and good to say 'well just don't use it' but when you're working with clients and enhancing existing systems then sometimes you don't have a choice. Every time it makes me hurt inside.

Front end framework wise, I had the pleasure of working with Vue.js on a new project recently and absolutely loved it. Angular can go eat my hat!

@JoseBalado

This comment has been minimized.

Copy link

@JoseBalado JoseBalado commented Nov 19, 2018

https://www.typescriptlang.org/docs/handbook/type-compatibility.html

A Note on Soundness
TypeScript’s type system allows certain operations that can’t be known at compile-time to be safe. When a type system has this property, it is said to not be “sound”. The places where TypeScript allows unsound behavior were carefully considered, and throughout this document we’ll explain where these happen and the motivating scenarios behind them.

@tosho-ait

This comment has been minimized.

Copy link

@tosho-ait tosho-ait commented Nov 29, 2018

+1

@multics

This comment has been minimized.

Copy link

@multics multics commented Dec 29, 2018

I just do not like everything microsoft made except those they bought e.g. github. Back to those programming on windows days, APIs of the os was so awful

@ymaz

This comment has been minimized.

Copy link

@ymaz ymaz commented Feb 7, 2019

+1

@payam-int

This comment has been minimized.

Copy link

@payam-int payam-int commented Feb 9, 2019

+1

@xuan9230

This comment has been minimized.

Copy link

@xuan9230 xuan9230 commented Feb 19, 2019

+1

@peq42

This comment has been minimized.

Copy link

@peq42 peq42 commented Feb 20, 2019

+1

@wspringer

This comment has been minimized.

Copy link

@wspringer wspringer commented Feb 22, 2019

+1 This might be my favorite place on the Internet.

@karamasoff

This comment has been minimized.

Copy link

@karamasoff karamasoff commented Mar 12, 2019

+1 fully agree

@nmyers217

This comment has been minimized.

Copy link

@nmyers217 nmyers217 commented Mar 28, 2019

+1

Remember guys, Microsoft's official policy is Embrace Extend Extinguish.

They tried to just extinguish last time with vbscript, but it didn't work and they got more clever. They realized they needed to appear more genuine before they could do that.

Right now we are still in the extend phase, they are extending javascript with typescript and the vscode ecosystem. Once they gain enough leverage and control, and they convince everyone to shill for them, they can begin extinguishing javascript permanently.

I'll be staying far away and keeping javascript as fun and fast as possible to program in.

@superpigju

This comment has been minimized.

Copy link

@superpigju superpigju commented Apr 4, 2019

As devs, we are forced to use 'fake' languages; they push it down our throats. Typescript is just one of many, many fake BS, pile of doo that we have to suffer with. Pure Javascript is Awesome!!. I can't wait for the day, the nightmare is over? Will it ever be over? lol - stay strong and don't let others stomp on you.

@gengns

This comment has been minimized.

@kispi

This comment has been minimized.

Copy link

@kispi kispi commented Jun 26, 2019

It's not worth using TS if we use too much 'any'
Obviously JS doesn't need burdensome supersets.

@michaeljota

This comment has been minimized.

Copy link

@michaeljota michaeljota commented Jul 11, 2019

Hey! 3 years now... JS is still around, but TypeScript is used more than plain JS. Seems you loose that bet. Funny you went with Vue and they decide to rewrite Vue 3 with TypeScript. Respecting Flow, most of the big projects using it are moving to TypeScript now. :).

They are even integrated more with the ES ecosystem. Babel, Jest and Eslint supporting TS.

I don't know how we are going to be in 3 years, but wherever it is, I'm sure TS will have a lot of guilty.

@succinction

This comment has been minimized.

Copy link

@succinction succinction commented Jul 15, 2019

Glad to finally find this--I thought I was the only one hating TS. I have been writing JS since 1998. JS is absolutely awesome as it is, then and now (ES6/ES7). TS is absolute dog sh!t. I have refused jobs that required TS. F-@k Microsoft. If you are coming from Java and you want to write JS, then learn JS, and cut the crybabying! Pretending that strong-typed JS is necessary only reveals your lack of competence. If JS is too hard for you, simply accept that you're not that brilliant, and GO BACK TO JAVA.

=======

Typescript is a trap for Newbies, or classical compiler-centric strictly-typed language programmers who wanna-be JavaScript developers. Instead of accepting that JavaScript is indeed a deep subject that merits study and experiment, they deny this with the conception of a belief that feeds their bias--that JS is fundamentally flawed. Not being able to fathom the utility of dynamic functional programming, they are easy prey to Microsoft's latest expression of "Embrace, Extend, Extinguish", Typescript.

Dynamic typing is a Feature, not a defect, of JavaScript. Perhaps it is like jumping out of an airplane for a person used to the strict-type institutionalization, but the way it works in JS is very useful and is a real-world reason that JS development can feel very fast, maybe too fast if you have been super fast. Waiting for compilers was never needed in JavaScript, and it did the job for all of these years before typescript was invented, so no it is not needed.

Typescript amounts to setting up a bunch of extra hurtles to trip yourself over, when instead you are trying to connect A to B. This is frustrating to a professional programmer who is just getting things to start working, and so much worse it would be to just be learning JS.

When you try to find the arguments of why you should use typescript, you find the same feel-good speech repeated everywhere which amounts to zero case studies but instead shaming for not using it and for not being enlightened enough to accept strong-types as superior. I find that typescript has advocates, or are they evangelists? The closest thing to any evidence is an assertion that you find bugs earlier. What I found is that typescript treats the use of dynamic-typing as a bug--so maybe this is the bug that they are finding earlier. Dynamic typing is in fact a fundamental feature that has made JavaScript successfully stand the test of time. Typescript can only slow you down, and it makes the code more ridged, which works against any effort to be Agile. But I wonder if it isn't that the intention is to slow down development? Or it really is that programmers coming from other languages are so used to sitting around waiting for the compiler that JavaScript development is too rapid for them? The fact that JavaScript has and is holding the load for all of these years is its own testimony. Certainly also part of the problem of the spread of this misconception is that decision makers or strict-type programmers are sometimes ignorant and easily fooled by the bias-feeding Microsoft propaganda.

The day will come when typescript goes out of style. Then we will be digging all of this crap out of the code. Then it will be like a new day has dawned and you will see the light and the beauty of clean code and uninhibited production, and in those days all developers will rejoice, and product owners will be disabused of the phantom bugs that typescript has delivered them from, and the time that was saved only in their imaginations.

@amcdnl

This comment has been minimized.

Copy link
Owner Author

@amcdnl amcdnl commented Jul 16, 2019

@lcsjunior

This comment has been minimized.

Copy link

@lcsjunior lcsjunior commented Jul 18, 2019

For me TypeScript is unnecessary. It's just another complication. It is to invent the wheel of the wheel.

@1ak31sha

This comment has been minimized.

Copy link

@1ak31sha 1ak31sha commented Jul 22, 2019

+1

@pparke

This comment has been minimized.

Copy link

@pparke pparke commented Jul 26, 2019

Hey! 3 years now... JS is still around, but TypeScript is used more than plain JS. Seems you loose that bet. Funny you went with Vue and they decide to rewrite Vue 3 with TypeScript. Respecting Flow, most of the big projects using it are moving to TypeScript now. :).

They are even integrated more with the ES ecosystem. Babel, Jest and Eslint supporting TS.

I don't know how we are going to be in 3 years, but wherever it is, I'm sure TS will have a lot of guilty.

Not sure where you're getting the idea that TypeScript is used more than JS, JS is still on top for every stat on Github with TS ranking in the bottom of the top 10.

https://madnight.github.io/githut/#/pushes/2019/2

@michaeljota

This comment has been minimized.

Copy link

@michaeljota michaeljota commented Jul 29, 2019

@pparke By using github, you can't tell the diference between vanilla JS, and JS transpiled with Babel, for example. But, sure, I don't think that TypeScript is being used more in general, just in large projects, enterprises, any many open source projects.

Sure, Flow had it's momento, but if look projects that use to used it to manage types, (Jest, for example) they are moving to TS.

@jkmartindale

This comment has been minimized.

Copy link

@jkmartindale jkmartindale commented Aug 1, 2019

If you are coming from Java and you want to write JS, then learn JS, and cut the crybabying! Pretending that strong-typed JS is necessary only reveals your lack of competence. If JS is too hard for you, simply accept that you're not that brilliant, and GO BACK TO JAVA.

To be fair, you have to have a very high IQ to understand JS. The typing is extremely subtle, and without a solid grasp of ESNext most of the code will go over a typical interviewer's head. There's also JS's nihilistic classes, which are deftly woven into prototype-based inheritance-its classless philosophy draws heavily from Self and Lua, for instance. The fans understand this stuff; they have the intellectual capacity to truly appreciate the depths of dynamic typing, to realise that it's not just flexible code- it's a flexible way to live LIFE. As a consequence people who dislike JS truly ARE idiots- of course they wouldn't appreciate, for instance, the binding of context to JS's existential keyword "this," which itself follows seven cryptic rules to determine binding. I'm smirking right now just imagining one of those addlepated simpletons scratching their heads in confusion as Brendan Eich's genius wit unfolds itself on their LCD screens. What fools.. how I pity them. 😂

And yes, by the way, i DO have a JS tattoo. And no, you cannot see it. It's for the ladies' eyes only- and even then they have to demonstrate that they're within 5 IQ points of my own (preferably lower) beforehand. Nothin personnel kid 😎

@michaeljota

This comment has been minimized.

Copy link

@michaeljota michaeljota commented Aug 1, 2019

@normancarcamo

This comment has been minimized.

Copy link

@normancarcamo normancarcamo commented Aug 5, 2019

It's not too bad, in my case honestly I don't like the ideas of OOP mixed in JS community, I prefer more to write code in FP style (Although JS isn't 100%, but it does some things really great that I hope they take this path from now on, but supporting async monads).

Btw, I agree in some your points.

@dirk-ecker

This comment has been minimized.

Copy link

@dirk-ecker dirk-ecker commented Aug 9, 2019

I also will stay with pure JS as long as I can, because it is fun to use and even fast to code.
Hit refresh and you get the result of your change, no compile, no transpile, no ... no .... simple, easy and fast.
I remember the times we had build times with Java with about 10 minutes, awful. TS ist heading in the same direction.

@rabelais88

This comment has been minimized.

Copy link

@rabelais88 rabelais88 commented Aug 14, 2019

For anyone who wants eslint typecheck without actually using typescript, read this. I've been using this on my project to track any complicated data structure and it's been working perfectly. It supports both autocompletion and type lint. and it compiles without any performance drop as it doesn't affect the actual compilation. you don't need a complicated setup, just put *.d.ts file on your work directory.

https://fettblog.eu/typescript-jsdoc-superpowers/
https://ricostacruz.com/til/typescript-jsdoc
https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html

the only downside of this, is that type conversion is awkward in this method.(the type conversion still does work though) I think the community should invent newer style of JSDOC and IDEs should support it: something similar to above(typescript + JSDOC) and leaner.

action.types.d.ts

export interface sayHelloArg {
  (msg: string, type: string): boolean;
}

export const sayHello: sayHelloArg;

export as namespace Actions;

usage

// @ts-check
/// <reference path="./action.types.d.ts" />

/** @type {Actions.sayHello} */
const sayHello(msg, type) {
  console.log(msg, type);
  return true;
}

type conversion

const greeting = (/** @type {Actions.sayHello} */(anotherFunction));
@michaeljota

This comment has been minimized.

Copy link

@michaeljota michaeljota commented Aug 14, 2019

@rabelais88 so you are saying that in order to write better JS that involves large and complex estructures you should use a Typescript definition for that estructures and trick your IDE to use the Typescript type system with comment annotations? Well... I guess you are writing JS after all... Right? Still... Seems like you are using Typescript nevertheless.

@michaeljota

This comment has been minimized.

Copy link

@michaeljota michaeljota commented Aug 16, 2019

VSCode doesn't show its full potential(better lint, better autocompletion) with vanilla JS.

Had you ever try an JS IDE before VSCode? There was not full potential. The best IDE might be WebStorm, but even then, it just tried to expose all the properties of every object with a given symbol name. What you have in VSCode is powered by the Typescript server, so you are using Typescript. Even if you don't actually write a .ts file.

Microsoft is obviously favoring Typescript.

It's not giving a favor to anything. On the contrary, Microsoft have worked really hard to make the Typescript server works with JS, and with JSDocs that is what you are using. They didn't have to, if they actually were giving any favoritism to Typescript, they could stay as use my language or don't any of its beneficies, but they had make a really big effort to make a better JS world.

The code above is just a method to exploit Typescript feature for vanilla JS.

I will write that in the actual way of what you are doing: The code above is just a method of using the Typescript server in vanilla JS. And it its, thanks to Microsoft: Type checking JavaScript files.

Don't get me wrong. I hate Typescript.

I think you don't understand Typescript, and you don't understand that you ARE using Typescript. But that's ok man.

You all are using Typescript in some way you don't understand. You can keep supporting the Microsoft is evil motto. You can even say that you all hate Typescript. That won't change, that for once, Microsoft did a good thing, that have improve everyone life, even if you choose to write vanilla JS.

PS: @sungryeol-bigpi don't take that personal. But I found funny how you all give the same arguments, over and over again, about how TS is evil, and all that. But you still use TS. Irony, I guess.

@normancarcamo

This comment has been minimized.

Copy link

@normancarcamo normancarcamo commented Aug 16, 2019

To write JS one doesn’t need VSCode at all, I still use vim 😅 and I don’t have problems.

@sunoterra

This comment has been minimized.

Copy link

@sunoterra sunoterra commented Oct 8, 2019

To write JS one doesn’t need VSCode at all, I still use vim 😅 and I don’t have problems.

+1

@sunoterra

This comment has been minimized.

Copy link

@sunoterra sunoterra commented Oct 8, 2019

+1 ... seriously ... nothing like moving backward to deprecated OOP, instead of moving forward. brought to you by Microshaft, the very same folks that brought us a decade of browser stagnation in the IE6-9 years. they should focus on entertainment and stop trying to force their fisher-price-my-first-development experiences on the World.

@zjaml

This comment has been minimized.

Copy link

@zjaml zjaml commented Oct 21, 2019

+1 this hate holds true even today. +1 hater here.
Every dev who needs to be productive come hate it with me!

This trash is creeping everywhere, making my life so much harder.

@zjaml

This comment has been minimized.

Copy link

@zjaml zjaml commented Oct 21, 2019

@michaeljota Don't get me wrong. I hate Typescript. It's not about forcing typed system on Javascript. Somebody has to describe what's inside the code anyway...it's a small improvement over JSDOC, not full Typescript. I am more of into documentation, and JSDOC has really outdated syntax. Typescript definition(d.ts) is simpler in many ways. VSCode doesn't show its full potential(better lint, better autocompletion) with vanilla JS; you know what I mean if you have used VSCode on both Typescript and vanilla JS. Microsoft is obviously favoring Typescript. The code above is just a method to exploit Typescript feature for vanilla JS.

VSCode is definitely worse with Typescript, there's no working go to definition any more as it only jumps to type definition. if you want to check the source code of a dependency, even if it is written by you, you end up somewhere in an auto generated cache file outside of your working folder. good luck find your way back.

@zjaml

This comment has been minimized.

Copy link

@zjaml zjaml commented Oct 21, 2019

For you all You only hate what you don't know

Do I need to remind you the things you hate in your life that you know of ?

@zjaml

This comment has been minimized.

Copy link

@zjaml zjaml commented Oct 21, 2019

Time to rebut everyone, let's say no to this TS shit to stop it creeping into our lives.

@kispi

This comment has been minimized.

Copy link

@kispi kispi commented Oct 22, 2019

I don't 'hate' TS technically, but still just don't need it at all

@michaeljota

This comment has been minimized.

Copy link

@michaeljota michaeljota commented Oct 23, 2019

@zjaml Please do, but you could read the post first and after that, you can tell why you still think TS and MS are all the evils.

@zjaml

This comment has been minimized.

Copy link

@zjaml zjaml commented Oct 23, 2019

I hate it because I cannot opt out of it. I use many dependencies some of which are using TS. Some of them are converted into TS.
In this process, number of lines of code tends to triple, and I used to be able to jump to implementation of the dependency directly to dig around. Now there's no way to do that.
I hate it because it's favored and adopted from people who doesn't get Javascript, the irony is that you still need good understanding of Javascript to do TS. TS just hide some of the edges that looks weird for JS, and package it in a way that's appealing to people coming from OOP background. But JS is fundamentally not OOP, hiding the fundamental difference is not helping people, it's misleading!

Then I found an interesting video about the history of Javascript and MS's historical attempt to take over Javascript, I was like, everything makes sense

For those who are interested:
https://www.youtube.com/watch?v=Sh6lK57Cuk4
A Brief History of JavaScript by the Creator of JavaScript
https://www.youtube.com/watch?v=3-9fnjzmXWA&t=287s

@xcurveballx

This comment has been minimized.

Copy link

@xcurveballx xcurveballx commented Dec 18, 2019

+1 I don't like TS because it is:

  1. Too much of a hustle - find/write type definitions, install myriads of additional project packages, IDE plugins, tweak dozens of settings, tune webpack etc.
  2. At some point I realized that TS code just pollutes my own code, deludes my logic. My code became too hard to perceive, too complicated to maintain/expand.
  3. Previous reasons made my dev process slow down. In commercial development this means that the process becomes more expensive. Especially so, if I have to embed TS into something that is working/was built fairly fine w/o TS in mind.
  4. In the end, I don't understand what is the value of TS, what big problem does it solve for me? If I somehow get a function instead of an array - I will spot and fix it myself...

I strongly believe that TS is just another attempt of backend guys (this time from Microsoft) to invade and own the territory that doesn't belong to them naturally, they once already lost (Sun/Oracle's JAVA applets in browsers in 90s-00s). They just cannot accept another inheritance model, another type-checking system. Besides, they often perceive JS as a toy for little boys, trying to boost their ego...

@zjaml

This comment has been minimized.

Copy link

@zjaml zjaml commented Dec 18, 2019

I've been using Flow recently and I really like it, it's more powerful without forcing you use it everywhere.
But it has some bugs and can be harder to get used to. So I went through another round of comparing it with TypeScript, trying to verify whether my attitude toward Typescript was wrong.
This brilliant article ended all my self doubt. https://medium.com/javascript-scene/the-typescript-tax-132ff4cb175b

@Khaleel

This comment has been minimized.

Copy link

@Khaleel Khaleel commented Jan 8, 2020

What a load of pig shit, just so those anal developers who write completely meaningless UI tests or Jest snapshots can feel good about themselves.
This x1000. TypeScript needs to be burned. Magento 2 Front End Development and everything in their PWA world too

@Louis-Saglio

This comment has been minimized.

Copy link

@Louis-Saglio Louis-Saglio commented Jan 30, 2020

The biggest problem I found with Typescript is the fact that instancies of custom class and the javascript key-value data structure are kind of merged in one huge mess.
IMHO, Typescripts tries to have the pros of dynamic and static languages, but it actually has the cons instead.

@SergeiSovik

This comment has been minimized.

Copy link

@SergeiSovik SergeiSovik commented Jan 31, 2020

To be or not to be, that’s the question ...

Why is TypeScript a bad language today? (January 2020)

Short answer:
There is only one real reason - it cannot be minimized using the Google Closure Compiler.
The Google Closure Compiler is the only one optimizer for the JavaScript language.

Extended answer:
For the first, JavaScript is a growing language and it has many versions, and therefore, to support the new version, a new version of the browser or platform that runs the scripts of the new version is required.
JavaScript versions in my opinion can be split into three global:
 - Stable - supported by all browsers and platforms.
 - ECMAScript 2015 - new commands and objects: let, const, class and Promise.
 - ECMAScript 2017 - asynchronous funcitons: async/await.
Trully speaking, there are newer versions, but they are supported by a limited number of platforms.

Secondary, there are three types of minimizers: obfuscators, compilers, and optimizers:
 - Obfuscators reduce the size of the program by replacing the names of objects with shorter and incomprehensible to humans.
 - Compilers, like obfuscators, replace names, and in addition removes unnecesary spaces and other, allow you to lower the version of the final language.
 - Optimizers do the same as compilers, and also analyze the code, delete the unused, and even rewrite it, which let detect hidden errors of programm.

Based on what is written, it turns out the best minimizer, it is an optimizer. According to statistics, the most popular Babel minimizer. The statistics are clearly exaggerated, because there is only one optimizer today, and it is the Google Closure Compiler. I will not argue that Babel or other minimizers are worse than GCC, but the fact is that they can not to optimize.

We have decided on a minimizer, now it's time to understand why TypeScript is bad? And it's simple, to minimize TypeScript using GCC, a very ugly pile of comments will be required, and instead of writing an application, most of the time will be spent to write these comments.

Reflections:
There are no bad tools, there are crooked hands ... Any minimizer can become the best by adding full optimization functionality. And TypeScript could be the best, when you don't have to write a lot of comments for GCC. But alas, today and now the choice is obvious. You need to write web applications at ECMAScript 2017 or higher, and optimize them for the right platform using the Google Closure Compiler.

Question:
If you read and realized the above, then make a choice: in which language is it better to write web applications?
JavaScript or TypeScript

https://www.facebook.com/permalink.php?story_fbid=220469648988085&id=100030751534086

@DominicTobias-b1

This comment has been minimized.

Copy link

@DominicTobias-b1 DominicTobias-b1 commented Feb 3, 2020

To be or not to be, that’s the question ...

Why is TypeScript a bad language today? (January 2020)

Short answer:
There is only one real reason - it cannot be minimized using the Google Closure Compiler.
The Google Closure Compiler is the only one optimizer for the JavaScript language.

Extended answer:
For the first, JavaScript is a growing language and it has many versions, and therefore, to support the new version, a new version of the browser or platform that runs the scripts of the new version is required.
JavaScript versions in my opinion can be split into three global:
 - Stable - supported by all browsers and platforms.
 - ECMAScript 2015 - new commands and objects: let, const, class and Promise.
 - ECMAScript 2017 - asynchronous funcitons: async/await.
Trully speaking, there are newer versions, but they are supported by a limited number of platforms.

Secondary, there are three types of minimizers: obfuscators, compilers, and optimizers:
 - Obfuscators reduce the size of the program by replacing the names of objects with shorter and incomprehensible to humans.
 - Compilers, like obfuscators, replace names, and in addition removes unnecesary spaces and other, allow you to lower the version of the final language.
 - Optimizers do the same as compilers, and also analyze the code, delete the unused, and even rewrite it, which let detect hidden errors of programm.

Based on what is written, it turns out the best minimizer, it is an optimizer. According to statistics, the most popular Babel minimizer. The statistics are clearly exaggerated, because there is only one optimizer today, and it is the Google Closure Compiler. I will not argue that Babel or other minimizers are worse than GCC, but the fact is that they can not to optimize.

We have decided on a minimizer, now it's time to understand why TypeScript is bad? And it's simple, to minimize TypeScript using GCC, a very ugly pile of comments will be required, and instead of writing an application, most of the time will be spent to write these comments.

Reflections:
There are no bad tools, there are crooked hands ... Any minimizer can become the best by adding full optimization functionality. And TypeScript could be the best, when you don't have to write a lot of comments for GCC. But alas, today and now the choice is obvious. You need to write web applications at ECMAScript 2017 or higher, and optimize them for the right platform using the Google Closure Compiler.

Question:
If you read and realized the above, then make a choice: in which language is it better to write web applications?
JavaScript or TypeScript

https://www.facebook.com/permalink.php?story_fbid=220469648988085&id=100030751534086

Google closure compiler is not the only optimiser. I would say Terser JS (and previously Uglify JS) are used in far more modern builds and does a good job at minimising and optimising. I think if you compared the difference in real world performance between codebases optimised in either the difference would be negligible, willing to be proven wrong though. Babel Typescript strips out TS on compilation and TS also compiles to JS, so there is no reason that you can't run an optimiser after that, and that's generally what people do in their build pipeline.

On a separate note as WASM gets more full featured and standardised we will have a lot more options to strongly type such as Rust, Go and C, and they will also have strong benefits in optimised WASM code then. That's where you'll really see a perf difference in hardcore computations, though it's currently kind of pointless for most real world use as WASM can't directly manipulate DOM and is actually slower to bridge over to JS to do it. Although it's worth mentioning there's a Typescript subset which can be compiled to WASM - https://github.com/AssemblyScript/assemblyscript

@SergeiSovik

This comment has been minimized.

Copy link

@SergeiSovik SergeiSovik commented Feb 3, 2020

To be or not to be, that’s the question ...
Why is TypeScript a bad language today? (January 2020)
Short answer:
There is only one real reason - it cannot be minimized using the Google Closure Compiler.
The Google Closure Compiler is the only one optimizer for the JavaScript language.
Extended answer:
For the first, JavaScript is a growing language and it has many versions, and therefore, to support the new version, a new version of the browser or platform that runs the scripts of the new version is required.
JavaScript versions in my opinion can be split into three global:
 - Stable - supported by all browsers and platforms.
 - ECMAScript 2015 - new commands and objects: let, const, class and Promise.
 - ECMAScript 2017 - asynchronous funcitons: async/await.
Trully speaking, there are newer versions, but they are supported by a limited number of platforms.
Secondary, there are three types of minimizers: obfuscators, compilers, and optimizers:
 - Obfuscators reduce the size of the program by replacing the names of objects with shorter and incomprehensible to humans.
 - Compilers, like obfuscators, replace names, and in addition removes unnecesary spaces and other, allow you to lower the version of the final language.
 - Optimizers do the same as compilers, and also analyze the code, delete the unused, and even rewrite it, which let detect hidden errors of programm.
Based on what is written, it turns out the best minimizer, it is an optimizer. According to statistics, the most popular Babel minimizer. The statistics are clearly exaggerated, because there is only one optimizer today, and it is the Google Closure Compiler. I will not argue that Babel or other minimizers are worse than GCC, but the fact is that they can not to optimize.
We have decided on a minimizer, now it's time to understand why TypeScript is bad? And it's simple, to minimize TypeScript using GCC, a very ugly pile of comments will be required, and instead of writing an application, most of the time will be spent to write these comments.
Reflections:
There are no bad tools, there are crooked hands ... Any minimizer can become the best by adding full optimization functionality. And TypeScript could be the best, when you don't have to write a lot of comments for GCC. But alas, today and now the choice is obvious. You need to write web applications at ECMAScript 2017 or higher, and optimize them for the right platform using the Google Closure Compiler.
Question:
If you read and realized the above, then make a choice: in which language is it better to write web applications?
JavaScript or TypeScript
https://www.facebook.com/permalink.php?story_fbid=220469648988085&id=100030751534086

Google closure compiler is not the only optimiser. I would say Terser JS (and previously Uglify JS) are used in far more modern builds and does a good job at minimising and optimising. I think if you compared the difference in real world performance between codebases optimised in either the difference would be negligible, willing to be proven wrong though. Babel Typescript strips out TS on compilation and TS also compiles to JS, so there is no reason that you can't run an optimiser after that, and that's generally what people do in their build pipeline.

On a separate note as WASM gets more full featured and standardised we will have a lot more options to strongly type such as Rust, Go and C, and they will also have strong benefits in optimised WASM code then. That's where you'll really see a perf difference in hardcore computations, though it's currently kind of pointless for most real world use as WASM can't directly manipulate DOM and is actually slower to bridge over to JS to do it. Although it's worth mentioning there's a Typescript subset which can be compiled to WASM - https://github.com/AssemblyScript/assemblyscript

Well, let's try to figure it out even deeper.
Google Closure Compiler can do error checks, actually it does a lot of sanity checks. As result JS can be developed and tested uncompiled.
This makes possible to work on a large codebase with secure feeling. It decrease amount of simple tests during development. GCC allow to find and remove errors in third party projects, preventing bugs results.

Terser JS does not do advanced optimisations, like GCC, that's the reason its faster.

P.S. Look at this fake stats https://www.npmtrends.com/google-closure-compiler-vs-javascript-obfuscator-vs-terser-vs-uglify-es
Comparation with GCC clone is not that smart. Original GCC has 5k+ stars, and Terser only 4k+.

Im not intended to use WASM, cus there is no access to DOM, and it not supported most used platforms, maby some day. But yeah, compiling from C++ to WASM is cool.

@webciter

This comment has been minimized.

Copy link

@webciter webciter commented Feb 23, 2020

typescript is stupid as fuck, it don't make sense

@vxcamiloxv

This comment has been minimized.

Copy link

@vxcamiloxv vxcamiloxv commented Mar 6, 2020

In fact many project that use Typescript use also babel, so is really crazy added another layer, Typescript + babel to get a JS output, we con do teh same with just babel

@adrien-thierry

This comment has been minimized.

Copy link

@adrien-thierry adrien-thierry commented Mar 10, 2020

I started to write NectarJS because of TypeScript, Dart, and all these new languages. NectarJS aims to compile TRUE js with a c++ backend that emulate var and objects

People who wants to help me can join us there : https://github.com/NectarJS/nectarjs

@Dragoteryx

This comment has been minimized.

Copy link

@Dragoteryx Dragoteryx commented Apr 8, 2020

NO, YOU CAN'T JUST USE STATIC TYPES IN JAVASCRIPT

haha typescript go brrr

@Dragoteryx

This comment has been minimized.

Copy link

@Dragoteryx Dragoteryx commented Apr 8, 2020

The biggest problem I found with Typescript is the fact that instancies of custom class and the javascript key-value data structure are kind of merged in one huge mess.
IMHO, Typescripts tries to have the pros of dynamic and static languages, but it actually has the cons instead.

WDYM? They are merged in one huge mess in Javascript too.
When you create a class instance in Javascript, all you're doing is creating a key-value data structure (an object), and defining its prototype to be the class' prototype.

Of course, Typescript could have been designed to make a distinction between key-value data structures and class instances (even though in Javascript they are the same thing), but then you'd have complained about the fact that Typescript makes a distinction that doesn't exist, and you'd be right.

Don't complain about Typescript's type system if you don't even understand how Javascript's works.

@jorgellose

This comment has been minimized.

Copy link

@jorgellose jorgellose commented Apr 16, 2020

Slow compilations ... ¿Based on what? There is something called incremental compilation, you dont need to recompile the whole project.
Difficult... ¿Why? Is practically 1:1 compared with JS

When i read things like this, i feel that the real problem is that people dont event know Javascript.

Probably most of you installed the typescript, tried to run it, failed and came here to cry.

This post is from 2016, 4 years later, Typescript is stronger than ever.

Personally, I rewrote like 10 back-end applications (Express / Koa) to Typecript because the benefit is obvious to someone who works intensively with Javascript.

Maybe in some years Javascript could help the IDE, at the moment i will continue with typescript.

@FostUK

This comment has been minimized.

Copy link

@FostUK FostUK commented May 28, 2020

What I'm sick of:
Every single open source js project now has a pr to convert it to Typescript and/or add typings files. Which then slows down development for the repo owners and complicates things for anyone wanting to contribute.

It's also sad that there appears to be more emphasis on ts than unit testing. TS gets in the way of refactors whereas unit tests give you confidence.

Also - people telling us that ts enables amazing code completion in vscode - yeah we've had that in webstorm with plain js for years.

Also - the "it's a superset" lie - which has bitten me several times.

Also - trying to get the builder to integrate with anything non-standard like a global js lib :(and then you have to run it through Babel anyway.

Also - why choose the worst types system ever? Did they not know about Haskell at least? I feel like Typescript is maybe for people who only want to program with classes.

Genuine question: how many type errors do people get? I counted 2 last year that were found immediately at runtime and I have had one issue this year with a lib that needed a number as a string that ts might have spotted (although prob not as the lib had no typings). Maybe the projects I'm on are more runtime heavy.

@rodelrebucas

This comment has been minimized.

Copy link

@rodelrebucas rodelrebucas commented May 30, 2020

I came here after I read Typescript:Handbook. I Hate it.period. But, I'll still used it 'cause I'm a lone cursed developer.

@osddeitf

This comment has been minimized.

Copy link

@osddeitf osddeitf commented Jun 14, 2020

I completely agree with you. I have struggled for so long about whether or not should I use it.

At first, Typescript is popular, so I give it a try.
First thing first, I usually look for documentation, which I prefer official ones.
But it's messy like hell.
And I have faced countless time the shitty things like type mismatch complaining.
Then when I'm sure I'm correct, I just add the suffix as any. (DON'T TRY THIS AT HOME, LOL)
When I more careful, I tried to solve it, and all the solutions I see just like workaround.

Today, when I tried to change my React project to Typescript, it's complain:

Type '{ children: Element[]; logoText: string; logo: any; image: any; handleDrawerToggle: () => void; open: boolean; }' is not assignable to type 'IntrinsicAttributes & InferPropsInner<Pick<{ handleDrawerToggle: Requireable<(...args: any[]) => any>; logo: Requireable<string>; image: Requireable<string>; logoText: Requireable<...>; open: Requireable<...>; }, never>> & Partial<...>'.
  Property 'children' does not exist on type 'IntrinsicAttributes & InferPropsInner<Pick<{ handleDrawerToggle: Requireable<(...args: any[]) => any>; logo: Requireable<string>; image: Requireable<string>; logoText: Requireable<...>; open: Requireable<...>; }, never>> & Partial<...>'.  TS2322

What are IntrinsicAttributes, InferPropsInner anyway?
And the very long message frustrated me, so I don't wanna try to read either.

I've been long hatred of OOP, as many complexity and abstraction are waste of effort.
Javascript with types is not bad, just Typescript is a mess.

@jorgellose

This comment has been minimized.

Copy link

@jorgellose jorgellose commented Jun 14, 2020

I completely agree with you. I have struggled for so long about whether or not should I use it.

At first, Typescript is popular, so I give it a try.
First thing first, I usually look for documentation, which I prefer official ones.
But it's messy like hell.
And I have faced countless time the shitty things like type mismatch complaining.
Then when I'm sure I'm correct, I just add the suffix as any. (DON'T TRY THIS AT HOME, LOL)
When I more careful, I tried to solve it, and all the solutions I see just like workaround.

Today, when I tried to change my React project to Typescript, it's complain:

Type '{ children: Element[]; logoText: string; logo: any; image: any; handleDrawerToggle: () => void; open: boolean; }' is not assignable to type 'IntrinsicAttributes & InferPropsInner<Pick<{ handleDrawerToggle: Requireable<(...args: any[]) => any>; logo: Requireable<string>; image: Requireable<string>; logoText: Requireable<...>; open: Requireable<...>; }, never>> & Partial<...>'.
  Property 'children' does not exist on type 'IntrinsicAttributes & InferPropsInner<Pick<{ handleDrawerToggle: Requireable<(...args: any[]) => any>; logo: Requireable<string>; image: Requireable<string>; logoText: Requireable<...>; open: Requireable<...>; }, never>> & Partial<...>'.  TS2322

What are IntrinsicAttributes, InferPropsInner anyway?
And the very long message frustrated me, so I don't wanna try to read either.

I've been long hatred of OOP, as many complexity and abstraction are waste of effort.
Javascript with types is not bad, just Typescript is a mess.

So you expected to change the "language" without any problem, next time write it directly in typescript, for me is practically the same as change it to .dart and spect somehow it will work.

Architecture is a waste of effort depending of the complexity of the app, maybe is an overkill for just 3-4 scripts but its necesary for a project with thousands of functions.

Finally the "dont try this at thome", any is exactly for that, maybe you dont need the types in some place of your app becouse you need more flexibility.

@MarkAndrewJohnson

This comment has been minimized.

Copy link

@MarkAndrewJohnson MarkAndrewJohnson commented Jun 16, 2020

Having been using TS for less a month in our new service as we begin a major functional rewrite from our monolith (one component within it for now), I'm finding TypeScript is working AGAINST me with often very obscure errors that make no sense (incorrect errors, line numbers, etc) and not finding my ACTUAL bugs (non-type bugs), than working WITH me. I seem to spend a lot more time dealing with cryptic errors than I ever did with vanilla JS. I feel like if I wanted a real type system I'd go with Java or something else (I start programming with BASIC then C/C++ and other languages, including Ada - extremely strongly typed!). I get people say it's a long-term investment but it's not feeling that way so far...

@aliakakis

This comment has been minimized.

Copy link

@aliakakis aliakakis commented Jul 14, 2020

I have been using TypeScript is some React based projects and to be honest we were battling with the language. Unfortunately code was unreadable in many cased but I believe that it was also because the lead front-end was just hyped-programming instead of actually developing the features needed. Most of time we were trying to understand cryptic errors. In many cases I found many typings redundant. I would favor flow ONLY because it opt-in/opt-out, which can be possible with TS unless you have a very strict TS linter.
To be completely honest static typing for state management stores is useful but ONLY for payloads.

@beebase

This comment has been minimized.

Copy link

@beebase beebase commented Jul 21, 2020

wow, this thread is still alive after 4(!) years...
Beside the fact that TS feels/looks horrible, what's the point in using it?
Am I the only one who hardly ever creates type related bugs? I know I'm good at screwing up business logic, but type errors??
It just never happens.
Besides, I use a very simple naming convention for variables by prefixing them.
(s=string, i=integer, b=boolean, o=object, a=array, ai=array of integers, ao=array of objects etc..)
const sName = "John"
const bMember = true
const oCar = {sBrand:'Honda', iCylinder:4}
const aoCar= {oHonda, oFord}
const aiYear=[2011, 2012,...]
Makes reading a breeze, cause you always know what you're dealing with in any line of code.

@jorgellose

This comment has been minimized.

Copy link

@jorgellose jorgellose commented Jul 22, 2020

jajaja aoCar, sname... pfff
Maybe the problem is not about "primitives" but about complex types.

const cars is an array of objets of type car, name is string it cant be a boolean (if so, you have a problem)

@UiCandy

This comment has been minimized.

Copy link

@UiCandy UiCandy commented Jul 23, 2020

The thing that still beats me that it's usually touted as something which 'Improves developer experience' .... you what mate?
Experience of being tortured trying to decipher errors which are 200+ characters and yet manage to say nothing at all.

@aliakakis

This comment has been minimized.

Copy link

@aliakakis aliakakis commented Jul 24, 2020

Angular API. In all seriousness its unreadable e.g. https://angular.io/api/common/http/HttpClient

@boazblake

This comment has been minimized.

Copy link

@boazblake boazblake commented Jul 28, 2020

types**** is another example of micro$oft$ doing what micro$oft$ does: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish

@Jorge-Luis-Rangel-Peralta

This comment has been minimized.

Copy link

@Jorge-Luis-Rangel-Peralta Jorge-Luis-Rangel-Peralta commented Aug 11, 2020

I made the migration to ts of my main project. And I not only in love with it, but also manage to change the main of at least half my team. I hate Java an OOP, so it strikes me ass odd that a lot of comments are about how ts is trying to make a Java out of js. It truly isn't, in the time working with ts, not a single class has being written. PD. YOU HAVE TO NOW JS AS YOUR OWN FACE TO WORK PROPERLY WITH TS

@Jorge-Luis-Rangel-Peralta

This comment has been minimized.

Copy link

@Jorge-Luis-Rangel-Peralta Jorge-Luis-Rangel-Peralta commented Aug 11, 2020

Also, Angular is awful, I agree

@FostUK

This comment has been minimized.

Copy link

@FostUK FostUK commented Aug 21, 2020

Urggh, just trying to alter an npm module's tsconfig to output ES6 modules instead of commonjs. Now running build has loads of /babel__traverse errors.

Literally every time I touch TS I end up wading through cryptic errors.

Piece of shit.

@awhite234

This comment has been minimized.

Copy link

@awhite234 awhite234 commented Aug 22, 2020

I rarely weigh in on these discussions, but Typescript fundamentally cripples an otherwise decent prototypical language for rapid prototyping on both back and front end. I also feel it does not IMO promote safer code for junior software engineers and instead increases complexity for all parties.

The challenges with typeless languages that TS attempts to resolve - e.g. ambiguity between types - are honestly rarely encountered and easily mitigated by teams of all experience levels. So ultimately it adds little but more boiler plate in a language that I would pick purely for coding speed.

I can only see it being useful for easing maintenance pains of parts of legacy JS applications that rely heavily on vanilla JS objects (due to interfaces).

@wilmol

This comment has been minimized.

Copy link

@wilmol wilmol commented Sep 8, 2020

Typescript doesnt even work. Pure garbage language.

@gdeliana

This comment has been minimized.

Copy link

@gdeliana gdeliana commented Sep 16, 2020

OK dear JS DEV community,

I am a web developer that started my career by self motivation and self learning and i don't have computer science in my background. I stumbled on Typescript a month ago because in my work a new DEV guy came from another company and he somehow managed to trick the lead developer to use Typescript.

After going through all the pain of reading many times the sugar coated features of Typescript, i just asked myself: BUT WHY ALL THE PAIN???

Is there any benefit to typescript?

I think typescript was created just to make JS look like JAVA so that some nerd devs could tell that hey i am still a nerd dev.

In Java types are for a reason, they actually make the language faster and optimize the memory usage (as well as in the other strictly typed programming languages) .......... BUT will JS have a memory optimization from being translated from typescript language? Unfortunately NOPE.

For you dear nerd devs that mention the documentation reason, i just don't get the fact how is it possible you take so long to understand what a variable type is, without using typescript.

But hey we are in some cool era for JS.

I mean, facebook brought React --- this is OK, it has a breakthrough -- the virtual DOM
Google - Angular --- crap as cant be more crap than that
Netflix - RXJS --- observables ...... wow, at the end is just for making async functions
And of course we couldn't miss our dear Microsoft, the fancy organization of candy UWP apps, adding its fancy candy sugar into code: Typescript

But what has changed at the end? Yeah we just produce html 👍

@stoplion

This comment has been minimized.

Copy link

@stoplion stoplion commented Sep 17, 2020

If they built better tooling around it might be better. I surround my JS with an armor of types, and all I get is a tooltip in VSCode. Half the time it'll say something like 'UserType'. Great, thanks.

@matvey-andreyev

This comment has been minimized.

Copy link

@matvey-andreyev matvey-andreyev commented Sep 18, 2020

The result of TypeScript introduction at my job is that I personally have to write more code with same deadlines and same salary.

@jorgellose

This comment has been minimized.

Copy link

@jorgellose jorgellose commented Sep 18, 2020

I dont see how can you write much more code in ts, the extra code is only to help you, I prefer 45K lines of code over 40K without types/interfaces.

Javascript is very flexible, and flexibility in a team with many people is not allways good, in mini projects (200 files or less) maybe, becouse is easy to manage that sort of projects but in a big project (erp, ecommerce, ...) having types helps alot, specialy for new people

I am speaking allways about backend where having 20KB more of JS doesnt slow down your web, transpilers allways output more code and i dont recommend to use TS for front end (for frontoffice)

@matvey-andreyev

This comment has been minimized.

Copy link

@matvey-andreyev matvey-andreyev commented Sep 25, 2020

I dont see how can you write much more code in ts, the extra code is only to help you, I prefer 45K lines of code over 40K without types/interfaces.

Rant / whining below, be warned.

Everyone on the team says so. «You have to wait and you'll see benefits sometimes in the future, when you won't be able to pass a string to a number-accepting method».

In the meanwhile, current and everyday problems and slowness of development are almost pathologically ignored.

This all reminds me of an old tale, where parents, grandparents think about an axe that hangs on a wall, and, in the future it can fall onto their yet unborn son who will be asked to bring potatoes located under the axe. Summarises modern webdev to me.

The most painful thing in the recent two days was focusing an input in a VueJS + TypeScript project. It works in the browser. But it does not pass through testing pipelines because of TypeScript. I've written three completely different versions of working code, and all of them do not pass because TS does not care that the method exists. That method should exist on HTMLElement, not inside a Vue component. And I am nobody, my experience, whatever it is, is ignored by the soulless robot who can't reach a Vue method and notice its existence. Also, it is inside a component installed from elsewhere, and fixing it basically means forking it and rewriting it so that an input can be fully embraced by TS.

The code that passes is zero code or commented version of the above.

I know about learning curve and such and am waiting for the times when I get along with it, but currently a task simply can not be deployed for hours more that it should have taken.

Three versions of working code have gotten thrown away. A third party component has to be rewritten. Just to focus into an input from another input.

That is how TS makes me write more, do less.

@FostUK

This comment has been minimized.

Copy link

@FostUK FostUK commented Sep 25, 2020

I dont see how can you write much more code in ts, the extra code is only to help you, I prefer 45K lines of code over 40K without types/interfaces.

https://github.com/blindman67/SimplexNoiseJS

"A JavaScript rewrite of typescript Open-Simplex-Noise an implementation of OpenSimplex noise

The rewrite provides a 15-20% performance improvement on the typescript implementation, file size reduction from 24.28K to 14.66K, and a reduced runtime memory footprint."

@jorgellose

This comment has been minimized.

Copy link

@jorgellose jorgellose commented Sep 25, 2020

You dont need Typescript for a 300 lines "project", plz be serious, Typescript shines in a big project, SimplexNoise is just a library with a couple of functions (something can be usefull with 300 lines, i am not speaking about that)

And in fact, that´s not even true, i donwnloaded the project, compiled and it weights 11.6KB, pff...

TS => Compiled 11.6KB => Minified 5.08KB => compressed 1.52KB (rar, just now i dont have br/gzip compiler)
JS MINIFIED => 9.49kb => compressed 3.67KB

I dont see how de constants file can be comparable becouse in JS version he is making arrays with decode function when in TS versión he just pasted 1280 numbers in an array (he did the same with all the arrays, wich explains the "gain" in weight)

My work is basically all based on performance, i am very concerned about making the code as performant as possible (thats why i dont recomend the use of typescript in client side, where KBs matters) but in server side KB practically doesnt matters and so you can make use of Typescript and use types where you need (TS doesnt force you to write with types) i mean, var called age is number, var called name is string, you dont need to put "const name: string;" becouse it is obvious but maybe you dont need to know that OrderReturnHistoryState has X fields and OrderHistory has N fields, maybe it could help you showing you all methods/properties.

@FostUK

This comment has been minimized.

Copy link

@FostUK FostUK commented Sep 28, 2020

You make a good point in that back end work which can be generally an understood quantity (ie: you don't necessarily need to spike the work out) and in which you don't want errors trickling down to the user then maybe TS is a better fit (I would still argue that TDD is actually what you need though).

I work in games which, in my opinion, is a horrendous fit for TS. The performance benefit of something like assemblyscript might be worth the effort involved though.

@beebase

This comment has been minimized.

Copy link

@beebase beebase commented Sep 28, 2020

@FostUK I agree. TDD sounds more like common sense than TS.

@jorgellose

This comment has been minimized.

Copy link

@jorgellose jorgellose commented Sep 28, 2020

TDD and Typescript are different things, in one you write tests before implementation in the other you have interfaces/types/some sintactic sugar. You can use both at the same time, it depends completly on your project. (big team, short time, easy, the boss, legacy code...)

@milahu

This comment has been minimized.

Copy link

@milahu milahu commented Sep 28, 2020

every two four hours of coding the javascript logic, i spend one hour making tslint shut the f*** up ....
i would not call this "script"ing any more, feels more like engraving stones for the next 10 million thousand years
im always happy when i can delegate the "make tslint happy" work to the TS fanboys

@FostUK SimplexNoiseJS is three years old, typescript has improved since then.
also, i wildly guess they could have implemented the optimizations in typescript as well

@khrome

This comment has been minimized.

Copy link

@khrome khrome commented Oct 5, 2020

I believe Google's Angular 2 team knows that any JavaScript project written in a language other than JavaScript has a history of not having many support and mostly fail. Nevertheless they chose TypeScript. This says that Angular 2 is not just a web framework. It is almost like an SDK that is designed to be used across all platforms(hence the total seperation from DOM).

AFAIK they chose it because they were forced by the Ads team to support Dart, so they already had to build alternative language support. It definitely did not seem like a given, were that not the case.

@brent2333

This comment has been minimized.

Copy link

@brent2333 brent2333 commented Oct 20, 2020

I hate everyone that is trying to invent there own scripting language that really isn't a language at all cuz it doesn't run anywhere unless you compile it first to javascript anyway
I hate those who think javascript is a bad language or don't know javascript at all. It feels like they are invading our platform and trying to fit a square in to our circle.

Javascript is changing a LOT now, so they have no way of keeping up the speed with the new specification.

If you are going to make something that is meant for the web or NodeJS - Learn JAVASCRIPT not something else

😁

@aaron-goshine

This comment has been minimized.

Copy link

@aaron-goshine aaron-goshine commented Dec 11, 2020

I have been hands on developing pure JavaScript and ECMAScript base languages for almost 20years ... they all were create marketed and then been killed of as result of redundancies... (LiveScript, J-Script, ActionScript, Dart, CoffeeScript, Silverlight, JavaApplet, ....the ones that is not even worth a mention)
so trust me when I say ... Flash action script once had 99 percent market shares in browser usage world wide.. (Flash action ActionScript is now the enemy and is outlawed in most companies, yeah you heard that right)---
I have written well test highly optimised vanilla JavaScript .. that is still running flawless for more that a decade .. and continue to add lots of business value (making £** Millions)--- replacing JavaScript is very hard --- especially with something more constraining
JavaScript will always adopt the good part from any worthy languages ( C, lisp, Haskell, Erlang ) and if TypeScript has anything that is universally useful ... JS will adopt it in due form .. effectively making TypeScript obsolete .. you wait and see

http://www.goshine-dev.co.uk/

@jorgellose

This comment has been minimized.

Copy link

@jorgellose jorgellose commented Dec 11, 2020

Typescript has 8 years, y started to use it 6 years ago, i dont see what are you trying to tell us, ¿dont use typescript because maybe in 10 years more it will be obsolete? Same can be applied for any language itself, in last 5 years of Javascript it has evolved alot maybe you say that better dont write code because in 2020 you have async/await, private accessor, classes (not prototypes), fetch (in browsers), etc...?¿

On the other hand, i dont see how Typescript is going to be obsolete when it covers something that javascript cant achieve without practically rebuild the language (types), i dont want to bloat front end js with for example interfaces than are only usefull during development

@diogo405

This comment has been minimized.

Copy link

@diogo405 diogo405 commented Dec 17, 2020

+1

@morganney

This comment has been minimized.

Copy link

@morganney morganney commented Dec 18, 2020

@Jorge-Luis-Rangel-Peralta

This comment has been minimized.

Copy link

@Jorge-Luis-Rangel-Peralta Jorge-Luis-Rangel-Peralta commented Dec 18, 2020

aaron-goshine

Let just say that tomorrow, js adopts a type system so, tomorrow is the day I should re-write all my ts codebase in js with types?.

I mean, it would be great for js to implement types as an ECMA standard, but that will not mean the dead of ts, sure I will ask my team to slowly write js compatible code so one day we will not need ts, but that is not a good reason to not use it now.

To the contrary, is a reason to already put types on our code base, the transition will be easier.

And again for the comments abobe, In my two years writing ts, I had never written a single class, nor in the server, nor in the client, so no, ts is not java, it's far from it. I dislike OOP a lot, by the way

@fesaza

This comment has been minimized.

Copy link

@fesaza fesaza commented Jan 8, 2021

Typescript makes React development boring!!!!

@Jorge-Luis-Rangel-Peralta

This comment has been minimized.

Copy link

@Jorge-Luis-Rangel-Peralta Jorge-Luis-Rangel-Peralta commented Jan 8, 2021

Typescript makes React development boring!!!!
and why is that?

@Rabios

This comment has been minimized.

Copy link

@Rabios Rabios commented Feb 17, 2021

Great, I'm not the only one who hates it!

@djmisterjon

This comment has been minimized.

Copy link

@djmisterjon djmisterjon commented Mar 8, 2021

heum wait, you can just do js inside ts file and avoid all others features.
I dont like pure ts, because weird syntax, but mix your js with ts is awesome.
Jsdoc are also supported in ts but only for information, no more error lint for jsdoc.
*In ts , you just add (if you want) the definition next to your symbole!
*In js , you add your definition and doc up to your symbole.
Example:

/**
   * js doc (with some ts hack)
   * @param {object} props Component props
   * @param {React.ReactNode} [props.children] Childrens passed by parents
   * @param {function(MouseEvent|React.PointerEvent):void} [props.onChange] - Using function():return
   * @param {import('csstype').Property.FlexDirection} [props.FlexDirection] - Using Import()
   * @param {React.CSSProperties['flexDirection']} [props.FlexDirection] - Using array ['propkey']
   * @param {Container.prototype['props']['orientation']} [props.orientation] - Using componment propTypes
   * @param {Partial<props>} [props.partial] - Using partial ts ..
 */

image
https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html

ts allow more sugar definition in your js project and also import ref definition more easily for avoid (circular shit) with modules!
Yes you can use ts as value also if you really need ! it will generate js for you.
Same as jsx generate html for you.
I use it sometime to fix some impossible ref definition in js.
example:
image

If you dont like ts, just dont use it as values, but as documentation to ref your architecture correctly.
Keep also you jsdoc, is supported and give more information !

But yeah , me too i dont like pure ts, weird and complex syntax, and only in English , no local support!
But you dont have to choose between ts or js !
ts is js ! ... hum let say js++ !


the only real major problem, is that sometimes the definition is not computed and this reduces the productivity, you can with some weird hacky way to get cumpute defenitions, but we waiter for a options !

@vladislavnabatov

This comment has been minimized.

Copy link

@vladislavnabatov vladislavnabatov commented Mar 23, 2021

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

@andykras

This comment has been minimized.

Copy link

@andykras andykras commented Apr 3, 2021

Thanks, absolutely agree. I have 15 years experience with deep C++, C# and JavaScript. And I can say that modern JS is rocks! When you write code on Typescript it's always a struggle with compiler to produce a good JavaScript, so why not straight away write in JS. To me, answer is obvious, it's just wasting my time when writing on TS.

@jorgellose

This comment has been minimized.

Copy link

@jorgellose jorgellose commented Apr 17, 2021

Thanks, absolutely agree. I have 15 years experience with deep C++, C# and JavaScript. And I can say that modern JS is rocks! When you write code on Typescript it's always a struggle with compiler to produce a good JavaScript, so why not straight away write in JS. To me, answer is obvious, it's just wasting my time when writing on TS.

Maybe you compile to es2015 or something worse, typescript outputing ES2018-2019-2020 seems correct to me.

This post was from 2016, yo can see how the world is accepting typescript, many big projects have been rewrite in typescript and report less bugs and faster developments

image

@andykras

This comment has been minimized.

Copy link

@andykras andykras commented Apr 20, 2021

Maybe you compile to es2015 or something worse, typescript outputing ES2018-2019-2020 seems correct to me.

This post was from 2016, yo can see how the world is accepting typescript, many big projects have been rewrite in typescript and report less bugs and faster developments

Typescript is nice, but it's just another language. Yes, it's semantically a superset of JS, but not every JS will be compiled as TS. I love JavaScript and I have nothing against those who love TypeScript. I just stick to the idea that it's better to learn how to write a good code, rather than pursuit silver bullet for JS. Based on my experience, code on JS is easier to read, simpler to change. Also I haven't faced with bugs that would be because of JavaScript itself. For undestanding, my main language is modern C++, I used to write in C# in the past (which has a lot of common with TS), and I really love static typings, I just don't think it's a silver bullet for JS\web development.

@ManelGonzalez-ops

This comment has been minimized.

Copy link

@ManelGonzalez-ops ManelGonzalez-ops commented Apr 27, 2021

At least writing Typescript without the NoImplicitAny to false in the frontend it's a fucking joke. You even have to type any events no matter how obvius it is what it's happening you have to write HTMLEventCLickblabla<HTMLDIv....> blablabla in every function it's just ridiculous.

@ReasonableDescent

This comment has been minimized.

Copy link

@ReasonableDescent ReasonableDescent commented Apr 28, 2021

"It's like they are trying to put a square in a circle hole." The hole must not have a strong enough argument type.

@Irrelon

This comment has been minimized.

Copy link

@Irrelon Irrelon commented Apr 29, 2021

Personally I think the issue with TypeScript isn't so much what it attempts to do (create type safety on top of JS) but that the type notations are horrible and simply not user friendly. Code is for humans. If you've been coding JS all your life it is very jarring to read something like this because it engages your brain's object parser, JSON parser, HTML parser and JS parser all at once:

type StringPredicate = (str: string) => boolean;

function pred3(...[str]: Parameters<StringPredicate>) : ReturnType<StringPredicate> {
    return str.length > 0;
}

Now consider something like this:

// Declare a function type
type stringPredicate = boolean (string str);

// Function declaration telling compiler that pred3 will adhere to stringPredicate's format
stringPredicate pred3;

// Function definition / implementation
const pred3 = (string str) => {
    return str.length > 0;
}

Personally something like the above is more readable, more natural and more familiar for anyone who's been coding for more than 5 years (seen other languages, used C++ etc).

OR JSDoc

We've had JSDoc for YEARS and creating a realtime type safety system utilising JSDoc notation is as easy as creating TypeScript. JSDoc requires no change to functional code so requires no compilation step, no source mapping etc. I'm not fundamentally against type safety, but the notation TypeScript uses is sub-optimal and should be revisited.

As MS says, "TypeScript began its life as an attempt to bring traditional object-oriented types to JavaScript so that the programmers at Microsoft could bring traditional object-oriented programs to the web." - Developers who are pushing TS as a one-lang-to-rule-them-all need to spend a bit more time coding... soon enough everything like this becomes a fad that has passed.

@sunoterra

This comment has been minimized.

Copy link

@sunoterra sunoterra commented May 7, 2021

another point is that the type checking does not even happen at runtime. i.e.

-) outside of the editor, it's imaginary.
-) it has no bearing on actual runtime reality.

meaning, one is literally wasting one's time by addressing complaints it has about your code. seriously.

all so some HDD n00bs (who pro'lly think Javascript [ES's most common knick-name], jQuery, Angular, React, etc are all different languages, instead of what they actually are, which is just a pre-agreed method of authoring ES) can feel warm and fuzzy about it, whilst they gaze upon it in their favorite editor.

imo, projects like https://elm-lang.org/ should get more attention.

@Celsiusss

This comment has been minimized.

Copy link

@Celsiusss Celsiusss commented May 9, 2021

What I hate about typescript, is that I end up dealing with these insane types that no one can read

const register: {
    <TFieldElement extends FieldElement<Record<string, any>>>(rules?: Partial<{
        required: string | boolean | ValidationValueMessage<boolean>;
        min: ValidationRule<React.ReactText>;
        ... 4 more ...;
        validate: Validate | Record<...>;
    }> | undefined): (ref: (TFieldElement & HTMLInputElement) | ... 3 more ... | null) => void;
    (name: string, rules?: Partial<...> | undefined): void;
    <TFieldElement extends FieldElement<...>>(ref: (TFieldElement & HTMLInputElement) | ... 3 more ... | null, rules?: Partial<...> | undefined): void;
}
@HunterKohler

This comment has been minimized.

Copy link

@HunterKohler HunterKohler commented Jul 9, 2021

Fantastic points man. I have been trying to decide, but being used to C++ types and templates, this just feels wrong, and totally overdifficult. And, an ISO standards man like myself hates them diverging from ECMA standard and creating such a widely dependent community.

@beebase

This comment has been minimized.

Copy link

@beebase beebase commented Jul 9, 2021

jajaja aoCar, sname... pfff
Maybe the problem is not about "primitives" but about complex types.

const cars is an array of objets of type car, name is string it cant be a boolean (if so, you have a problem)

Either you are very sloppy at typing (maybe that's why you love TS) or you have no clue what I mean..
oCar.sName is pretty much self explaining.
We have an o(object) Car with a prop s(string)Name.
I f*cking hate TS. It's hijacking JS and spreading like a tumor.

@sha-hin

This comment has been minimized.

Copy link

@sha-hin sha-hin commented Jul 11, 2021

The most thing I feel disgusted when it happens, when I got a project and the client requesting that we should use TS.
Even I prefer to use strict typing in any language that support it, but I don't feel it's fit here, and there's no standard way to debug errors.
Yes TS prevents some errors but not most of them and I don't think it's worth it to waste all this time for those errors that will prevent.

@djmisterjon

This comment has been minimized.

Copy link

@djmisterjon djmisterjon commented Jul 11, 2021

The idea is not to build a 100% TS app !
TS can be used like layer above JS only !
Most will develop in JS, and only if necessary will add a TS layer to properly references the projects behaviors.
An App 100% in JS will be easy!, but a Software! or a complex API !, will quickly becomes unmanageable, ambiguous references that point to others ambiguous references! TS is the top layers which simply guides the JS project.

It offers a lot of useless functionality that you can do in JS if you want !, but using it as layers to references your architectures is a big ++!
I see it more as an evolution to jsdoc!
Before we used jsdoc for refs , now have TS for refs js project !

TS simply eliminates ambiguities and also errors, but it is mostly ambiguity that is the problem in a development with no typed language !


What I hate about typescript, is that I end up dealing with these insane types that no one can read

const register: {
    <TFieldElement extends FieldElement<Record<string, any>>>(rules?: Partial<{
        required: string | boolean | ValidationValueMessage<boolean>;
        min: ValidationRule<React.ReactText>;
        ... 4 more ...;
        validate: Validate | Record<...>;
    }> | undefined): (ref: (TFieldElement & HTMLInputElement) | ... 3 more ... | null) => void;
    (name: string, rules?: Partial<...> | undefined): void;
    <TFieldElement extends FieldElement<...>>(ref: (TFieldElement & HTMLInputElement) | ... 3 more ... | null, rules?: Partial<...> | undefined): void;
}

Types utilities are not supposed to be read !! you can or you should use it only as a layer above your js codes !
In most case , you make one folder where you add all utilities types , and you import types to you JS codes (where they are in .ts .tsx )
So you can code in vanilla JS and just user or add TS flags for better Intelisence, generating types and refs !
Same as Jsdoc , but more powerful !

@alienspaces

This comment has been minimized.

Copy link

@alienspaces alienspaces commented Jul 20, 2021

+1 👍 A big fan of strongly typed languages (Go, Dart), generics are great when used wisely, not a fan of Typescript, the tooling, and the obfuscated mess it makes in a project.

@wjjmjh

This comment has been minimized.

Copy link

@wjjmjh wjjmjh commented Aug 10, 2021

One of my friends claimed he is a big fan of ts and he strongly recommenced me to use it. I laughed when I saw he used any everywhere in ts codebase.

Such a joke language, broke the beauty of JS

@FostUK

This comment has been minimized.

Copy link

@FostUK FostUK commented Aug 10, 2021

Yeah I have someone telling me about how Typescript adds the optional chaining operator - sigh.

@jorgellose

This comment has been minimized.

Copy link

@jorgellose jorgellose commented Aug 10, 2021

Optional chaning is not suported in some iphones at the moment, so you still will need something that reads your javascript and trasnforms it to something different if you want to suport a great amount of dispositives.

In any case in typescript we can use it practically since the start, and in vanilla javascript since last year.
Probably all the typescript features will arrive to Javascript (except types, the most important thing), at the moment with javascript we are waiting getters setters private methods class static and not static properties, etc..., when they arrive to the language, you would need to wait another year (if no more) to use it without transpilers (transpilers wich bloat your code more that typescript)

I love both, javascript and typescript, but for big projects i dont see the point of use just javascript, types help me too much, specially with refactors

@Irrelon

This comment has been minimized.

Copy link

@Irrelon Irrelon commented Aug 11, 2021

@jorgellose > when they arrive to the language, you would need to wait another year (if no more) to use it without transpilers (transpilers wich bloat your code more that typescript)

How do polyfills used by TS transpilation differ from those used by JS transpilation? Both are transpiled to utilise language features not yet released. Where is your evidence that TS transpiled code is less bloated?

@joetidee

This comment has been minimized.

Copy link

@joetidee joetidee commented Aug 17, 2021

The TS syntax makes my eyes bleed. The Typescript tax is very real and I was looking for some solace from Eric Elliot to try to turn around the TypeScript adoption. I'm really struggling to understand why people use it.

@Irrelon

This comment has been minimized.

Copy link

@Irrelon Irrelon commented Aug 18, 2021

@joetidee Agree completely. It's much less the mission and much more the implementation that is suspect. JSDoc may not be perfect but it's readable and doesn't interfere with your code. TS requires rewriting code JUST to support type annotations that are freaking horrible. JSDoc does type annotations without modifying your executable code at all and its actually readable by a human being. I seriously cannot understand why anyone thinks the Typescript "language" is worthwhile.

I can only assume that 99% of TS proponents have no knowledge of JSDoc or the capabilities it has and many have probably come to development recently rather than being in the industry for years. I cannot think of a single thing TS can do that JSDoc cannot. Anyone?

Maybe TS proponents are people who use VSCode and never any other IDE so don't know what the JetBrains IDEs like WebStorm do when they load a project with JSDoc. If I wasn't looking at the code, I wouldn't be able to tell the difference between the intellisense from JSDoc based code or TS based code, so what's the point of TS?

What is the definition of "better"? TS better than JSDoc? TS would have to be easier to read and write (it's not), quicker to read and write (it's not), quicker to modify when needed (it's not), produce more performant code than hand-written JS (it doesn't), be more fun to write (it's not) etc.

Arguments used for TS that I've seen in this thread:

  1. TypeScript brings new language features before they are released - ERM... babel

  2. TypeScript checks your code for errors based on types you are using - ERM... JSDoc + a decent IDE has been doing this for years, I get red lines and can pinpoint exactly where the passed value differs from the type declared by JSDoc, including what type is being passed and what is expected

  3. TypeScript makes you a better programmer - ERM... experience does that, not the language you write

  4. TypeScript doesn't need to be used everywhere, it can be a layer on top of your JS code - ERM... never worked anywhere that didn't take an all-or-nothing approach, and this argument sounds like a gateway drug dealer trying to get you hooked

  5. TypeScript makes refactoring easier - ERM... flat out no. It makes it MUCH MUCH harder. Part of the joy of web development is trying something and instantly seeing the result. With TS we are back to compile steps, type complaints before you're finished refactoring etc... it sucks the joy out of web development. Even if you have to compile because you are using babel, it's way faster in a large codebase than TS so you get to iterate quicker.

As the author of many open source and closed source (large) projects (Isogenic Game Engine, ForerunnerDB, Irrelon Path, Orbzu to name just a few), I'm not a newbie to this space. I've seen it all before. TS is at best a useful parsing tool when used with vanilla JS and JSDoc, at worst it is a cancer on the entire JS ecosystem.

Oh, and this is what documentation looks like autogenerated from JSDoc comments - or even including example code, right in the JSDoc... show me docs generated from TS... oh yeah, you can't, because no description exists for any of the type data.

@jorgellose

This comment has been minimized.

Copy link

@jorgellose jorgellose commented Aug 18, 2021

Of course you can have property description´s lol. Just comment your types and you have descriptions in your documentation and in the whole IDE.
Ts is very similar to other typed languages, like C #, .net core 5 is a beast, so i dont think is something bad to have the possibility to switch to a faster language for CPU intensive microservices with less effort.

@Irrelon

This comment has been minimized.

Copy link

@Irrelon Irrelon commented Aug 18, 2021

Of course you can have property description´s lol. Just comment your types and you have descriptions in your documentation and in the whole IDE.

@jorgellose do you have an example? I would like to see how it's done!

@mjobuda

This comment has been minimized.

Copy link

@mjobuda mjobuda commented Sep 2, 2021

TypeScript is almost as terrible as Windows!!! Who creates this nonsense?
Should I call this BPScript aka BoilerPlateScript or rather BSScript?
Rather the latter!!! The only reason this piece of ***** is to make people dependent on M$$$. There is no other reason of existence for it. They implemented all kind of features which prolonges the process to build software. It's a nightmare. I really can't see any good intentions of it's creators. It's a pile of **. I used more then 10 languages in my 20 year long SW dev career and BSScript is by far the worst experience I had. It has so many features that don't make any sense besides of forcing their users to produce boilerplate code.
Yes. People who think this language is good haven't used any other language so they don't know that most of the code they produce is boilerplate. It's like somebody lived all her life in north korea. Everything that is done in TS is horrible. There is no piece of software in TypeScript that is well written because it is not possible to write good code with this language.
Most prominent example: VScode. I did some plugin development for this piece of garbage.
I stopped using VScode after this!!! All I wanted to do is map a functioncall when the user presses F3.
Do you think that this was as simple as setting it in a mapping like ...'F3' : myFunctionCall() ...?
Of course not!!!! This would be against the philosophy of the whole ecosystem!!
You have to set it up in a few places and read tons of documentation which is very unprecise written.
And then they give you tons of examples to study with millions of lines of code.
It's the typical product of a monopoly.
For another product I won't mention here to make to many enemies I need a string from the config.
I has a mechanism for configuring stuff, so i thought it should be trivial to set&get a string.
Boy was I wrong!!! Not in TypeScript world. I asked the question in their official Discord server. There are 750 persons sitting there nad nobody was able to anwser this question. I have now the sus[icion that this software is also written only to make people dependent on it and sell them their services. And typescript is perfect technology for this kind of strategy! It's notfor making good software, it's usecase is to create unmaintanable software!!
Don't use TS. Use Javascript. You'll be way more productive and your product will be more stable and better, And waaaaaay more maintanable.
Or use Locomotive Basic fom 1984. Anything is better then this @
!@&
^^%!!

@Irrelon

This comment has been minimized.

Copy link

@Irrelon Irrelon commented Sep 2, 2021

@mjobuda I mean... don't hold back, tell us what you think! :p hehe... but yeah, I essentially agree with you on most of your points. The sad thing is, lots of developers actually think that TypeScript is the only way to have type safety in JS... through no real fault of their own... it's all marketing. JSDoc doesn't sound like a type annotation system does it? I wonder if it was re-branded as JSTypeDoc it would get more recognition.

@jorgellose

This comment has been minimized.

Copy link

@jorgellose jorgellose commented Sep 2, 2021

XD... impossible to achieve with Typescript and impossible to read with such differences with Javascript
image
image

M$$$ whants to control youuuuuuuu.... uuuuuuuuuu (spectral sound)

@morganney

This comment has been minimized.

Copy link

@morganney morganney commented Sep 2, 2021

Should I call this BPScript aka BoilerPlateScript or rather BSScript?

I prefer to call it HypeScript: any

@jorgellose

This comment has been minimized.

Copy link

@jorgellose jorgellose commented Sep 2, 2021

7 years of hype!!!

@archcra

This comment has been minimized.

Copy link

@archcra archcra commented Sep 24, 2021

For small team and agile project, I do not think TypeScript is the right choice.

@andykras

This comment has been minimized.

Copy link

@andykras andykras commented Sep 25, 2021

Now consider something like this:

// Declare a function type
type stringPredicate = boolean (string str);

// Function declaration telling compiler that pred3 will adhere to stringPredicate's format
stringPredicate pred3;

// Function definition / implementation
const pred3 = (string str) => {
    return str.length > 0;
}

👍 like it. Your version looks much better then TS one. Actually when I first time saw types notation, I think why not use C#/C++ semantics.

It's just ugly.

@Kamyil

This comment has been minimized.

Copy link

@Kamyil Kamyil commented Sep 28, 2021

Reading all of those comments makes me think that I found a place of people that just want to make a rant about a technology that they're very inexperienced with or people with very huge ego.
The reason why TS exists is not to force you to write OOP JavaScript, or want to make you love Microsoft for some reason (lol).
Because TS is just an extended JavaScript (like SCSS is just an extended CSS) with ability to write your own types. With much more robust tooling and better IDE features that allows you to f.e. auto-import modules from another files, rename things across files, use auto-fix features etc. in your favoruite IDE.

You're not forced to use OOP, you can write your all-functional code you want.
You're not forced to explicitly type every goddamn thing - you can simply use primitive types for your declared variables or type the arguments and then rely on type inference which will make you get TypeScript benefits with almost 100% looking like JS code.

and finally... there is a specific reason why TypeScript is widely loved by a lot of developers (according to surveys). TypeScript solves the problem of writing huge-scale applications with relatively low entry level. Because TypeScript will be almost always more explicit and precise about the problem than browser's console. Which makes your life much easier and you can

Of course you can always say "if you can't write JavaScript, then you're too stupid to use that language, go back to Java"
But if you're working with such an attitude with your co-workers... well. I feel sorry for your coworkers, because working with somebody with this attitude will almost always result into very unhealthy teamwork.

I would be rather be "that stupid guy" and allow my coworkers to understand the code better by defining bunch of types and interfaces with JSDocs on them to describe what code does and why and let the tool itself give feedback immediately for my teammates what they're doing wrong and why , instead of forcing my teammates to debug the code for hours just to understand basic concepts that app uses, because of my high ego.

If you want to discuss with me more in chat or have any TypeScript problem - you're welcome to PM me :) I can help

@mjobuda

This comment has been minimized.

Copy link

@mjobuda mjobuda commented Sep 28, 2021

"You're not forced to use OOP, you can write your all-functional code you want.
You're not forced to