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.

[deleted]

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.

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.

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.

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.

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❤️

In a proper development environment (e.g., VS Code), TypeScript provides autocompletion, typo warnings, and syntax highlighting.
I think types themselves can serve as great comments.

Can you detail what kind of projects you work on? How many developers, how many years of development, LOC, etc. Is your main issue writing TS or running TS (tools issues vs. language issues)?

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.

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

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:

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

I hate most of the tooling built on top of JS. They improve the code at the cost of complexity. It gets tiring seeing 25+ configuration files at your root holder.

As someone who uses both typed and untyped languages, I am with you. I don't like typescript either.

And I've observed it boils down to 2 things:

1. People used to statically typed langauges wanting JavaScript to act how they're used to.
2. People not taking the time to learn how JavaScript works and rushing to complain that it doesn't have a or b.

Will I be using typescript?
No. Because:

1. It makes codebases more difficult to read.
2. I sat down with a dev that has been at this for over 20 years and he impressed upon me the importance of understanding the core of the language you're working in. He also showed me, in real time, that you don't need it (TS) when you've done your due diligence

You simply have to grow into the types.

If you have a toy project where you are the only developer, sure, you can survive TypeScript bases. You have a lot of information in your head that allows you to navigate the project efficiently, add features easily and maintain your code

If, on the other hand, the project is large and many people are working on it, no typing will not work (or will work very badly).

If the project requires high reliability. You need to maintain the code for many years. People on the team change.

Type script, is a tool that allows you to get all the context about a project out of your head and into code.
Another plus is that far fewer bugs make their way into production. It is much more costly (to everyone, business, developers, customers) to fix a problem in production than it is to do it straight away when writing functionality

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 undefined value 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.

Side note: JSDoc uses tsserver for intellisense and flagging errors. It's all TypeScript in the end :)

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.

What really matters to me is the objective. That is, if I have to create something, let it serve its purpose. Having options is freedom. I try to use TS and not the other way around. But sometimes, because I don't have time and need to learn more about TS, I resort to what I've mastered. It's true that sometimes TS makes me a little desperate, but it has its points

Yes. I shame on people who don't appropriate type safety, autocompletion, and compile-time error checking. And don’t ever tell me you’re using JSDoc, if it wasn't TypeScript, there would be no types in JSDoc at all. It was TypeScript that brought types into JSDoc.

So please take a little more time to dig into the problem, it’s true that configuring TypeScript properly can be a challenge, but it's worth it. I, too, hate tsconfig, but I would die if there were no TypeScript.

Could you please write about hard facts instead of your "feelings" ?

No, It is not a shame, I was a hardcore typescript developer but now I'm shifted to core javascript again.

With every language you can write bad programs with large code bases as with every language you can write good organized programs with large code bases. It’s up to your or your team skills. I think programming languages preferences are highly biased. For example if you come from a strong static language background you will feel better using typescript as it provides types. Others may not

Fixing TypeScript errors with "any" is the lazy solution and terrible in the long term for maintainability. You basically turn off type-checking and yolo.

No, you are not alone.
I don't like it either. I mean, it has its good point and benefits, but is not for all projects.
As every other tool, it should be chosen base on a right evaluation of benefits and contras.

But as any trendy wave ... now everything is TS, even if it is not required at all.

Here is the ultimate guide to TypeScript for you, absolutely free. Just deep dive and you will love the dominance of TypeScript.

Ritik Banger (रितिक बांगड़) 🇮🇳 on LinkedIn: Typescript- the ultimate guide | 30 comments

Be the TypeScript Hero from Zero! 🔥 I am thrilled to share with you the ultimate TypeScript guide, the final part that will transform you from a TypeScript… | 30 comments on LinkedIn

linkedin.com

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 C# and now change to Python have some problem

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

I quite like typescript but I do run into problems where certain libraries don't support it. Or if you copy>paste a code-snippet from an API you have to google for the type annotations.

I'm still looking vor a VS Code extension that auto-compiles TS when starting a live server. Maybe it exists?

I tried using @JSDoc annotations, this works quite well but makes the code less legible.

And, it is important to understand that when you were able to master the types (and not hate them), realize them... Without them you will no longer be able to write code! Looking back, I realize that I was doing something completely stupid and wasted a lot of time on debugging. Now code without types seems to me like “shit code”, which is impossible to read and very difficult to understand.

