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

Comments

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

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

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

[Martin Muzatko]

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

[Gilbert]

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

[Martin Muzatko]

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

[cucheng]

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

[Hamidreza]

Tnx

[Hamidreza]

tnx

[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!

[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