I've been seeing this trend lately: more and more developers bashing TypeScript. The gripes range from it being "too complex" to "slowing down development."
While not all concerns are unfounded, hating on TypeScript in 2024 just doesn't add up.
Letâs break it down. đ
TypeScript Isnât Your Enemy, Itâs Your Safety Net
I get itâJavaScript is flexible, dynamic, and lets you ship code fast. But that same flexibility is also what leads to bugs that are hard to catch until itâs too late. TypeScript's strictness isnât there to slow you down; itâs there to save you from spending hours debugging issues that could have been caught early.
Hereâs an example:
let id;
getUserByID(id);
In theory, id can be a number, a UUID, a random string, or a structured string. But depending on what type it is, you might get an error if you try to increment it or pass it to an API that expects it to have a specific structure and type.
And you can figure out what type it is by looking at how itâs used. But you know what makes this a non-issue?
let id: number;
function getUserByID(id: string) {...}
// and that's the most basic thing you could do
getUserByID(id); // boink, error!
When you add TypeScript to your project, you're adding a layer of security. Itâs like putting on a seatbelt. Sure, you can drive without it, but why risk it when a simple precaution could save you from a crash? đđĽ In a time where software quality is more critical than ever, TypeScriptâs type-checking is a safeguard that just makes sense.
Itâs Not as Complicated as You Think
Another complaint I hear often is that TypeScript is "too complicated." But letâs be realâJavaScript can be a mess. Function signatures that accept any input, objects that morph shape, and code thatâs one typo away from breaking in production. TypeScript isnât adding complexity; itâs formalizing or standardizing it.
Think about it this way:
Youâre working on the frontend side of a feature, and someone else might have some work overlapping with you. Thereâs also going to be backend APIs you need to incorporate, but those arenât ready yet. Youâve been asked to begin the UI work anyway.
How do you ensure that the code you write right now is consistent with the data youâll get from the APIs? And that if something does change on the APIs, thereâs a source of truth that all parties need to adhere to?
Thatâs right.
By defining types.
With types defined before implementation begins, there should be no confusion about what data contracts are shared between the UI and APIs, and if something indeed is different, then all that needs to be done is to go and stick to the contracts defined earlier.
If you can learn React, wrangle with Webpack, or deal with async/await, then you can learn TypeScript. And hereâs the kickerâitâs a skill that pays dividends. The learning curve is worth it because it forces you to think more critically about your code. Instead of hacking together a quick fix, youâre thinking about architecture, types, and long-term maintainability. đ ď¸
Faster Development, Not Slower
Thereâs this myth that TypeScript slows down development. But in reality, the opposite is often true. By catching errors during compile time instead of at runtime, TypeScript helps you move faster in the long run. Youâre not spending your days in the browser console, chasing down undefined variables or weird type coercions. đ
TypeScriptâs tooling is also top-notch.
Features like autocompletion, refactoring tools, and inline documentation make the development experience smoother. Youâre not just writing codeâyouâre navigating a well-lit, well-marked road instead of stumbling around in the dark. đ
Hereâs a personal anecdote.
Before I fully embraced TypeScript, I often found myself in the weeds of codebase archaeology. Iâd encounter a function and have no idea what arguments it was supposed to take. Was it a string? An object? What params were needed in this object? Which ones were optional? Was something that was made to look optional actually required somewhere in the callstack?
Because devs arenât perfect, poor variable names, inconsistent naming conventions, and coding preferences get in the way all the timeâŚ
So, Iâd do the dance: scrolling back to the functionâs declaration, digging through implementations, trying to piece together what was supposed to go where. And if autocomplete was supposed to save me? Forget it. It was useless. The code editor was just as clueless as I was. đ
Sure, you could argue that JSDoc comments might help. But if youâre going through all that effort to manually document types and function signatures, then why are you doing that to yourself? Youâre basically doing TypeScriptâs job, but without any of the actual benefits. TypeScript eliminates all that guesswork, letting you code with confidence and speed.
TypeScript Is the Future (And the Present)
TypeScript is on its 5th version. Itâs basically at 100k stars on GitHub. It has 55 Million+ downloads PER WEEK on NPM. More and more major projects and companies are adopting it. Thereâs a reason for that: TypeScript brings stability, scalability, and confidence to codebases. Itâs not just about todayâs project, but about building something that can grow and evolve without collapsing under its own weight. Itâs about not having to write documentation and tests separately all the time (it doesnât entirely replace them, of course).
So, letâs cut through the noise. The hate TypeScript gets in 2024 is largely misplaced. Sure, itâs not perfect â no tool is. But the benefits far outweigh the drawbacks. Itâs time to stop viewing TypeScript as an obstacle and start seeing it as the essential tool it is.
Embrace it, learn it, and youâll find yourself writing better code, faster. đŞ
TypeScript Isnât Perfect, but donât let perfect be the enemy of good!
Of course, TypeScript isn't without its flaws. One legitimate gripe is the overhead of setting it up in a project that wasnât built with it in mind. Converting a legacy codebase to TypeScript can be a time-consuming process, and itâs not always feasible for teams that are under tight deadlines. âł
Additionally, sometimes TypeScriptâs strict type system can feel like itâs fighting you rather than helping you, especially when you're dealing with complex types or third-party libraries that havenât been properly typed.
TypeScript is only as good as the dev configuring it.
Iâve worked on multiple TS projects, some of which had relatively lax configurations that would allow people to use any types or avoid strict or null checks. You mix untyped or loosely typed code into a typed codebase, and the situation could end up being bad enough.
Where do we go from here?
That said, these are short-term pains for long-term gains. Yes, it might slow you down initially, but the stability and maintainability you gain more than make up for it.
And these issues used to be a lot more severe a few years ago, but itâs arguably a lot better now.
In my opinion, put in the effort to learn TS. TS enables you to partially introduce it to an existing codebaseâtry that. Or perhaps create smaller pet projects that leverage TypeScript.
Plus, TS devs make a bit more money than JS devs based on the most recent StackOverflow survey.
And speaking of better code...
If you're curious about how TypeScript can level up a real-world project:
âĄď¸ Check out the Middleware repo âĄď¸
It's a great example of TypeScript in action, and who knowsâyou might just pick up a few ideas for your own projects! đ
Even better, tell us how our code IS NOT the best!
If you have some solid suggestions, I'll amend the post to include them as examples!
Top comments (86)
Wow, even If I wanted to seriously discuss the bad side of TS the level of blindness idolatry to TS in this post and comment section makes me actually feel happy I dodged the bullet of this cult.
"TypeScript's strictness isnât there to slow you down"
Sure, just let me read 100 lines of cryptic named type definitions before I understand the actual useful 5 lines of a simple function.
Typescript != Saviour of your bad junior
JS code.
"Itâs Not as Complicated as You Think"
Can you shout this louder to the thousand of TS devs that end up using "Any" because the complexity is just not worth it? đ
"More and more major projects and companies are adopting it. Thereâs a reason for that: TypeScript brings stability, scalability, and confidence to codebases. Itâs not just about todayâs project, but about building something that can grow and evolve without collapsing under its own weight."
Are you saying before TS existed 100% of pure JS projects eventually collapsed by their own weight? Because that's a WILD claim. Truth is JS has and will keep thriving with or without TS.
That's some super strong hate towards TS.
This is just super exaggerated. I've never had 100 lines of type serve only a single 5 line function. I can't imagine when you'll have types taking more lines than your implementation. If you exclude code within libraries, then, sure, technically that can happen.
No one is claiming this. :)
A bad dev will write bad code in any language.
The world was writing software before TS, or even JS was a thing.
TS is not a silver bullet. But for those who want to generally improve the maintainability of their codebases, it offers a lot.
And clearly enough people feel the same way about it, given that super recently Node.js took the first step in introducing native TS support.
news.ycombinator.com/item?id=41064351
Oh believe me, I've seen a lot of TS projects and the bigger they get the messier it becomes for newcomers to understand it. It is just a hell of type extensions and file navigations. I also see it when I add a TS package to my codebase and I want to see the source code, I start clicking on my IDE type definitions and I can keep clicking through types and types, we even have a game with other devs, "let's see who can get to the first "Any" type with the lowest clicks possible" heh.
And clearly enough people feel the same way about it, given that super recently Node.js took the first step in introducing native TS support.
Shure, Node likes to listen to their community, but is that always the best for Node? I doubt it, I doubt embedding NPM (the slowest package manager of them all) into Node was the best decision. Also "native TS support" is a big stretch. From the original issue:
"It is possible to execute TypeScript files by setting the experimental flag --experimental-strip-types.
Node.js will transpile TypeScript source code into JavaScript source code.
During the transpilation process, no type checking is performed, and types are discarded."
Does that sounds like "native TS support" to you?
I am that newcomer who doesn't understand it all , but still tries.
Nice too meet you lol .
Have you ever worked on a large monorepo with extensive incoming data? It's not unusual to see 100 lines of type definitions for just five data types. Using type composition and extensions can easily result in even more extensive code.
Not to criticize TypeScript, but many projects still rely on standard JavaScript. It's best to avoid switching to TypeScript unless you're prepared to thoroughly revise all existing code. However, starting a new codebase with TypeScript have benefits, provided the developers embrace it.
I'd say it's best not to move a large codebase that is not already on TS, to TS.
Or at least isolate parts of it if someone is really planning a migration to TS.
But neither of that really relates to hating (or liking) TS. It's often not practical enough for a business to undertake that effort unless there are significant issues with the code which somehow only a language change can solve. Now that's super unlikely.
Wow , so your just directly saying ,
Its best not to move onto a codebase of a large project already using TS ?
Because I am definitely doing that here bro , and I definitely have no other choice to get this project working for a MC manager. .....
github.com/MCSManager
This project needs help if anyone has the time ,
I have a serious developer question.
This is not to jump in a rant or pick a side , I have heard this for some time.
I will ask a simple question here , and a simple one alone.
" Is it , or is it not possible , to produce the same readability by separating your JavaScript code , into a simple file that does the typechecking and then , an application to run those variables? "
If it is possible to structure such a thing in such a way ( which i think it is , ) I would like to try it to make an example.
Basically , lets see if we can simply do the same thing that typescript does , but just in vanilla by hand ?
( Minus the config files and compilation )
I would certainly be more than happy to try and give a go at it , for good demonstrational purposes.
Then , I could make a npm package for it.
Reducing the value of typescript to rubble.
--- Checkmate.
Oh jeez, you poor passive-aggressive soul. Developers don't "hate" TypeScript, they hate introducing overhead that doesn't bring equal to greater value to their codebase. This whole post is based around a strawman argument supplemented by terrible takes and rebuttals for it's own critique of an argument/claim that NO ONE IS MAKING!
The best way to look at TypeScript is a "build tool" because that's effectively what it's adding to, the build step. TypeScript is a glorified Linter that allows you to define, while developing, rules for your codebase's types. Great!
However, guess what doesn't give a damn or even know what those defined rules are? Your end-user and final production code. TypeScript doesn't fix things for the product, it fixes things for the Developer. Can that lead to improvements in the product? Sure! Will it always? NO!
Even in your article you agree hint at this, it's still up to the Developer to not mess it up right? Well why not just use the same argument towards writing JavaScript? We have an array of different best practices and design patterns that have been battle tested and refined to a point where I fail to realize where TypeScript really fills in the gaps? Here's some scenarios where TypeScript is actually cool: Introducing new devs to your codebase (assuming your Types aren't overly complex of course), helping developers when they have dive into low-level code in the codebase (could be old code for example that hasn't been updated in awhile), and adding an extra of build-step requirements to ensure the code follows the plan that was set before.
Linter, unit tests, JSDoc. These pretty much eradicate the need for a static type system and additionally add to your codebase in a positive way with less overhead than TypeScript. Enterprise software however, LOVES TypeScript because it's just an extra layer to add to all this, because why not right? Why do you think Microsoft developed it?
You're falling victim to a very bad behavior which simply, hop on the bandwagon of a new technology and point fingers at anyone on the gravel path that doesn't care about, and is doing complete fine without, your bandwagon.
Why would I want to introduce this huge overhead for a majority of my projects, when I can simply write some comments, generate a markdown file, and call it a day?
Pointing at Node.js introducing basic-level TypeScript support doesn't "support" your argument either. It just shows you can't actually form a defense for your argument so you use someone's PR to say, "I'm right because they're doing it too".
Create flimsy critique of strawman argument -> Hide behind a PR to defend the flimsy critique of strawman argument -> I win????
Is that the plan here?
Spot on. Now, let's abolish the weird
classsyntax too.The class syntax is actually an overhead that is welcomed by the community for good reasons.
It takes little-to-no effort to bring into a codebase, it actually makes it easier to do things with classes (private/static variables, extending classes), and they make the code clearer.
Comparing classes to TypeScript is a very naĂŻve comparison. One is focused on a singular part of JavaScript, the other wants to enforce something across ALL of JavaScript. They're fighting two different battles.
Class syntax is for the most part syntactic sugar and introduced to 'lure' developers with a disdain for JS/ES20xx into the language. A new and imho better idea (even better then the native JS/ES20xx prototype oriented programming) is class free object oriented programming.
To sum up: to get the most out of JS/ES20xx I would advise
And to be complete: try to use the functional nature of JS/ES20xx to the max.
I have 29 year experience with (server-/client side) JS/ES20xx and this is where my coding style evolved into. Still, everyone is free to code their own way ofcourse.
I mean sure you can go your whole life without using ES6 class syntax.
But it is it hurting you in any way to use it? Does it actually get in your way at all? Trying to fit in using function syntax instead of class syntax into a conversation about TypeScript is a bit odd. It's like riding on the coat tails of one political movement to advertise your own? They don't really seem related...because they aren't.
What's even the problem being addressed here? Aesthetics???
TypeScript is about static typing JS/ES20xx. Class syntax is an addition to JS/ES20xx. Both are unnecessary and (imho) polluting the language.
BTW 'Function syntax' is not a thing. If you refer to my recommandation to use the functional nature of JS/ES20xx I meant: try to use functional programming where you can - because JS/ES20xx basically can be used as a functional language.
JavaScript is an Object Oriented Programming language.
I don't even LIKE objectional programming , I am a functional dev ,
But even I will tell you , if your not creating objects through classes in a object oriented programming language ,
Your probably using the language wrong.
Classes are the base foundation of OOP languages , its elementary.
I love TS for Type safety đ¨âđť. My favourite type is any.
I'm in the camp that TypeScript just isn't necessary and it adds additional overhead both in setup and maintaining type definitions. JavaScript is loosely typed by design which is one of its biggest strengths.
I would consider using types more with JavaScript if it became part of the official spec.
You're saying JavaScript is loosely typed by design, but that you'll consider using types if it becomes part of the spec. So you hate typescript so much that you'll only consider using it if it becomes part of the JavaScript spec...
it's not a matter of love or hatred to the typing of variables.
for me, it's a matter of scripting vs. compiling. during compilation, we even forget what we intended to achieve.
so, including types in the runtime would definitely help.
I don't "hate typescript so much" it's just not necessary. We use it on some of our projects.
Debugging untyped code is a nightmare, so I would say it is absolutely necessary, but to each their own I guess. I highly prefer not having to debug someone elses runtime mess.
You might be interested in this: news.ycombinator.com/item?id=41064351
I'd say JS offers a quick start because all the context about definitions and usage is in your head, and the moment a 2nd dev joins the club you need to start documenting things in some form.
You might choose JSDoc, or comments. And that may or may not get followed at all.
At least types are enforced on compile time, and it might feel like it's extra work to get started, but it saves time later.
You could say poorly written types will cause greater headache, but so will poorly written/documented code in any language.
I absolutely HAVE to agree with you here ,
the communication around documentation of code , is the single biggest interoperability problem of the 21st century , and the organization around typescript for that does have some caveats for that.
The only thing with that is ,
I have seen hundereds of typescript projects and not one instruction of how to compile it.
At least Vanilla JavaScript doesnt have to give you compiling docs to read for config files to just set a freaking typecheck.
It comes to be a matter of choice in this , as it is hard too argue that ALL the documentation for compiling and building , is still better off than vanilla.
Strongly agree.
I always hated typescript and could never find myself using it. Then someone insisted I should try it "you'll never imagine how much typescript auto infers for you, so you don't even need manual typing".
I was surprised! And never looked back. The tooling, especially intellisense has sped up my development so much more than typing those extra characters.
typeofis your friendintellij sucks , and no one here wants to buy their crappy products.
typeof , is a VANILLA JAVASCRIPT METHOD.
And thats your claim of why to use TS ,
a vanilla js method.
Really ? is that all you got ?
typeof is a vanilla js method in runtime code, but is a ts keyword in type code. I'm not dumb.
typescriptlang.org/docs/handbook/2...
And who mentioned intellij? I use vscode all along.
The holy code of TS: immaculate, pristine, clear... If you don't understand this in 0.3 seconds you shouldn't call yourself a JS developer ;)
You can write complex/confusing code in any language. :)
And sometimes the language necessitates writing weird code to get what you need.
But using an exceptionally complex example as an argument against a language is a non-argument to begin with.
I wouldn't call it "exceptionally complex example" when I just google "typescript code" and got dozens of screenshots like that... I'm pretty sure I will always find TS spaghetti code without much effort. Heres another one!
I know the code is nonsense but that's not the point... I'm talking about making JS even more readable complex by adding an unnecessary layer of definitions.
You cant just say that some code is not worth talking about dude.
This is typescript code.
Read it and weep , you cant make excuses for everything.
Respond to the post.
Can you read the typescript code for me bro ?
Library authors usually write such complex types to make their API work magically in vs code intellisense, but most devs will never write such code
this looks my code before the release date đ
I work in a typescript spa just over 500k lines and never seen garbage like that.
I am all in favor for strict typing. My language of choice is Ada which statically and strictly typed; so strict that it would not cast an integer to float, unless you explicitly ask for it.
Sure, you need to write a bit more when you code, but you save a ton of debugging time (as much as 90%, according to some studies and personal experience).
Dynamic (but still strict, as in Ruby) typing can be useful in scripting: short utility programs or some fast-and-dirty code that you need at the moment. If your code is medium size and/or expect to be long lived (therefore, in need of maintenance), then the investment that a statically and strictly typed language requires is definitively going to pay interesting dividends.
Also, types are not some kind of ball and chain that you are forced to drag along, but they are an integral part of your code. Code and types are tightly intertwined. Some think that being loosely typed is a strength of JS, to me loosely typing is a weakness and a serious one.
So, there's a lot going on here. :)
But there is a lot of strong hate and exaggeration going on here. What happened folks? :) Be nice, share a realistic example for why you disagree and move on.
I'm just some dude on the internet with an opinion.
About TS being a lot of extra work:
There are a lot of folks here who seem to believe that using Typescript means you must type every single variable, object, constant everywhere manually, or at least in most places.
I think some of you would be amazed by how much typescript can automatically infer and still be perfectly useful.
But you're not wrong. It is extra work at times. No dev is perfect. Badly written code exists in all languages. And poorly written types are a thing. Fighting with libraries to get types in certain functions working how you want is a thing.
Without TS, you'd not really have more battles in my opinion, you'll just have different battles.
About debugging:
One thing that I believe the post doesn't really cover, but is vital to why I personally love typescript, is:
Debugging and refactoring.
In a well typed codebase, you won't believe how seamless and quick it makes refactoring variable usages, structures, return types of things, etc.
An example:
In a next.js codebase, I have an API that sends something to the browser, which gets stored in the state, and eventually used in the UI. (this is a bit simplified)
When I decided to simply change the structure and name of what the API was returning, it was almost as trivial as hitting F2 and typing in the new name. All its usages got updated automatically, and I was 100% sure that nothing would break. (and that was correct)
Of course, this is one of the more awesome examples I've encountered.
And of course, caveat being, "well typed".
But again, any tool used in a half-measured way won't be able to help with you with all its capabilities. You don't say postgres is bad, while complaining about a slow postgres query and mentioning that your table has no indexes.
About TS having no place, being useless, dead-end, pointless, etc. anywhere...
Sure, that's an opinion. And you're entitled to it.
But maybe consider for a moment why it seems like the whole JS ecosystem is adopting support for TS. What are they seeing that you're not? Microsoft isn't holding a gun to anyone's head. And every single "TS" project out there can run without TS support.
Maybe it has certain benefits that you don't see yet?
Of course, no language exists for every single use-case. Some of you have politely and clearly expressed that. The point of the post wasn't to say YOU MUST USE TS FOR EVERYTHING, INCLUDING BRUSHING YOUR TEETH IN THE MORNING. đ¤ˇ
Take it easy, folks!
Thanks for joining the discussion! :)
The thing is... This is not so "open" discussion as you want people to believe it. You already have a strong polarized black/white opinion of TS so anyone that disagrees with it is automatically "hating" TS. Hating is a strong word, just because I disagree with an idea doesn't mean I actually hate it. As several other comments point out, experience developers just can't find a reason to justify all the overhead and extra unnecessary work introduced by TS, but still doesn't mean they must hate it...
What I DO hate is the way some people try to shove it to your face, like TS is some kind of Jesus Christ that has come to save you from the "ugliness" of JS, really weird cult-type vibes.
Maybe it has certain benefits that you don't see yet? See? This is the scary part, you are trying to force people to believe to same as you, exactly like a religion, polarized... "If you don't believe in what I believe you are going to hell!"
" I'm just some dude on the internet with an opinion. "
Well , maybe dont just be " Some dude " ,
maybe a person.
Honestly, after so many years of JS coding, I still want to see those magical bugs that are so hard to catch, even with unit tests, to justify another layer of obstruction on top of my code. I have no hate for Typescript. I just don't like it.
You've never seen implicit type casting because someone passed a string instead of number or anything like that? Typescript is just making that stuff a compile time error instead of a runtime error that you have to debug to find.
I dont even know there are people hating typescript lol.
But i get if some people dont like it. because i happen to not liking it too at first. but only because i didnt know the benefit yet.
So, i come in to a conclusion that people who don't like Typescript are either a junior dev or inefficient dev lol.
Typescript is really make it easier especially when you work with the nested object / array, which is a common case for a middle to large project. I dont have to remember the structure of that object/array when i have to make changes later. Just look at the interface / type, and let the VSCode display the autocomplete when referencing a key in the object.
The older version of the project i worked on didn't use typescript. When i have to fix a bug there, i always have to do the tedious task, tracing a deeply nested object. It's a pain in the ass..
That's my story, for anyone who wonder what's the benefit of typescript
If programming languages were pokemon, typescript would be bulbasaur, super functional, pun intended. Couldn't hate even if I wanted đ¤đ
Personally I might prefer Squirtle Squad! đ
Because they're blue too, like the TS logo.
And I think with the evolved versions, Blastoise would handily beat Venusaur. đ¤Ł
lol
I'm intrigued lately bij ReScript, which promises to be a simpler and more powerful Typescript.
Unfortunately it not popuar enough for me to be able to convince my colleagues to use it.
Also it doesn't work for Vue. It does for React, but I don't use that.
Currently, in my experience, Typescript is better than plain JavaScript for large projects. That is, if you can live with some red underlines in your editor or with using any :-)
The biggest slowdown / extra step is introducing a compile step to projects that don't already have one (due to React, Babel, whatever). Another point against TS was backend frameworks, where it seemed impossible to adapt their tutorial boilerplate ES6 code due to the missing or incomplete return type documentation.
I don't mind the TypeScript syntax, as I never found JS code elegant in the first place and I rather have verbose and explicit source code than a compact one that is hard to understand and maintain. I like JSDoc, and modern IDEs like PhpStorm will use it to show hints and type warnings. Both JSDoc and TypeScript can get verbose, but still much better and less verbose than React PropTypes or some of the overcomplicated streams and file handles in Java.
I think type safety should be a top priority for the next ECMAScript standard, much like PHP has evolved from a pragmatic web development add-on to a serious programming language.
No hate, only love
Haters are gonna hate. Lol. Nice post.
TS is one option for developers, one tool in the tool belt. It's not appropriate anywhere JS is. But I'd say it is actually rarely appropriate, if ever.
Why? Because it makes the JS learning curve for juniors problematic and much more extreme. And for experienced veteran developers like me (40 years), it is almost entirely coding overhead for little to no benefit.
Using TS trades long-term simplicity, readability and maintainability for the short-term benefit of finding a bug at build-time. Once it's built and running fine, the ongoing cost is almost all overhead, effectively technical debt.
There was a time, decades ago, when Modula-2 was my preferred language. It is a very type-strict language (more than TS). I had only a few years experience and yet almost all my code ran the first time without a single bug. I know type-safe languages. The problem is that it does slow you down during edit/build-time, in exchange for speeding up the development time investment spent at run-time, and in some cases, thereafter.
But once you get enough experience with JS (or any language), the occasional bug that type-safety avoids are typos and brain farts that are very quickly and easily fixed. I don't really want that overhead and code unreadability, especially on a team project. Readability and maintainability are far more important. Doing a 1- or 2- page Data Format doc to share or for history completes that. And I find intellisense works really well (perhaps more readable) without the TS info.
So I think TS is a tool for learning type-safe strict typing languages, and might help for some intermediate developers (with say 5-10 years experience), but in general, the cost outweighs the benefits if you are, or have, any mix of juniors and seniors. Teach the juniors code maintainability skills instead.
I think you're going to see a lot of pushback for what feels like effectively suggesting TS is always better than JS. I think it will feel somewhat arrogant to veteran developers. I want to say the author probably has 5 to 15 years experience because that confidence of being a tool being the best in general disappears pretty quick after you've worked with dozens of languages, since before there were frameworks (or in my case, since before there were web browsers). We learn that simplicity almost always wins. And JS is already complicated enough; TS is not simplicity.
So many devs need to speak to a therapist after reading this post and comments! đ¤
Some comments may only be visible to logged-in visitors. Sign in to view all comments.