I ask you, don’t engage in childish hate. Just study, study and study. And the creators of Svelte refuse TS for other reasons, having experience, reasons and a clear understanding of all the pros and cons.

Been so for 40 years. There is pros and cons with evertyhing. And recently, probably because of the typescript mobb maffia (read the comments people wrote when turbo8 left TS) have people been afraid to openly speak about how much TypeScript actually suck.

There are pros of using it, but would say 99% does not want to use it. It will cost the conpany more money, TS cause more bugs than less, it cause more bloat, making the codebase larger. And it makes the maintance cost higher. It is undenible true.

My "Aha!" moment was that I could refactor code / move it around and immediately have visibility on what I broke, then I could fix it before discovering the problem during runtime. Absolute game-changer.

Used to hate it until I adopted it, now I can't go back.

It's not the unsung hero, it's just the hero, we sing about it all the time.

keep in mind that you don't have to use everything typescript offers

Imagine you have a clone of you out there looking prim and proper and going to church shaving and staying clean and listening to gospel carrying a bible.

On the other hand the real you does not shower, you dont cook and you dont even have a social life cos its gonna eat into your coding time. you are a coder after all. You also listen to rock and hip hop and crazy dance music and sometimes ABBA.

but your clone gets the girls cause he is so clean and proper. and the parents love him. but then he is alsmost 100% you.

What if I decided to get clean and proper one of these fateful days. then what is gonna happen to him?

My question which I have asked one too many times is :
1.What if JS enables Types as a feature one of these fateful days?
Then what is gonna happen to TS? and the TS commando defence army? lol
-- just jokes
2.Does JS not have a Types feature already or something like it?

TS's type systems has a lot of the same issues C++98's had. We're not longer pre-2011

It's mainly the dev experience for me, the tooling, etc. I can use Javascript on projects as well but I kind of feel naked when I do. I can change a small amount of code and have no idea how it affects the entire project. With typescript having a compiler that yells at you when you mess up feels good. One thing I don't like about TS is that when I try to write a generic method to re-use everywhere I have to do type-gymnastics of my own but other than that I would prefer to go with typescript if I have the chance.

Not that I'm big TypeScript fan but, what are your better alternatives? Because even if I hate TypeScript I hate even more large codebase without TypeScript. If I could choose Java or any other language that enforces types I'd choose that but in web development there isn't really simpler tool than TypeScript. Also how you use it goes long way - learning to use it better can go long way making experience less miserable.

Ouch lol, sorry 'bout that. What browser are you using?

Right I'll try Firefox mac, see what happens!

😂😂

Using both JS and TS, depending on the project and its size, but on commercial side it also comes to client wish instability about product, roadmap and direction.

The more client doesn't know what he wants or which is the direction of his product I prefer Typescript, it is just easier to refactor the whole codebase if needed and I feel like it gives me some level of security when doing that.

Using JS when writing POC, MVP or small projects, side projects (I use TS sometimes just for the sake of it, but rarely in this case) and projects that are very very stable and need new features or some changes. Under very stable I mean - when client is sure about his wishes, needs and direction of the product.

TS is a tool, Flow is also a tool that you can add to have types in JS without breaking the mould of the whole codebase and is really noob friendly. It really helped me to transition to TS easy.

All this are just tools, you just have to use them where they fit, you won't use tank to kill a fly!

If you don't like TS, that's ok, but if the job requires it, well, you are SoL as business is business and your preferences don't matter at all. Just try to find other job and don't hate the tool because you don't like it.

I don't like Angular, I don't use it, I skip jobs with that requirement. I don't talk sh1t about it though. It is just a tool to get the job done.

I don't want to use typescript because I don't want to compile my javascript before I use it, and because types aren't that important.

"Oh but types tell you about what you're using!" Only if you already know about the type, otherwise you're looking through the documentation anyway. What you need is an IDE that can do proper type inference. If JS can be interpreted it can have a proper IDE.

Yes, I also hate it sometimes, I had to read all the documentation of generics again yesterday and mapping. But I have to say that I hate the most when someone in our project do not use it correctly. I've been moved from teams 3 times within my project, and I've faced how difficult it is when the previous developer didn't use Typescript and I can't get help from it. The learning curve is much much step without TypeScript, our project has complex objects everywhere objects inside objects that then contains arrays of objects that also contains arrays, can be undefined, null, or that never should be undefined. In my experience I would say that a project with 20 50 100 developers is not possible without TypeScript

