DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Cover image for Typescript vs Javascript : Which one should you use for your next project ?
Suhail Kakar
Suhail Kakar

Posted on • Originally published at blog.suhailkakar.com

Typescript vs Javascript : Which one should you use for your next project ?

Introduction

JavaScript is a scripting language for building dynamic web pages. It adhered to client-side development principles, thus it operates entirely within the user's web browser and requires no resources from the web server. Javascript may also be used with other technologies such as REST APIs, XML, and others.

Typescript is a superset of Javascript. It is a statically built language for writing Javascript code that is straightforward and simple. It may be used with Node.js or any browser that supports ECMAScript 3 or above.

Difference Between Javascript and Typescript

Typescript Javascript
To make the code comprehensible for browsers, it will convert to JavaScript code. Can be directly used in browsers
There is support for ES3, ES4, ES5 and ES6 No support for compiling additional ES3, ES4, ES5 or ES6 features
During the compilation process, errors can be identified and rectified. Because it is an interpreted language, errors can only be discovered during runtime.
Since it is a superset, all the JavaScript libraries, and other JavaScript code works without any changes JS libraries work by default
Functions can have optional parameters This feature is not possible in JavaScript
Numbers, Strings are considered as interfaces. Number, string are objects.
Powerful and intuitive language Neat and clean, most suitable for simple web applications
Supports modules, generics and interfaces to define data No support for modules, generics or interface
The community support is still growing and not so huge Huge community support, including extensive documentation and assistance in resolving issues.
Prototyping is possible Prototyping support is not there
Takes time to learn and code, scripting knowledge is a must. Can be learned on the go, no prior scripting experience is needed.

Features of Javascript

  • It's utilised on both the client and server sides.
  • It's simple to learn and use, and it's a cross-platform language.
  • Strong Testing Workflow
  • It's a dynamic language: flexible and powerful

Features of Typescript

  • It's a dynamic language that's both versatile and strong.
  • Offered great productivity for developers & Maintainability
  • Code 'discoverability' & refactoring
  • Optional Static Type Annotation / Static Typing

Which one is better ?

JavaScript is excellent for experienced developers working on relatively small coding tasks. However, if you have a development team with experience and understanding, Typescript is the best alternative.

Conclusion

I hope you found this article helpful. If you need any help please let me know at comment section

Let's connect on Twitter and LinkedIn

πŸ‘‹ Thanks for reading, See you next time

Top comments (15)

Collapse
lukeshiru profile image
Luke Shiru • Edited on

I love TypeScript, but...

  • "Functions can have optional parameters". That can also be done in JavaScript.
  • There is no difference between Number between TS and JS (same applies to String).
  • "Powerful and intuitive language". It can be "intuitive" if you already know other languages like C#, and you already use JSDocs, but if you only know JS, types in TS aren't intuitive.
  • "No support for modules, generics or interface". JS has modules with import/export, and it doesn't need Generics and interfaces, but if you really need them, you can just use JSDocs and the TS server can use that to infer the types.
  • "Can be learned on the go, no prior scripting experience is needed". Both languages require some effort to be learn. To use TS you can apply the knowledge you get from JS and then some more.

The list feels partially biased, like it says "TS is hard but good, JS is easy but bad" and even when I do everything in TS nowadays, I disagree with that position. You can always have a combination of the two by using JSDocs with JavaScript, and then writing custom types and interfaces in .d.ts files.

Cheers!

Collapse
blindfish3 profile image
Ben Calder

I would also add that in practice the difference between compile time and run time errors is pretty irrelevant. When I worked on pure JS projects in the past I always had a dev environment set up that refreshed my browser on every save: so I got near instant feedback.

Collapse
rsgilbert profile image
Gilbert

Thank you very much. This is what I need to hear. I've spent a week learning TypeScript and I feel I know it sufficiently well to use it in my next project. I used it in a project that is in production now and it was "fine". But I feel like the reasons to use it do not justify it if I can avoid it. I had heard of JSDoc from someone else on the Deno core team and how it can be used to infer types but I never got to explore that. Now that you've mentioned it to me again I think I can finally begin to explore it and see what it can do for me. Go JSDoc!

Collapse
lukeshiru profile image
Luke Shiru

I'm what some consider a "TypeScript evangelist", but the things mentioned in this post weren't 100% correct. TS is an amazing tool, but more often than not some folks attribute to it stuff that is actually present in JS already. One thing I'm certain is that TS makes you a better JS developer, but you don't need to do the migration suddenly, you can do it gradually by first using types from JSDocs and setting jsconfig.json to be strict, so you get some error checking. Once you get the hang of it you can stick to it or you can easily migrate to TS, is on you. Either if you use TS directly, or trough JSDocs, the DX value of typing your code is too high to overlook it.

Happy that my comment shed some light for you, Gilbert. Happy coding!

Thread Thread
rsgilbert profile image
Gilbert

Thanks alot. You must have alot of experience in these things!
Right now I am learning JSDoc and its interesting. I've just tried out the jsconfig.json file and added checkJs . It works wonders. code.visualstudio.com/docs/languag...

I must confess, I am not so eager to go the TS way. I've done all the handbook guides on the website and already used it in a production app but I am still not bought.

