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 sentimen...
For further actions, you may consider blocking this person and/or reporting abuse
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
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!
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.
It's not so much that I hate the tool, it's that I hate how it is propagated.
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.
God knows I love scripting languages, and the main -and probably the only- reason for using TS for me is type hints.
In certain scenarios TS it's simply annoying and in others it's quite valuable, now JavaScript happens to lack of type hints, a feature that other scripting languages such as Python or Php have implemented long ago, hence you need a dependency to handle that, and the most common -not the only one- is TypeScript. Fine, I mean, I don't care if it's one or the other, what I want is the feature itself.
TS has become some sort of standard to deal with this, for that reason I feel that TS is necessary for now, the natural question for me its not using TS or not, it is "how much of TS do you use?" Because you can use it just for type hints and call it a day and I believe that we all can agree that learning how to declare a type is not that much of a hassle right?
You can also use JSDoc + TS Pragma to declare types, I did a post on that here:
To TS or not to TS, that is NOT the question. Is it?
JoelBonetR 🥇 ・ Apr 26 '22
If you happen to check it you'll notice that some points you made are well represented in the comment section (what I call tribalism), even though VSCode is using TS behind the scenes to make it work.
Long story short, if ES happens to implement type hints properly -read as not some halved-solution without taking into account DX and/or testing scenarios like what they did with the WebComponents core API- I would avoid using TS in a handful of projects straightaway, but for that we need to wait.
I love your comment.
Makes a lot of valid points
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
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 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 ofactions- each have own user defined type can be combined like inuseReducerand thats all. So I think TS is much cleaner and safer than JS.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 😅😂
"hate" here is a response paving the way to others to come out and say we love to work with JS not TS
and regarding investment true, agree, needs more than JS (although fans promise it will pay back)
My point is that if JS happen to integrate optional Type Hints like Python or PHP it would be nice and in tones of products TS won't be needed, specially in frontend where using FP instead OOP as main paradigm reduces bundle size due to the tree shake.
On the other hand TS would still be valuable as it adds other useful features in certain scenarios as for now.
Just to clarify, when I say type hints I mean to be able to do something like:
Which is fully integrated, natural, gets populated automagically to JSDoc when inspecting function calls and so on and so forth, and not something like:
Which already works if you use TS Pragma (
// @ts-check) at the top of the js file, but its kind of unnatural; you need to jump your eyes from an arg/param to the doc to understand which type it is expecting and so on and so forth.So we'll see how and when JS evolves again and how it ends up being implemented!
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.
Exactly, at most it is nice to have!
Neither "nice to have".
Any tool you choose in your life may serve to make your work easy.
Can you use a screwdriver to drive a nail? Yes, you can.
Should be optimal to use a hammer instead? Obviously.
Is it nice to have a hammer to drive a nail? No, it is not.
So when you apply it to Typescript, the pure benefits of having this super-syntax in any project is to have a set of strict types for using between layers and APIs of your solution.
Therefore you should use Typescript whenever:
And by external third-party developers I refer to:
That way you ensure, in development stage, that noone is using in an invalid way your code.
Friendly reminder in here, that when your code is pushed to production, all your Typescript code is transpiled into Javascript (which is the language either NodeJS or web browsers understand), and once un runtime your code may contain security gaps.
But, then ask this question to you: who is going to use my code?
If the answer is: yourself.
Then, you don't need Typescript.
Thanks for the explaination
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.
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
toStringandvalueOf. Hopefully the latter has changed with well-known symbols but I’m not sure.Javascript rocks
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.
So it is for the love of IDE features?
Yes also, it helps me to detect errors earlier and avoid possible bugs, which I would otherwise leave behind for sure.
I love how the pie chart after answering flickers scrollbars at the refresh rate of my screen, 144 FPS.
Ouch lol, sorry 'bout that. What browser are you using?
Firefox on Windows.
Right I'll try Firefox mac, see what happens!
it is made in javascript. just saying... :p
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:
Will I be using typescript?
No. Because:
Very much agree. It isn't always the case, but very often I've seen devs cling to or adopt TS like a 'security blanket' because they can't/won't adapt to working with a different mindset and/or take the time - like you say - to fully understand JS.
I started out many, many years ago with strictly typed languages, and coming to JS was really a breath of fresh air. Going back to strict typing feels like programming in a straitjacket. The rapid, creative, expressive development possible in JS is a really good thing.
we should also notice, that types are not the only difference between Javascript and C++ or Pascal. Javascript is an interpreted value, so some errors are only detected when the code is executed. A compier / linker can do a much better job here.
Well that is very nicely put! add to that requiring that on top of JS making it harder for new comers to start for something that is only nice to have.
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!!!).
Big assumption there bro
You should have supplimented your argument with "why TS is bad?"
There is no justification provided by you for it in your post.
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.
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.
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.
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.
Many things support your claim to be honest!
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)?
The no need issue
We are a team of 18+- developers most remote, we run and have several projects (many are in production for years), myself 8+ years of development.
My main issue that it is not needed, and I dont have to put developers through requiring it, it is more like nice to have, and although it is, developers are being under a lot of community pressure if they say otherwise!
I have to say maybe you have not reached the point at which the transition cost makes it worth it:
This conversation is new within the JavaScript community but old within the overall software engineering community. It is not a battle between JS and TS; it is a battle between static and dynamic typing. All the research that I have seen over my +10 years in the sector points in the same direction:
You can read more here web.cs.ucdavis.edu/~filkov/papers/... you can find many more papers like this if you search online.
Thanks a lot for sharing 😍 very interesting even outside context of TS
And the abstract ends with:
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
anytype.🤣🤣 its my code, I want to have as many any(s) as I wish
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.
Me, I didnt use it as long as you for sure. I appreciate your point of view, do you see it a must for all JS developers?
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.
I love Javascript with all my heart too
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.
What if you are starting the project with a team and it is your call?
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.
If you are to use it at all, I agree, true, it would make sense only in the context of a large project
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.
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...
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
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.
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.
😂😂 true, it is being on loop too
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.
That is why we are here to encourage haters to come out!
You are right in every sense, add to that you add to the new comers a barrier although they might be JS fit.
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.
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
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
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
Thank you 👌
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.
We are just in different legions 😁
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
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
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?
Then all JS community will love it, and it is part of what all JS devs learn and use. TS will vanish in an ideal world, but it wont as we are communities with loyalty
No, It is not a shame, I was a hardcore typescript developer but now I'm shifted to core javascript again.
😍
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.
It is why using Typescript to follow the trend only 😂
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.
Yea I dont like what I dont understand as well 😂 but in case of TS i just hate it, although I used it, worked with it, built with it (only couple of projects tbh)
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.
We dont want it to go anywhere 🤣
I just want TS fans and users to use since they like it and see reasons for that, and leave alone those not using it and see JS is doing a great job, since it is the case, we shouldnt turn that into something some developers feeling inferior for
Naw; I also prefer a more flexible JavaScript. You’re not alone, but the nice thing is that they’re interoperable.
True
I only see more brackets, more words, more unknown characters, more import, more red lines, more thing to read, more configurations...
more time to add all those, at a reasonable size of project, this amount of time to do all that can be detrimental
You're not the only one, although "hate" is a big word, I'd say I love JS 😍 more than TS
The love for Javascript is beyond simple words 😍😍
I just made a post as well about getting rid of Typescript. You're not alone!
I hate pressure being put to use it
TS is better but complicated actually. I'll be choose TS (cause my code look shine) for more safer than using JS.
Reading typescript vs javascript posts is almost like reading pozidriv vs phillips screwdrivers discussions :)
🤣🤣
Maybe try rust
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.
U are right about that
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.
I like TS, but generator function type declaration is the weak point of my TS mindset. Any one are using generator function in JS?
TS's type systems has a lot of the same issues C++98's had. We're not longer pre-2011
keep in mind that you don't have to use everything typescript offers
🤙 then why at all?
Could you please write about hard facts instead of your "feelings" ?
Not the point here, why would you question anyone for using a language or another, a framework or the other in the first place?
It is not always about facts, do you reconsider all available options when starting a project and pick the best in accordance to facts, or have preference?
Just like woodworking, you can’t use one tool for everything! But, much of the strong typing could be unforced by a good transcompiler.
Why have it at all then in the first place?
😂😂
I saw Java in the college and I like it, is it weird? 🤣
🤣🤣 a bit
So do I.
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.
yea many others will go down the same road just to get a job
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...
“I hate things that i don’t understand” kinda emotional post.
🤣🤣🤣 the exact shaming we posted to provoke, thank you
Look at this: will be interesting for you
dev.to/desone/why-typescript-vs-ja...
TypeScript is to JavaScript what BEM is to CSS.
If you write good, dry, modular JavaScript then Typescript is unnecessary.