I like TS, but generator function type declaration is the weak point of my TS mindset. Any one are using generator function in JS?

I have to give you the cold heart truth - TS is not going anywhere.
Just think about how much libraries/tools and projects are currently built using TS. Imagine all that being again(for no reason) re-written in other advanced version of JS(which we might never ever get). This is will be nightmare!

I know some people dont like but .. it usually people who dont know how to use types and write good high quality code. TS is just a tool, it does the job for what is made for.

Question being why do you hate it?

I mean it's a tool, it's convenient in certain scenarios and maybe not so convenient in others.

Also having TS doesn't mean you should use all features it provides, you can use it just for typechecking and typedefs as a substitute for the more boilerplatey JSDoc + TS Pragma, in this situation it will be convenient most of the time.

It's like prettier with formatOnSave enabled, you might not use it but whenever you do you understand the value of it, just that TS needs a bit more investment in terms of time to be appreciated.

Oh and... in the situations in which you feel like it's absurd to use you can just use JS!

It doesn't need to be all or nothing 😅😂

Maybe try rust

Reading typescript vs javascript posts is almost like reading pozidriv vs phillips screwdrivers discussions :)

it is made in javascript. just saying... :p

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 blabla java. 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".

several times I've been trying to play with TS, and then gave up because I could not like it 😐

Personally, JavaScript is my first programming language, and I love the beauty of its simplicity and purity.

I hate what TS brings to JS world. It destroyed the clarity of JS by a kind of terrible syntax.

JS doesn't need type. There are other languages for that. If I have to write a program that is tight, close to the operating system, high performance, and low on resources, I will use Vlang, Go, or Rust. When I build the websites, APIs and simple services, JS is enough.

I really don't see any reason to use TS.

I created a typescript module: react-state-factory which is very long, around 100 LOC. If do not count the config files. But what I saw under this project is the question how can I handle user created type in our library. That field I found few traps, but at end the result is perefectly solve my problem: one state, and one group of actions - each have own user defined type can be combined like in useReducer and thats all. So I think TS is much cleaner and safer than JS.

If we works arrays of one type then this type declaration will be help:

export type Mapper = <T>(list: T[]) => T[];

export const rotateList:Mapper = ([first, ...rest]) => [...rest, first];
export const shuffleList:Mapper = list => [...list].sort(() => Math.random() > 0.5 ? 1 : -1);

const rolls = shuffle([1,2,3,4,5,6]); // TS declared rolls type automatically to number[]

From my perspective I don't understand why I should learn typescript. javascript itself should add those features in the language not learning a language on top of a language + I think typescript looks really ugly and quite complex just to do something simple...

Why is TypeScript hailed as the savior of big projects? Is it really the unsung hero in the sprawling chaos of JavaScript?

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.

For the TypeScript fans, share your “Aha!” moment when TypeScript clicked for you 😎.

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.

And for my fellow “TypeScript skeptics”, why do you really hate it?

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 hate things that i don’t understand” kinda emotional post.

TS is better but complicated actually. I'll be choose TS (cause my code look shine) for more safer than using JS.

It's not so much that I hate the tool, it's that I hate how it is propagated.

