TL;DR
TypeScript is mid. Use Rust or C# for example if you wanna go 100% strict. Otherwise, stick to JavaScript + JSDOC + some tooling....
For further actions, you may consider blocking this person and/or reporting abuse
So, the article seems very biased from someone who is a huge advocate for JS, rather than pointing out actual flaws of the Typescript language.
I think the point of time consuming learning the language isn't valid and again opinionated. The syntax is not that different compared to JavaScript in reality. There are much more convoluted language syntax out there e.g Python, C++ to name but a few.
verbosity, is the whole point of any real strongly typed language. Without it, everything is simply dynamic types, making it difficult to know the schema of an object. Again it's the whole nature / reasoning for a typed language.
In what way is syntax difficult. What are you comparing it with. You seem to be implying the syntax of JS is easy however TS really isn't that different.
Your testing point, I'm not following the scenario you're describing. Why would you wish to change the property of a type in a single test ? Are you referring to the value, or the type of the property ? If the latter I'd say you need to reassess the test / object needs
What are you are actually referring to. Why isn't it that great. You simply state your opinion but don't explain why.
The problem with the article is that all of the 17 reasons are subjective and highly debatable. Other devs (the ones who do use/like TS) are adamant that it does have benefits for them. Who is "right"? No idea, this is an endless debate, but I've never seen any arguments from either side which totally convince me.
The only thing I see is that the "market share" and usage of TS are growing steadily, and by now it's becoming dominant ... so all I can conclude is that "TS must be doing something right". Just from looking at the stats and the rate of adoption I think TS is the future, whether we like it or not.
I'm not sure language adoption is a fair metric. Some people are pushing the use of TS in all circumstances regardless of real interest. As stated in the article TS might be a great solution for large project. But not for smaller team with less experienced devs.
Yes, it is doing something which is keeping it in the market:
1- gives insight into the code to non-programmers and machines. Like AutoComplete tools in VS code and AI code analysers
2- it lets project managers micro-manage programmers and have a say on PRs and gives clues to organisation chart climbers.
3- restricts productivity and creativity so that companies are more likely to buy solutions than develop them. A good example can be using MS CRM rather than developing your own company tailor made system.
4 -by both ways cutting developers productivity and amplifying machine insights, it is facilitating machinized programming which is promoted by big techs and cloud provider and therefore they push for it.
Bold and interesting claims, not sure if they're backed up by facts and numbers :)
I am leaving JavaScript world after 6 years of specialist JavaScript/Typescript development. There are too many brain washed idiot developers there, generating dirty code and with Typescript being enforced I am really tired of shit cleaning. Convincing people doesn't help as all big mouthes are brain washing hundreds per minute, is waste of time. Going into Python for a while.
I'm now using Typescript in earnest for the first time on a project, and I can honestly say it's a better experience than I expected - no major issues so far ... not saying that it "must" be used instead of straight JS on every project, but the experience so far is not too bad.
Good luck with Python, my favorite backend language is PHP (with Laravel as the framework).
Thank you for your comment. I strive to provide quality content that is both informative and enjoyable to read. I am sorry to hear that you felt the article was not up to par in terms of your agreement with my opinion, which is ok.
Not only that, I am not quite sure if 17 flaws are not good enough to accurately convey my opinion in the language, but that doesn’t mean you should give up on my words altogether.
Furthermore, I think it is also important to keep in mind the context of my writing by taking the time to read my words carefully before responding. This will help you ensure that you don't miss any important information or points that I am trying to make.
Thank you again for taking the time to leave a comment. Have a good day/evening.
So, you write a subjective article about typescript, because you dont like it and when a reader raises some valid questions, instead of giving a substantive response, you respond with something along the lines of: "if you dont agree with me you're stupid". Or: "I'm so smart you dont understand me".
It seems to me that your only perogative here is to start a flame war and I hope people will report your abuse.
This was exactly my attitude when I started with TS. It's a very different mentality: when I learned JS, i got in the habit of runtime type checking. Getting rid of that, learning new idioms and considering compile time takes a lot of effort.
Change always takes effort, nobody will dispute that and the road can be challenging depending on your history, but to write an article like the author did and put in this amount of effort to come up with unfounded reasons not to change... Thats a really bad attitude. Furthermore, you can tell what the authors attitude is by the responses they gave to some of the replies they got that disproved the reasons they gave.
I don't think there is anything wrong with writing a subjective article. In fact, it can be quite helpful to other developers who are considering using the language. By reading about another developer's experience with TypeScript, they can get a better sense of whether or not the language would be a good fit for them. Additionally, subjective articles can provide insights into how best to use TypeScript in order to get the most out of it.
I know that objectivity is key when writing about technical topics. Next time I will focus on more facts and data rather than personal opinion or being subjective.
I mean, If I were to respond the way I wanted, I would look redundant. I would repeat the same points raised in the article, which is why I suggested reading it carefully. However, it is ultimately up to the reader whether or not they want to read it. I am not trying to prove that I am smarter than anyone but merely wanted to raise what seems to be important issues.
It is ok to remind people to use their damn minds.
But, is it worth it? I say "it depends". The best answer comes from looking inward and determining if the change you seek is for betterment. If so, then making the effort to change will undoubtedly lead to a more positive outcome full of new opportunities and experiences.
Everyone has their own perspectives, however, it is important to remember the code of conduct of the platform when publishing an article. Everyone has the right to express their opinion in a respectful manner, and by doing so, it will help ensure that any conversation remains civil and respectful.
Peace!
There is in no way any evidence to prove this. In fact, as I see it, all they did was pay devs working on React to do a number of talks when React came out. The React docs have sucked almost to this day aka no real investment (they just got reworked and are somewhat better now). They did very little in terms of video tutorials either. They definitely had no paid advertisements.
What they did do is hit a nerve of the JS community at the time, namely the acknowledged hackery of using jQuery to update the DOM when data changed. Using the power of reactive programming, React turned the frontend world upside down for the positive. Now everyone can let their data do the walking. That is why React is so popular.
Scott
When you decide to become respectful, we can carry on our discussion in a more positive and productive manner.
I actually agree with him...
Using typescript instead of native JS, the gain is minimal compared to the flaws. FrontEnd is UI/UX, it's only an interface, you don't need to make it over-complicated.
The simple concept of typing everything is completely irrelevant in Front where you only need to display numbers and strings, and send forms.
The business layer is Backend and must stay in there.
This! Also if you come from a background where you are used to using strongly typed languages, I would argue that picking up typescript is pretty straight forward. Point 16 seems like a "you" problem rather than an actual issue.
This article is highly subjective and I would argue kind of misleading and reductive to boot.
Why would someone switch from a strongly typed language to Typescript, which is less type-safe, probably not at all as @idleman pointed out. In my opinion, you better go for JavaScript if you are looking for forgiveness' sake. I mean, I don't get it. Is type safety a spectrum? I just don't see the point in sacrificing that level of safety for the sake of convenience. If you want convenience, use JavaScript(Also, I am not advocating for neither JS nor TS. But it just seems the logical fit in this case.)!
For me, the sweet spot between readability and type annotations is JSDoc. I find that it strikes a nice balance between the two. While bloating the code with type annotations can make it less readable, JSDoc, however, allows for a more powerful way of documenting our code by also providing type annotations.
Just sayin'.
because they have to because that's what their job uses?
this is click bait dude =)
TypeScript is the go-to language for both frontend and backend developers today. Poe's Law is preventing me from being able to tell whether you're actually serious or you're just trolling TypeScript fans.
I mean, you point out that there's more typing...and then duplicate the types in the TSDoc, which isn't necessary. The TypeScript types are vastly superior to the unverified and likely stale JSDoc comments. Also, having real types in your app, in my experience, speeds up development by 2-5x, so any extra actual typing is more than compensated for by the increased development speed.
And types aren't useful? Only if you press the
anybutton too often, which is another of your "downsides." Yeah, it hurts when I do that? Don't do that.And FlowType...which is used on Facebook projects and practically nowhere else. Where's the DefinitelyTyped equivalent? Pretty much absent.
And unit tests in TypeScript don't need to be hard to use. Instead of having them take a class parameter, have them take an interface that needs exactly the members you need in the function you're testing.
So many others are just reaching. "I hate Microsoft. Sort of." Really? Whatever.
Again, masterful troll, poor actual technical critique. TypeScript gets you to a level of software engineering impossible in JavaScript.
Haha:
"whether you're actually serious or you're just trolling TypeScript fans" ...
I'm pretty sure the author is serious, although for a moment I also thought he might be trolling.
Its both, he is serious but also trying to start a flame war at the same time because it helps his statistics. This article is going to be at the top of the listings for a while.
Yeah, and it's kinda sad. I'm very new to dev.to, just test-driving, but I think I'll just skip it (the same way as TikTok), if it continues with this content ballooning strategy (which I don't think it can/would change, actually).
I think the discussions are often fun, and in many cases they're more interesting (and sometimes even higher quality) than the articles proper ... the good thing is that the discussions (almost) always remain respectful and on-topic - kudos to the dev.to moderators!
I think it is always better to post good constructive criticism than to simply ramble on. However, there is always a time and a place for both types of comments. Sometimes, it is helpful to simply vent and get our thoughts and feelings out there, even if they're not perfectly articulated. But, It is better to post well-articulated arguments like what @tqbit did in his comment. Anyways, thanks for contributing to the discussion!
Strong disagree there. I have seen very few discussions with opposing views that remained respectful and when the author of the article shows their utter contempt of the people with different views (which is extremely disrespectful in my humble opinion but not against the rules for some reason). If the people in question respond, the dev.to mods ban THEM instead of the author who created the context and is the actual instigator of the disrespectful discourse. Discussions can be fun, but only if one of two scenarios is true: Either they moderate the platform equally and everyone who shows disrespect gets banned, OR you allow the community to moderate itself which means if someone acts like an ***hole, you can tell it to their face. Instead of the current situation where you get muzzled by the dev.to moderator team, while they allow the instigators (trolls) to continue.
People DID post constructive criticism with examples that proved some of your points were NOT valid and you responded by putting yourself above them and suggesting they didnt read your article properly. Thats arrogant and disrespectful and you should be banned for it in my humble opinion.
But not to worry though the dev.to team got your back and they will probably ban me instead for calling you out on your behavior. Succesful troll succeeds 👍
I completely understand that. I'm just like you, a human being who is trying to become perfect. And I know that it's not always easy. But I do think that some of the points in the article are still valid. Especially when it comes to using TSDoc to document your TS code, whereas you can use JSDoc with JS and it provides everything that TS has to offer.
That's what it seems like. If not the case, it is OK and I would be responding with the same points written in the article. That's why I suggested reading it. And it is also sad that some people are jumping straight into the comment section without even daring to read the introduction.
Hence my comment:
Sometimes, it is helpful to simply vent and get our thoughts and feelings out there, even if they're not perfectly articulated.
I think we also shouldn't be too quick and eager to be calling for others to be banned, something with the pot and the kettle ... ;)
Sometimes you just need to let it go, the way I see it is that discussions like these are mainly a bit of fun, even when they get "heated" - let's not take it too seriously and be TOO sensitive, it's not the end of the world.
More of this, Please. Thank you.
Maybe the author should let it go and just not use typescript if it upsets them so much. Instead of going on a dev platform and trying to start a flame war that might get others banned of said platform. 🤷
As much as I disagree with author, I think he is perfectly fine writing a controversial article like this. It's an opinion piece what can excite flaming, sure. But it can also be educational for others who don't have a strong inclination towards a side.
It is not a controversial article, more like educational because people don't know most of the stuff he points out. They are like you, refuse to accept the truth. But most points is correct.
If TypeScript provided real type safety, it would enforce every single type at runtime and for the most basic primitives, enforce memory constraints and so on, like Rust/C++.
Except theres nothing educational about it, as was already pointed out by several others. The examples are fabricated. In other words: the author is lying in order to provide argumentation for their personal opinion.
No, most of the stuff he mention is correct. You just don´t know better because you have been told massive with lies and cannot check it yourself. You probably want to believe it yourself too, making it even harder for you too see the truth.
One of TypeScript largest myth is about it has type safety, which is bs. You can cast anything to anything is TS, can it is by definition not type safe. In C++/Rust you cannot do it, because those language has REAL type safety. If you want to prove TypeScript is type safe, you need prove the "cast" operator do not exist in TypeScript and all objects has memory constraints (= fixed memory size). And this is 100% not the case.
Common kids, this debate is over 40 years old. Types don't make any real difference if you take everything into account. It is time to grow up, really.
You swap development speed for catching simple bugs, that never reach production anyway if you have a good tests (which is required anyway!).
Want development speed: Go JS.
Want types: Go Rust/C++ and compile it to WebAssembly
Want slow development speed and no type safety: Go TypeScript.
That is the hard truth.
I think you misunderstood what the word type safety means.
The ability to typecast does not make a language not type safe:
This is what typesafety means. You do not have to write arbitrary conditions in your code to check whether a function returned what you hoped it would return. Without typesafety the function above would look something like this:
And that check is still highly naive what if anotherParam is of a type (like undefined) that does not have a toString() method? Exactly, you get a runtime error.
Also if you think c++ does not have typecasting... youre just plain wrong: typecasting in c++
So come on kids, instead of acting like kids and talking BS about stuff you know nothing about, how about go read up on the things you want to talk about. In the spirit of that, I will admit I know nothing about c++, but that page about typecasting was easily found.
You have no clue what you are talking about. I know TypeScript claims to have type safety and I know they do static checks that is obvious wrong, but beside that, no fking type safety at all! They are just wishes, please give me an an object of "type" and you may get an object of "type", say an integer. In C++ and Rust if you say you want some primitive value, 100% of the time you you get it. Real typed languages have CPU constraints and memory constraints. You can simply speaking TRUST an int is an int if the type says it is an int. In TypeScript you cannot DO IT! It is just a wish.
You should not try to teach other people what type safety means, when you clearly does not know even be basics in programming beside some fancy TypeScript stuff that are 99% just adversating talk from the team that sell the product.
I am not against types, but if the language says it is type safe, and a lot of people just repeats the lie when it is simple to provide this is not the case, it is extremely annoying. Sure, I know TS core team know it is not type safe, but they want to sell their product so it is reasonable they continue to spread the lie. But rest of you, what are your excuse?
In my opinion, both Renske and you are overly aggressive in your style of debating ... we don't need to be over-sensitive but "you have no clue what you are talking about" and Renske's "BS" paragraph are examples where you guys resort to needless "ad hominems".
This article really started a flame war, nice for the entertainment if you're into it, but we're not really getting anywhere. My take on TS is, if you think it benefits you then use it, if you think not then don't use it.
Yeah, its my mistake. I don't mean to be so aggressive.
No worries :)
It was actual BS though. And they continue digging a deeper hole of BS. Tbh their nonsense is so far out there that it's not even worth responding to anymore.
Yeah, I'm with you there. You were appropriately calling a BS argument BS. That's not an ad hominem.
Saw a video recently about static types and C++ that had a related point: If you're arguing, you're losing.
We're arguing. They have an emotionally based disklike of TypeScript. We will never move the needle with logic.
I mean, above the surgery calls my post a ramble, and accused me of not reading the article. But then he goes on to repeat the same misinformation that I've already debunked. Speaking of not reading what was written.
Let them use inferior tools and celebrate that practice. There's nothing we can say to change their opinion.
The video is long, but it details a guy spending years trying to advocate for C++ in the embedded community, and he was far more patient and strategic than I've ever been--and yet he still failed. It's a good watch.
The points raised in the article are not correct as was already pointed out by several other commentors. The examples are fabricated and the only substance that remains is the authors personal aversion of Typescript.
I am sorry Typescript isnt working out for you. Nobody will force you to keep using it if you have convinced yourself that Typescript produces more runtime errors than using plain Javascript. Goodluck with that. 👍
Yeah actually I had a negative experience, once, with dev.to moderation - I received a one week ban, and my "opponent" as well, while my verbiage was still reasonably polite and moderate, while his was just extremely rude - but we both received exactly the same kind of slap on the wrist (one week ban) ! That did feel unjustified, but oh well, in a case like that you sometimes need to let it go and think "whatever".
I didn't do that. The compiler chose the
anytype, not my fault.It becomes harder when you decide all of a sudden you should change a specific variable type which reflects on the test case.
I mean, what's your decision when you realize that the CEO of the company you are working with shared such an opinion on Linux and open-source in general? Of course against him.
Sorry if you took it that way. I think you will change your mind if you ever considered reading it carefully. But, it is ok if it is not the case.
Thanks for leaving a comment, btw.
In javascript, in the best possible scenario your unit test then fails and you have to fix the code anyway. More than likely, your test continues to pass and your start getting silent errors at runtime.
Because you didn't enable strict mode. Which no TypeScript developer I've worked with would fail to do. So I wonder you actually use TypeScript that much.
The compiler chose
anybecause you have a var that is declared but not defined, and also not typed. If you don't give either a type or a value to a variable, then it's going to class it as any, so that you can put whatever you want into it, later.100% valid TypeScript.
Solved problem.
US dropped nuclear bombs on Japan. Japan slaughtered China. Britain colonized the world. I won't even say what Germany did. And yet, those countries are globally respected.
That CEO has been retired for a very long time. Nowadays Microsoft uses Linux to run their own servers and apps.
It's also worth noting that GitHub, VSCode, npm, Azure are also their products. Their representatives also put weight into development of things like OpenTelemetry, CNCF (cloud native computing foundation), WASI and many other important things.
The first example in "why use typescript" is not an example of Typescript not catching an error. It's an example of Typescript working exactly right. You said "TypeScript doesn't recognize the type mismatch and type-checks the code successfully" - there is no type mismatch. You literally said the function
pushaccepts arrays that contain numbers and strings. So pushing a number into it is perfectly fine. Arrays that contain mixed types is allowed, how else would you type something like that?If you want to do what it looks like you _meant _to write, you would say:
function push(arr: Array<number> | Array<string>) ...or if you didn't want to look like you read the TS hello world yesterday:
const push = (arr: number[] | string[]) ...In other words a function that accepts arrays of numbers or arrays of strings. Then it would notice that you didn't check the type in the
arr.pushcall. Perfect.Also your
Rectangleclass example is misleading. You say you're just comparing Typescript to JSDoc but they are two very different programs. Your JSDoc version doesn't allow strings and you're comparing it to a Typescript version that does allow strings. You also wrote it in a very naive way that should really be cleaned up. If you want to (very weirdly) allowstring | numbereverywhere, make that a type.type RectAttr = string | number, then use that everywhere. Bam, cleaner and more informative than the JS one. But since your JS version just completely blindly accepts any input and happily coerces it tonumberat runtime, it's not really showing the strengths you think it is. It sucks, frankly. What good is a program that runs without complaint when I write(new Rectangle({})).calcArea()? That shouldn't get past anything but it does.As others have suggested, this sounds like just an error of not having any experience using Typescript. This isn't even advanced stuff, that's the basics. I recommend you take some time and learn Typescript, once you actually get past hello world, it becomes apparent that it's very powerful.
There may be reasons to have misgivings about Typescript, possibly. But they'd have to be reasons that vanilla JS is better, and it simply isn't. This is very close to not even being a matter of opinion anymore. Even a mediocre type system (and TS is an excellent one) is better than none.
Arrow functions are now a higher standard, ok.
Alrighty. We have a TypeScript Chad over here. I have put this simple example intentionally just to show how people are ridiculously good at throwing insults, rather than pointing out how the compiler can sometimes act drunk. Since you have some TypeScript experience, I suppose you worked with enums before. So, could you please tell me what's wrong with the following enum?
And guess what? OMG, The strict mode is enabled! Could you please tell me what is the point of enums if it doesn't limit the values to just 0 and 1?
It would be great If you could prove that TS is better than JS.
Here you go another example when the compiler assigning the type to
anywhich is a valuable type to have, I guess?Result:
That said, I doubt that TypeScript is worth learning like at all. It trips you up a lot more than just writing vanilla JavaScript. In my experience, the benefits of using TypeScript are not worth the trouble it causes.
Have a good day.
Edit: I am not going to list every single flaw / common pitfall in TypeScript. You get the point. However, One fact still stands:
TS is NOT better than JS.
With the enums, well, congrats you found a skeleton in the closet of the language, a bad design choice made early on that they are trying to fix but are kind of stuck with. I'm sure Javascript has none of those. Enums just shouldn't be used in my opinion because they are not actually enums. As designed, they're meant to represent bit flags unless you use string enums. Instead, one should just use unions or one of the many other more enum-like things.
Keep in mind, Typescript isn't C# or Java, you have to actually learn it not just assume all the constructs work the same way.
Anyway, on to your next example. That doesn't compile for me. When I write
const object = this.foo.objects[index]it fails with "object has implicit typeany". As expected. This is from the noImplicitAny flag, which is also enabled by simply using strict mode as many of the comments in this thread have told you repeatedly is the standard if you want type safety.The
anytype only exists to babysit old bad Javascript code and idioms. It shouldn't be used explicitly nor should you allow things to implicitly become any, which is why the noImplicitAny flag exists.This is an assertion made without experience. There is no way this is true, javascript has libraries of books and exobytes of websites dedicated to teaching people how to avoid all the pitfalls and rough edges of Javascript, not use certain dangerous language features, and on and on. It trips up beginners and newcomers to the language by acting differently than expected (especially with people who think it's similar to the language it is named after). The language is full of surprises and weird behavior, it's practically a meme. Typescript takes many of those lessons learned and enforces them with a compiler which is eons better than a human at actually finding errors.
You're taking these few odd edge cases that many people never even noticed after using Typescript for years and saying because of this odd edge case the language is bad and not useful. This is absolutely hilarious and ironic coming from someone advocating for Javascript.
TS is significantly better than Javascript and to me, that's an objective fact. There may be some reasons to like JS still, from time to time, but usually not. Development time is faster in Typescript, quality is better, readability (the actual most important part of code) is better. All the complaints you may have about Typescript apply just as well to Javascript, but none of the benefits of Typescript apply to Javascript. You find weird edge cases that don't come up in practice and ignore the 99% of the time where the language does exactly what you expect.
As a professional software developer with 20 years experience and most of those using Javascript, I would never go willingly back to Javascript and actively promote upgrading Javascript (or Java for that matter) code into Typescript where possible. I also recommend against hiring anybody who would argue things like Javascript being preferable. Typescript is just so much easier to use and better on every level.
Ah, I see.
That's what I have learned from this example.
I see.
Got it!
I am not sure if I am the only one who doesn't understand the motivation behind TypeScript, but I will give it a shot. First of all, C#, also created by Microsoft, is a strongly typed language that can be used to create web applications. However, JavaScript is a dynamically typed language that can be used to create websites. So, my question is, what is the place for TypeScript in this equation? Don't get me wrong. I am not saying that innovation is a bad thing. What I meant to say is that it looks like TypeScript doesn't seem to me fulfilling a practical use case. However, it is highly likely to be acting like a bridge between C# and JavaScript, allowing developers to use familiar syntaxes while leveraging the power of dynamic languages like JavaScript. In this case, that would make sense.
Exactly. Hahahaha.
Cool.
Alright!
Now, we are talking.
Lol. Really? But, I think that advocating for either JS or TS is the same thing. Since you will end up with JS code in both cases. However, I think that C# is a better option than TS in my opinion.
Will see.
Your enum example has nothing to do with enums.
You are reassigning the chatStatus variable, it's not longer an enum. Its the same as complaining your array is no longer an array when you reassign it:
Obviously if you reassign a variable its not going to complain, since you are reassigning it... Reassignment is not a typescript thing, its a javascript thing. Thats how javascript works and since typescript is a superset of javascript, its also how typescript works.
This DOES throw an error:
This would ALSO throw an error:
Your comment shows the lack of understanding of what is the point of enums like at all. Besides readability, enums are used to limit the values in a certain range. In Java for example, you can't do this because
999999is a value outside the enum range [0 for Online, 1 for Offline]. Moreover, enums are mainly used in facade design pattern.Back to your rambling, you can't assign, however, a value of type
stringto an already declarednumbervariable:In the case of enums, the compiler should complain that
999999is outside of [0, 1].That's the whole point.
Have a nice day/evening.
Edit: I think TS is following the same C# philosophy where it can accept any value that a
numbercan. That's why999999doesn't throw any exceptions. Alrighty.Your point is that you want typescript to work exactly like C# Have you considered just using C# then?
In any case, congrats, you found one quirk in Typescript. Enums are implemented kinda shitty, according to you that invalidates the whole concept of Typescript... Good for you. Luckily most other developers are capable of being a little less biased. If you need to have typesafe enums in Typescript, you can try to not be an obnoxious hater and use unions like everybody else:
Yup, that's what most folks suggested.
You could have done somesthing constructive and wrote an article about why not to use enums in Typescript, explain to people its better to use unions. You would get less, but much better responses and people would actually learn something. Or if you have a suggestion on how Typescript SHOULD implement enums, you can make a pull request on their repo: github.com/microsoft/TypeScript or create an issue: github.com/microsoft/TypeScript/is... they are pretty open for constructive feedback from users.
Noted.
I am afraid to contribute to that repo cause, by now, every engineer at MS thinks I am mentally disabled or something along this line. LMAO.
OMG! I couldn't agree more! It's so refreshing to see somebody with level-headed thinking in this day and age. We need more people like you to help set the world back on track. Thank you for speaking up and showing true sanity!
"There are several frameworks that are objectively better than React" (emphasis mine).
I don't think you understand the meaning of the word "objectively". I can't think of many things in software development that are objectively better than other things.
Yeah... I mean... Abso-freakin-lutely!
Just the same that happens when you start a project with any language and platform.
The cost of redoing that is related to the team's expertise on the old and new language/platform/framework as well as the LoC, complexity, maturity (of both the project and the team) and quite a few points more.
Still I can't see why TS is set here as example, it's honestly worse with vanilla JS.
On the other hand that's one of our jobs (for us Tech Leads and software Architects) to do the right tech choices based in different points we need to weight and tackle before even a developer writes a LoC.
I am a big advocate for JSDoc, not as a replacement for TS but because the reality is that there are way more vanilla JS projects than TS + Flow + whatever new type-system-for-JS combined, and using JSDoc along TS Pragma makes it way easier to migrate the project to TS later on.
On small to middle projects, JSDoc may suffice with the condition that you set some automatic checks to ensure JSDoc is not only added to new functions but maintained when refactoring/modifying existing ones.
On middle to large projects TS is the choice. Flow is nice and so but we're not a research institute (at least in any company I worked in), that's the real market and the decisions should be backed; TS has a large community and maturity thus it's the option (like it or not).
Last but not least I won't let THIS kind of code to be merged into develop. You know? This code that's complex for the complexity, not splitted enough, bunched with arbitrary stuff... A.K.A. "overengineering", bad practices, "look how complex this looks, gimme a rise" and so on and so forth.
This just depends on the people doing the CR and just like with management, PO, DM or any other responsibility job position... You can get either lucky or burned depending on who's sitting on those chairs, and that my friend is not TS's fault.
But if any reader got the stars aligned in a good project and still doesn't like what he's doing, then you're either burned down or you lack the required skills for the job you're doing, and the solution for both is to find a new job.
Hope it helps somehow,
Cheers!
I appreciate your feedback on this matter. I am in agreement with many of your opinions. However, the following could be a valid argument, but not a strong one. One could argue that reformatting code from JavaScript to python or any dynamically typed language is much simpler than reformatting code from typescript to python. This is because when refactoring from JavaScript to python, you don't have to worry about removing the types that were present in the typescript code.
Refactoring from typescript to python however requires more work as you have to manually remove all the types that have been declared in the source code. This can be a time consuming process and may lead to errors if not done correctly.
Thank you for responding. I am a big a fan of your work/opinions! Let's keep fighting!
Hi Mahmoud,
Thank you for your answer!
Let me tear this down a bit.
While that could be true in certain situations, it's not usually the real experience.
First of all, there are almost no reasons to translate "literally" from JS to Python.
Reasons:
On the other hand, it's not a matter of "I have to remove the types manually" as something that bothers you.
Having the types brings you the possibility to slowly but surely write similar functions for the necessary use-cases without the frightening errors in runtime that the QA will point out few minutes after the merge of your PR (or at least way less than without having type hints).
On the other hand, Python does have type hints that work in dev time (just like TS) thanks to IDE implementations and are a nice to have as well.
So, for this given TS function:
you will probably write this in Python:
and the equivalent in JS would be
Depending on the project (to be honest, it's usually the first use-case 😂)
If I was to say something negative around TS is that it sure takes more time to having things done than JS at the beginning and maybe
compiletranspile times can be itchy, specially if you have a low-spec computer (I'm so used to transpile JS using babel, webpack, Parcel... that few seconds are not doing the difference at all) and of course that the learning curve is higher, but assuming you got the basics on CS you already checked C/C++, Java and many other languages that are for sure more complex in depth than JS/TS hence... idk, it may be just a matter of point of view and self experience 😁Got it. However, I am afraid to ask about a python version of the bubble sort written in TS. LOL.
I'm not much into python tbh but here's a try:
some Py master may point out something wrong idk.
On the other hand you need to be honest. You put over-complexity on purpose to the bubble sort above just to stress your points to an infinite level, and... c'mon man, you know that!😂
This can be done much simpler:
And it will infer the types accordingly.
Those
lessThantypes are set there for no reason, a comparison statement(
X > Y,X < Yetc) is always a boolean context (it will always evaluate totrue || false).Around the type checks.... Even Java doesn't check types in runtime (it is the compiler) so of course if you want to have them in runtime, that's a totally different story.
It may be a confusion between type hints or type checks in dev time (something implicit on TS, Java, C# and many other languages) and type checks at runtime (something you need to code yourself in any language as far as I can remember).
I don't know if you noticed this, but his bubbleSort example was not a run time sort. It was such an unrealistic convoluted example, it was a toy like an obfuscated C contest as others have said. So the
lessThanetc types were actually necessary.His example would make a new type (not a sorted list) that only allows sorted lists as values. Which means it's only for array literals. I.e. you can make a type like
type SortedArrayand then use it likeconst x: SortedArray = [1,5,2](which would be an error because 1, 5, 2 is not sorted).As mentioned, not a useful or reasonable example, it's exactly like using obfuscated C code to say C is confusing. Your example actually shows what a reasonable bubbleSort would look like in Typescript, which as you note looks almost identical to JS, but isn't doing the same thing.
Kudos on that John, I honestly didn't even tried to understand everything 🤷🏻♀️😂
That being said, I believe that most code snippets I saw online with half this complexity are blending concepts.
One thing is to know that a function argument should be a number and a completely different thing is to ensure the function does what it should using types. We've unit tests for that and they work way better IRL.
If we consider that TS types are touring complete you
cando things like those, even youshouldn'tand neither it is its purpose.But maybe I'm wrong, or getting older or idk 😂
Ok? The same could be said for migrating any other strongly-typed language to a dynamically-typed one. The reverse is also true though. Migrating from TS to another strongly-typed language like Java or C# would be much easier than migrating from JS. As others have pointed out, you seem to have a personal vendetta against TS for some reason and don't have much in the way of actual reasoning for why it's worse than JS, other than niche "what-if" scenarios.
Refactoring from Typescript to Python (for whatever would drive a person to do such a thing) is exactly as easy as going from Javascript to Python. You just compile the code. Bam, javascript. Since Typescript doesn't touch the structure of your code, the output will be exactly the same as manually typed Javascript.
hahahaha didn't even thank about this option. Good one!
Python has type annotations and pluggable type systems. I like to use these. Therefore refactoring to the type of python I would write would be easier. Then again, if I was refactoring to a dynamic language I could just strip the types via a Babel transform.
First off, you've obviously dedicated a lot of time and research into this article. I found several very valid and well-thought points, some which I do not agree with and a few that I find simply incorrect (= could not cross-verify anywhere).
TL:DR - I have added a few counter arguments for each of the points of this post, all of which are very subjective. I love JSDoc, especially in environments that do not support TS. Some of your points, in my eyes, might be a bit misleading to devs getting started with the language. You're invited to disagree with each of them, hence the tone.
1. The Learning Curve.
As you state, using TS or not heavily depends on the use case. Given you're working on an enterprise-grade project with several developers, comparing the cost of learning against the cost of later maintenance, I find this no valid argument against Typescript.
Quite the opposite - since it's hard to learn, it's a valuable asset for your portfolio. Learning TS increases your net worth and distinguishes you from other developers.
2. Strict Type Checking System.
The example you provide is literally a type-only bubble sort in TS. I do not find it to be a practical example of static type checks. Applying this principle to anything but snippets feels like writing the whole codebase in a
@typesdirectory.I agree with your statement that complex types are, well, complex. That's why they're being used. Compared to languages like Rust or Java, you do not have to type your whole project. If types are too complex, you're free to leave them out.
3. Verbosity And Lack of Readability.
True, large TS codebases are a mess. Just from my experience, it's not the types per se that cause havoc, but the way they're named and maintained. If you and your co-devs handle them properly and prevent them from rotting, this problem can largely be circumvented.
Regarding one of your alternative solutions: In my eyes, JSDoc is more verbose compared to TS. You can see it in your own example - in many cases properly named variables can easily replace JSDoc comments.
4. Lack Of Intuitive Syntax
See point 1.
5. Lack of Compatibility.
The example you describe is not a problem with the language. Why should I ditch the language if the environment does not support it? That feels like saying 'I ditch Python because it does not run in my browser console' in 2015. This problem led to a great innovation called Pyscript.
6. Low Productivity.
Frankly, sometimes I have the feeling I only write types for the compiler's sake. But writing types, enums and interfaces forces me to think through by data structures and optimise on the go. And I would always choose taking weeks longer for the initial release than spending months patching up my mess.
I do want it because I'll spend only the weekend writing on the code. And I'll have forgotten most of the data structures in the time between. Because I am lazy and do not document a lot (sometimes ChatGPT does that for me), I'm happy seeing my previous thoughts neatly formatted as interfaces waiting for me to come back.
All of my previous Hackathon submissions, after learning the language, are written at least partially in TS. One even won me a grand prize. And I'm happy for the static types, because now I can keep developing on it without reviewing the whole codebase.
Using Javascript is great because of the short time-to-market, but in my eyes, it's largely outweighed by maintenance costs for enterprise grade apps.
7. False Promises.
If this is true, I have a misconception of the language. Is this your personal opinion or has this been stated by one of the core development team? If so, can you please provide a source for this statement?
For me TS is pretty much this:
Source: typescriptlang.org/docs/handbook/i... , second paragraph, last sentence.
8. Lack of Flexibility.
See points 2, 6 and 7
I don't think TS limits my creativity. All types are optional, nothing prevents me from typing everything with
any. But I find it more elegant and more responsible towards my customers to write robust code. With great power comes great responsibility, after all.9. Giant Corporation Abuse.
Yes and no.
Fortunately, Microsoft is not solely run by Steve Ballmer. Of course they used to doom Open Source, until they figured how to capitalise on it. And now, there's software like this:
And to provide a more recent opinion on Windows <-> Linux: cloudblogs.microsoft.com/windowsse...
10. Clever Devs Abuse.
This happens in Javascript too & does not really count as a reason to ditch the language
11. Not A JS Superset.
I am unsure how to respond to this statement and the example you provide properly. In general, you're not wrong. Since TS uses static types, types must be known at compile time. This also goes for your example. Yet as stated in point 8, I see no problem in this, but an opportunity to make my code more robust:
12. Slower Compile Time + 13. Additional Transpilation Step
True, that's the price you pay.
14. Lack of Performance.
Usually, you do not ship TS code to production.
Performance can indeed become a problem during development when using TS in Node.js using ts-node or nodemon. In the frontend, Vite does a good job at solving performance issues.
15. Writing Unit Tests.
I find it even easier because all my types are already declared and, if I did a good job, count for tests and the software.
And where's the problem? I would want my co-dev to document a change like this somewhere.
I still remember an upgrade from formidable v2 -> v3, where a single property name changed and I spent a whole week figuring this out (in a JS codebase) because the app would keep crashing. Okay, I haven't read the breaking changes in the log, but I was still quite upset about such a minor change making such a huge impact.
16. Types Are Not That Useful.
See points 1-15
17. Heavier Tech Debt.
Sure there are madman PMs changing the architecture halfway through the project. But that's not technical debt, it's poor planning.
Also:
Boy am I glad the concept of static typing is language agnostic.
Thank you so much for your kind words!Oh thanks! I'm glad you appreciated all the work that went into this article. It's true that a lot of research and time went into it, and I'm pleased to hear that it was worth it. I'm glad that it resonated with you. Thank you for taking the time to read it.This!
Let's do this!
1. The Learning Curve.
Of course, I mean if you want to pay me xxx$ , I can learn whatever the heck you wanted. That's not the point. As stated in the article, the main point is:
2. Strict Type Checking System.
Agree with this.
3. Verbosity And Lack of Readability.
This!
The same argument can be made for JS. If you and your co-developers follow the best practices in JS, this problem can largely be circumvented. By following best practices, you can ensure that everyone on your team is on the same page, which makes it easier to avoid errors and manage code changes.
But in the case of using TSDoc with TS, you will end up with the same verbosity.
This opens up a whole new debate: Proper Naming Convention Vs Code Documentation. But, Agree with you on this point.
5. Lack of Compatibility.
You points are valid over here. But, sometimes it can cause headaches. It is my fault that I didn't provide a reproducible example cause it's was too complicated and I don't have the rights to share it.
6. Low Productivity.
This!
So, it is clear that it will lower your productivity, ok.
I think your experience is great and I'm happy you had success with using TypeScript. However, I disagree with using it in a time-constrained environment such as a one-day hackathon. The learning curve for TypeScript is quite steep and there's not enough time to came up with a prototype to take full advantage of its benefits.
7. False Promises.
If it doesn't solve JavaScript problems, then what is the point of inventing this language? I would say, it is not 100% valid, yet still a speculative argument.
The absence of a static type checker is a problem in JS, isn't it?
14. Lack of Performance.
This!
I see your points, and I understand where you're coming from. However, I would argue that you would still resort to TS/JSDoc anyway to document your TS code. Have a look at the core TS code and let me know. This begs the question: why use TypeScript in the first place? Know what I am saying?
I apologize should I have mislead you, but my words were not meant to be kind, but critital. Yes, you did a lot of research and I appreciate the article. That doesn't mean that I agree with everything.
What gave you this idea?
The repository you linked includes a ts declaration file for interfaces. In this case, JSDoc is used to provide additional information inside IDEs or text editors. Try and type the following in your IDE:
Hover over
find. You'll see the JSDoc comments are equal to the text content. Also, the declaration file is for vanilla ES6 Javascript features and tbf I'm happy for every piece of documentation I can get.There are more examples. Projects like Deno also ship fully commented interface libraries because they're very useful to develop with:
github.com/denoland/deno/blob/421e...
There are two answers, one for this case and a generic one.
For a code library like this, I am happy when people do proper documentation. The documentation happens to be part of the code. And it integrates well into my IDE, too. Sounds good.
For all other cases
The latter is, again, especially important when working in teams. And I don't have to use JSDoc to provide these small popups in the IDE, normal comments are perfectly sufficient.
By now, I see a lot of projects that use the monorepos style written in TS. Because while not essential, it helps to prevent code rigidity. Below are examples for three robust and famous frameworks with a huge codebase and many team members:
I meant not in an insulting way. Criticism is always welcome.
That's the whole point. Why using TS in the first place and TSDoc with TS when you can use JSDoc for type-checking, documentation, and code suggestions in JS?
I think you're answering this question with a few of your article's points.
TS enforces strict types and invites developers from other statically typed, OOP - based languages, like Java and C#, to participate in projects. With the static types they already know and the flexibility of Javascript's core features
TS is actually (mainly) intuitive syntax (once you get used to it).
Compared to Javascript, TS reduces tech debt on the short & long run. It makes mono-repositories easier to maintain & libraries and modules public APIs less prone to errors. Because you have a compiler to convince that your logic is sound, with all pros and cons that brings.
Now you could argue: Well, all of this goes for JSDoc, too, doesn't it?
Yes and no. Because
JSDoc enforces no strict types. There is Javadoc, but I've seen it used very rarely in the wild, while Java Types are everywhere
JSDoc is verbose and not part of the code, but a textual extension. I don't find typing out function arguments very intuitive. Not now, probably not ever. I keep forgetting how to do a proper @typedef every other time and I cannot declare complex types. Also, I find generics in JSDoc rather ugly.
(maybe the most important part): JSDoc has no compiler. You can type your whole codebase with JSDoc without any other benefit but the comments in your IDE.
See. You are providing already existing statically typed languages. Why bother creating a new one? Oh, I forget, it is just another standard.
JavaScript has become one of the most popular programming languages in the world because it gives us the freedom to write code without being constrained by static types. People seem to forget that.
For me, it is. However, I think it's really hard for developers who are just starting out using the language. There are SO many questions and common pitfalls that can trip them up. It's scary!
In VSCode, just enable it in file > preferences > settings > search for "checkjs"
And Bam! You got semantic checking enabled (kind of static typing).
How about using TSDoc with TS code?
What? Are we talking about semantic checking NOT a benefit?
This is SO wrong. JavaScript is as ubiquitous as it is because of browsers and the Internet. Had JavaScript not been the language used to make HTML interactive and there would be some other language, then we'd all be using that more than likely. The popularity of JavaScript today has NOTHING to do with what JavaScript is as a language in the end. I'd also add that JavaScript as a programming language only really became significant in 2010, when the first Node version came out, allowing JavaScript to be used for both frontend and backend applications. It doesn't matter either. The point being, I think we can agree, JavaScript is the #1 web application language right now.
Now, my correction also doesn't make your point moot. JavaScript can and does give us the freedom to write code without static types. However, once a code base gets to a certain size, this freedom becomes a very common footgun and that is why TypeScript became even a thing and why it is growing fast. Because teams of developers need type safety.
I'm not going to go into your litany of reasons not to use TypeScript. I'll say for sure, you are swimming against the stream that is gaining in strength. Instead of complaining with a list of shaky reasons to dislike TypeScript, put your energy into supporting making the language better, because, JavaScript's and TypeScript's ubiquity isn't going to stop any time soon. It is all here to stay. And if I were you, I'd want to make waves by making the language better, instead of looking like the one whiny fish who thinks the stream is going in the wrong direction and ending up bumping heads with the other fish going that same direction. It's counterproductive for us all.
Scott
I think you're trying to compare apples to pears. Have you ever tried to write a React app using C#?
Regarding 'Why bother creating a new one?'. Because competition is good for innovation. I don't see competing standards as a bad thing. Because they compete to be the best, hence they keep improving. And from my minor perspective, TS is superior to JSDoc in terms of static type checking in every way.
Types in Typescript are optional
Can you verify this? I found it hard because I never worked with static types before. And I would argue that the hardest part is to learn the syntax - which is true for all other languages. I think it's really hard for developers who are just starting using ANY language.
That's no strict type checking because there's no compiler, just the Typescript language server. (Yes, even JSDoc uses Typescript under the hood, hooray for standards.)
Looks pretty verbose too. Perhaps I should have formulated: 'JSDoc to be looks more verbose than Typescript based on the lines of text added to a particular file'.
I'm not sure how you got that idea tbf. I stated that JSDoc has no compiler and TS does.
With 'You can type your whole codebase with JSDoc without any other benefit but the comments in your IDE.', I meant:
If there is an error due to wrong type expectations, you might not even notice it in the application itself. I love Javascript's anarchistic approach to dynamic types, it's what opened the gate to programming to me. At the same time, I've seen horrible crimes being comitted using Vanilla JS - Syntax in non-strict mode.
Imagine you have a shop system. A customer orders a t-shirt and a jacket. Your junior dev has presented a logic to calculate shipping fee based on the total amount of items.
You can probably spot the mistake right away? Let's to the same, this time typed out:
Now remove the quotation marks from around the
qtyproperty of both items, pat your junior on the shoulder and say "We've all been there".And yes, you could have achieved the same behavior with JSDoc & The JS/TS check. Just like your junior could have ignored this mistake and ship the whole thing, causing havoc at checkout. Because no compiler could stop him.
I completely agree; competition is not a bad thing. In fact, it can be quite healthy and motivating. However, I think the key point here is that the mentality has shifted over the years from static languages to more flexible, dynamic ones. And now we are seeing a move back to static languages. This begs the question of why we are now moving backward. Transitioning from dynamically typed language to statically typed ones?
I think it's important to keep in mind that while competition is definitely a good thing, we also need to be careful not to get too caught up in it. There's a fine line between healthy competition and unhealthy obsession, and it's important to make sure we don't cross that line.
Still can't see why it is superior.
Yep.
How? Here is a good comparison between the two.
As mentioned in the article, This is intentional, as having a compiler would slow down the development process. JSDoc is intended to be used as a documentation tool, and not as a means of adding code generation or validation. Still, it is possible to use JSDoc for these purposes.
I would argue that JSDoc's lack of a compiler can be seen as a positive thing. The need for a compiler would slow down the development process, and JSDoc's focus on documentation over compilation means that it can be used more quickly and easily.
Same.
Again, for forgiveness' sake. If there are good QA / development philosophies followed, we are good.
That's the main point.
It is true that mistakes are inevitable, but it is also true that when the right DevOps philosophy is followed and implemented, it helps to prevent and minimize the chances of making any mistakes. The key thing here is to have an understanding of what works for your team and business and then build a reliable system around it.
This could include setting up guidelines for code review, automated tests, deployment processes, etc., to ensure that only quality code makes its way into production. Additionally, having a correct monitoring strategy in place can help you detect problems in the system before they become too big and cause disruption.
The moral of the story is that while dynamic languages offer flexibility, static typing gives us safety and security when coding. So although moving from statically typed languages to dynamic languages may feel like a step backward, in reality, it is a step forward in terms of overall efficiency and productivity.
I think we've reached a sweet spot in our discussion, so I'd like to finish with one last comment.
This sounds a lot like having an additional step in between development and production. Like compilation.
You argued that a compiler slows development down. Then I'd say: Let's ditch QA altogether, like that we reduce our time to market by another 25%. Also, let's ditch all modern frameworks and write monolithic CSS again. Na, why bother writing classes? Inline CSS is the way, because with our IDE, we can do a mass-replace anyway. Or let AI handle the complex stuff (this seems like a real alternative by now).
Your code example gave me the shivers btw. I've seen a dev in my previous org naming all function arguments param1, param2, param3, ... . That went up to 12 args in one function.
Your comments seem a bit redundant and cover up for missing function context, so allow me to add another example here in TS, without the verbosity:
By proper naming, you can actually reduce the amount of comments you need. This is a simple example, so let me give you another in TS and JS.
The following code will read a file from a local machine. It can read it in three different ways: Buffer, JSON or String.
Here's what I came up with in Javascript applying the same logic as you did above:
The only thing that changed is that I moved all the information out of the function and put it above, creating 4 additional lines of code I could have saved.
While this example is very specific, you can see an increase of ~12% in textual content (lines and signs)
In a real project, this value might be significantly smaller, but If I can save 4 or 5% in a project with thousands of lines of code while increasing readability AND have static type checks AND I have a DevOps pipeline in place anyway, I'd be willing to pay the price of using a compiler.
I would say yes, but it is not necessarily the case. A compilation is not necessary as an additional step between development and production. Someone may argue that TDD could be this step.
I think you missed the point I was trying to make. I'm not arguing about the naming conventions, I'm just showing how the function definition line becomes so fat/bloated without using JSDoc. I mean, have a look at this line:
Instead, JSDoc offers the most convenient way for both documentation and type checking (with CheckJS).
This will make your function easier to read without the need to scroll horizontally. So, I think with JSDoc, it's arguably much easier to understand what's going on.
This opens up a whole new debate: Code Documentation VS Good Naming Convention.
But the first example doesn't have documentation. If you use TSDoc, you will end up with the same number of lines in both examples.
Totally agree with your arguments. The biggest strength of JavaScript is its simplicity and flexibility. I love the natural beauty of its syntax.
The abuse sometimes turns the source code into something horrible!
If tc39 wants to make it a statically typed language, I hope that it should be something lightweight similar to type hints in Python.
When I need a strongly typed language, I would choose Vlang or Golang.
Same.
I agree such TS code is hard to grasp and maintain. But it's not fare to say that Golang is better at this. It's impossible to write complex types in Golang, and if you like this inability - just don't write complex types in TypeScript!
Don't get me wrong, i'm a full time Vue developer and I like Vue way more than react. But to say something is objectively better is nonsense.
It completely depends on the goal you have.
Lot of you points are totally irrelevant in certain situations. Even though you can measure them.
It's like saying bicycles are better than cars because they are objectively lighter.
That's it I'm swapping my car for a bicycle tomorrow!
It's sad to see such a hype and such a negativity in comments at the same time. It feels like folks are offended and just afraid to accept that they had spent a huge amount of time for worthless knowledge. Take it easy guys, TS is legit which doesn't cancel legitimacy of the author's points. Be brave to accept: TS is not ideal, and not fun at ll in terms of DX. It became neither fish nor fowl.
This is a goto technology for big teams because many developers just don't give a funk about writing good code and TS forces some good practices. But at the same time, we all saw a lot of examples of great software written in JS, and awful software written in TS.
So the truth is: TS is not better than JS.
Other truths are relevant and contextual.
JavaScript is fine! ✅
Types aren't that useful! ✅
You have my vote for president.
14. Wow. Just wow.
It says:
When? Where? How? Do you know how TypeScript works? Like at all? TypeScript only has shims. If a new variable appears in front of you that somehow magically underperforms, guess what? It is your own fault.
You either write performant code that TS doesn't have to figure it out, or you type TS that works the way it is intended. If a shim for older JS is giving you a hard time, simply stop depending on said shim. My God! This is one of those articles that should just be deleted. Free speech, I guess. This reminds me about the guy that was trying to convince people DRY is bad.
I mean, taken as a maxim, and applying no further thought, DRY is terrible. Especially when coupled with OO inheritance.
People fear OO soo much and I don't know why. Yes, I know all about the composition over inheritance argument, but OO, as you place it, is not the devil. I do OO quite often with superb results. And I kind of do take it as a maxim. I hate copying and pasting from one place to another. I literally forbid this practice to myself.
The opposite of DRY isn't copy+paste. Not adhering to DRY is simply typing the same thing more than once. Typing
for (int i ...)more than once would be a violation, if you take it literally enough. Which actually makes FP and declarative operations on sets a pretty sound way of reducing repetition.Regarding DRY and inheritance, how do you get a Duck and a Penguin to extend Bird, without invariant problems that break the Liskov Substitution Principal of any subtype S, being perfectly compatible with it's supertype?
Are you really trying to imply that there's a difference between copying and pasting and manually typing the same thing ??? The end result is the same. This adds no value to the discussion.
So you only have one for loop in your codebase...
And how do you get a Square to inherit from a Rectangle, or a Circle to inherit from an Ellipse, without LSP violations? You wouldn't want to have both a Rectangle and a Square. That's wasteful and not DRY, in a world without nuance, so how do you do it?
DRY, without nuance leads to architectural nightmares, which lead to refactoring nightmares, which lead to a decade of the game industry just using god-blobs for literally every possible thing that could go through the engine... essentially having your object inherit from the object type that has every property and every method possible in the system, and then just praying you don't call the wrong one on the wrong thing at the wrong time.
This discussion brings up some thinking I constantly have. Some people (too many) contend that JavaScript isn't an OO language. However, that is absolutely wrong. It's an OO language through and through, but without the need to have classes for object instantiation. Yes, the ECMA group broke down and offered classes in ECMA Script 2015/ES6, but you still don't need them to get objects in JavaScript. And because of this "class rules them all" thinking, you also get the misconception of what OO is all about. It's not about class constructs, it's about designing software around objects......no matter how they are created. And thus, people who stay very high-levelish with their understandings of OO programming misconstrue the lack of having classes to be "it's not OO". So, so wrong....
Out of that and back to the subject, class inheritance in a class based language is definitely a really bad form of coupling. And to me, this is where JavaScript shines. Because with its protypal inheritance modal, Mr. Eich tried to "lock away" the issues of class based inheritance. And yes, you can still do other very bad things with this form of inheritance too. But, the goal was, to help the developer avoid the class inheritance issue altogether, by, wait for it, not needing classes to instantiate objects. Woohooo!
In the end, understanding what it means to have inheritance between object defining constructs and why it can become total evil if the depths of the hierarchy become too deep, should be one of the basic teachings for any noob developer. That is when "composition over inheritance" should also be taught (along with other basics in software architecture and design).
Scott
I always try not to be harsh. I was going to say the only valid point in this article is the additional compiling step (bothers me personally) then I remembered it's the same deal with babel, as you need to use it (unless it's not a serious project). All the other points can be attributed to lack of understanding or knowledge about things like tsconfig. The typing system is the solution we got to have to solve bomb-like errors in runtime caused by typos or mis communicated documentations. Try to think of how much lines of code you would write to just check if the params passed to a function call are valid. If you're gonna bring up flow or jsdoc, other commenters already said enough about it (obsolescence, lack of basic functionalities...). I've been doing JS in the backend and frontend for more than 10 years, the only JS projects that survive are those written in TS. You can tweak for performance and regain it, but you can't sacrifice code quality, sophisticated integrated documentations and universal understability of the project by any developer.
Well said - TS is all about increased levels of rigor and quality, as an antidote to the prototypical (pun intended) nature of JS "cowboy coding" ... the author's article mentions "17 reasons", but not 17 compelling reasons :)
This is a very verbose and well articulated opinion.
As someone who has been using TS for about 3 years now, I would like to point out that many claims in this are very much conjecture rather than substantive analysis of Typescript.
TS doesn't restrict JavaScript because it is all removed at runtime. It only gives you a false sense of security if you have not typed your code properly.
TS is a very powerful tool and, to the authors credit, it does come with a learning curve. The bottom line though, like any other tool, it is only as useful as you make it.
Verbose and well articulated.. I'm not sure of that. This article felt to me like he just sat and thought long and hard about every point he hated about ts (regardless if some of the points are a reach). And then, like a school student trying to fill in a word quota, padded out a lot of his points with surface filler or purposely cherry-picked examples of convolution to illustrate his point (ie his bubblesort example). Not good faith
Good luck refactoring / modifying a huge code base that isn't written in a strictly typed language. That is, unless your team has covered the type-level contracts with unit tests; which I highly doubt if they're been convinced by any of your arguments to ditch Typescript.
I think refactoring is the most compelling reason why TS is a good thing (and code navigation is a strong reason as well).
I think you should put in actual work to learn typescript. This is just basically a hate article on TS
Define "actual work". Should I open an OnlyFans account and start sharing exclusive TypeScript content, or what?
Nope. Not at all. This proves that you didn't even bother reading the conclusion.
I'm not sure I'd pay for that lmao :)
But idea should be tried out for sure. Just remember to wear the right attire :)
😂😂😂😂😂😂
😂
Sorry for my aggressive tone
I just really don't think those reasons are valid.
Not sure I would pay for that too 😂
All of those reasons have caveats or a degree of subjectivity. You could also make a list of other statistics that supposedly show that Vue or Svelte are objectively worse.
Personally I think these frameworks are converging to the point that it barely matters which you choose. I'll always choose Vue for my own projects because I like the syntax and I had a good community experience. But I also work with React every day and I'm okay with that. Why do we need to constantly prove one library is better than another anyway?
The reason React is "winning", I think, is because it has momentum. It was the first serious contender to Angular which was a huge breath of fresh air at the time. It quickly gained a following, which translated into being taken seriously in business. I worked at a company that built their MVP in Vue, but for their v1 they moved to React because it was easier to find candidates and market. Nothing to do with what we devs consider objectively good, it's just "the standard".
Rant over.
Angular is not AngularJS.
@jfbrennan exactly! So many devs acting like sheep because it's popular, provides jobs and is "easy", when all they are doing is shooting themselves in the foot learning a convoluted framework that brings nothing of benefit to the table. I will not be persuaded. Svelte is the way to go, get back to the basics of web development! #DeathToReact
@jfbrennan I'm just tired of the never ending debate over what framework ist better, overrated etc.
It's such a useless discussion where no one will ever win. When you start a fresh project you can and should debate with you team which framework is the best fit. But the answer will only partially depend on hard facts like bundle size or web standard compliance.
Of course you will not pick a framework because it's bigger or slower. But for most of the projects all modern frameworks are small and fast enough.
So it really comes down to thinks lice developer expertise or availability.
In my opinion most of the people that say framework ... is too slow are simply doing things wrong.
If you follow your arguments consequently you should not use a framework at all. This was you will have the smallest bundle size the (potentially) most performance and the best standard compliance.
React is dominant in the market and provides the jobs and the $$$ - that's enough reason for many people to use it, even when they don't like it. We need to put bread on the table, that's the harsh truth, and in many cases you can't even choose yourself, a company or a customer will make the choice for you and you need to deal with it.
Number 11 is sooo wrong. I guess much of this is wrong.
Number 11 shows the error because TypeScript is not (yet) able to read your mind. Just do it properly:
If you don't know TypeScript, don't blame it if it blows in your face.
is not a valid JavaScript code.
^
|
--- This!
Do you know what a superset is? It means Typescript has things that Javascript doesn't. Remove the types and it's valid Javascript.
And this line IS valid JS, but will be interpreted entirely differently in TS:
It totally depends on what you mean by "TS is a superset of JS"....
Whilst it is true that all JS is syntactically valid TS - that does not mean that the JS code will compile in TS, or even if it does... it might not do the same thing as it did in plain JS.
So if you mean "TS is a syntactic superset of JS" then that is probably (to my knowledge) valid, but if you mean that "All JS code will compile in TS, but TS adds some more functionality on top - and is therefore a superset" - that is not correct... although I've seen many people say it.
In this section, I was explaining that It is important to understand that not all JS code is valid TS code. This can be seen through the counterexample I provided. This proves that TS is not necessarily a superset of JS. Hope this clarifies the situation.
TypeScript is there to help. TypeScript IS a superset and your example does not really apply because TS can be told to still transpile. If you do that, however, you are forgoing the benefits of TS.
The article is kind of toxic in my opinion. It feels like a very biased opinion from a person that simply dislikes TS.
What he wanted was code that allows anything to be done to
bar. The Typescript equivalent would just beconst bar: any = {}. That's what he seems to want, however misguided.He wants code that just does the wrong thing but stays quiet about it.
This reminds me of one of those YouTube "apology" videos where you learn much more about the YouTuber than you ever wanted to know, and not in a good way. This article will (hopefully) have very little impact on the use of Typescript in substantial JS projects, but I fear it will have a profound effect on the author's employment prospects with any hiring manager who stumbles across it while performing due diligence.
There's nothing wrong with having opinions, but when they so often stem from a fundamental misunderstanding of the language being criticized (as so many of the coding examples show), I think you're really better off keeping your opinion to yourself.
PS Are people really still using var?
PPS Using a meta-programming example (Reason 2) that seems designed to show that the type system is Turing complete (which was all the rage with C++ templates a few years ago) as an illustration that the type system is "difficult to use" is such an egregious strawman that it alone robs the article of any credibility.
The author would definitely be rejected if I’d see his application in the mail.
Same for the opposite, not be able to see TypeScript flaws makes the person a bad developer in general.
Absolutely you must be able to see the motivation behind usage and that will determine what is optimal or suboptimal for you. Drawbacks are relative but should be studied to be prepared once you land in a different work context
@idleman this is not a case of "not being able to see TypeScript flaws". The author lacks basic understading of the language. Except maybe this is a troll article, then great he wrote a good troll piece.
Thanks for the content you've put together here. I'm neither for or against but it's great to see the Dev community wheel out to get into the comments, really good to see the passion and understanding people have on the subject coming out.
I'd like to see more articles like this, if anything the comments are gold and really hit hard for some, we can't always have a "why X is all you need"
Maybe there's a dichotomy here between devs who grew up with purely script-like, typeless programming languages (Pearl, Python, JS etc), versus people with some background in typed languages like C++ or Java ... I think many people with a heavily quick-n-dirty "cowboy coding" attitude hate the structure and the rules that TypeScript imposes on them.
From my own experience, I'm now doing a project with the Ionic framework (not with Angular, but with React), and since Ionic has always had a heavy TypeScript bias, I'm automatically using TypeScript for this project - and guess what, I can seriously say that I love it!
I've hardly put any effort into learning TypeScript (I studied it a bit in the past, but that was a LONG time ago), but it comes pretty naturally and intuitively - and no, it doesn't seem to make my code verbose or cumbersome or whatever, on the contrary - I would say it increases its expressiveness, makes for a form of "auto documentation", definitely enhances "intellisense" and code navigation in my IDE (VSCode), and also aids in refactoring - plus, I have the feeling that it "forces" me to put more thinking into the design of my code and my data structures, it makes things explicit and "formalizes" some stuff ... this is the first time I've really gone "all the way" with TypeScript on a project - in general it's giving me a good feeling, and I can easily see the benefits.
Finally, I noticed that even the author of this article says that TS does have benefits for "more complex" projects with larger teams - by saying that he effectively undermines the rest of his arguments :)
P.S. advertising things like JSDoc and Flow as alternatives does not make any sense - by mentioning those he already admits that using types DOES have benefits, but JSDoc and Flow are the poor man's version of TypeScript with a tiny market share and community - it's a dead end you don't want to invest your time in ... if you realize that types have benefits for JS then there's only one choice that makes sense - TypeScript.
I don't think it's related to the script-like/typeless vs strongly typed background.
Personally, I come from a pretty much pure script-like/typeless background and since I've discovered Typescript, I would never even contemplate the idea of going back to JS.
TS typings are just great, they can be as simple or as complicated as you want them to be. You reap most of the benefits from strongly typed languages while keeping most of the flexibility of script-like/typeless languages.
I think it's more about the "cowboy coding" attitude. I've seen extremely great JS developers only feeling alive when editing code directly in the files on the production server... The structure is like a conservative parent to their rebel attitude, they simply can't take it...
And yet, for all those truly skilled and impressive developers, I would not hire a single of them. They...
Don't get me wrong, they can achieve very impressive results and most of their work will be very functional with few bugs. But you can't run a team with them, they're lone wolves by design and this is simply unsustainable in an enterprise context.
I would take a team with good TS devs over a team of JS unicorns any day.
That's a very thoughtful and well-written comment - some (well, many) comments are higher quality than the articles they're commenting on!
You hit the nail on the head here - TS simply enforces a degree of structure and discipline which makes the difference between documented, structured and maintainable - versus that brilliant but incomprehensible cowboy-style spaghetti mess, which the rest of the team cannot comprehend.
I really believe that this whole JS versus TS debate is largely a matter of "culture" (professional/business culture, that is) - the 'cowboys' (lone wolves is another appropriate metaphor, you can also call them the "10 times" programmers, or the unicorns) with their desire for freedom & speed, versus the "team players". I know the kind of people that you can build a team and a company on - for the long haul.
Your PS is the comment I've been looking for. Why would you be advocating for JSDoc and Flow while trying to paint typescript blue. Whereas TS is superior to those 2 by far.
IMO the article oozes a lack of understanding of TS.
Right! Yes the author contradicts himself there, and in a couple of other places ... anyway, this article makes for an amusing discussion.
I am sure there are easier ways to write a sort routine in TS than your example. So why include it? You can write convoluted code in any language.
Well, I don't think that is convoluted at all. It is just an example of a strongly typed typescript code taking care of all edge cases. Know what I am saying?
No, it's really not.
It's an example of using TypeScript generics to sort a list at compile time. Which is super useful...pretty much never.
Better to just run some kind of offline sort and spit out a JSON file if you really want items to be pre-sorted.
It's literally just a Stupid Programmer Trick. It's like pulling code from the Obfuscated C Code contest and using it to criticize C.
> It's literally just a Stupid Programmer Trick. It's like pulling code from the Obfuscated C Code contest and using it to criticize C.
Exactly my point.
Ever heard of the ternary operator and what it is used for?
It is assigning the type value of
LessThanbased on conditions evaluated for the types of A and B. Again NOT convoluted at all. Pretty straightforward.The question isn't whether it's straightforward. It's whether it's sane. Or even marginally useful.
Why do math in generics in TypeScript? At least in C++ templates there can be a rationalization.
Am I the only person that feels like this post should be taken down? Imagine a new engineer reads this and is swayed from typescript...hopefully they read the comments, but they are at the bottom of the post. I barely read this because the opening was really bad. Please have other engineers vet your future work. We all want to support each other in this community.
If this post was a troll of the dev.to website to get traffic, it worked on me. I read this and literally made an account here so I could point out some of the bugs and misunderstandings in this post. It's horrible. Then I read the whole thing (carefully, as the author suggested), and it veers between fluff and nonsense.
Click bait has its place, but I don't think it helps to make posts this wrong just because it'll get attention.
Am I the only one who want to ban all people who post comments like the above?
The commenter is right.
Just because you don't like something doesn't mean it should be cancelled!!! 😡
The argument nowadays isn't about performance, that's a smaller argument. The biggest issue particularly with React is that it promotes anti-patterns and bad ways of coding that should have been handled with classes to begin with. Components are always written poorly, causing a huge mess, and because of how flexible React is, everyone has their own way of writing React code that causes the project to be unmaintainable in the long run.
My chief complaint about React is not that it doesn't use classes or objects - it did use them, but deliberately moved away from them in favor of functions - FP (functional programming) is a valid alternative to OO.
No, my main complaint is that the burden of handling and optimizing the "low level stuff" is left to the developer - you really need to be (or become) an expert in "React best practices" in order to avoid excessive re-rendering of your components - this is, what I call, the "low level stuff", which should be taken care of by the framework, so that the developer can focus on business value!
I mean, how many lengthy, complicated articles have I read recently about all kinds of arcane patterns or 'practices' we need to follow with React in order to avoid unnecessary component re-rendering ... let me repeat it once again: THE FRAMEWORK SHOULD TAKE CARE OF THIS KIND OF LOW LEVEL STUFF !
(don't get me started on things like
useMemo, that's just an ugly hack - when people's apps perform like a snail and they start "fixing" that by peppering their code withuseMemoall over the place, then you know it's the beginning of the end)I don't want to spend my time to become an "expert" in arcane React techniques to prevent my app from performing like a pig - I want to create business value for the client!
(other case in point - look at the ridiculous amount of discussions about Redux versus Context - mainly how "unnecessary" Redux is, and that it should be replaced as soon as possoble with "Context" - then watch the same people, 1 or 2 months later, complaining how their app inexplicably got slow like a turtle ...)
Not sure where Riot is coming from, if you want a modern comparable framework with high popularity; choose SolidJS. Bundle size of all these frameworks, including React, is still small enough that it really does not matter.
Poor image optimisation, large stylesheets, external scripts, they all diminish any optimisation gains made by the core library bundle size.
Bold statement, all code has legacy stuff and will gain more legacy code as time goes on. Only extremely new frameworks (a SolidJS for example) have little legacy. But new frameworks have the trade-off that they have small communities and thus have less support/information available. This trade-off will always exist.
Learning curve is a highly subjective matter. Some people find Vue concepts easier to grasp, others React. Some people love Svelte, I personally strongly dislike the syntax. This is the most subjective measurement out there.
JSX transpiles down to regular old HTML, it's nothing more than a templating syntax. Just like Vue and Angular have a lot of custom HTML attributes, and Svelte has logic blocks. Even in React you can write 100% valid HTML.
The compatibility with custom components is a bit poor indeed. Although it too has 100% support in the experimental release so that is coming up in the future.
Looking at the aforementioned facts, this simply does not hold true. Every language has its pros and its cons and more often than not your locked in to a default framework used within a company. If you have the choice, pick whatever framework you feel most comfortable with, chances are 99% that you are not working on a cutting-edge website that needs every micro-optimalisation out there.
Personally, if I had the choice I would go with SolidJS (as spoilered by my first line of writing). But Svelte with Sveltekit is also a strong contender. Remix and NextJS on the other hand also deliver very solid applications. Seriously, there's a whole world out there and every framework will probably do just fine. It's mainly a trade off regarding developer experience. (And yes, that too is subjective).
@leob
Redux and React Context will more often than not give you the same re-rendering headaches. It's mainly a issue of a proper architecture and for that you need a good understanding of how rendering in React (or whatever framework you prefer) works.
Great article. The violence in reactions shows how powerful the TypeScript cult is...
Not all disagreements are by virtue of being in some cult.
When a physicist makes a refutation to some flat-earth advocate, it's not because the physicist is in a cult. It's because as a physicist, they have a better understanding of physics, and some of the statements refuted are just objectively, impirically incorrect.
A lot of this article is subjective. Sure. Great. Some of the points, however, are either due to solid lack of understanding, a wilful attempt to troll/mislead, or some sort of petulant rebelliousness that leads to self-destructive coding practices?
I just aimed violent reactions.
The article is subjective but probably as much as articles singing the praises of TS.
In substance, I really find awkward to add static types on frontend (I have mixed feelings on the backend). DOM and HTTP requests & responses are by essence dynamic, types are thus informative so we can't really rely on them.
By that logic, though, types on the back-end are useless, because you can't trust your DB schema to not change, and to have every query response to be filled with valid data, and internet data and user input are just as unreliable on the back as on the front.
So what do you do on the back? You have validators, and you cast to a known type. And if you can't build a valid type out of the input, then the input is bad, and you probably shouldn't just keep blindly using it.
The same is true for the front end.
It doesn't mean you can't employ this level of rigor in JS... I just know that many people don't... and don't really do it in the back, either.
And languages like TS and tools like Zod make this easier.
Sorry but this is not true. This is a trope I see people say now and again. There is nothing different from a programming perspective about backend vs frontend. They are both doing the same thing. If there is ever any compelling reason to use types on the backend, it is exactly as valid and useful on the frontend. It's just that until recently we have not had the option of using types on the frontend.
Nah, they're not dynamic. We know exactly what they are statically at compile time. A JSON payload has type
string. Period. If you ever find yourself taking some JSON object and just calling it aUserProfile, you've massively messed up. Or you're just taking shortcuts which is fine sometimes, and puts you in the same place you were in with Javascript.fetchResponse.json() returns a promise fullfilled with a dynamic object. Period.
Yeah it does, so the type is
unknownor some indexed type. You do not just force it to have some type without checking. You validate it. And none of this is at all even remotely unique to frontend development. Anything that you interact with that is data coming from outside your program isunknowninherently (or simple strings, whatever fits best). For example every HTTP request you get on the server is a plain unknown data blob. The way you handle that is the same way you would do it in any typed or untyped language. You parse the data and validate that it meets your expectations. Sure you can slap a label on it just blindly claiming it's aUserProfileor whatever, you can do that in Typescript and in Javascript and both will give you equally shaky results. That might be good enough for the short term or even long term, depending. But again, this is not a scenario that is somehow more prevalent on the frontend or specially handled by Javascript or Typescript.Actually neither in backend nor frontend you really NEED types. You can validate data without types, there are tons of fp patterns for it in JS. And adding types didn't insure in any way the validity of your data.
JavaScript is a dynamically typed language, deal with it. If you prefer static typing in backend there are plenty of static typed languages...
Where in my comment did I say you need types? You don't need anything other than compare and
goto, but languages are designed to make certain repetitive patterns (and errors) easier to handle.Javascript is dynamically typed, but just like how the computer itself is dynamically typed, we write compilers to give us certain guarantees that make programming easier and less buggy.
Thanks!
Folks are overly judgemental...
Wow. These comments are giving off a lot of Dark Souls 'get gud' energy.
I'm new to TS, but I do find that the TS code written by experts/advanced users can be hard to follow and off-putting.
Instead of 'ha ha newb' posts, could anyone suggest good TS resources or good examples where TS have solved a problem caused by JS loose typing.
I feel that way when I read code written by experts in any language I don't know.
I don't think the comments are saying "ha ha newb", I'm sorry it looks like that to you. That's not helpful. At least for my comments the point was to illustrate how completely and objectively wrong the post is. Like, languages can be a matter of taste and opinion, but many of the things he wrote are actually wrong, not opinions.
If you haven't seen problems caused by JS loose typing, then you haven't been writing JS for very long and the best remedy is just keep at it. It's not bad to know Javascript, so if you go that route, good on you. With time, you will be bitten by many MANY JS loose typing bugs. I'm of the opinion that you probably aren't going to learn the subtle pros and cons of something like this by reading articles. Just use it. And be comforted in the fact that a lot of people use Typescript, very experience professional people, and they love it. So even if you end up not liking it in the long run, you won't have wasted your time.
You asked for resources to get better: I found the official Discord community to be very supportive, and I leaned a ton there. Do your best to understand the advanced features you're looking at, then ask for help when you get stuck. It was especially important to be able to ask about symbols that are hard to search for, like
?:, etc.Well, you can write small projects using js, if your project is console.log('Hello World');
Otherwise now days it is almost impossible to scale projects without proper typed language, be it typescript, dart or flow.
This article tries to give a point, but doesn't really convince, why anyone should use JS over TS.
Recently I started to work on a small project, which was written in JS React/node. The first thing I did, added typescript, and what do you think? Lots of bugs came out immediately, just because of type mismatch.
So my conclusion, TS is a must for JS developer in 2023.
I have worked with 500 000+ lines of code projects without any issue. Your issue is how you structure your code, thats all.
500000+ lines of code of pure js and no issues, sounds like a magic. Anyway, there can be different opinions, one can say you can use only JS, another can say you MUST know TS, the job market speaks for itself :)
It is always constructive and beneficial to have developers share their views/opinions on tools. I always love reading it and appreciate their hard work on comparing them! It will make the developers community flies.
I suggest we can do this - Typescript Vs Javascript
Reasons(or parameters) And Pros & Cons(best with code example widely used for good function features)
Popularity: Yes. It may make you to land a job easily, but it makes your work harder if you only need to use a Swiss knife to cut an apple, but your boss or company force you to carry big chainsaw.
Monopoly: I have said the same thing on GitHub. It is always smarter and beneficial for developer to have a backup tools/plans or even backdoor.(haha)
Imagine when every developer can’t live without only one tool(eg. GitHub) and suddenly there is a paywall tsunami forced you to pay. What can you do about it? Similarly like v4ccines.
Let’s conclude it. You won’t take a big chainsaw to cut a small apple while you can use a Swiss knife to simply cut it. Also, there are times you may want to use a big chainsaw to chop off a big tree. And there are many smart developers can use a big chainsaw to peel an apple nicely.
The point is your project is an apple or a big trunk ? Does it worth it to pull the trigger and vrooooom and start the big or mini chainsaw? You need to flip and learn the manual.
I hope developers can keep an open mind and share their views but not giving personal attack or toxic comments.
Another thing to add on: nothing is definite in this world. Who can tell if one day the tools may have developed into a better way ? Or another HypeScript come by?
Hey Alex. I am always a big fan of your comments. They seem all lovely to me. I appreciate the time and effort that you put into them, and I enjoy the way that they make me feel. Your comments are always so thoughtful and insightful, and I look forward to reading them every time.
Yup! Let's do this.
Exactly.
Lol.
Agree.
Same.
Undeniable fact!
Hahahha. Good one!
Thank you again for being such a (thought/wonder)ful person!
Thank you for your compliment!
I do believe in Cause and Effect or Ripple effect. And I believe everyone especially developers are the cause of matter to this world. For every words or every action taken, it will bring a ripple to this world no matter how small it may seem to be. I have been looking forward to crowds of developers are thinking on the right track to make this world better.
Sometimes a small pat on the back or a nice word may change what is going next to the person or the world.
I wrote dev.to/gmartigny/typescript-is-was... a few month ago, so needless to say I strongly agree with you.
The promise of TS is lovely, but the real world application is a mess.
Makes perfect sense, why write in Typescript and transpile to Javascript when the solution can be written in Javascript directly? I don't know what's in the mind of stupid-ass engineering managers who adapted this as part of their toolkit, Typescript is nonsense from Day 1.
This is SO TRUE. Hahahaha.
Thank you for the article as I always find a critique of any language or technology very useful. I love JS and NodeJs, but do acknowledge it has some serious issues. Reading some of the reactions (similar to other critiques of Typescript) it's as if you're attacking their mother or them personally. It's kind of ridiculous and I'm not sure why people have such strong hatred or visceral responses to critiques of any tool. Tabs vs Spaces all over again.
It was a good choice in posting Ryan Carnito critique of Typescript as he makes a few additional great points. I would also like to add some of the comments that Eric Elliot added in regards to Typescript which cause a huge barrage of attacks, nasty comments, straw men, and purposeful misunderstandings... again why? Entertaining to read, but not really necessary.
You Might Not Need TypeScript (or Static Types)
The Shocking Secret About Static Types
The thing that was so unfortunate about Eric Elliots articles is how soo many people missed key points he was making. He is not anti-types or anti-Typescript he expresses that clearly. His point was just that you may not need Typescript as the title says in a polite way. It was a counter to much of the strong claims and hype of many blindly promoting Typescript. It was a very critical look at the tool, which is a good thing. I love that he states something that cannot be stressed enough, that most of the issues that come up in software development have more to do with logical errors by the developer than by only type errors. Type errors are very real, but so are other more prevalent types of bugs. I also love that Elliot and Uncle Bob really hit hard on unit testing. I keep hearing the claim that having a tool like typescript helps to refactor code, which is true in terms of your code's api, but is silent when it comes to ensuring your changes have not effected the spec'ed out for behaviour in realtime, not at compile time.
Another great thing is Elliot links to an article that really calls to question the strong claims that types saves a team from bugs. It looks at Bug density of Strongly Type languages (C, C++, C#, Java, etc) vs dynamic languages (Python, JS, Ruby, etc). If the idea that types lead to less bugs, then languages which are strongly typed should shine, but they don't. A great section of the article:
The Broken Promise of Static Typing
Or to put it another way, "So simple even a caveman can do it."
Truthfully, Javascript misses the mark on some of the points of what makes a language simple, but I can say it is very forgiving about mistakes. I taught programming in college for about 5 years to artists (who hate anything to do with programming). I was amazed how easier it was for them to pick up Javascript than Actionscript 3.0 (now I'm dating myself) and C#. There were other factors involved as well like JS running easily in a browser, the debug tools of the browser console, etc. But overall it was like night and day. This obviously anecdotal but I think still important to consider.
I think the goal of simplicity in a language also aligns well with your's and Ryan Carniato's critiques that Typescript adds more visual noise to a much simpler Javascript. More noise is more to read, evaluate, and debug when going through a codebase. I'm not sure why statements like that offend people. It's not an evil or good thing, it's basically the cost of doing business, which some feel is worth paying, which is fine.
I myself am very comfortable with strongly typed languages working in Actionscript 3.0, Java, C#, and now C (Several personal projects for embedded stuff like Raspberry Pi). You learn that types do not save you from errors (as Elliot and others pointed out). This is not an argument against types or typescript, it just an acknowledged as to the limits of a tool or methodology. Typescript is not a silver bullet and neither is any other language or tool. But the way many people promote and defend it (like comments here suggesting that this article should be removed because of a different opinion / experience of Typescript), as if Typescript is the only "real" or "sane" or "moral" way to code. It's a bit odd to me and just not true.
Some really sophisticated and complex libraries were built in JS before Typescript came along and will continue to be built after. In the end, all of this back and forth reminds of what Brendan Elch once said, "Always bet on JS". Thanks again for adding to the public discussion critiquing Typescript. More of this should happen for all tools even Javascript. As a developer I want to know the good and bad of a language, tool, or methodology before investing heavily into it. And if I've invested into it, I want to hear reason why others have not, even if I disagree. Thanks and take care.
It's always nice to receive thoughtful comments, and I appreciate the effort you took to write that. I'm pleased to know that my words resonated with you and that you enjoyed reading my article.
Same. It is unfortunate that some people feel the need to resort to such comments in order to make themselves feel better. Such responses are not only cruel but also hurtful, and they should not be tolerated.
Good share! I am reading it at the moment.
Thanks for bringing this up! That's exactly what i was refering to in a way or another in the unit testing section.
Good mind!
Exactly.
Same.
I never heard of ActionScript before, but after doing some research, it sounds very interesting. I also had a similar experience working with Raspberry Pis during college days. It was a great way to learn about programming and electronics. I'm looking forward to learning more about ActionScript and see what I can create with it!
So perfectly put!
Same. I don't think this article should be taken down. I think it's well-presented and provides a valuable perspective.
Good to hear!
Thank you so much for your insightful comment; It's always great to hear from readers like you. Your thoughts are very much appreciated.
Same.
I really appreciate your feedback and I'm glad you enjoyed the article. I hope you'll stick around and continue to enjoy thought-provoking content like this in the future. Peace!
I am glad you find Actionscript interesting. However, I should warn you it's a dead / dying language since support for the Flash Player was officially ended by Adobe a few years ago. Ironically, Actionscript 3.0 was based on the proposal to make Javascript a more "serious" language, through the ECMAScript 4 proposal. Roughly speaking, Macromedia (before Adobe bought them) decided to move forward with Actionscript 3.0 based around the ECMAScript 4 proposal before it was approved and built a whole eco-system and community around it. The unfortunate thing for them was the proposal was rejected a few years later. Not only this but due to the success and power of JS, CSS3, HTML5, and Apple's refusal to support Flash, the Flash player was eventually killed. There's a great article on the Auth0 site about it:
The Real Story Behind ECMAScript 4
I'm not sure many people or projects are using Actionscript 3.0 at the moment but it was fun while it lasted. One of my favorite projects was the Flashpunk Game Engine (it's what I used to give my students to teach programming before I switched the course classes to use JS and HTML5). They loved it. Have fun with it if you like and I wish you good luck on whatever you do.
At the moment I've mainly been pushing people to learn more and more Javascript and have been moving towards using Raylib (A game engine built in C) that runs in WASM. Soooo much fun. The web is such an amazing platform for development.
I feel you on the negative comments. In the end don't let the haters keep you down. Say what you need to say (respectfully of course) and keep moving on. Take care and good luck.
Side note: It's also funny a lot of people accusing you of not understanding or appreciating the power of having types in a language like Typescript. And yet in your last reply you show an interest in Actionscript 3.0 which is strongly typed. Lol. The same thing happened to Eric Elliot in his articles. Just keep on keeping on.
I started use TypeScript 2 by own decision many years ago, but now, as Angular developer, I am forced to use TypeScript :) I feel some of your points.
It is right, that TS can be replaced with JSDoc, because many IDEs support it and I used it in few pure JS projects or tooling scripts. Anyway, strong typing is a major feature, which won't be replaced soon and ditch TS is too early :)
^
|
--- This!
Experience:
Our team has created a "big SPA application" based on JavaScript + JSDoc, works like a charm! There are more than 800 JavaScript file. We rewrote a previous TypeScript, Vue.js program.
We have been using Svelte since 2021, it is better than React: clean, readable code, fast compiling, learning curve is lower, (yes, React is worse, but more widespread - If you are familiar with React, Svelte will be a joy to use).
We use TypeScript indirectly, there are d.ts files (or JSDoc) in the external packages and the generated code (OpenAPI), which VS Code uses very well. But it's transparent to developers.
I can work with both React and TypeScript. But I see that it is unnecessary, since there is Svelte and JSDoc (and generated d.ts).
Lower maintenance costs, easier modification, much easier training and better code readability are definitely advantages.
Innovation in our profession cannot stop: what will come after React and TypeScript?
See folks. You can also achieve enterprise-level applications with just vanilla JS. Not sure what is the point of TS anymore.
Thanks for sharing your experience.
Have used TS for 2.5y out of my 14y of web development. And I don't like the TS syntax. However I'm in favor of typing (using JSdoc) cuz it gives a better IDE IntelliSense and type safety without the need of writing any TS syntax. I think it gives me better debugging experiences without the need of any transpilation & SourceMap and it runs instantly without any compile time.
plus it's better for cross compatible code and runs everywhere without extra tooling.
I honestly wish for there to be one day where we can honestly specify what type of variables we want to use such as an int16 variable and anything else can't be assigned to it. ecmascript-types is more superior proposal than type-annotations that dosen't even befit the runtime engine one ounce. it's just annotations that literally dose nothing for the engine
I contribute to a lot of open source project but if it's written in typescript then i don't want to even dig into it and it's unnecessary build tool they have and just report an issue instead. it may be b/c i'm not that good at TypeScript also and i can admit that. TS have been really bad at generating strict valid ES Modules with it's extension-less import syntax and have completely ignored the problem of resolving file paths with explicit paths for years, but that might have changed now with resent pushback from ESM-only modules (don't know if TS have gotten any better at it) in any case it's the worst at resolving paths remotely. Deno's TS version at least got it right and enforces the use of '.ts' at the end.
Both JS/TS consumer of any module written in TS often have to pay the price of importing a hole bundle dependency instead of just importing the files that they only need. So any module that bundles things isn't so good at code splitting. It may not be that for all the cases but it often is. And sometimes you just have to use TreeShaking b/c of it and forcing those consumer to introduce unnecessary build tools who just wishes to instantly prototype stuff without the need of any extra dependencies.
I often reject any job offer i get if it have any wording of TypeScript in their job description.
I don't think TS syntax makes me any better developer. in fact i think it's the opposite. I think knowing basic core javascript of how it works and what kind of dynamic feature that it's compatible of makes me smarter for also knowing things such as symbol.toPrimitive, toString and toJSON what different casting those dose for you and all of that. I think it's also important to know what can break your code for doing "dangerous" things. Cutting corners are sometimes nice when you for instance want to add number/booleans into URLSearchParams and not having to cast everything into string when it dose it for you with WebIDL conversion. TypeScript are actually very bad at understanding this dynamic casting at it's core and dosen't see some valid usecase to be legit by being more strict about stuff.
TypeScript do not offer any runtime type safety and gives you upfront type safety instead. that won't mean that any other consumer will also use typescript and might instead use your TS code incorrectly unless you don't throw them a TypeError
JavaScript isn't broken as many think it's. Dynamic languages is a feature in itself that dose not need to be fixed. thanks to dynamic feature we can reuse older variables that isn't longer needed and create smaller bundles. but that's mostly only something js minifier have to care about.
it's fun/challenging to code golf and write extremely compact mini games / one liner features with byte saving techniques that not even minifiers can do better.
it's even possible to write code that is type friendly without the need of either JSDoc or TS syntax if you just specify the default types and write optional arguments with default parameters. even the devtool can understand optional argument and hit you with a ? mark for some functions if it have default arguments, that isn't the case when you use jsdoc or ts annotation to say that something is optional. instanceof checks is also helpful for getting the right type interferences.
Browser are never going to allow nothing else other than javascript and wasm, Google tried with Dart and failed.
In this case the feature is exposing additional programming languages to the web, something without any real benefit to anyone other than fans of the current "most awesome" language (not too long ago that might have been Go, a year or so ago this would have been ruby, before than python, i recall i brief surge in haskell popularity not that long ago as well, Lua has been on the verges for a long time, in this case it's Dart -- who's to say there won't be a completely language in vogue in 6 months?), but as a cost it fragments the web and adds a substantial additional maintenance burden -- just maintaining the v8 and jsc bindings isn't trivial and they're for the same language.
The issue here isn't "can we make multiple vms live in webkit" it's "can we expose multiple languages to the web", to the former i say obviously as we already do, to the latter I say that we don't want to.
Unless we want to turn Blink into the engine that everyone hates because of all its unique "features" that break the open web standards, a la certain browsers in the late 90s.
And b/c of this i'm going to be forever a pure vanilla JS lover ❤️
TS user can stick to what they think are best. if that works for you then 👍
i love the Type IntelliSense you provide (but what i don't really like is that i can't easely view/debug your source code. i often enter the d.ts territory from using VSCode 👎 wish is not what i want to view half of the time. i wanna know how you solve things sometimes.
what i don't understand is if you love a typed language that much, why aren't you using C++, rust or any typed language and compile it to WASM? you would get near native performance speed out of it then? trying to introduce types onto a non-typed feels like like trying to fit a square into a circle hole.
Wow, what a valuable experience/opinion to share! I couldn't agree more; your comment is truly relatable and insightful. Thank you so much for taking the time to write such a thoughtful response. I'm glad that your own experiences resonate so much with what was shared. JS is here to stay!
Can also mention that i also use TypeScript in a since (but not it's weird syntax) b/c i have turned on checkjs in global VSCode config by setting this:
it helps me a lot. it is as equivalent good as any typing TS provide.
I have also written you might Not Need TypeScript...(syntax)
I also think that writing JSDoc enforce me to write better documentation of what each and every property/functions dose, I believe most (not all) TS developer for the most part just annotate their code with what kind of type it is but dose not document it in any way except in their readme... I could be wrong too but that's the impression i get when looking at others TS open source projects
Being JS typeless doesn't mean you have to write typeless programs. If you don't know the types in the program, you more likely must rethink the initial design.
Thank you for writing this article!
I wrote an article a while back with a similar spirit: We’re not writing our code in TypeScript, why?
Regarding the whole React vs X debate that's been going on here, I'd say the only real argument against React you can make is the lack of two-way-modal-binding that at least Angular and Vue (I do not have personal experience with others) do have.
Having to constantly track state updates in useState, use state set calls, manually write event handlers (i.e.
onClickoronChange) is a huge chore compared to the aforementioned alternatives.This is especially a problem in larger enterprise applications that are very form-heavy. Think of dashboards for customers where they have to provide upwards of 20 text fields, dropdowns, and radio buttons to place an EU standards compliant train driving order (coincidentally the system I've been working in for the past 2 years (public domain information so I can divulge this, don't worry)).
I've been writing React for the past 3,5 years for work and personal projects (even longer) but for the latter I've recently picked up Nuxt (Vue framework) and I absolutely love how much easier it is to make forms and track data.
I hate getting into these "my framework could beat up your framework" debates which are inherently futile, but I just have to agree with your last point. Vue is just so easy to work with. I use React for most work-related stuff, but I'll always pick Vue for anything else.
Car vs jet is not a fair comparison to React vs insert-favourite-framework.
Car vs jet is more like assembly vs sketch or something.
We argue otherwise but the differences between view frameworks are marginal at most, and in reality, we're all fighting over which shade of light blue is the best light blue.
It's periwinkle blue by the way ;) (/s)
Periwinkle is slow and bloated and doesn't have the community support of other shades and only has traction because of big corporation adoption.
Appreciate your effort for compiling such a long useless article to say "I hate Typesctipt; I don't understand it!". Where is the trash bin?
This is (By Far) the best written most articulate article i have ever read on this topic. The author wrote nothing but the truth which is why I see a lot of people write hateful comments. Truth hit hard.
I agree that JSDoc TS can get you very far compared to TS.
Not sure about Flow, I’d probably pick TS over it since it’s vastly more popular and most libraries have types for it.
But frankly, I was expecting an argument for ReScript over TypeScript!
rescript-lang.org
Sounds like a good opportunity for another "17 Compelling Reasons To Start Ditching TypeScript Now. " to me.
Welcome down the rabbit hole😏
Here’s a quick comparison of syntax and a brief note at the end about why ReScript is safer than TypeScript:
dev.to/redbar0n/typescript-vs-resc...
As for me, I prefer JS over TS because "isn't the main advantage of an interpreted language is: they are quick and dirty?"
I love HTML + CSS + JS + PHP because I can check the end result of my work in less than one second, every time I change something in the code I am working on. Using extra stuff like TS, which needs to transpiled into JS, every time, before it can be run / previewed in the browser, is annoying. The transpile time is very short, admittedly, but it is still there.
Then the second point, which is the pointless-ness of TS. JS is a language with very few data types to begin with, so I don't see the need of extra carefulness. The basic data type only consists of : string, number and boolean. There is no separation into char, or integer/float/decimal. If one of my teammates is foolish enough to assign string value to a variable or a property named "count", then she has no business working together with us.
JS gang for the win 💪.
Undeniable fact.
The ultimate degree of freedom and flexibility FTW.
I'm glad you took the time to speak your mind on this topic. Much appreciated!
The main advantage of an interpreted language is: they are quick and dirty.
The main disadvantage of an interpreted language is: they are quick and dirty.
As for your second point, I'm sure you've likely encountered this before:
let count = document.querySelector("input[type=number]").value;This will work just fine when subtracted, multiplied, or divided by another value. But not if you're using addition.
2 + "2" // 222 - "2" // 0
Well.. to each their own...
To me, quick and dirty is not a disadvantage.
Look at python: how it is loved for it's quickness, and ahem, dirtyness.
How it is able to complete complicated task in some few imports and lines of codes.
I would rather switch back to using C# if I really wanted strict typing / type safety. [I came from C# background: WPF, Winforms, ASP.NET]. Using TS beats of purpose of using JS as my backend language.
The 2nd point is exactly what I am talking about. JS is a language with very few data types to begin with. If I am getting a value from document.querySelector("input[type=number]").value then I always make sure to perform parseInt() on it, if I am to perform math calculation on it. Otherwise, which is most of the time, I simply sent it to the backend. I expects my teammates to be able to do such a simple task as well. Because 'it is not rocket science'. It is a well known fact that all kind of HTML inputs return value as string. If they don't know that basic fact, they have no business working together with me.
Also, when the data arrive at the backend, it is mandatory to perform PHP intval() or JS parseInt() on all integer data to begin with, since HTML POST is insecure by design, bad actors can put SQL injections there instead of our expected values.
"A steep learning curve...."
"Typescript can be difficult and time-consuming to learn.."
The "curve" in the diagram shows something that's easy to learn - a lot is learnt in a short period of time. Something that's time-consuming to learn should have a line that more closely follows the X-axis, not the Y-axis as shown.
From Wikipedia:
Hey @pauljherring, Thank you for the heads up. Fixed!
Look at those triggered heads exploding. Funny how those "counter arguments" are also what a lot of the TS community would crap on other languages for "having to do it the right way".
I actually liked the language, but community really turns me off.
Exactly. One of the most toxic cults I have ever interacted with for a very long time. They would rather prove you are stupid than provide any help whatsoever.
I used typescript on two different projects. It was looking good at the beginning. But when the project grew bigger, more problems I faced with typescript. Fixing bugs in the project code is one thing but fixing type issues with typescript itself killed lot of my time.
I ditched typescript and adopted better discipline in writing JavaScript. JSDoc solves most of my intellisense and documentation problems. I am not against typescript but I don't think it's very useful for me.
Regardless of the validity or certainty of the arguments, since many are preferences, I believe that this post raises an enriching debate, and this is clearly seen in the comments, many of which are well-founded for or against, but in all cases, full of arguments, which is precisely a very good starting point for anyone who needs to start scratching the shell of this world.
Thanks for your contribution Mahmoud.
Wow, great point! I'm glad you brought that up. This article is all about encouraging people to speak their pure minds and not be afraid to share their opinions. We live in a world where people are constantly being judged for their opinions/knowledge, and that's just not right. We should all be free to express ourselves without fear of retribution.
Anytime.
Congrats on creating a 🌶️ article with a lot of comments 😅
Like others said it definitely feels very subjective while trying to come across as objective.
I have rewritten projects in TypeScript and it was amazing to see the hidden bugs that were waiting to rear their ugly heads.
To your point of the learning curve, one of the things that I do find painful about TypeScript is the documentation and examples. Seeing things like
type T2 = Parameters<<T>(arg: T) => T>was definitely discouraging when I was getting started with it.Yeah, it caused turbulence in the atmosphere. LMAO.
Yup. But, I don't think there is anything wrong with this writing style. Otherwise, I think It would feel very boring. Know what I am saying?
Same.
This!
Thanks for sharing your valuable experience. Much appreciated!
1996 JavaScript vs. JScript
2003 One True Brace vs. K&R
2008 spaces vs. tabs
2013 no semicolons vs. semicolons
2018 functional vs. object oriented
2021 Svelte vs. React
2023 TypeScript vs. JavaScript
2028 SOS vs. TAT
Agreeing with Mahmoud. Great post. I particularly like: "10. Clever Devs Abuse" :o)
TS has become a religion out of the blue. It's nothing but a typing tool working on top JS, that is how it started, and that is what it is. About 5% of it is useful, the rest is abracadabra. Microsoft has ported C# onto JS: oh, big deal!..
Frontend and backend are both programming, but they are very different beasts. A lot of strong typing is important on the backend, not on the frontend, just like data validation, security, unit testing etc. Many people come from b/e programming, and it takes them a long time to realise f/e is not b/e: the realities, needs, priorities are all very different. I think if you find yourself spending a lot of time and effort on typing on f/e, you should take a step back and re-consider what you're doing: you should be doing most of that on the b/e.
Also, if you're doing React programming, you use a subset of JS, where we avoid most of the unsafe features of JS (eg. non-local scopes). That is exactly one of the main advantages of React. Exactly because of that, if you're doing React, you need TS much less, than if you were doing plain JS programming.
Imho.
Good points were raised over here. Agree!
I love this. I couldn't agree more. TS for anything other than a huge big company level app, with a team of many developers (90% of the tike this isn't the case) you don't need TS. It will only slow you down, give you headaches.
TS lovers, Tell me where is the logic in using a tool that is designed to help you code better, if all it does is slow you down? Using prop types is 10x more convient and has same exact advantages.
Any senior developer with enough experience has no need for TS if the app isn't massive with a large team of developers.
Thanks.
JS gang for the win 💪.
Completely agree, Still, I believe that by following the best practices in JavaScript, we are still able to achieve enterprise-level applications.
Underrated and undeniable fact.
Thanks for sharing your experience!
My problem with TS is it is not like other typed languages. Other typed languages compile to byte code or binary. And when a type error occurs it will either prevent you from compiling or crashes.
TS tries to solve this problem by adding stricter types, but that doesn't really help. Now code is cluttered with union types and other generic code for the sole purpose of making the transpiler happy.
💯
I totally agree with the author, and don't understand why some comments are taking it personally to defend TS.
I tried to use TS and found it unnecessarily cumbersome.
The beauty of JS is that it is flexible and now comes TS to take that flexibility away.
I am a freelancer and also i have some ready to sell software products so I'm not required by an employer or team to use any specific technology so I'm freely choosing to stick to JS.
I expect TS to continue to evolve until it becomes even more rigid and then the tide will turn against it.
Being a software developer since 1996. I've seen many similar technologies come and go.
Also Microsoft tried to destroy JavaScript in the past by introducing its own flavor JScript in order to control the direction of the frontend development, thank goodness that didn't succeed.
Is this April 1st? A joke? Candid camera?
Bonsoir à tous. Je voulais me mettre au typescript.Mais là je reste perplexe. Si quelqu'un veut bien me donner son apport dans le développement et ce que ça peut changer pour une habituée du js.Horsmis le typage statique...qu est ce que ça vous apporte? Et la difficulté d apprentissage du TS? Merci par avance. Je vous souhaite une bonne année.
Bonsoir. Je pense qu'un bon point de départ est la documentation officielle. Il y a aussi un canal discord.
Merci
I would sometimes like to scream at devs who think it would be a great idea to alter a programming language. They're invariably the sort of people who don't get the point of the brevity and simplicity of an untyped language. Strict typing apart from the situation of typed arrays which are very useful, is an alien concept to javascript. Sometimes less is more and I haven't found any calculation or process to be impossible to do in javascript. Stop messing with it. It makes development so much more time consuming when you need an interface class as in the extreme case of Java or C++ to copy an unsigned integer to an unsigned bloody integer. The developer knows that it's an unsigned integer at both source and destination but the compiler and syntax requires 3 or 4 times the code. While I've had problems with typos I haven't had many problems with the wrong type being passed. I defensively do type checking at runtime and it gives me the opportunity to do different things with the same parameter depending on its' type. Try and do that with a strictly typed language and start tearing your hair out. It actually makes my code better and more flexible with for instance the situation in a browser where the first argument to a function could either be a HTML element, a string ID of the element or a configuration object to create one. Without half a dozen coded use cases in the function definition as JS has no concept of headers as such anyway.
I'm not some stick in the mud old fuddy duddy despite my age. I've been a programmer for nearly 40 years and learnt the hard way what works best and sometimes new isn't always better.
Stop messing with my go to language capable of writing operating system software if used right.
The people who want to add more syntactic sugar. Increase development times 3 fold and basically impose their vision on everybody else should go and write their own sodding language. JS was never meant to be used that way simply because of shoddy coders with poor memory when it comes to an API and make lots of mistakes.
You should mention TypeScript cannot provide typesafety. Everyone who has done some low level programming know it. Types has a fixed memory layout and a set of CPU instructions that effectively can operate onpon a specific type.
In TypeScript can you cast a picture to an integer, in real typed language cannot you do it. This is what typesafety means in the real world, you should be able to trust the most basic primitives at least. In TypeScript, you cannot do it. But you still pay the cost of decreased development speed.
I have worked with pure JS large code bases and its fine. No issues with scaling.
There are so many poor work conventions for developers now that have only become conventions because they aee deemed to be solutions for problems arising from many people working on large projects. Tailwind is one, BEM is another. Neither help: learn CSS. TypeScript is another.
Typescript doesn't prevent runtime errors.
It runs as JavaScript so if your code base interacts with any other code then that interaction still has to be checked for type at runtime. So it provides a false sense of security.
Typescript also limits JavaScript's true power of being a runtime language.
I noticed that in a code example a variable for an addition function was typed as . This defeats its own purpose...
Also there are so many other ways of suggesting or ensuring 'types'. Giving your variables names with types might help.
Modularity was a selling point of early Typescript. But JS has had had modularity since efore Typescript albeit using libraries initially. But then using Typescript is no different to using a library. Js now has modules built-in.
Not sure how much MS push Typescript. They seem to be much more FOSS friendly these days.
Main MS shame Infind is filenames with SharePoint/OneDrive
All in my clearly not so humble opinion.
The function is typed incorrectly based on your specifications. The following is what you want:
The whole "lack of performance" point and specially this part:
Doesn't make no sense to me. Typescript doesn't add any runtime overhead because there's no runtime type checking. It really seems like you just don't know how the language works.
I might be wrong though, so if you'd like to elaborate on this example I'd love to hear it!
It doesn't make sense to you because it doesn't make sense, period. It's a particularly telling example of the author's lack of understanding of the very subject he's attempting to critique. It's unfortunate that he chose to make such inflammatory claims (albeit with a slippery "likely" thrown in) with no attempt to provide evidence for the claim.
Yes. All types will be stripped when transpile into js. Javascript engine does not understand any :type.
You cannot do function overloading based on different type parameter signature.
Because there is no type in run time.
And you can't even type check for logic flow in your code.
Guess why? Because there is no type in run time. :D
But there are some caveats;
Ref: Effective Typescript by Dan Vanderkam
You've done a great job, thanks for that
A warm welcome!
You're still using "var" for your examples, I'd advise spending a bit of time learning instead of writing nonsense. Not necessarily a steep learning curve is a bad thing, doing it may actually teach you something.
Also: jsdoc checking is built via typescript, you aren't escaping it.
Wow, please don't hold back any thoughts. 😀
Billions of strong-type programmers love TypeScript. For them there's almost no ramp up time.
TypeScript front-ends using C# or Java are almost Isomorphic (similar syntax).
It's true Microsoft has thrown their own adopters under the bus multiple times. Be careful.
Microsoft now owns the largest Javascript repo on the planet. (Github) and their new CEO has already pulled them out of the ditch in many ways. TypeScript is their only programming entry to Javascript. It will not be sunsetted.
The intellisense experience in TypeScript is twice as good as in Javascript
The language service for TypeScript is fantastic, (it reduces runtime errors to almost zero; while the compiler catches the rest)
TypeScript features are 5 years ahead of Javascript.
JDOC is still needed for publication of an API.
The extra typing required is a safe typing feature which save run time error discovery.
Too long compile times are always an architectural issue because monolithic development is ridiculous. Creation of npm packages (even locally) is simple. Each module should only do one thing.
Microsoft developed how many compilers? All of them are high quality.
Willingly rejecting TypeScript makes one unemployable in that space at a different company who uses it.
Google officially approved TypeScript internally about 5 years ago.
TypeScript never had a book with the words 'the good parts' in the title.
TypeScript people don't hate Javascript.
Working with any variable has zero type ambiguity.
Best of all TypeScript brings language bigots to the surface.
Even Crockford says that it's time for something new.
Don't tell me to stop using TypeScript. It has improved my development speed substantially and I can catch bugs and understand code faster than I had ever done using plain JS. Honestly, all those OOP devs were right: JS can be a disaster of a language if not used right. All developers should be learning how to use proper typed languages so they can build reliable systems. Your bio says you're an electronic engineer so likely you have worked with C and maybe Rust, so you of all people should understand the importance of types in programming.
Yet, TypeScript do not have types, it has type annotations. In Rust/C++ are types enforced, in TypeScript they are not. In TypeScript can you assign a picture to an number, run rust/C++ you can´t.
Then enforce type checking by reconfiguring your settings via tsconfig.json, preventing compilation if type errors exist. Clearly you haven't been coding in TS very long
Clearly you have not been thinking. By default do TypeScript not enforce types, nor do its playground here: "typescriptlang.org/play". But please, what config do I need to change. Here is the reference: "typescriptlang.org/tsconfig". You only need to mention what rule, if you can!
The rule name, under compilerOptions is "strict": true. This is an alias for setting all of the following rules to true:
noImplicitAny
strictNullChecks
strictFunctionTypes
strictBindCallApply
strictPropertyInitialization
noImplicitThis
alwaysStrict
That's all you have to do. Even if you can't enforce type checking in your project for some reason, lead by example and reorganize your code to follow best practices. That's what code standards are for in a team. Clearly you can't read docs right.
And it do not make your code type safe. Clearly you don't know what type safe means. Type safety means for example you can trust the types, you cannot for example cast a picture of santa claus to an integer for example. In TypeScript YOU CAN.
So, let's break down what's wrong with this article.
I'm not basing this on opinions, but rather pointing out factually incorrect things, some things that are not based on any evidence, and/or some information that is heavily bent to fit the narrative.
My point is to stray away any beginners or people "on the edge" in this topic from believing this article and making bad decisions, by showing the article does not provide actual verified information.
The first wrong thing comes even before we get to the "17 reasons".
This is not an argument, but a technical definition. It is a syntactic superset (if you assume some conditions for example using --allowJS), but this is beside the point.
Let's establish what a superset is in simple terms - it's the same but with some fluff added on top. So in this case, just javascript with some types added on top.
Let's get to the arguments.
Argument 1
This one is an opinion and does not offer any facts to back it up. It also fails to address that the types have no effect on the output code, so "proficiency in JavaScript" is the same for JavaScript program. Basically this argument makes no sense for JS vs TS comparison.
Argument 3
Author shows a bunch of screenshots presenting "equivalent" code in TS and JS. Code is basically the same size.
TS code has unnecessary typings in jsdoc. All jsdoc typings are factually incorrect ("number" instead of "string or number").
JS code presented has problems of incorrectly handling incorrect input (anything besides string or number which were accounted for).
TS code presented does not have this problem (by preventing such input at compile time).
Ironically, this means that TS example code is objectively better at least in one aspect (handling incorrect inputs to function).
Author even skips into explicitly enforcing his opinions mid-argument.
Argument 4
While obviously any language syntax can be hard to understand for people who don't yet know how to code...
... Typescript syntax is nothing new. It uses java/c++ like syntax for generics, and pretty basic js/c like syntax for types/interfaces.
No "conventions" are presented. Are we supposed to get scared of the unknown? :)
Argument 5
Is the project manager editing the code? If yes, then you may have bigger problems than your language preference.
This is factually wrong- you don't need to do that. Compiling the typescript code produces javascript. No manual conversion is needed.
You can always compile it and work with JS directly, if you wish. This is a stretch.
Argument 6
No data or arguments are provided to why that is so.
Any concept of writing something in JS or with minimal typings (and then adding types to that) is completely ignored.
Argument 7
No sources are provided where Typescript team makes any claims to TS solving problems. And those sources certainly do exist.
Quote from Typescript Design doc:
Argument 8
The sentence is structured as if "security" is a design goal of TS. We establish earlier that it is not. No strong sides are given as examples. The argument is based solely on polemics.
Argument 10
Critic is given without any facts, statistics or examples.
Argument 11
The arguments about to which degree TS is a superset of JS can be had, but this example is pointless, as this code compiles with
--allowJS.Argument 12
Argument 13
This is not an additional step. Typescript can be used instead of Babel.
This is factually wrong.
Let's take a look at TS design goals:
Typescript does not add any "type-safety" as it does not alter resulting code based on types.
Argument 14
Factually wrong.
TS design goals:
Typing system is erased at compile time. The code is structured in the same way as the original program.
Typescript will not and cannot create variables for a large dynamically sized array. But it's basically the way that JS already handles object arrays under the hood. This shows that author does not know what JS array is conceptually.
Argument 17
Speculative argument.
Let's perform a thought experiment. Replace the word "Typescript" in the above sentence with any other language name, for example, "Javascript". Did the meaning change?
It did not.
This means that the "argument" was never about the language in question.
Typescript alternatives
Attempt to alienate the language using "big scary evil corporation". No factual evidence.
No data is provided as to why flow is "faster".
I skipped all points that do have at least some basic information backing them up.
To clarify, this does not mean that i agree with them. It's that they do have at least some informational value to them, or written in somewhat honest unbacked opinion form, with minimal speculation.
The main pitfall that we encounter throughout the article, of course, besides the factually unsupported/factually wrong parts, speculation and logical fallacies, is that author entirely avoids (or rejects?) the concept of someone being able to code sometimes in JS and sometimes in TS. Completely missing the essential principle of "right tool for the right job".
And as TS is a JS superset - if you can write TS programs, you can write JS programs.
I'd argue that author does not understand the topic that he is writing about, but that would be speculation.
And we already established i don't tolerate that :)
This article, the amount of likes on it (and comments that somehow agree with it) is an example as to why every programming forum that you can post "advice" on needs a dislike button.
I mean, one of the difficulties that comes with coding in TypeScript is mastering its type system. In order to write correct code, you must master its type system, which can add a significant amount of time to your development process.
Thanks for pointing this out. I will fix it.
The whole point here is that if you were to document your TS code with TSDoc and bloat your code with additional types, why not use JSDoc for type annotations so your code looks clean and dandy?
Forget about naming conventions for a split sec.
Agree with this. Only for beginners to programming in general.
Lol.
I mean you gotta write types alongside your code. Forget about all the extensions and code snippets out there.
I mean. There are tools like CheckJS for this thing.
Thanks for the heads up. I will tweak this thing.
I mean. It is right there in the conclusion:
Ummm...
Alrighty.
Nah, we are good.
It's always good to get constructive feedback on our work. It helps us to improve and grow as writers. Thank you for taking the time to offer your critique.
Although I agree with the sentiment that TS is used even in cases where it brings more issues than it solves, most points are easily dismissible strawmen.
This actually makes the article counter-productive when bringing this up.
Cool
Thank you! You've reflected all my secret doubts about TypeScript. I'm using JavaScript for 20+ years and find it very comprehensive (even vanilla JS). There is all you need for programming anything.
You lost me at "A Wise Programmer" reading your profile. Good and really wise people don't call themselves wise.
But, then I see "reader of Epistemology". Ok. But, philosophers, or aspiring ones, should "attempt to construct theories that are synoptic, descriptively accurate, explanatorily powerful, and in all other respects rationally defensible".
Unfortunately this article lacks on "rational defensibility".
Try again.
Scott
In the face of criticism, it is important to remember to maintain a professional, respectful tone. Instead of attacking the bio, it would be more productive to challenge the arguments shared in the article with thoughtful and reasoned responses. This would create an atmosphere of constructive dialogue, potentially leading to further discussion and edification between parties.
By taking this approach, not only will you demonstrate your maturity and thoughtfulness, but you will also contribute to the usefulness of your comment. Rather than simply dismissing or disregarding another's opinion, you can challenge it in a way that encourages both sides to engage in meaningful exchange. This in turn makes for a more informed discussion, which benefits all participants involved.
Last but not least, by responding to comments with civility and respect, no matter the content of their statement or opinion, you can help foster a more productive environment for discourse. This is especially important when engaging with topics that may be controversial or difficult to discuss. By setting a higher standard for communication, we can all work together to make our conversations more meaningful and enriching experiences.
Thanks for expressing your maturity in this comment.
Regards,
Mahmoud.
There was nothing attacking in my comment. In the face of criticism, one should read into what was said and try to take away what might be constructive and what isn't and decide to act on either. I see, you decided not to change your bio. And I'll say it again. Wise people don't call themselves "wise". That, to me, is a sign of immaturity.
My comment to your article, its content, is just as mature as your article and as enlightening and as helpful too. The only difference is, you took a lot more effort to write your point of view and I didn't.
Articles like this waste a ton of people's time, because those who know better try to dispel the points made. And, there are already a ton of replies doing this. Have you taken heed to any of them? It is also why I didn't try to counter argue your points.
I love TypeScript, despite its quirks and difficulties. Yes, it isn't perfect. There is no such a thing as a perfect language. And despite TypeScript being imperfect, many, many people are building many fantastic things with it and doing it with a lot of success. Did you know, TypeScript is the fastest growing language currently? That alone counter argues all your points in this article.
I also wrote below in the comments, something along the lines of, instead of being the fish swimming against the stream of progress, you could take your energy and try to make that progress even better. That is what being mature and constructive is all about.
Scott
Hello, I am confused by your screenshot in #3: dev.to/wiseai/17-compelling-reason....
The screenshot reports that a string can not be passed the constructor of the Rectangle class. However the constructor shown in your code explicitly allows a union: number | string. Is your TS code in that section wrong or am I missing something about how your IDE operates?
Also for the record, I claim the IDE is correct. Only numbers should be allowed in there. There is no explicit cast (yeah I know the type change isn't a runtime thing so it's not technically a cast but....) for string to number in the code. Calling
Rectangle("fred", "Ginger")should fail massively at compile time not when the code is running on some browser somewhere in the world rendering a web page unusable.Hey John, thanks for raising the issue. I was showing that type-checking with JSDoc works in the JS example (That's not TS).
I tried to dodge Typescript by using JSDocs in my personal projects, and the latter is just too limited and difficult to use in mildly complex scenarios compared to the prior. If what you need is a type system for your code, JSDocs is definitely a no-go, if you want to keep using JavaScript directly, you're in better hands by using '.d.ts' files as your metadata.
An example scenario where JSDocs fall short is generics, that thing is way too verbose there, and doesn't work when currying is involved, it's just useless.
For a start I'd like to point out that most of your examples of TypeScript doing weird things can only happen when strict mode is turned off, and I don't think many TypeScript developers choose to turn that off.
I mostly choose it together with my team when it's a pragmatic choice. Most of us like it just fine. Most of us don't like JavaScript (or dart). Some of us like go. Most don't. Everyone I work with hates PHP. None of this means any of these languages are good or bad, it's just the feelings and opinions our personalities coupled with our experience have created.
Most languages have annoying things about them. TypeScript feels quite expressive and nice compared to other popular/modern languages. As long as you have some lint rules to prevent you using the bad stuff from JavaScript.
I don't really agree. Haskell is difficult, Scala can be difficult. But they're also fun.
I tried this example, TypeScript caught the error. No strict mode huh?
Barely.
Strongly disagree. TypeScript code is JavaScript with more. Documentation colocated with your code (types are documentation) and good static analysis that catches bugs ahead of time.
Reverse TypeScript with JavaScript in this sentence and you have my position.
So does TypeScript.
No, it's much slower. You also say that flow is better because it only checks what has changed, but this is also how TypeScript works when you use
incrementalvia the command line or config file.I'm having a hard time taking those "State of JS" points as anything else than developers complaining about things they don't understand, when I see "clumsy coding style" and "hard learning curve" as the main criticisms. TS is about as straightforward as it goes when it comes to type systems. If anything I'd say it'd be more than time we ditch loose typing altogether.
... and then you're relying on individual developers setting up their editor in a certain way, which is absolutely horrific. Let's keep those checks in CI, please. I'd also love to see those clean, bugproof JS codebases you're talking about.
Code reviews don't eliminate runtime type errors, knowledge sharing culture can change with leadership changes, and seniors make mistakes too.
Yes, and that's exactly the point. The main problem with the JS type system is not that it's dynamic, but that it's loose as hell.
This article is just pure BS! If you want to criticize something, do it objectively using known or widely-acceptable measures for which one can compare one laguage to another.
Maybe you needed the view counts and reads. If so, well you've succeeded. Other than that, I've never read an article as crap as this, ever! Filled with personal bias construed as 'compelling reasons'. Could have done better. I was honestly looking forward to reading something sensible.
TS has its headaches when first getting started out (many times I resisted the urge to throw in the towel and go back to my comfort zone), but its advantages far outweigh the cons IMHO, and I can't imagine using untyped JS for a serious project anymore. JSDoc, Flow alternatives I've read about, however, for typed support it helps to go with the flow (pun intended) unless writing code in a vacuum because typings are included with or are available for most open source modules nowadays, there is wide boilerplate support (e.g., nextjs, nests, remix, etc.), and TS has strong community mindshare. For me at least, such things often win out -- even over a technically superior offerings in other areas.
I was JS fanatic first. But 2 years ago when I was working on complex react desktop scinetic application as FE developer, I try to simplify the program with TS, and that stepp was great success, because after 1 month refactoring ( program development to this date near 1.5 year ), our program was fare more clear, and self documented, special the complex types which was declared and easy to made modify when something change between the FE BE relation ( python BE ).
Some of these reasons is right TS somtime give extra complexity ... which need to be avoide, if our types is easy and cleen enough, then declaration part is still small. Even my complex application was enough only 2 TS declaration files.
I think JSDoc never replaced that functionality.
When I need a quick fix some TS issue - and dont have time for that, in large strange codebase I do this:
Based on this article, the biggest criticism is the learning curve (Reason 1). TypeScript is a programming language that is a super set of JavaScript, meaning that if you know JavaScript already you won't have to start from scratch. Anyone who has previous experience with other programming languages such as C# or Java will also quickly find their way around generics, classes and interfaces. There are also helpful websites that show you all TypeScript Compiler Errors and their solutions. 🎓
TypeScript's compatibility and flexibility is exceptionally high because you can actually import plain JavaScript code in TypeScript code. You can even import and type JSON files. 🤯
TypeScript 4.9 even comes with huge performance improvements, so compile time became much faster. There even is a watch mode in TypeScript which helps you to run code on-the-fly. You also won't feel the additional transpilation step when using tools such as ts-node or the Deno runtime (which treats TypeScript as a first-class citizen). 💪
I would never consider JSDoc or Flow as a comparable alternative because these tools don't have the IDE support which TypeScript entails. Stripe just recently migrated from Flow to TypeScript with more than 3.7 million lines of code. ☠️
Not really.
Again, that's not true. Take a look at the counterexample I provided.
I can't find that definition in the official docs. That's based on your interpretation, which is fine.
So not beginner friendly and not for those who just started their way in programming. Alright.
Cool!
That's funny. I mean look at the core TS code. There’s a bit of TS and a lot of, OMFG, JSDoc! You would still use JSDoc to document your TS code, anyway.
Have a nice day!
There is no JSDoc in the core TS code. The doc comments used in TypeScript source files are using TSDoc syntax. The official TypeScript page also says in a big heading that "TypeScript is JavaScript with syntax for types", which means that it IS a superset of JavaScript. Even Wikipedia writes that existing JavaScript programs are also valid TypeScript programs. And guess what... The team behind TypeScript (Daniel Rosenwasser, Orta Therox & Co.) are now bringing type annotations to JavaScript.
JS/TSDoc same concept.
You only need a counterexample to prove this argument is wrong. Have a look at mine which is a valid JS and not valid TS.
Hope it will not become mandatory.
Wow. So many thoughts.
I'll say this, a couple years ago I forced myself to switch to Typescript and I've been extremely happy that I did so. My teams did as well and we all prefer it.
JSDoc is just typing that doesn't properly check itself. There are so many small mistakes that I would make that strong typing catches. And yeah, ideally my IDE would catch too - but not always.
Strong typing also makes using 3rd party libs much easier. I know what types the arguments need to be instead of digging through docs.
Compile time isn't that bad. If you really need it, use esbuild or something. I have never been waiting on a TS build thinking, "Why can't this be faster?"
Mostly, I type in interfaces for my function args. There is very little typing I need to do in most of my code. Inference works. So for the vast majority of my work it isn't really different from JS. And if I have to create an argument type/interface for my function - that's the same as JSDoc. Only that the compiler and IDE will be enforcing that typing in my code where my JSDoc can get out of sync.
TS lets my teams see one another's code easier. Again, they could write JSDoc. They won't. It is hard enough to get devs to write proper unit tests. We are always in a hurry it seems. At least with TS they sort of have to set something up. And return types can be inferred, where as a JSDoc you would need to manually define that.
It is great that everyone has a choice in what they want to do with their own code. I'll agree with the corporate decision to adopt TS over JS. I know it is antidotal, but my experience is that it leads to better code and faster development.
Edit: I proved that this guy is dead wrong on everything. Then he proceeded to remove his comments. What a coward!
Mahmoud, this is where you show how you don't understand what you are talking about, unfortunately.
In the first snippet, the docs are to document the parameters. You could remove all the comments and still have type support only with the 3 lines of code defining the function.
In the second snippet, you need the JSDoc to get some type support.
Thus it is much more verbose. It is also more tedious to maintain.
It's also less powerful than TypeScript!
I mean...
Based on that logic, its also possible to say that in the end if end-users and developers don't care about the quality of their code or how they write it, then why do we even bother with standards, best practices, etc. Why do we go through the trouble of writing blog posts on how to have a good app architecture if in the end people just choose React, create messy components, and call it a day. We need to turn that mindset around if we are going to create better quality software
So you're saying if you don't use TS, your code is guaranteed ti be bad structure and messy?
Actually I was talking about React, although I do encourage people to use TS to help with that regard. React has only lead to messier components because some people don't follow standards
Shame on those people. I can write "neat" components and everywhere I've worked either had standards in place (with code reviews etc.) or I lobbied for standards to be followed when joining.
Yes you can make a mess of React components if you're new or lazy - the same applies to all frameworks and languages - but that's a negative that falls on the developer not the library surely?
exactly. "Because some people don't follow standards". That's their fault only. That means you can ditch TS and have a JS codebase that is as clean as any TS codebase. Don't make the mistake to think TS does anything apart making sure you pass the right type to your components/functions. Anything you think it does more, is just your imagination.
Funnily enough, the messiness of a codebase is one of my biggest worries when joining a new company 😅
This was exactly my attitude when I was introduced to a Typescript via a codebase that had poor types. It was actually worse than plain Javascript. Fortunately, after a few years, I now know better and any terrible Typescript experience is the fault of a particular codebase and not the language. The language itself does nothing but enhance productivity and is excellent.
There's not a whole lot of things that are black and white, but the author of this article is just dead wrong. I've used enough good and bad Typescript to have learned that lesson.
I don't know why the DEV Community's newsletter showed me another super opinionated article in the first place just because it's attention-grabbing and has many likes/engagements.
Talking about the article, instead of "17 Compelling Reasons To Start Ditching TypeScript Now.", the title could have been "17 Compelling Reasons Why I Ditched TypeScript." The author says:
So the title should match with the author's opinions.
It's probably the first time i'm hesitant to write a response to an article, but not because i'm unsure what to say.
It's because i'm unsure i want to encourage this sort of "articles", but okay, i'll bite, because i believe the truth comes first.
And the truth in this case is - this is not a programming article. This is not based on facts. This is an opinion piece disguised as a fact-based article, and i despise it for what it is.
If you are someone that scrolled to comments first and are now thinking of reading this article - please don't.
Be wary of the people that just tell you to ditch some technology just because they "know better". If that's their biggest argument - they probably don't know any better.
However, if you already did - i'll break it down in a separate comment.
The verbosity point (#3) says everything one needs to know about the bias the author has in this article towards using JS.
You can’t be seriously saying that adding
number | stringin 3 places made the code unreadable. I feel like there’s some sort of deliberate protest against TS as I’m sure the author is smart enough to understand the code just as well when it’s written like thiswidth: numberor like thiswidth.Also, what does make the code bloated are all those objectively useless js docs the author added to the examples. If you are familiar with actual clean code principles and code smells, you will immediately understand that the example code in point #3 should never pass code review whether it was written in TS or JS.
Now, there are cases when you must document the code but only to explain the WHY when there is no easy way to do so with just code.
I see that he is also saying things like it depends on the project and it might be better or worse to use TS or JS but he inevitably gravitates towards finding some reason why it’s still better to use JS.
A senior developer doesn’t need types kind of attitude - I read this almost in every post that hates on strictly typed languages. This statement comes from a point of arrogance. I have interviewed well over a hundred developers in my career so far and I can tell with certainty that “senior” is a very relative term. I see comments here also mention this idea. It doesn’t surprise me as ego has a big influence on all of us (myself included) but recognizing that seems harder than we know. Please, define what “senior” actually means for yourself first. I can tell you that everyone makes mistakes. From beginners to Professionals.
In summary, this is a showcase that not everybody will like TS which is fine. The article, however, could include much less subjectivity and therefore been much efficient (pun intended) with sharing the intended message.
I do applaud the author for the desire to share knowledge with the world. Whatever the motivation behind it was. I hope the more he writes the better his insights will become.
P.S. Types do make the code more bug free, to use the term the author wrote. There’s even a paper about a study conducted that showcases this. m.slashdot.org/story/331629
Oh God this might be the least substantial, most subjective, most worthless article I ever read.
Being against static typing is like a structural engineer being against mathematics because it’s just a waste of time.
It’s time to take amateurs out of computing, now, for the sake of our collective digital infrastructure.
Thank you for your comment, but I have to say that I'm disappointed. It's painfully obvious that you don't have the qualifications or experience to suggest anything. Your comment was nothing more than a collection of ramblings and insults. How much did they pay you for your rambling comment?
Your comment was not useful at all. Instead, you chose to insult rather than deliver something useful. This is simply unacceptable and an absolute waste of time. I would suggest that next time you take the time to think about what you're going to say before you say it.
The amount of respect or credibility given to someone should be based on their experience and qualifications; not on whether they agree with you or not. In this case, it's clear that your opinion lacks value and insight, making it irrelevant in the grand scheme of things.
Therefore, I suggest you take some time to reflect on what constitutes respectful communication before commenting again in the future. It's important to remember that thoughtful responses can make a difference in how others perceive you, and how seriously they take your opinion.
I would like to put my own sentiments and opinions as I have also made my own controversial post regarding the state of the JavaScript ecosystem, which makes me also qualified enough to make my own two cents on this matter.
I would admit, my first reading on this entry felt really hostile, but reading it more I understand the point you are trying to cross, but I do have some counter-arguments too on this matter, all based from real experiences and lessons I have encountered when working on large companies and startups.
Counter-point 1: It's more familiar for those who has never touched JS.
I agree that while something like this for JS shouldn't be a necessity, but the language can throw off anyone who has no prior experience with JS or any dynamically-typed language at all.
Picture this example: I am a C# programmer with 10 years experience in my boot and I want to get into web development using the existing web development tools out there (let's assume Blazor doesn't exist yet for the sake of brevity). I will find TypeScript more familiar because:
I am already familiar with defining my types and I am comfortable with reading my code this way.
It requires almost few to no learning curve for me (JS after all does borrow a lot of Java syntax - shocking!).
It is (subjectively) more ergonomic to me as I have read way more verbose code before with my language of choice before I wanted to dip my toes in web development.
What does this mean? You can train any developer that has never touched web development at all, and they'd be able to get a day's work done with TypeScript.
Counter-point 2: There are already runtimes/editors that reads TypeScript by default
If you've been following the JavaScript ecosystem recently, you'd be hard-pressed to not find the more modern toolkits like Bun and Deno not already ship with a TypeScript compiler by default! And we don't even need to go farther, because TypeScript's compiler can be embedded almost anywhere that has a JS Engine that complies with ECMAScript's standards.
This does definitely mean nothing, but this also puts the perspective that TypeScript is so widespread that it'll be too hard to not find a single editor that doesn't have support for it unless it's so legacy it can't be used at all (add the fact Microsoft has championed an open protocol that even your text editor supports).
Counter-point 3: TypeScript is more than just the language itself
The TypeScript team have been closely followed the ECMA TC39 working group so well, and had presented all the lessons they have from TypeScript to integrate to the JavaScript Language itself - and one of them happens to be the Type Annotations Proposal. And TypeScript also allowed us to use latest ECMAScript syntax without ever waiting for the JS engines to implement them.
I have always lauded TypeScript because it allowed to experiment with some of the Stage 3 proposal changes to the JavaScript language, so in a sense, it allowed me to visualize the future of JavaScript without worrying about JS engine differences.
Oh did I mention it can analyze JS code too?
Closing words
Of course I will not cover things like strict mode in the runtimes, but I will also point out that I will also point out that everything is opinionated, like the article itself. While, of course, its possible to write vanilla JavaScript (which I do sometimes a lot), it will still depend on your the project's scale as well and the situation at hand. I cannot speak in whole at the JavaScript community, I simply speak in my own words and my own perspectives on what I think is "effective".
Sincerely, a TypeScript/JavaScript developer.
Mahmoud, I appreciate the time and effort that you put into writing this article. However, I think the reason you are getting so many negative comments is because your title is misleading.
I came in to read this article with an open mind. I came out of it without anything useful.
These are not "Compelling Reasons", these are just your personal opinion, most/all of which I disagree with.
It's because I can disagree with them, that they are just opinions. They are not facts.
They are also redundant. I would bundle up "Learning Curve", "Lack of Readability", "Lack Of Intuitive Syntax", "Low Productivity", "Lack of Flexibility" into the same category: "You Don't Understand It Well".
JSDoc is a terrible alternative to TypeScript. I speak from experience.
I understand that you are frustrated.
But, unfortunately, your article is a disservice to the community.
On the plus side, you put yourself on the radar, right?
Bad press is better than no press?
Thanks.
Semi-clickbait.
It seems like you jumped straight into the comment section.
Not everything written in this article is actually a personal opinion. There are well-referenced facts and evidence to back up my claims.
It is ok.
?
Hahahahahaha. Not really.
So you are using TSDoc to document your TS code, right?
Ok.
What? When? Why?
Nope. I am always on the radar by default.
Absolutly not. I hope you'll take the time to read it and that it will be helpful to you. Thanks again for commenting!
You are polite. I will give you that.
This does not change, unfortunately, how misguided your article is. You should not have "Wise" in your profile, based on this article.
So many negative comments, Mahmoud. I hope you are not so delusional as to think that you are right and everyone else is wrong.
Bye now, and take care.
This article must be the most bonkers thing ive ever read about typescript.
The line
"Typescript can be slow and cumbersome, especially compared to more streamlined languages like JavaScript"
KILLED ME
Is literally IS JavaScript i am so confused. I feel like writing an article refuting everything here
It's good to read articles about TS stating the other side of the argument; but I think you've introduced a bit too much noise with the number of downsides you list; not least because some will be considered opinionated or faults in the user rather than the language.
I would concentrate on a selection that can be backed up with more compelling evidence:
Sadly this has become another religious argument (as can be seen in some of the comments) so you have to be extra careful when presenting the negative side of TS; otherwise you'll just be labelled as a crazy heretic 😅
I'm at least reassured by the fact that there are a few well established developers who share our opinion/experience; like this guy
The length of this article and lengths you've gone to really show how much you despise typescript. I'm sorry it's caused you so much frustration.
I think enough other people have pointed out how incredibly subjective and biased your points are so I won't comment on this.
However, Typescript is 100% the way forward. Trying to be as objective as possible (as I resisted it at first myself, and flowjs, and jsdocs), my productivity is 10x what it was when using vanilla js. And I can onboard someone to a typescript codebase so much easier, because it's all typed and self-documenting and they get code hints out of the box.
Perhaps (again, like me a few years ago), the issue is more that people aren't using typescript cleanly.
Pretty sad that dev.io pushed me such an worthless article and so many people waste time to argue with those meaningless points. I would say this article is quite successful to gain traffic with dramatic title. But it's just a waste of time reading it. Like learning any new language, we will face difficulties with the limitations of our experience. it's normal to take a personal notes to write down those initial pain points. But not appropriate to publish those points within a month without much deep understanding. Please wait some time and gain a bit deep understanding and review those personal note to see if they still make sense before making the public judgement.
And the big "bad corporation" rationale is soooo boring. I don't see people complaining to Oracle about MySQL, or complaining to Google about NodeJS or Chrome (the browser area), etc. etc. etc.
It is just this aberration linux hippies have against Microsoft. Is Microsoft trying to push its product? That's called marketing. Nobody is forcing you to use it. I guess Microsoft haters will hate for no good reason.
It appears you're trying to convince people to lose interest in Typescript just because you don't like it. You can find a number of flaws for any language, but in the end what matters is what you do with it.
Jesus christ, this is the epitome of unfounded and obnoxiously verbose ramblings from people who barely understand what the hell they're talking of and are just playing it for the engagement.
This app is overdue a dislike button...
I find the article to be a bit repetitive in the "reasons" . "Hard to learn", "makes a mess of the code" and similar phrases plague nearly all 17 given "reasons" not to use TypeScript. That being said, I totally agree. I don't really care about the learning curve, as devs, we need to keep learning new stuff all the time.
So my experience with TS was this: I got assigned to work on a project that is using TS. I come from a GoLang background, so I understand how type systems work. We were using a framework I was not familiar with (which was actually a collection of other frameworks mounted on top of each other). I got to a point where I needed to use some of the frameworks internal types. I literally had to spend hours reading the frameworks type definitions, or just copy pasting examples from different web sites to get anything done. The IDE would present a "type hint" that pretty much looked like gibberish for any given function argument in the framework, so they were utterly useless, and in the end, it turned out that the argument could simply be a string.
I can work around those issues and can see the benefits TS brings, but I do agree, it's not a perfect solution and is not suited for all projects.
Nice recommendations on JSDoc and Flow. I will read further about these!
just read the title and thought “what a horrible idea.” as an engineer that has worked in the javascript ecosystem professionally for over 10 years now, every project i currently work on is written in TS. that goes for open source projects i work on to projects for my job, all of them are written in TS. on a personal level i wouldn’t choose anything but TS for any project i would start in the JS ecosystem.
it looks like the post has gotten a lot of the same review by the community, so that goes to show how important many people feel about the usage of TS. most of the comments offered in the post are simply illustrating the writers lack of programming language awareness. these patterns and ideas that TS adds to JS are common in most other programming languages. as a mentor i have found TS only clarifies the confusion most new engineers experience with vanilla JS.
I had to check the the year because these articles were very popular like 5 years ago, but have mostly vanished since then.
I think over time a developer gets burned by enough bugs that TypeScript could of prevented that they just give up and use it.
None of your points talk about the consequences of breaking the build for the team, or the product for the end user.
New programmers often have trouble and fight the compiler, that’s why learning yo program is better with a dynamic language like Python. Experienced programmers though see the compiler as an indispensable tool ensuring entire classes of bugs are prevented before the code even runs.
Not really flaws, but rather missinterpretations of my own words.
I mean, ever read the introduction? Also. not everything shared in this article is really opinions, but well-referenced facts and evidence to back up my claims.
Typescript is a whole lot more than just adding types. It has many more features to add productivity and make a code base a lot better and dry. That said, the adding of types is hugely important in itself. If you're doing a tiny / trivial project, fair enough go ahead, but anything serious if you're not using typescript you are doing yourself and your company a huge disservice.
Not necessarily the case. The following are some good IRL examples:
Comment 1 by István Pató
Comment 2 by Jimmy Wärting
https://www.youtube.com/watch?v=xLDVfBUgD8U&list=PLMbQ6gO16YCfehsIRfF4UQvJeYckFY9W-&index=26
"TypeScript nowadays is the hottest trending JavaScript dialect and is becoming more and more popular in the community. We all know, the TypeScript key feature is the introduction of static typing in weakly-typed JavaScript. But that’s not for free! Let's recap - why do we need types? What are the advantages and disadvantages of using TypeScript? What is its cost and what’s the impact of its adoption? And then the trick: get the benefits of TypeScript without using it!"
"2. Strict Type Checking System."
How are you going to list the entire reason the language exists as a downside? This post reads like you don't understand what Typescript is for.
Flow is faster,really? I read it was slower than TS. If you think JS can’t have solid type system you should check Elm. It transpiles to JS but it has a very solid type system with excellent compiler error messages and speed.
And what do you think about PureScript?
I also had a grudge against TypeScript. Ever since I started using frameworks that actually push you towards TypeScript, I started to like it. Started feeling forced though, but debugging got so much easier, intellisense also makes coding faster in the long run.
Some languages, you just got to push through your hatred, to like it.
Oh, come on :)
So how many projects (commercial or just pet projects) you've really finished and deployed using TS and/or JS?
Better titles for this article: "17 Reasons Why I Misunderstand TypeScript" or "17 Ways That I Lack Understanding of TypeScript"
Great article, thanks for the research and write-up. I noticed sveltekit is also making the move towards jsdoc - twitter.com/Rich_Harris/status/144... - considering javadoc has been around for decades, your article suggested a natural progression for Js. Good job.
Typescript is a hugely important and necessary development, in fact of strategic importance to any business serious about its software quality and productivity, and I am concerned that articles such as this have the potential to mislead developers and managers. I spotted that the real issue may be that junior developers have been told to use Typescript without its benefits and reasoning being given and hence leading to attitudes such as this.
Does DEV.TO have any editorial process to pre vet articles? I have to question the wisdom of publishing such articles which can seriously mislead.
Wrong! it is definitely not "hugely important". The reason why you believe it is is a sign you have rather limited knowledge and have yourself been misguided for believing it is. So I rather would want dev.to to remove all "always use TypeScript" articles, because there is very limited such cases in real life.
What people like you forgot is time. Sure, if you have everything equal, "types" is preferred, but guess what, that condition do not exist. Time is always a limited resource. Good tests is 100% better than using types, so developer would prefer those instead of over-use TypeScript.
It is not even type safe for god sake. You don't know TypeScript if you don´t know that.
I also know typescript and haver one year experience with it.
But I spend more time getting the types right instead of programming at all and it let you stay in the OOP world I want to leave. It seems to me that the java and c# guys who wants to programm in their known OOP world preferes TS over JS.
So the last five years I stayed with JS and was lucky with it, no need for TS.
And to get the thing right, I write more test, that explains the code in more detail than TS ever can with its types.
Maybe this can be a way to avoid types?
Would you argue jumping into a typescript codebase is more difficult then a JS one? Having worked with large codebases, statically typed is always easier to parse and prevent future bugs in my view. And JS code written by others, is just exponentially harder to debug. Both of these reasons are why I like TS better then JS.
This a troll article right? Please tell me it is
And I'm sure your company can also find 17 reasons to ditch any of their programmers.
The only thing I dislike with TS is the added bundle/build complexity. Setting up babel and other stuff like that is such a waste of my time. But I still do it, because it brings tons of benefits that you've probably missed, or misunderstood how great they are.
Where's the popcorn emoji?
While this article is well written, I can't help but feel that the social media culture of looking for views based on controversial opinion is slowly filtering into "development" blogs.
Getting a bit tired of it all.
I don't understand why people get offended. I understand the article because I have been in that same position.
I don't have enough TS experience for all those cases. But I understand you and I identify with every detail you indicate.
It's like someone goes from python, php, js to languages like Java and C#, where the level of complexity grows and you start to doubt everything. That is to say, something that you did easily and quickly becomes a longer task and if you don't immediately see the benefit it seems like a waste.
Yes, everything has its benefits, its pros and cons. I have been working with Angular for a year and it was easy for me to understand TS because I used java. And yes, with what I've been working on I haven't needed to investigate much more in TS, which is much more complex and deep and I don't think anyone has really learned it at all (I have books that I haven't finished and there is always something new).
In short, I see it as resistance to change, not that the tool is bad as such. Yes I have seen people making disasters especially with the "any" but I still prefer it than the disaster I have seen with pure js 🤣
In the end: It doesn't matter, in each job one adapts to what the company uses and that's it. The discussion is good but we are not going to achieve any change. It's just to relax and read.
I like how you write and structure the posts
It was over all well written indeed. Everything has pros and cons, but TS people are a cult and it is extremely bad for our society. If anyone should be cancelled/censored, it is those people.
If you want to use types, use c++/rust and compile it to webassembly. If you want flexibility, use JS.
The only reason to ditch TypeScript (the .ts file extension actually, not the tool) will be having the option to add types on the JavaScript itself. Then we would not have to use the "compilation step", if we want rich type-based dev environment. "allowjs" and "checkjs" are very handy. But I cannot put some little hints here and there to hint the ts engine checking my code.
Great developers always have made great tools already.
If you don't want to wait for compiling, use SWC. this will cut your 'wasting time' down to milliseconds.
(Deno uses SWC under the hood)
'Developer' means a person who develops something new.
MS and the open source team developed Typescript and IDE like vscode to solve problems(I won't mention them here),
and other developers also developed a fast ts compiler to solve another problem.
That's how open source works and how new technologies are made, on the other hand, you didn't develop a new solution nor even try to search google on how to make TS compile faster.
"Typescript compiles slowly so it should be avoided"
This is an off-topic argument, at least it seems to me.
99% agree, the article is brilliant. Just 1 small point: Typescript does not have a couple of advantages mentioned in the article, which I guess author put them in the article to keep brain washed typescript programmers happy and avoid their F-words.
For example: Typescript is unfamiliar for both JavaScript Devs and other languages Devs but gives a fake sense of being at home to people coming from BackEnd.
Also I can add, Typescript ecosystem (not the typescript itself) never tolerates JavaScript co-existence.
The linting/ defined policies/ brain washed programmers who push for Typescript are already making it very strictly preferences and opinionated environment. Even some Typescript keywords has been already restricted (like "any")by these brain washed programmers.
Says the guy who uses
varI wasn't aware that there are
varphobic folks out there. Ma bad!I don't see any alternatives to Typescript in my case, since I immensely enjoy template literal types, mapped types and generics. The alternatives don't seem to be as potent as current Typescript, as flawed as it might appear.
Thank you for your time writing this.
I have thought a lot about TypeScript and have debated a lot with colleagues/friends and I think I know the answer if we should hate TypeScript or love it.
Everyone, YES EVERYONE, loves the benefits that TypeScript provides (mostly IDE autocompletion and Type Annotations being able to specify types for variables, functions etc)
But almost everyone, hates the fact that we have to change JavaScript Syntax to achieve that. For me, since I don't see an alternative, sacrificing JS Syntax is ok in favor of getting those benefits.
So the answer is that TypeScript is needed and it doesn't really makes sense to have a project without using it because we are missing so much with pure JS. In fact, studies have shown that just by having TS you get rid of many potential or hidden bugs.
But... and there is a huge but here... large projects with TypeScript usually have a lot of unreadable code and some types that I call "masterpiece art" because it feels impossible to understand that code and very difficult to create it from scratch.
So it's crystal clear, that we need a tool to enable all the benefits of TS but with writing JS code. I have thought a lot about this and all I can say for now, is that this tool can exist by doing something like Quokajs -- so knowing what actual value a variable holds -- in order to provide IDE autocompletion and an extension where we can easily specify the "type" of a variable. Think of it something like a popup showing up on hover where we can specify what type a variable should be, type functions etc but all that without altering JS code. The truth is that for this tool I think of leveraging TypeScript and inlay hints from VSCode to show the types but this project is just in the "idea phase".
To summarize, TypeScript is very useful but the truth is has many downsides. Nevertheless, TypeScript is great even if we don't have to write TS code in the future it, for sure, made a lot of impact and improves a lot of things
Problem with TS it that its advocates don't understand specific workings of JS well enough, and adding TS to that makes the problem double in size. The result is building low-standard problematic, inefficient verbose code. It is wise thus to avoid companies that insist on TS instead of JS. because you will spare youself of a lot of future trouble. I have seen quite a lot inefficient, spaghetty TS code where programmer tried to be 'smart' instead of being efficient, and I always LOL seeing using type 'any' whenever he/she puts himself/herself into the corner. They simply don't understand that JS is a functional programming language, not an OOP strict-type language
TS advocates ignore fundamental fact, that resulting compiled JS code completely ignores everything you wrote in TS. This isn't even problematic, it's hillarious. I avoid such environments like a plague
I scrolled DIRECTLY to the bottom to see what the comments looked like.
Congratulations! Your post made a comment section worthy of reddit!
Will somebody pass the popcorn?
Garbage. How is this getting so many likes?
Not reading this.
There's no reason to ditch Typescript.
I will not stand for such heresy.
What a silly write-up, I feel sorry for any young, impressionable devs that are unfortunate enough to stumble onto this blurb of ignorance.
I think this article would be more accepted with a title such as "My personal opinion/experience with typescript".
If you are a new developer out there please know that the drawbacks listed above are not ratified factors to choose on whether you should learn/use typescript or not.
Typescript is a great programming language that solves a lot of problems especially in big projects maintained by large number of frontend developers.
Sorry to spam, but I just have to gripe a little. The JS code I have insists on cute little runtime JS checks at the head of every function (e.g., const { query } request || {}). That is wasteful and late to catch bugs. Once you've deserialized a value and checked its type validity, you're always assured that value is correct, at compile time, no less, and you never have to check its type ever again...even and especially if (!!requiredValue) return false
All of these are a YOU problem not typescript problem. You get shitty code when you write shitty code, typescript has an incredibly powerful type system…
No offense, but this attitude makes making new code easier at the expense of those who will try to debug it later. Again, please please reconsider if you're working with other humans on a project that will grow at all.
I'm in the middle of converting an old JS project into TS. Maybe it's just a little more experience, but fighting with the compiler is a good thing! Loosy goosey, non explicit typing is making this old code impossible to read. I encourage you and your readers to reconsider and do a bit more learning.
The truth is that typescript was purely created to give the devs who did serverside web apps in asp.net or jsp a tool with which they would do javascript. You would be surprised that in 2023 there are still devs who never wrote js apps but have done a ton of webforms or jsp.
You are far from the reality! Typescript is the future and your article is just because your frustrations nothing more, I hope your article will not stop anyone from learning typescript.
"I had just started using it, like one month in...." the only problem I think you seem to have with TS.
If you dont understood why type are must have - you probably never created really big JS app.
Your article did far more than spark debate over a technology - it [the comments] shows the extraordinary toxic climate of software development today.
I have never heard, nor do I ever expect to hear, a business fail because they didn't use typescript. Yet the level of emotion coming out of the comments section is so extraordinary - as if this decision is life or death to your ability to be a good engineer.
The best/experienced programmers and engineers that I've ever met would never ever say TS is better than JS. They would also not say JS is better than TS.
Yet I suspect that due to the extraordinary over-hiring of engineers in many companies, causing bloat, many engineers are just writing lines of code, aka managing software, instead of actually building software.
I also suspect that those against TS are at odds not necessarily with TS as a language but that its one of the many layers upon layers of libraries/frameworks causing build times to go higher and higher, and dependency management hell....needing tools like lerna, web pack...after a while, the fatigue sets in.
Maybe we need a new interview question for engineers - what are your current build times, and what could you do to reduce them?
I digress - going off the rails.
This was a good article that shows the level objectivity that we should always have.
Please post a link to the deno typescript discussion in the article. Thanks!
Update: I found it at docs.google.com/document/u/0/d/1_W...
and it says:
“Update June 10 2020: I saw that this design doc was being discussed more widely. Most people don't have the context to understand this narrow technical document - it is only applicable to a very particular, very technical situation in the internals of Deno. This is not at all a reflection on the usefulness of TypeScript in general.”
So now I see why no link was pasted in this “opinion piece” article.
[6] docs.google.com. Design Doc: Use JavaScript instead of TypeScript for internal Deno Code, docs.google.com, Retrieved 2022-12-28.
Is this a joke?
My thoughts exactly, have I been in a time warp and its April 1st already ...
"Clumsy programming style"? It's literally the flaw of JS, not TS.
Every 'disadvantage' you've written is actually a plus, you're just a lazy ass b*tch.
Lack of strict typing is a menace in programming right now.
I mean, that's what the data is showing:
Yeah, I see. Being able to deliver 2k+ lines of code daily is called lazy-a** b*tch nowadays.
Not necessary. I have also seen horrible things in statically typed ones.
One of the few posts that are hating on TypeScript instead of JavaScript. The one hot take that makes everyone point knives at you 😂
Those are a lot of words to say you don't like TypeScript.
Just don't use it
very week arguments ...
So same thoughts about the TC39 types as comments proposal?
tc39.es/proposal-type-annotations/
Bundle size btfo, probably...
Typescript is for Java developers in denial #tongue-in-cheek
Was this article written by ChatGPT as a way to drive new users to dev.to? If so, bravo.
This article was clearly not written by a ChatGPT. I have been writing articles for ages and have developed my own style of writing both with my name attached and anonymously on Wikipedia and other websites. As you can see, the writing style is sophisticated and professional, with an abundance of clear and well-referenced facts and evidence to back up my claims. This suggests that it was written by a human being who has spent time researching the topic and carefully assessing both sides to come up with an objective opinion. Cheers!
This seems to be the most talked post on dev
This article should be renamed "17 reasons I'm too lazy to write better code with typescript"
Respectfully resuming the opera: "Click bait"
Seems like a very biased view from the perspective of someone that's strongly disliked the adoption curve of getting used to typescript...
Hard to believe this article has been written by a "Wise" programmer.
This article is absolute useless trash.
Republish this on April 1st to get some good laughs
17 Opinions
Most of of are real though, hard truth for TS lovers though. Same for all extreme cults, truth is hard.
This whole article is one big eye roll!
As a JS lover I agree with 1 out of 17 points. 16 others are too subjective.
Thank you for the article ! Now I know what to learn for the new year!
SOrry I DONT AGREE WITH YOU. THANKS
Good efforts but I almost dont agree with the most of the article.
**
You can manage every check fromt the Jason file setting for the typeScript.
**
bs
Bruh.
Bad code is bad despite the programming language used.
The push function you wrote is an example of bad code.
Lol, no.
Can we just agree that they BOTH suck?