I've been seeing this trend lately: more and more developers bashing TypeScript. The gripes range from it being "too complex" to "slowing down deve...
For further actions, you may consider blocking this person and/or reporting abuse
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
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 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 ,
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.
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'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.
All of these hundereds of typescript projects should have one line in package.json for compiling TypeScript and if you're a web dev you should know how to run that line/script (Example:
npm run build). If it doesn't have that then blame the author I guess. Otherwise, agree with you fully.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 ?
Bro 😂 you sound like a baby. You know what? JS sucks, its too complex. Just read this code:
You cant just say that some code is not worth talking about dude.
This is JavaScript code. (it actually is, try it)
Read it and weep , you cant make excuses for everything.
Respond to the post.
Can you read the JavaScript 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.
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.
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.
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! 🤗
I just prefer to use JavaScript along with JSDoc.
I strongly believe that TS has built it's hate due to it's use cases and not it's complexity. I would say that I wouldn't use TS that often, but places where I need autocomplete then TS is my thing!
Now to be exact, I mean, think about it, C is also typed, C# is also typed, java is also typed, they all are static typed programming language, so why would you use TS? Well for it's relevance to JS maybe? Or maybe because it's high-level yet statically typed? Now keep in mind I also use TS, but I wouldn't say that I would use it for everything, just like software engineering is, it's all about, it depends, it totally depends on the problem, the requirements, the team, and a bunch of other factors, I wouldn't use TS if I were a C# programming building .Net stuff, no I wouldn't and the only reason why TS get's so much hate is because of it's use case, who would build a code editor with TS? VSCode, now no offence to VSCode, I use it too when I am using TS, but to be real, it would have been better to create a code editor with rust like zed, or maybe a more light weighted language, why? Because TS is a subset of JS, it's not even a programming language, just like mojo is a subset of python, yeah mojo is fast but that's not the focus, the thing is, it all depends! I would use TS over rust because that's what I use, but I would use Java over TS because I need speed, if i need type safety, I would try to figure out what are my requirements.
So yeah, it all depends, there's no hate to TS and there's no hate to any other language, they all have their drawbacks and it all depends on what the affecting factors are.
JS/ES20xx is also 'typed'. Just not staticly.
Well ... I don't know. I don't hate typescript (had to use it professionally for years, alongside c#), but I do think it's pretty useless to force js/ES20xx into static typing.
Just check your input when necessary. For example:
Or use design by contract
When you are concerned about type checking: here's my small library that checks the type of nearly every js-thing you throw at it
No, it's not a myth. I have coded in both JS and TS on commercial projects for roughly equivalent amounts of time. Even though I was advocating for TS and believe the idea is good in theory, it does slow down development. The issue of spending days on the console to spot a bug seems more related to poor debugging skills and junior developer concerns rather than a lack of TypeScript. You don't necessarily need types in code if you have a solid understanding of your code's structure and logic while developing. Debugging skills and thoughtful coding practices can often mitigate the issues that TypeScript aims to address. Typescript basically eats your time on a daily basis, while bugs are still an occasional issue with or without TS.
I don't hate TS but I do find it unnecessary in most cases. You're never going to get around the fact that it's incredibly difficult to completely type all of your variables, objects, and interfaces properly.
In one of the open source projects I was contributing to, they had something like 60,000 lines of code. The interface file for the SQL database had something like 5,000 lines on its own and most of them were redundant since they didn't add anything new to the data. The person who wrote the code admitted to doing so because they found the linter to be annoying and decided to write the types as a result.
In other typed languages, the types indicate how the data will be laid out in memory and this isn't really the case for typescript because it transpiles down to JS. You can still accidentally sneak the wrong types into the wrong variables no matter how you write your types.
MUSIC EXAMPLE vs TYPESCRIPT
If this is a music player, then what types of "data" was sent by those "other people" that is so "vague or unknown"?
That is, if this is music, then the variable names are like,
Name of song, artist name, music genre, bit quality, date uploaded, length of song, etc.
All of these are well-known parameter variable names and no one is taking wild guesses at these data types.
And If one of these are "null", you just add boilerplate code to handle that anyway, regardless of TypeScript.
I do NOT see "real-world" problem being solved by using TypeScript.
All I see are silly examples of a "function that adds or divides 2 numbers' to justify "type checking". e.g., Who writes a function just to do basic math????
Next, developers are testing (aka runtime) their code LINE-BY-LINE anyway, so "compile-time" checking isn't all that beneficial in saving a developer time coding.
In other words, TypeScript adds a layer of complexity that doesn't have that much benefit to the JavaScript world.
NEWS FLASH:
TypeScript is just JSDocs in another form. It just adds a compilation step to ensure you're using the types as documented. It's useful, but it could've been achieved purely with JSDocs.
The problem isn't the language, it's the developer!
Why simplify when you can complicate?
Dont slow yourself down by the clean code philosophy, you can always spend the 5 nights debugging the code later and deciding an eventual rewrite 😤
Or the 5 nights trying to get the compiler to run. I'd rather debug code than build process.
--- Dont care how many downloads it has .
--- Dont care about type checking , I can do perfectly fine in vanilla js.
--- Dont care about doing stupid .ts.config files.
--- Dont care about liking typescript.
--- Dont care for compiling projects in it
--- Dont care for overbloating my code with a needless framework that can be defeated by a simple if statement.
--- Dont care about anything that has to do with typescript , because it is a pointless language , as I usually just typecheck in one file then build the app , it works the same as if you dont even install typescript and you wrote it in vanilla.
--- Dont care about hearing peoples reasoning , because again , I DONT NEED IT TO TYPE CHECK . THATS INSANE.
----- But at the end of the day , people just like it for interoperability , so as a developer who does appreciate standards and implementing them , I digress that there may be some benifits.
So , no i will most likely never " Like " typescript.
However when it comes to working with reproducable code in bigger projects with many people , I could see benifits there.
Either way , if your looking for a job
*your still 100% right , *
My thoughts have little value on the code choices made.
People have just misdirected their hate for JS to leak into typescript. It’s just superior!
I love JS, just hate TS. 20 years of experience, I know how Typing suck. Not TS fault. All typing language suck. 10 years with Java
Interesting, @quanla
My opinion changed the other way round. I worked on various large JS codebases and over time it got to the point where large scale efforts to move to typed systems were put in.
When people face problem, they often resort to changes, even when improvement is not guarranteed. TS is surely a promising change, but I am just too addicted to the power that dynamic JS offer
@jayantbh i think you should also mention what will happen when we turn off strict null checks.
PS- 2k type errors across our codebase 🫠
Kinda mentioned that, but don't air the dirty laundry. 😛
Typescript is designed to be superset of javascript, Problem arises when it doesn't follow javascript syntax in typecasting. Syntactically, javascript is very similar to C, C++, Java, PHP or C#, If providing typecasting was the primary goal, Typescript could have been syntactically very similar to how aforementioned programming languages provide typecasting, For example, let id could have been int id instead of let id: number. Programmers could have very happily embraced it if that was the case.
I never understood why Typescript is a thing. If you feel types make your code safer, used a typed language like Golang, C#, etc.
The beauty of JavaScript is it's simplicity, until MS got involved.
Thanks for the article 😍
Now I think I'm in hate with TypeScript ☺️
TS is a gimmick… causes unreadable code and add another layer to maintain … most documentations today I noticed shows example code both in TS and plain JavaScript.
I remember the same documentation in past show TS only.
Autocomplete is a great feature of TypeScript, but my problem with it is that it’s only “compile” (bundle or transpile might be more appropriate) time type checking of a JIT compiled, loosely typed scripting language. The type hints don’t tell the VM what to expect. It’s still inferring from the inbound parameters, and since TypeScript deals with a lot of UI data and API responses, there’s plenty of room for things to fail silently. The syntax is also incredibly clunky for anyone coming from another strongly typed language. I LOVE the idea of strongly typed JavaScript. Web apps could be a lot faster, and backends written in node would be a lot more stable. But TypeScript is a bandaid on an axe wound.
Truly amazing
When I started working with TS at first I felt it's to much of just defining types and enum and interface
But later when I used in my open source project it made me realise how amazing/useful typescript is
Great read 👍
visual code ts lsp is unstable!
Typescript as a documentation helper and object shapes is great for consistency. But if I need to do some type magic, for minimal it might be, then I hate it.
Then, what is JSDoc for? Can't it be used instead of TS?
I like typescript until it doesn't waste my time, I like to use it in partial mode where any is allowed because I do not want to deal with typings for hours and hours
Eh, typescript is cool and I think if your project needs it then ya definitely use it.
What developers using TypeScript like to talk about is defining simple interfaces and types to self-document their code. It's really good at that for sure. Where you start getting into muddy waters with TypeScript is when you start trying to write "utility" types.
For example, you start with a union type and then your realize well, not all types that derive from this type should be included. So you define a type to extract from that union to avoid rewriting a bunch of similar types over and over. Then you decide that you want to maybe apply the same methodology to an Interface so you write a way to "pick" from that interface...so on and so on.
What you get is a bunch of types that are modifying other types to make it so TypeScript isn't a total pain in the ass for large projects. You touched on this kinda, but also didn't really go in depth with how much of a foot-gun TypeScript can be. It was more so wrapped up in, "ya it can be annoying, but so can every other tool! and it's up to the dev to do it right!"
Well that doesn't seem like a fun time 😂
It all gets really confusing for others really quick so writing simple JSDoc on a function could just be all you need and nothing more. It all depends on what your code is, the scale it's at, e.t.c.
Comparing TypeScript to JSDoc is pretty much comparing a F1 racing car to a Toyota Corolla. Sure they are both vehicles, but I wouldn't expect someone to drive to the grocery store in a F1 racing car. In the same vein, I wouldn't expect someone to use TypeScript for a simple library.
Long ago people set out to write utility classnames for CSS and eventually gave up when it turned out to be a nightmare without end... Until some new guy made Tailwind 🤦
The moral of the story: dont utility anything, unless you're writing a framework, or other reusable lib.
Or to be more concrete: Dont pick or omit from something picked or omitted already. In that case extract the sub types you need, into their own type and create a new type from that (unless you have really compelling reasons not to #itdepends).
Hand a human a stick, they'll find 1000+ ways of using that stick.
Hand a human a rock, they'll find 1000+ ways of using that rock.
Hand a human a strict typing layer over JavaScript, they'll find 1000+ ways to use the strict typing layer.
It just so happens that people don't like work so they'll just make it easier to use by metaprogramming the shit out of it and make the developer who didn't even want it typed in the first place cry (aka: me).