1. Devs who act as if you not using it is ignorance on your part the "any good dev" smear.
2. Devs who can't articulate why they need it; They heard from another dev that it was great, they read an article, or the new dev coming in used it at his last gig and has been hyping it amongst his new team and his pitch sounds like brochure ware. They can't point to a current or recent dev failure or cost in their project that this tool specifically addresses, just vague handwaving and strawmen.
3. Devs who inherit it without understanding it. It's in the project they are tasked with maintaining and then as they move to a new project they assume that it must follow the other project's patterns. It's a defaulting behavior without serious thought.
4. Assuming there's zero cost and adoption is all upside. There IS a ramp and integration cost associated with bringing TypeScript into a team and how that adoption might impact other teams. This is especially true of organizations that have a mix of employees and contractors (i.e. employees you can train and manage ramp on vs contractors that you can't train you can only replace due to co-employment concerns) That cost has to be managed and onboarding has to be managed.
5. Adoption via force/pressure/coercion. Having two teams working in adjacent spaces that should be sharing resources where one is using TypeScript and the other using vanilla JS the vanilla JS team may feel forced to adopt TypeScript solely for alignment and not for specific gain.
6. Resume padding. Hey, this will look good on your resume and not having it will look bad. You'd be stupid not to have it (see #5)
7. The condescending/smug attitude from other devs who are using TypeScript and you aren't unequivocal in your excitement toward TypeScript
8. The added complexity and disruption being injected to otherwise simple projects when other more compelling problems need to be addressed (prioritization of labor spend)
9. Devs proactively deciding to upgrade existing projects without talking it through with other teams, management, or product owners, and then leaving the org and the project with no KT
10. Acting like everything TypeScript does is new and novel and hasn't been around well before TypeScript or that somehow the overhead in getting types set up and projects configured is SOOOOOOOO much less than any other option that devs have refused to do before it. People aren't solely adopting TypeScript because of the developer experience, or for some theoretical labor savings, or for reducing errors... they're adopting it because A. The architect told them to B. They felt pressure from peers C. It's the new bright and shiny D. Microsoft has deep pockets and has ensured it's everywhere/marketing (not organic growth) E. Because... why not? (I kid you not this was an answer from a dev)

I've argued this point before. Teams I work with wanted to adopt TypeScript and I asked them "what problem is it solving for your team" and they brought the bullet points from some presentation. I asked them if any of the bullet points related to any errors they'd actually seen in their products and to quantify that. They could not. I was then told they didn't need to prove that it was useful because it was just common sense (i.e. Not the "common sense" as in something we can all mutually observe and agree to be reality, but the "common sense" that's about popularity and not observable fact.). It's similar to when I talk to dev teams about why they have zero test coverage and why they've turned the linters off and I get back "we planned to work on that next Sprint, but right now we're trying to get TypeScript configured" and I'm just, "wait, you're what?"

You haven't written a test in 6 months or addressed a single linting issue in your code, your code is all over the place, and you think TypeScript is the magic sauce that will fix it all? And that is the core of the dysfunction I see about TypeScript vs no TypeScript. It's become a cargo cult versus a reasoned response among mature organizations for improving their code quality, time to market, and reduce errors making it to production. Because I can guarantee developers that don't want to document their code, don't want to deal with linting, don't follow their metrics reporting, and seemingly can't debug using the debugger today won't find themselves magically better developers able or willing to do all that stuff with TypeScript in the mix. They'll start slapping a bunch of types that will basically take anything together just to hit the next deadline and the code will be no better and possibly even worse that before. Why? Because people will think because they're using TypeScript that it's safe and they'll trust the code more than they should and they'll rubber stamp the code reviews because there weren't any TypeScript errors.

It's just a tool at the end of the day and we need to set aside the hype and not dismiss the fact that it might not be the right place or time for some teams to adopt and that there might be bigger fish to fry.

I saw Java in the college and I like it, is it weird? 🤣

Using Typescript is wrong. This makes you dependent on a programming language that may be obsolete tomorrow. It is always better to be careful when using Microsoft technologies. Do not use Typescript and also try to never use client-side frameworks for small to medium projects. JavaScript works great. Do not fall into Microsoft's trap! It is better to reach high skills in JavaScript.

Unfortunately, Microsoft has a one-dimensional view of many things and does not consider other dimensions.

Microsoft is not interested in helping the web! Microsoft's goal is to dominate the web.

I don't have a problem with Typescript. I've used it a couple times, but I find it's almost more useful with larger projects of course, because it dramatically reduces bugs and tends to keep things more organized. It has its place.

The only time I disliked TS was when I was a newbie dev and couldn't figure out how to fix compiler errors.

Now that I've learned how to use it effectively and know when to bail out when the types aren't useful, there's no going back. Untyped JS, especially in a big project, is just unbearable.

The bigger the project, the more TS benefits you, both for its self documenting features, and for breezy refactoring.

There's certainly a learning curve about what works and what doesn't. I'd say it's pretty easy to misuse, which explains why some developers get frustrated over it.

I have never liked or use TypeScript.
I think it makes the job harder to do period.
While I have seen some of It's benefits in libraries that use it I still don't see myself using it. The fact the there might also be a technical reason to ditch it in the future on certain projects even further makes it a turn off.

