But am I alone in this boat, gently rowing down the river of resistance against the *TypeScript * tide? Or are there others who share this sentiment 😍? Or better yet, are there knights in shining armor ready to defend TypeScript’s honor and educate the peasants like me on the path of righteous coding 🤣🤣?
I love Javascript but Hate Typescript!
Here are some discussion nuggets to chew on:
- Why is TypeScript hailed as the savior of big projects? Is it really the unsung hero in the sprawling chaos of JavaScript?
- For the TypeScript fans, share your “Aha!” moment when TypeScript clicked for you 😎.
- And for my fellow “TypeScript skeptics”, why do you really hate it?
Top comments (208)
No, you're not the only that hates it. Many also do. It's been the "trendy" thing for a long while and people prefer it because "it has better tooling".
But wait and see, the TS era is coming to an end. When some proposals for JS make it to the official spec, TS will be just a memory.
And we will be able to go back to develop for the web using the original holy trio of web dev.
Well, TypeScript was written to make JS development better. If the JS spec succeeds in adding type annotations in a backward-compatible way, then TS will have reached its goal - mission accomplished.
But till that moment comes, I think there's still a VERY long way to go!
Yeah, I don’t think “better” is the same for everyone though.
This the important take away message I think
dev.to/desone/why-typescript-vs-ja...
I think you misunderstand what TS is about. People don't use it because it has "better tooling", they use it because TS brings responsibility and clarity to the codebase and it eliminates a whole class of errors thanks to static type checking.
Does it have tradeoffs? Absolutely. Are they worth it? You bet your money it is. If you don't like it, don't use it in your pet projects, but please do use it where quality and team communication matters.
Be careful not to mistake your value judgement as universal. Your TypeScript preference is just that.
I have been programming for more than three decades, and I’ve had so many people make the same argument you’re making, and it never really seems to be as cut-and-dry.
You can write great code and trash code in any language. The skill level of the developer, time and attention taken, and the organizational commitment to quality are more important than the choice of language (or meta-language).
Well as we have seen for at least the past decade, it's the preference of the large part of the JS community, and you can't dismiss it as just one man's opinion. One example for all is the DHH's infamous PR and the community's pushback against poorly justified switch away from TS.
You miss my point, no one here is saying that it's always cut-and-dry or that TS magically makes you write perfect code. My point is that TS should be used where team cooperation, and with it hand in hand quality, matters.
You saying that the choice between JS and TS in the context of team work is secondary seems to me like saying that you can write great code in Notepad. Sure you can but it's gonna be ineffective, error driven and will make it hard to cooperate with your teammates, and I feel the same about picking JS over TS, unless one has a very good reason to do otherwise (like Svelte team for example).
I think it's incumbent on you, given how many teams trust TS, to provide a better alternative. Don't get me wrong, I'd love to learn from you, so if you have one please show us.
I’m sorry, why is it my responsibility to guide a group of people to a different preference? Your confrontational approach to this disagreement on a matter of preference doesn’t seem terribly helpful to anybody here.
I am not saying “do not use typescript.” I am saying that we shouldn’t insist others do based on our personal preferences. Recommendations are only that: recommendations. They carry no moral or ethical imperative, and they warrant no judgement or rebuke in most cases.
The solution to writing safe and secure code is the same now as it has been since I started in this field in 1998:
There is no runtime or language that will protect users if we won’t put in the work. An appeal to popularity will not change this fact.
Everyone should concider this as a rule:
"You can write great code and trash code in any language."
Yes, but still, in my view, an algorithm can be better expressed in a language, or even paradigm than in another. I see TypeScript like "cleaning your room", nobody said you need to like it... I always remember what my mom said: "If you are living in my house, you will clean your room. You see a use in it or not!" :) Sadly, I only started to see the value of a clean room when I was by my own.
Yeah, I see where you’re coming from. Unfortunately, though, it falls apart once it “cleaning” one’s room is found to be subjective. If your mom’s definition of cleaning the room was that the walls should be painted every time a very particular color that changed every week based on which influencers were saying what, it would be far less reasonable a demand.
These preferences that are being expressed as objectively clean or best practice are, in fact, neither objective nor are they durable over time. They’re subjective. They change over time. They’re preferences, not best practice.
My contention isn’t that a messy bedroom is fine. My contention is that you are not entitled to promote your personal preferences as though they were objective or best practice, even if you can find a bunch of folks who would agree with you.
I’ve been programming computers since I was a child, and I’ve used dozens of languages on a variety of operating systems in a bunch of domains. There’s always someone telling me what is and isn’t readable or clean or best practice, and six months later that changes. It’s arbitrary, it’s preference. There’s nothing wrong with having preferences, I sure have my own, but there is a lot wrong with using coercive language and behavior to promote preference as best practice.
Sure, I also thought my room was clean enough back then. I just think you are asking the wrong question anyway, because "feelings"about things are subjective, for sure.
I am just pointing, It is about putting yourself in your mother's shoes. She probably doesn't like that your room is the only one that disrupt the whole house dynamics. :) There is nothing wrong on using pure JavaScript on your own house, maybe not in a hospital cancer machine firmware?
What an odd analogy, and odder question still.
As to “hospital cancer machine firmware,” whatever that is, I would be perfectly comfortable running JavaScript provided they had done their due diligence, and I’d be wildly uncomfortable with code written in any language where folks asserted that the very language itself (or meta-language in the case of TypeScript) was so good that it didn’t require good practice.
It is the practice of good software engineering that makes good software, the languages are just busywork in most cases.
In 27 years of professional software work, I’ve had so many people tell me that their favorite things were the best or were the cleanest or were the most intuitive. 100% of those people were mistaking their preferences for objective fact.
About the "whatever it is", any firmware that controls a cancer treatment machine, like LINACs.
Well, maybe this is why feelings is far from being a good guidance. First, I would read the literature about critical systems, and there I would find that, for the best security possible, devices like that, require deterministic timing, making them hard real-time system, and so, I would never use an interpreted language, or one that relies on a garbage collector, because they will never comply.
Anyway, JavaScript doesn't meet many of FDA's Class III requirements, so why, despite the funny suggestion of not using it, I doubt anyone sane would ever think of JavaScript as a choice. :)
Everyone should concider this as a rule:
You can write great code and trash code in any language.
Since you delved into this, it was you who dismissed preference for TS as a mere matter of taste, completely disregarding the fact that so many teams prefer it for good reasons, shielding it with 30 years of experience, which is very prone to sound like "I know better", so who's confrontational?
Anyway, I hoped at least that you can support your statement with an alternative approach in the context in question, but you haven't. While I agree with your points on ensuring quality, you left out the fact that languages we use just aren't equal, which is ultimately what we are talking here. In this regard your posts didn't bring anything new to the discussion and in this sense they are not terribly useful to anyone here either.
1 question, is there something you can do with TS you can't achieve at all with JS (leaving assumptions of pushing garbage JS aside)?
The reason I object to your preferences being declared best practice is because in my decades of working in this field I have encountered so many folks who feel entitled to do the same thing you are doing right now, just with different references.
C++ was made to be “safer” than C. Java was made to be “safer” than C++. So many opinionated, fervent, and often popular assertions are made without any real value to add. Keep in mind that COBOL is still used in a number of places and accomplishes its objectives just fine.
Use the language that you want, but this hauteur you have around your preferences is off-putting and adds no value.
Before you go shifting responsibility again, please return to the beginning of the thread to find where you started this thread by telling other people what to do based on your preferences.
Mistaking your preferences for best practice is never helpful.
Nope. Outside of the semantics of the language there is no functional difference, because at the end of the day TypeScript is executed as JavaScript.
That was a hypothetical question of course
Good question @bytebricks . I assume you mean JS with JSDoc? If you mean JS without any type information, then the answer is clear - one has much less control over how a codebase evolves over time, but I'll go with TS vs JS+JSdoc.
To me it's not a question about which one is more powerful, since JSDoc very much closed the gap, be it in expressiveness or tooling. But I have 2 major problems with JSDoc:
Exactly this. I think the dislike arises when people think TS is some magic bullet that has to be used on every project, rather than a specific solution to a specific problem that may arise in certain code bases. In this case, I think TS shines in large, distributed code bases where a lot of different devs might need to be on the same page and the code needs to be crystal clear. In cases like that, static typing would be a huge asset. Or a dev who is coming to JavaScript from a static language like C or Java and wants to keep some of those language features, it could make the language more comfortable to work with.
But for a JavaScript hobbyist working on a pet project, or a junior dev who’s still trying to wrap their head around the fundamentals of JavaScript as a whole? Of course it’s going to feel like an extra layer of unnecessary frustration because in those cases, using TS is wholly unnecessary.
I think there’s too much pressure on younger devs in general to always learn the latest and greatest thing, often at the expense of mastering fundamentals. If you’re learning React but still struggle with JS or you’re learning Typescript but haven’t tried out a statically typed language, even just a little, you prob need to slow down and focus more on the fundamentals.
Anyway, thanks for coming to my TED talk.
I see where people who dislike it are coming from, but I think the argument is mainly emotional. "I don't like the look of types and they slow me down" I keep hearing, and I was like that in the past as well. But these people forget about the huge upside which I mentioned above.
I don't think one needs a big team with a huge codebase to make TS shine as you say. I'd even go as far as saying, that whenever there is any team of devs and their project is at least semi-serious, TS is a big asset worth the effort. Unless there is a strong argument against it, like we saw in the Svelte team dropping it for DX and delivery reasons. But those cases are rather rare and very individual in their reasoning.
But of course, pet projects, students, anyone who just wants to try out programming JS, TS can be an useless overhead for you, 100%.
The way you put it, you're definitely saying TS is a must and a good practice.
I think if you really know what you're doing in JS, TS is just an extra.
I realized we never defined if JSDoc is used or not. If it is, I am kinda fine with that, but I'd still prefer TS for application development. I prefer it in lib dev as well, but I understand teams like Svelte dropping it and using JSDoc instead. If we talk not using any static type information, that's suitable only for smaller projects or those that don't have long term ambition imo.
The use of typescript is definitely a must for me, when starting either small or large projects with small or large teams, I do it because I can't deal with dynamic typing anymore, it slows me down too much, maybe not initially but as you develop the codebase you need to keep more and more context into your mind (what is being received vs what is being returned) rather than having it be inferred by the compiler, which is soo much more helpful.
I don't think I would switch to JSDoc as an alternative as I have tried it, and approached it the same way, but it turned out to be very awkward and ugly, sort of out of place, even stopped working when I spun up the project after a while...
That's fine. Opinions are like JS frameworks. There are too many of them and none is completely right or wrong.
Would you be willing to elaborate on why you believe TS is "trendy"? Its been around for more than a decade (longer than ReactJS) and has dominant marketshare (according to the most recent State of JS). In the tech industry, something lasting more than 10 years is quite rare, so I'm curious to understand your thoughts.
Also, would you mind clarifying how upcoming proposals making TS "just a memory" shows that TS is bad? If TS has had such a positive impact on the industry that it's principles are being adopted by JS, wouldn't that indicate that TS is significantly good? Or am I looking at this incorrectly?
its like someone stealing your shine!!!!
Its like when you get to realise that most of the hits of Elvis Presley were written by Black artists back in the oppressive days and they never got anything or any credit for them.
TS is like
JS looking prim and proper and getting the girl.
🤗🤗
it is Trendy !== Trending
Dont you see shaming for rejecting TS 😑?
I think you might misunderstand me friend. There is no shaming going on. Poster made some statements, so I asked for more information and included some facts that don't seem to support those statements.
Exactly that, if it does make it to the JS official spec then mission accomplished! But I think we're a while off from that. I absolutely hated it when we first started using it in our projects but now I can't imagine not using it unless it actually gets baked into JS.
It won’t.. JS will never have what TS has because there is no intentions to make JS “strongly typed”..
It doesn't need to be "strongly typed". That will pretty much destroy the language. But the "type annotations" proposal can help with that types ordeal.
Still won’t make JS any closer to what TS supposed to help to do.
Maybe
nah, TS type level is another language on it own, TC 39 will not even come close to what TS can really do
In fact I would argue that TC 39 will further accelerate TS adoption because TC 39 exposes type system to JS developers, making them easier to accept TS once JS developers want more powerful type safe features
Until Javascript becomes statically typing
Amen to that 😍
Most, if not all of those features come from and because of TS. Even now, you see them. For example, classes, or ahem...type annotations?
So eventually your beloved JS will become TS, just under a different name; will you hate JS then?
dev.to/desone/why-typescript-vs-ja...
I never understand why some devs have so strong preferences over something and are willing to wage wars just to defend what they prefer. It's all contextual, they're just tools, choose whatever works for you in your context. At the end of the day, what matters is that the tools you chose and used pay your bills.
Popular developer opinion guides the industry in that direction. When there are more developers on a certain boat, that boat ends up getting more of the love, effort, community resources, open source contributions, updates, support, and job opportunity. Developers need to shill for their favorite tech stacks because it directly benefits them when other devs hop onto the train and make contributions to add features, stability, tutorials, etc. to the exact thing they currently enjoy using.
It goes a little too far sometimes, yeah, but overall there's no helping that devs will point out the shortcomings of one technology and advocate for the ones they'd rather use instead. Mindshare is important.
We tend to stand by our choices and defend them maybe that is why 🤗 add to that we like to be in groups and trends work by create groups (communities) and that would have loyalty!
Perhaps you had some kind of configuration issue going on...hoisting is completely supported in TS...
This is valid and works just fine in TS:
Yeah that sounds more like a linter rule maybe? TS itself definitely supports function hoisting and always has as far as I know
Really? Because it's just sitting there complaining to me about function used before it's defined when I converted over a bit of JS where I'd put the utilities at the end. You must be right I guess. oops.
You're right on the linter rule, that and the support for JSDoc in IntelliJ for showing me parameter information.
that's your eslint not typescript
Agreed, must be! Shows how often I use it I guess :)
This is a first for me. I write Svelte in TS and function hoisting works just fine for me.
Hmmm, odd, I was just doing this for an article I wrote and get function used before its defined... I'm no TS expert - I must be me missing something.
That is a good point!
I hate that we have to accept it as it is the "trend" so to be cool you cant reject it!
No one here is saying you have to accept TS. There are legitimate technical reasons not to use it in some projects. At the end of the day, TS is a tool, just like a hammer, just like a pen. There are jobs each of those tools are good for, and jobs they aren't.
There are also people who don't prefer to use a particular hammer (maybe it's too heavy for them), or don't like using a particular pen (maybe it hurts their hand, or they like how ink flows from another pen). Having preferences is 100% fine...we ALL have them. As long as it's recognized as a preference, and not right or wrong.
I personally don't like Tailwind, for example, because I prefer to write vanilla CSS...this does not make people who use it wrong, nor do I reject it. It's just another tool, and in some cases, it may be the right tool for the job.
With all that said, you seem to want to reject TS. May I ask why you feel this way?
No, you got me wrong I dont reject TS as a choice. You can choose whatever you want as long as the community is not setting a "right or wrong" based on assumptions that who uses JS is sure building a small side thing or pushing garbage to his production and thus creating pressure that leaves no room for preference for JS
Ah gotcha, please forgive my misunderstanding. I agree with you 💯
As soon as preference starts being treated as right and wrong, it's bad...regardless of what side you are on.
No worries at all, the whole discussion is to clarify this part, to put less pressure on new comers and developers worried to come out with there preference. I am sure you already see in this community and others such pressure.
Absolutely. I see it a lot in the Tailwind community, and saw it in the React community for a while, but not so much recently.
It's funny that this pressure exists so much in the JS world. In other languages, these kinds of things just don't exist nearly as much!
I agree, maybe JS is used everywhere in so many ways that is why.
Of course Tailwind is another such example where you should be entitled to have preference no matter what are the advantages of it as you still can produce the same result (regardless of how) and no one should be pressured to use in anyway but it is happening around the clock!
You may be right! Another reason may be the lack of standards in JS as compared to other languages.
True to that
TypeScript is not trendy. It's a battle-tested tool that stood the test of time. What's trendy is hating on TypeScript.
To begin with, I would advise against deeply loving and deeply hating languages or frameworks in general. They're tools in a toolbox—use what fits the task most. Having preferences is fine, but waging wars for them is just wasted energy.
That being said, there are cases where people are just wrong. For example, when someone claims that ditching types is good in general or should be the default.
Types matter, and their significance only grows exponentially as a project (especially an application) grows. It doesn't take a behemoth of a project to realize how types can spare developers from hours of agonizing frustration.
Let's talk about why.
1. Debugging
You might hate the number of red squiggly lines screaming in your face now, but they often end up being tremendous time savers in the long run.
The value of compile-time errors should never be underestimated, regardless of the project's scale. The hunt for that elusive
undefinedvalue that you used somewhere is never fun.2. Documentation
With types, you document what the function does. Without types, you document what it does, what it returns, which parameters are optional, and the types of each parameter.
3. Readability
Sometimes explicit typing is redundant. However, more often than not, having the type declared next to your variable is the only way of knowing exactly what's going on without pausing or resorting to explanatory comments.
That's why type inference (which TS supports) is a great feature to have. You get the best of both worlds.
4. Scalability
Teams grow with projects in most cases, and introducing new team members to a sprawling app, that has evolved over several years, can be daunting.
The last thing you want is to have new members trying to figure out the types when they should be grasping the intricacies of the codebase and how the hundreds of files in there relate to each other.
5. Testing
It is a matter of fact that you need more tests in an untyped environment to achieve the same level of code coverage otherwise. With a compiler, you don't worry about types. Without one, your tests are incomplete if you don't.
Now, TS doesn't have to be the only way to achieve typing in the JS ecosystem, but the default should always be to have types.
Your other option is JSDoc. You can get intellisense and most of the features of TS by using JSDoc, but it comes at the cost of added maintenance and, in my opinion, hindered readability.
I have yet to encounter compelling reasons to choose JSDoc over TypeScript. Some argue that library developers may end up spending disproportionate amount of time on types, but I can't speak to that as I am not a library developer.
TS isn't the most appealing language to work with. For backend development, you might go for other (hopefully typed) languages. However, for the frontend, I am convinced from experience that TypeScript reigns supreme.
I think we dislike the hype, the ecosystem kind of pushing ts by force, some frameworks even go full ts. I think they oversell the problem ts is solving and sometimes you are caring thinking more about types than functionality.
In the other hand it is a good tool that can be helpful and when you give the opportunity and work for two or three projects you get used to it.
As a devs we have to care if hate is making us dish a good tool (unless that hate is for java) extreme opinions in code are mostly bad.
well said!
Indeed!
I think it is also because unconsciously we hate the idea of too many unnecessary languages; they make the work for us too much....too hard. especially when you realise that this language is exactly JS 90%.
Sometimes you even have glorified identity functions just so you can get helpful type-checking
Agree 👍
TS creates too much overhead imo, the most advantage to me is type annotations. However I think the whole OOP style stuff reminds me of writing
blablajava. I love Js mainly because I don't need generics, Interfaces, enums etc. because there often simple solutions that do the job pretty well, too.Reading Typescript code of some repos just gives me headaches. This is also because in Typescript "it's all expressive, so there is no need for comments and additional documentation".
My aha! moment was reliable code completion. This made it possible for the inexperienced developers on my team to write working code and track down issues before runtime. Major improvement over raw JavaScript for even medium sized projects. That said, Typescript is surprisingly bad at instantiating JSON objects into reasonably typed entities.
Thanks @blakeanderson for sharing that
I also hated Typescript when I just started using it, but I think I was biased then since I mainly had experience with weakly typed languages such as Python and Javascript. But, I have come to appreciate Typescript and its type safety. It also has great tooling and autocomplete. I wrote an article on this topic recently as I noticed some devs are starting to ditch TS for JS.
Could you share the source are you looking at that's showing devs are ditching TS for JS?
Here is a direct link to Ruby on Rails creator David Heinemeier Hansson post on Turbo 8 dropping TS: world.hey.com/dhh/turbo-8-is-dropp...
My blog post also highlighted other examples in the Disadvantages of Typescript section
Here is a YT video from Fireship on the topic as well: youtube.com/watch?v=5ChkQKUzDCs
Thank you for sharing these! 😃
Do you think these are examples of developers ditching TS? Or teams determining that it's not the right tool for the job they're doing?
A bit of both. David for example has a strong dislike for TS. This is obviously a contrarian stance, but some agree with him
That’s fair. 😊
I ask because I believe it’s important for us all to think through these kinds of decisions and situations. People see libraries like Svelte dropping TS and immediately jump to the conclusion that types and TS and all that is taking a dive and they should “ditch it”, but sadly, many do not take the time to understand why this decision was made. Rich Harris (the creator of Svelte) is still a big supporter of types, just not the overhead that comes with using .ts files in the context of building a library/framework/package. (if you’re interested, check out an interview where he goes over this: https://m.youtube.com/watch?v=MJHO6FSioPI&feature=youtu.be)
In the Fireship YT video you shared, he made a point to state that even in their own application, he didn’t see them moving away from Typescript. This is because the benefits of its use in large applications quite often outweighs the additional overhead mentioned above.
I love that guy! 😍
I absolutely agree with @wraith
JS rocks 😎
It's important to note that neither TypeScript nor JavaScript is inherently "bad" or "good." The suitability of a programming language depends on the context in which it is used and the specific needs of a project. Both TypeScript and JavaScript have their advantages and disadvantages, and the choice between them depends on factors like project requirements, team expertise, and personal preferences. Let's explore some reasons why someone might consider TypeScript less favorable compared to JavaScript:
Reasons Some Developers Might Prefer JavaScript over TypeScript:
Simplicity: JavaScript is often praised for its simplicity and ease of use. It has a forgiving syntax, which allows developers to quickly write code without dealing with the complexities of static typing.
Faster Development: JavaScript projects can often be set up and developed more quickly due to its dynamic nature. There's no need to define types explicitly, allowing for rapid prototyping and iteration.
Lighter Learning Curve: JavaScript's dynamic typing can be more forgiving for beginners. There are fewer concepts to grasp initially, making it accessible for those new to programming.
Community and Ecosystem: JavaScript has been around for a long time and has a vast ecosystem with a multitude of libraries and frameworks. Some developers prefer the extensive options and flexibility this provides.
Less Boilerplate Code: JavaScript code can be shorter and more concise since developers don't have to write type annotations for variables, functions, etc. This can lead to more straightforward and readable code for some developers.
Preference for Dynamic Typing: Some developers prefer the flexibility of dynamic typing, where variables can change types during runtime. This can allow for creative solutions in certain situations.
Less Tooling Overhead: JavaScript projects typically require fewer build tools and configurations since there's no need for a TypeScript compiler. Some developers prefer a more lightweight development environment.
However, It's Worth Noting:
Type Safety: One of TypeScript's main advantages is its static type checking, which can catch potential errors before runtime. This can lead to more robust and maintainable code, especially in large projects.
Code Maintainability: TypeScript's static types can make the codebase more self-documenting, enhancing readability and making it easier to maintain, especially in larger teams or projects.
At the end, the choice between TypeScript and JavaScript should be based on the specific needs of a project, team preferences, and the long-term goals of the development. Neither language is inherently superior; they simply offer different trade-offs, and the best choice depends on the specific context in which they are used.
There is an obvious disadvantage of TypeScript - this is the build stage. Of course, using it for development for NodeJS or browsers is a little more complicated and much easier for Deno. But damn, how can you refuse types? TS cannot be a replacement for JS and vice versa, these are different approaches, different thinking. Long since I started writing the code itself, I describe the types (it’s like sketching a sketch, a draft, a plan). If all types converge, I know even without code that the program will work and will already know exactly what code to write. Types speed up the process of developing complex programs and the process of debugging them.
I don’t want to offend anyone, but most often it’s not a love for TS - it’s a dislike for the types. And not loving types is not loving all typed languages and the very concept that makes you think before you write some code. Yes, it’s hard to think, sorry, that’s reality
Appreciated point of view
Some comments may only be visible to logged-in visitors. Sign in to view all comments.