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.
My name is Samuel Braun, I am 23 and from Germany. I absolutely love learning and sharing knowledge about web development, especially in the frontend field which is why I made this account ✋
The hate towards TS is real and justified. (For context: I love TS and would use it almost every time). Most people get into TS at their job or another project. Its extremely easy (its the default basically) to create tsconfigs thats arent strict enough. Which causes developers to write any quickly and make TS useless. A good codebase has no anys at all, and if it needed some they were placed intentionally and not because the dev didn't know how to fix the error. And I don't see a good reason for codebases being too complex, it might be either that some dev pulled the "I'm smart" card and wrote complex types uneededly or that the dev experiencing the difficulty did not have experience using TS (properly). Most types in a codebase should be in the arguments of functions and .. thats it. And even if you know TS well and still run into issues that often that you hate it, its a sign that you write bad js code. Many js devs treat their variables as if they really were anys, moving with that mindset into TS is impossible and for good reason.
The shitty thing about TS is that its too easy to write badly so most people do (especially in teams).
If you have 1 cryptic type definition -> either bad code or you shouldn't touch it.
If you need to use any often because it would otherwise be too complex -> you either don't know typescript enough and overlook a simple solution or the way you write js code is questionable (which often happens to people who didnt learn/use any typed language)
If you think TS is complicated -> Yes, absolutely you are right. Its not even the syntax and errors that often become complex. The much harder part is to avoid these errors in the first place while writing code.
JS devs are frustrated with TS for the same reason C# devs are frustrated with JS. It makes no sense until you understand the why and no one teaches about the why.
Sure, just let me read 100 lines of cryptic named type definitions before I understand the actual useful 5 lines of a simple function.
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.
Typescript != Saviour of your bad junior
JS code.
No one is claiming this. :)
A bad dev will write bad code in any language.
Are you saying before TS existed 100% of pure JS projects eventually collapsed by their own weight?
:) I would assume you know this isn't what I mean.
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
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.
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."
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?
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
ditch the idea of static typing
ditch class syntax (you even don't need it for creating web components)
move to class free object oriented programming (example)
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???
Trying to fit in using function syntax instead of class syntax into a conversation about TypeScript is a bit odd
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.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.
The hate towards TS is real and justified. (For context: I love TS and would use it almost every time). Most people get into TS at their job or another project. Its extremely easy (its the default basically) to create tsconfigs thats arent strict enough. Which causes developers to write any quickly and make TS useless. A good codebase has no anys at all, and if it needed some they were placed intentionally and not because the dev didn't know how to fix the error. And I don't see a good reason for codebases being too complex, it might be either that some dev pulled the "I'm smart" card and wrote complex types uneededly or that the dev experiencing the difficulty did not have experience using TS (properly). Most types in a codebase should be in the arguments of functions and .. thats it. And even if you know TS well and still run into issues that often that you hate it, its a sign that you write bad js code. Many js devs treat their variables as if they really were anys, moving with that mindset into TS is impossible and for good reason.
The shitty thing about TS is that its too easy to write badly so most people do (especially in teams).
JS devs are frustrated with TS for the same reason C# devs are frustrated with JS. It makes no sense until you understand the why and no one teaches about the why.
I love TS for Type safety 👨💻. My favourite type is any.
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
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 ,
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 .
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 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.