Now if I work in a team the already uses it, I would but I am not gonna start any project with it I really still can't see much value in it tha outweighs the overhead

I think Javascript should get "typed".

The sheer advocacy for things like TS and React is also really scary for me.

why do you really hate it?

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 tsc or 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 tsc that 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

#typescript #jsdoc

[deleted]

If you're alone on that boat, I'm alone with you. I hate Typescript with a passion for potatoes' sake. When I use JS, my perils are basically never type-related. But I embrace them. Understanding the quirks of JavaScript is what makes my relationship with it so special. Yes, I really meant it the day I said "for better or worse". TS is just lots of bloat, verbosity, and frustration.

Just like woodworking, you can’t use one tool for everything! But, much of the strong typing could be unforced by a good transcompiler.

To be honest, I don't like typescript at all. I however learned it and use it just because it seems like its the trend.

I only see more brackets, more words, more unknown characters, more import, more red lines, more thing to read, more configurations...

I came to JavaScript after using C#, 15 years ago. I immediately loved not having to write types for everything. The few times I’ve been trying TypeScript, I’ve had trouble writing higher order functions. Even writing OOP, since TypeScript (still!) doesn’t understand object properties like toString and valueOf. Hopefully the latter has changed with well-known symbols but I’m not sure.

I taught myself to program, which was not easy. Especially debugging drove me crazy from time to time.

In my opinion, it would have been much easier to learn the additional work through typescript and to get the advantages of the support in the IDE.

I love typescript and never want to write pure javascript again.

How long have you used Typescript? I've been coding in Javascript every day for 20 years and when TS first came out I hated it. It took intensive full time use until writing most TS was hardly a thought and I could understand the errors and also see the massive benefits to love it. Now I wouldn't dream of writing anything in plain JS. The code I write is virtually bug free first time and I can refactor with confidence, as well as have great intellisense. I can also share validation across client-server with things like Zod. I would take strict types over tests any day of the century.

You're not the only one, although "hate" is a big word, I'd say I love JS 😍 more than TS

Of all the ranting against the TS, I have never heared even one logical argument by the TS critics why it allegedly so bad (The real reason for it is , you don't understand it !!!, but not understading something is not a scale of it being bad!!!).

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'll add my two cents, which are I generally prefer Typescript. I like having types assigned to protect myself from myself and make the code clearer. This is the same reason I'm glad you can specify types in the newer version of Python.

However, the overhead of setting it upand working around its overzealousness to enforce things can be painful. I do yell at it quite a bit when it complains about using the any type.

True

This the important take away message I think

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.

That was a hypothetical question of course

TypeScript is to JavaScript what BEM is to CSS.
If you write good, dry, modular JavaScript then Typescript is unnecessary.

I just made a post as well about getting rid of Typescript. You're not alone!

So do I.

Look at this: will be interesting for you
dev.to/desone/why-typescript-vs-ja...

It's not a shame to hate TypeScript, but we do have to respect it's place in the JavaScript ecosystem. It has done a lot to make writing large javascript codebases possible in an enterprise setting, which one could argue isn't a good thing and we should have just used a better language in the first place.

If we must work with JavaScript, which is reality of web development, then typescript has allowed js to slowly become better. It's ability to be gradually adopted with easy escape hatches are why it became so popular.

But I think we can do better, and we should continue to push what is possible in the JS ecosystem for better scalability and developer experience. I've put my bet on ReScript, which is a statically and strong typed language with a JS like syntax that compiles to JS. It has lots of great modern language features that you would recognize from languages like Rust and Gleam, a strong type system (no any types), a fast compiler, and it works great alongside all the standard JS tools like NPM, Vite, React, etc...

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?

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. :)

Nah... I am just saying that requisites say what tools you chose, not "feelings". Plus, I originally replied to this: "You can write great code and trash code in any language." This still can poorly comply with requisites, not to say, totally fail them.

Furthermore, I was clear about agreeing on cases for JavaScript use, and as I stated, in my view, I see space for it in faster small to medium projects as well as single-dev projects, but if someone plans to counterargument TypeScript can also solve all other cases perfectly, Who is arguing in favor of a panacea? :)

No problem, I still wouldn't decide on tech based on feelings. And to the original person I talked to, I still don't agree because such statement totally ignores the requisites, context, etc. :)

