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 (202)
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."
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.
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
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
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 👍
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 😎
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
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.
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
Because it adds a compilation step while still not doing it's job properly compared to something like ReScript; I call that poor ROI.
And the truth is that TS got popular not because of types and certainly not type-safety (though that term gets bounced around alot leading to (I presume) a false sense of security) but because these application developers are infatuated with editor/IDE features like C#/Visual Studio and Java/Eclipse developers before them.
Granted Babel had already introduced that compilation step but it was perfectly happy as long as your JS was syntactically correct.
With TS your have to explain your program on TS's terms before it will finally shut up and give your runtime code.
I like types; I just don't like how TS deals with them; ultimately TypeScript is still JavaScript, i.e. JS is not “just a compile target”; TS deliberately accepts limitations so that it can be gradually adopted in a JS code base (though from a working JS code perspective TS is a subset of JS; TS is only superset in terms of language features). Well then …
“I often wish I worked in a language where I could start dynamic and end statically”
Then esbuild and Vite happened; as long as your TS made sense on the JavaScript level, they would generate runnable output quickly without having to deal with
tscor LSP complaints.So now you can forge ahead experimenting a bit using TS-syntax with near instantaneous transpilation either before you decide to just delete it or perhaps keeping the experiment and even writing a few tests before taking the time to address
tsc's issues with the types.Finally it was reasonable to use TypeScript for what it is actually good at: to lint JavaScript types (just because your types check doesn't mean the code is type-safe—it's probably mostly type-safe).
“If you can't beat 'em, join 'em”
So now that you found a use for TS, the inconvenient truth is that despite TS's flaws you might as well learn it far better than most people who “use” it and evangelize for it.
TypeScript is easy for those who largely consume pre-typed libraries through LSP supported editors but if you tend to write lower level JS code in order to minimize dependencies using TS's type language to explain to
tscthat your code is just fine can become a bit of a chore until you are much more comfortable with its extract types from value space into type space approach.The bonus of knowing it well is that you can keep pointing out to TS fans how flawed TypeScript actually is.
Once you get to a certain competence level you can start to entertain adopting TS JSDoc where it makes sense.
Using Typescript without compilation
Pascal Schilp ・ Mar 26
Well Thanks a lot for sharing this, and adding to my list of arguments why I reject any suggestion of using TS in any project we have 🤙
Nobody cares what you do for internal projects except perhaps the people who have to work on it now and in the future.
However once you have published interfaces, TypeScript support for your users is now table stakes—TypeScript support is now part of the cost of doing business.
I remember in March 2020, I liked the fact when I took Svelte 3 for a spin that it wasn't TypeScript centric but the lack of TypeScript support was hurting its adoption at the time.
All that changed in July 2020 and that shift was likely instrumental in its move into 4th position behind React, Vue, and Angular (and getting support from Vercel).
The kerfuffle around SvelteKit's move to JSDoc in May 2023 really just highlighted how many TS developers don't understand the finer details of the tool chain they work with on a daily basis.
Moving forward SvelteKit wasn't abandoning TS support for their users but they had simply decided to internally shift to a workflow where TypeScript wasn't used as a language but only as a type linter.
That gave them full control over the runtime JavaScript and removed the TypeScript syntax as a barrier with respect to any tooling they wished to leverage.
The issue with the DHH situation (September 2023) was that he discarded pre-existing project type information and put any future typing effort squarely back into userland (which tends to be less than ideal as user type contributors are often not familiar with the packages core functionality which can influence user types).
In some ways your projects may benefit from people who are capable and willing to sling TS JSDoc.
Yes and no. TypeScript helps enforcing constraints and thus avoids some mistakes that may happen especially in exceptionally large projects. Also, the tooling apart from the compiler is quite helpful.
I was originally sceptical of it when it came out 11 years ago. Its type system was too limited then to be more help than hindrance for more complex solutions.
TypeScript has come a long way since then and its type system has become a lot more powerful. In a larger project distributed between multiple teams, it can help avoid a lot of issues.
I still wouldn't call myself a fan. I'm happy that it exists, but I'm also happy that I don't have to use it all the time, especially for small-scale stuff. I don't love it, but I appreciate the option.
It's still somewhat limited, especially if you compare it to type systems like the one of rust. The earlier integration of decorators in order to keep the angular devs happy was a mistake. Enums are stupid the way they are implemented in TS, they should really be compiled away instead of sullying the code with unnecessary objects. The engine is a bit slow and the error messages are hard to read.
Still, I wouldn't say I hate it, either.
I love 😍 how you think about TS!
Hmmm I started programming using statically types languages like C,Java.
Always hated python. Always hated the lack of type system and horrible design choices in javascript.
And Typescript is love❤️
I don't hate it, I think hate is a strong word. I disagree with how TS is enforced in all projects (besides backends frameworks) and how people get obsessed more with type safety and keep doing type gymnastics and types wrangling as DHH said in his blog post.
But on the frontend, TS killed the joy of working with and that is a fact. I have plenty of code of people using types on the HTML elements and using types for CSS inside styled-components (why, just whyyyyy).
This generates so much overhead and unnecessary complexity even on small projects or MVPs. For doing something quick (and not necessarily dirty) TS is not necessary.
More time spend on beauty of code than functionality of it!
i also hate TS, because it need more code and more time, and maintain the Type in TS is also a thing that very boring, but i think the reason why we hate JS is becasue we very familiar with JS and it is like a muscle menory so that it same like with when you code Java and now change to Python have some problem
Some comments may only be visible to logged-in visitors. Sign in to view all comments.