In recent years, TypeScript has emerged as a popular choice for many developers due to its extra layer of static typing. However, this article will...
For further actions, you may consider blocking this person and/or reporting abuse
These arguments are weak. You may find this out if you work on one project with several people. If you're creating a simple business card for yourself and you're the only one working on this project then maybe you can still manage without TS. For larger projects, plain js will not work. The cost of fixing errors that arise from lack of typing will be too high.
Wordpress they use Javascript , for their large project : github.com/WordPress/gutenberg
if you have solid design pattern , then it will easy to maintain the project
Keep in mind that specific project started at a time when TypeScript was still an early adopter option more than a best practice recommendation, and TypeScript is an invasive upgrade for existing JavaScript projects - so it may not be a feasible change for the team if they have other outward-facing priorities to invest their efforts in.
As far as good patterns - I'll assume that the timing for the project conception aids in this perspective. Had this project kicked off pre 2015, it would likely have less maintainable code today.
It's not the same. They still use JSDoc, and generate their typings for users of the library to consume.
No "solid design pattern" is going to catch all type errors.
To be fair, JSDoc doesn't let you(r IDE) catch type errors, they are more like annotations, orwith suggestions.
And?
Some people use C instead ov Rust — does that mean C is better? /rt
^ second this. The benefits of TypeScript are seen at scale for collaboration, complexity, and maintenance, so it's not really an argument of using one or the other, but knowing which is the more appropriate solution for the task at hand. My language of choice for writing code today is TypeScript, but I don't hesitate to switch back to JavaScript if the working conditions negate the need for the additional quality controls.
I don't view TypeScript as having a smaller talent pool - unless you're going to skip an onboarding period for your engineers. TypeScript is JavaScript with extras and a compiler step. JavaScript engineers can quickly adapt.
Hello Grzegorz Szelig, Welcome to the dev community glad you are sharing your knowledge and educating others, The development of TS was done making it a super JS to prone errors before going into production. You have a valid point here .
Were there no big projects before typescript? Static code analysis for javascript has gotten better as well, there's no need to use typescript
I must respectfully disagree with the notion that reverting back to JavaScript from TypeScript is a beneficial move. Here's why:
Type Safety: One of the standout features of TypeScript is its ability to catch errors during compile-time rather than runtime, which can potentially save developers from encountering numerous bugs and issues down the line. This type safety can significantly streamline the debugging process, making maintenance easier in the long run.
Improved Developer Experience: TypeScript offers an enhanced developer experience with features like autocompletion, refactoring support, and advanced type checking, which can significantly boost productivity and code reliability.
Community and Corporate Support: TypeScript has garnered substantial support from both the community and corporations. Many popular libraries and frameworks have adopted TypeScript, offering type definitions that can help developers avoid common pitfalls and write more robust code.
Scalability: For large-scale projects, TypeScript's static typing system can be a boon. It helps in maintaining a structured codebase, making it easier to scale the project without getting bogged down by the complexity that dynamic typing can sometimes introduce.
Interoperability: It's worth noting that TypeScript is a superset of JavaScript, meaning that all JavaScript code is valid TypeScript code. This allows for a smoother transition between the two, and developers can gradually adopt TypeScript features in their JavaScript projects without a complete overhaul.
While JavaScript's flexibility and dynamic nature have their own set of advantages, the benefits of using TypeScript, especially in larger, more complex projects, cannot be understated. I believe a more balanced approach where the strengths of both languages are utilized based on the project's specific needs would be a more prudent strategy.
let x = 3
x = "foobar"
is valid js but not valid ts
That's because ov type-inferencing — just add
:anyright afterx.Sure, I guess this does kind ov invalidate the whole "all JS is valid TS" statement, but it's a minor tweak to the code; usually, most people want variables to have only one type, which is why TS defaults to choosing a type.
Sure but "ts is a superset of js" is spread all over the internet while it's factually incorrect
How about this for a compromise? "TypeScript is a superset ov JavaScript, but only in terms ov syntax, not in terms ov rules.".
you shouldn't be writing your code like this to begin with... The whole point of TS (from my understanding) is to improve manageability but if you're not writing good code from the get-go then you should probably focus on improving that first.
Thank you @patric12 for your comment,
check here how react success to write the largest & best frontend framework using just javascript without any typescript :
github.com/facebook/react
What do you think ?
They use Flow, as static type checking similar to typescript developed by Meta as well.
As @webjose pointed out, React's performance isn't really relevant here.
Additionally, you're not considering whether or not they are using some other means ov type-checking, like @giovannimazzuoccolo pointed out.
@lalami It seems like you might not have extensive experience with TypeScript. In the TypeScript ecosystem, it's quite common for libraries not originally written in TypeScript to have separate type definition packages to support TypeScript development.
React? The BEST? See these performance benchmarks. Where is React? Always to the right, in the yellows and reds.
However, saying this is just a fallacy as its performance has nothing to do with what TypeScript is meant to do.
So what do I think? I think React has already met End Of Life. It just so happens to be the #1 in popularity. Give Svelte a year or two. Everyone will be on Svelte.
Whether you go TypeScript or JsDoc is a matter of taste in good amount, but to say only JavaScript is madness.
I think (2) has long been fixed. Our project is core is JS only with JSDoc and autocompletion is just fine in JetBrains IDEs and VSCode. As are type notifications etc without the need for a compiler.
I see real benefits for TS is very large projects with many teams, though the architectural patterns we use in our project separate concerns and team interactions well. We support modules and micro front ends built in either. We have JSDoc and typedefs for the key functions.
I can see from your perspective that JS may seem like a better choice when limiting the context of the argument between TS and JS. Unfortunately, the context is significantly larger than your argument considers.
I would love to hear your thoughts on how JS is a better choice at scale. Or for different project types. I know there have been successful projects built without TS, so I'm not just looking for examples of people who didn't use it. But instead, I would like to hear your thoughts and perspective.
For example, one problem I consistently run into without TS is identifying data structures. If I'm trying to reuse someone else's function or component, figuring out the required structure of an object is unnecessarily complicated and often requires a lot of time investigating. This can be solved with the addition of JSDocs, but since you did not include that in your argument, I assume you are not using it...but if you are, there is also a learning curve to proper JSDoc format, so it's more of a tradeoff. Do you have thoughts on how JS makes this sort of thing easier without the need for other tools?
Additionally, I know there have been several large projects recently dropping the use of TS (Svelte for example), but before making a sweeping declaration that "if these teams are dropping it, so should everyone" we must first consider the reason why they are doing so. Many of the example projects people bring up in this regard are packages and libraries meant to be used within applications. Building a package/library is vastly different than building an application. They have different requirements, considerations, skillsets, serve different needs, and have different audiences. Could you share your thoughts on why TS should not be used for any project, rather than it being used as a tool for specific jobs for which it's best suited?
I look forward to hearing your thoughts here!
I agree with most of your arguments; simplicity and flexibility of JS vs TS, could be that there is a larger talent pool for JS than TS. I do not agree 100% about the learning curve if the leaner has good base on different OOP languages (apart of JS) and do not agree about that the initial setup time is larger for TS than JS, depend of what are you building, for complex projects the set up time is very similar (Unless you are saying that you can not write TS on a web-console from your browser). About that JS is better for prototyping, hacking, and do PoCs I agree. But for complex projects, that has lot of components and parts, and lot of developers involved, TS is a winner, reduces the errors and misinterpretations when you are using a component that wrote another one.
Also I must admit that for the last 7 years I was developing at services at the backend and could be that the point of view of a fronted dev could be more JS oriented.
I see you've been scrolling through Twitter lol
And...?
How is that relevant?
I have to disagree with you on this one, working with plain JS on a large project within a team is super hard and most of the time end up as a mess, you might increase the development pace and make the code look cleaner, but maintaining the code will get harder over time and if you are not super careful you will get regression bugs everywhere and
Uncaught TypeError: undefined is not a function.If you're writing a library and having issues with TS, you should consider JSDoc.
If you're just writing apps, don't switch back to vanilla JS. It's a terrible idea to ditch static typing, and all the benefits it brings, just because "code looks cleaner".
Well said, I came here to say this exactly!
There are a lot of arguments being made that packages are dropping TS. What I see frequently is people failing to realize that building a package/library is not at all the same thing as building an application. It's like the difference of working on a car's engine vs working on a car's interior. Both are important jobs, but they both require different tools.
At the end of the day, TS is a tool. It's not the only tool. And we should always try to choose the right tool for the job.
I think mentioning React as an example here is a bit ironic. While it's true that it has been written in pure JS, they have also created Flow, which is quite similar to TypeScript, and React PropTypes. So I assume they clearly saw a strong demand for types.
oh wow, Thank you for the good article!
here another nice article : Turbo 8 is dropping TypeScript
As @szagi3891 says, your points are weak. — Here's why.
This goes for any dynamically-typed programming language; this isn't special to JavaScript.
Also, there are reasons why you wouldn't want to just be flexible.
Well, if said developer is versed well enough in JavaScript, they should be able to get the hand ov TypeScript almost instantly.
Literally, as much or as little TS as you want can be typed or untyped, so certain, TypeScript-specifc, features can be introduced to the programmer, and integrated into their code, slowly, in a way that gives them room to breathe.
Not really.
Consider my last point, again; since as little or as much ov the code can typed, we can make the TypeScript as similar or dissimilar to JavaScript as we'd like — however, simplifying the code will just water down any benefits TypeScript is trying to give you.
And?
There doesn't need to be type-definitions just for TypeScript — one can get by perfectly fine by just using the JavaScript types' names — not to mention that using
classes in JavaScript and TypeScript is virtually identical.I have read your article carefully. In my personal opinion, one should strive to use both JavaScript and TypeScript well. Moreover, as a project grows, TypeScript becomes absolutely necessary, I believe. In my company, when we developed a massive commercial real estate solution, we built the server using JavaScript. We worked hard with jsdoc to handle a complex database schema. Eventually, we implemented a system quite similar to the Nest framework, but the lack of types was truly a terrible experience. When we migrated that project to TypeScript and Nest, we felt a real sense of liberation.
I feel once you start using TS, its pretty difficult to go back to a non-type world. It nourishes discipline in coding which is the best part.
Agree, the only way returning back to JS after TS is when you are forced to work on legacy projects
After learning TS I had never created a project with JS :)
I read this article and I'm intrigued by the author's arguments for going back to JavaScript from TypeScript. I've been using TypeScript for a while now, and I definitely agree that it can be a bit verbose and can add some overhead to development.
However, I also think that the benefits of TypeScript outweigh the costs. TypeScript can help to catch errors early on, which can save time and frustration in the long run. It can also make code more maintainable and easier to collaborate on. I think it's important to weigh the pros and cons of TypeScript before making a decision about whether or not to use it.
Look at this dev.to/desone/why-typescript-vs-ja...
Interesting!
i use chatgpt in telegram free bot in this link