Came across this post after typing into Google "Typescript Sucks" to see what would come up. I am not a fan of Typescript as most of my dev experience and bugs come from async issues or logic issues. What's also interesting is this insistence that "real software", "complex software", or "professional software" can only be done with Typescript. Which is just not true. Erlang which is a dynamic language has built the Ericson phone system and Whatsapp. If you ever listen to Joe Armstrong talk about the goals of the language, he describe many of the goals that are supposedly only possible in languages like Typescript (things like scalability, refactoring, maintenance, working with large teams, reduced bugs, etc...). I remember back when I first got into Javascript in 2008 one of the most advanced projects was Sencha's grid system (Known as ExtJs). It was all built in JS and maintained in JS because TS did not exist yet. It was honestly such a pleasure to work with since they had clear documentation and a stable product (again this is personal experience and may vary with others). I've worked in languages like C#, Java, and C (which is one of my favorites languages), but none of those languages save you from common errors that programmers make all the time. That's why I like articles where people go an analyze code bugs and show that there is no "clear winner" between static vs dynamic languages, just preference being presented as some objective truth. We should all also remember that a tool is not a substitute of a good programmer. Or as Tony Hoare put it:

There are two methods in software design. One is to make the program so simple, there are obviously no errors. The other is to make it so complicated, there are no obvious errors.

As many here have already pointed out, you can write bad code in any language. I've seen bad code in both JS and TS and good code in JS and TS. However, the current dev culture makes it seem like TS is the only way to achieve this, which is just not true. This is why I think you started this post as a way to add a contrarian view to the sea of Typescript promotion and hopefully help others understand there are other ways.

While we are at it, I thought I would give you some resources in your journey of thinking through this. Ultimately I think it's a bigger issue between static vs dynamic types. However, I will add that there are beautiful statically typed languages that don't get attention because we are advocating a certain style of static typing (specially C++, C# and Java style of typing).

• The Many Advantages of Dynamic Languages

The fundamental difference between dynamic and static languages is that in dynamic languages values have types, while variables and expressions don’t. Static languages are the opposite, expressions and variables have types. Values tend to be binary blobs at runtime.

In other words, in dynamic languages (Javascript, Python, Smalltalk, Erlang, etc) the type information is retained at runtime, while in buildtime static languages they type information usually is not. Understanding this basic but essential difference can open your mind to so much clarity in this debate / conflict.

• OSCON 2010: Rob Pike, "Public Static Void" - Great talk on how crazy complex much of programming has become. The thing that gets me about this talk is stuff like Boolean.TRUE. Also how he talks about, we've convinced ourselves that if you code like this you must be doing it right. Keep in mind Rob Pike is pro static types and his talk is about how he thinks static typing should be done.

• The Unreasonable Effectiveness of Dynamic Typing for Practical Programs - Tries to actually get data / research around the question "is it really better to have static types?". Best take away was his section on the ignorance on how extensive type theory is, the type system of physics, and his C++ code example where the bulk of it was written just to satisfy the compiler.

• The broken promise of static typing

• "Stop Writing Dead Programs" by Jack Rusher (Strange Loop 2022) - Great talk on getting out of the build mentality and moving towards a live / dynamic coding mentality.

• Bret Victor - Inventing on Principle - An AMAZING talk on what is possible with a dynamic mindset. Something we have mostly forgotten in the development world but are moving back to with things like live refresh in frontend frameworks.

• You Might Not Need TypeScript (or Static Types)

• The TypeScript Tax

• Breaking Open: Erlang

• Why Isn't Functional Programming the Norm? – Richard Feldman

• Yesterday's Computer of Tomorrow: The Xerox Alto │Smalltalk-76 Demo

• #rC3 - What have we lost?

• A list and count of keywords in programming languages - Added this one because I personally believe complexity creeps in at the language level. Look at Elixir (which is built on BEAM from Erlang). It only has 15 keywords.... very interesting.

There is soooooo much more. I would recommend studying the history of computer / language / systems design with people like Alan Kay and Bret Victor. It does a lot to help to mentally inoculate or protect a person from just accepting the noise and promotion that a particular way of programming is the only way to go. Be willing to expand you mind and see what is possible. Take care and keep questioning the development cultural norm.