Ever since I noticed from the guides how they always side with the C# way when it comes to picking a choice, I became skeptical. typescriptlang.org/docs/handbook/2...
They even had the balls to give a link on the so called "C# reasoning"!!!!!!!!!

I am curiously exploring this comparison thing further, I have a question posted here: qr.ae/pGlqut

Thread Thread
lukeshiru profile image
Luke Shiru

The core idea of TypeScript is to be "JavaScript with some extra stuff on top", that's why they call it a superset of JavaScript, because if you grab a .js file and rename it to .ts, that's a valid TS file. This allows you to do a slow migration without having to add types everywhere.
Now, some strong typed language folks will tell you that you need to type everything, but in my experience TS is at its best when you use it as you would use JSDocs: Just type when the editor can't infer the types automatically, to improve your DX. No need to write const x: string = "hi"; when you can just write const x = "hi"; and let the editor infer the type string automatically.
One pretty cool thing about types from my point of view, is that the TS team used JSDocs types, so if you are using JSDocs already, then you don't have to learn something new, you just use those same types directly in your code, instead of "next to it" as JSDocs do.
When it comes to C# similarities, I think interfaces is ehat borrows more from it (mainly because it was created by the same folks and there wasn't an equivalent in JS for that), but other than that, I usually feel like doing JS with inline JSDocs which I find extremely useful already, and on top of that I can compile new features targeting old browsers (like Babel does), but it keeps the code similar to what I would have written myself in JS if I had to, and the type validation at dev is also a great feature, even more so if you work with a big team.

Collapse
martinmuzatko profile image
Martin Muzatko • Edited on

"No support for compiling additional ES3, ES4, ES5 or ES6 features"

This is plain wrong.
You can use the complete ES3,4,5,6 feature set today in the browser or in nodejs without needing to compile. NodeJS supports .mjs files with package.json property "type" set to "module" which support ES6 modules and in HTML you can mark es6 modules as <script type="module">

Since it is a superset, all the JavaScript libraries, and other JavaScript code works without any changes

Work as in it executes. Not work as in it comes with types for the safity we want. If you are lucky enough, there will be a @types package.

Numbers, Strings are considered as interfaces.

Actually, using Number and String as type is frowned upon. The correct way is the lowercase counterpart number and string (and boolean).
Numbers and Strings exist the same way in TS as in JS. Number.IsFinite exists in both TS and JS, otherwise it wouldn't be JS compatible.

Neat and clean, most suitable for simple web applications

You can abuse any language or framework to do what it should not. Like people create elaborate systems with PHP.
More code has more room for failure, but usually you want safety from the start, not only when the project has grown to 50k loc. (trust me, I know how migrating a large project is like)

No support for modules, generics or interface

Only partially correct.
Modules are supported with .mjs or type=module in the browser.
Interfaces can be written with JSDoc, but they are not as terse and helpful as TS interfaces. Although you can mix TS in jsdoc.

Prototyping support is not there

What does that mean?
The concept of object prototype exists in JS and TS. Otherwise they wouldn't be compatibly.

The community support is still growing and not so huge

All major packages (over 6000 projects have dts files, and many are native TS projects) have type definitions by now. I think adaption is going pretty well

That was a lot of facts to get straight. If you found any errors or have questions, let me know.

Collapse
rsgilbert profile image
Gilbert

I dont understand whose side your on here. Are you rooting for TypeScript or JavaScript?

Collapse
martinmuzatko profile image
Martin Muzatko

I just attempted to correct statements for both JS and TS. No need to be on any side to make objective statements.

Collapse
sebbdk profile image
Sebastian Vargr

Nether are better. :)

I suggest we stop trying to compare hammers & screwdrivers, apples and oranges etc.

Typescript is intended to be type strong, Javascript is type weak.

What we should use, should depend on, how much time we want to spend, the team we have, is it a high volume product or a low volume product, what would the impact of downtime be, the importance of avoiding errors, do want to unit test, what libraries are we using, what is the experience level of the implementers, who is this made for, does compile stack complexity matter and finally should this run in a shoebox.. maaaybe?

There's a reason carpenters do not use a swish army knife for all their work. :)

Collapse
gdenn profile image
Dennis Groß (he/him)

I use JavaScript ES6 in my personal projects but TypeScript at work.

I suggest to use TypeScript in larger projects, especially when multiple developers are involved. It makes it just easier to use the code of others when you use a static typed language.

For me, the biggest drawback of TypeScript is the additional transpilation step into JavaScript. That can be really tedious if you work with large React projects.

Collapse
trangchongcheng profile image
cucheng

Sometine i dont know type of data so i will set any, anyone like me?

Collapse
jfbrennan profile image
Jordan Brennan • Edited on

Can you please explain these

Prototyping is possible | Prototyping support is not there

No support for compiling additional ES3, ES4, ES5 or ES6 features

Collapse
hr_coder profile image
Hamidreza

tnx

Collapse
hr_coder profile image
Hamidreza

Tnx

Now it's your turn.

Β 
πŸ—’ Share a tutorial
πŸ€” Reflect on your coding journey
❓ Ask a question
Β 
Create an account to join hundreds of thousands of DEV members on their journey.