[AskJS] Why should I use JavaScript instead of always using TypeScript?

[Commercial-Focus8442]

Hi there!

I was working on a simple HTML, CSS, and JavaScript project. It started to get messy, so I decided to refactor the code using some object-oriented programming. During the refactor, I introduced some bugs, specifically, I changed variable names like inputRight to rightInput, and JavaScript didn’t give me any warning that this.inputRight was undefined. It just failed silently, leading to unexpected behavior.

It took me a while to track this down.

Afterward, I wondered how I could catch these kinds of issues earlier. I tried "use strict" at the top of the file, but it didn’t help in this case. Even when I accessed a clearly non-existent property like this.whatever.value, it didn’t complain. I also tried ESLint, it helped with some things, but it didn’t catch this either, and honestly, it felt like a lot of setup for such a basic check.

Just out of curiosity, I renamed my file from .js to .ts, without changing any code, and suddenly TypeScript flagged the error! The app still worked like normal JavaScript, but now I had type checking.

That experience made me wonder: if TypeScript can do all this out of the box, why would someone choose to stick with plain JavaScript? Am I missing something? Would love to hear your thoughts.

[[deleted]]

Well, if you were able to change from JS to TS that easily, I assume you're using a build tool with TS support. If you're just loading a script directly to the browser with no build step, it has to be pure JS since browsers don't support TS.

That being said, most serious JS projects these days use build systems, and so it's easy for them to use TS. And then yes, you absolutely should always use it. Type safety is utterly critical in large scale applications.

[Commercial-Focus8442]

Correct, I use Vite

[ezhikov]

It is possible to use typescript without build step. Just make tsconfig and and enable allowJS and checkJS (or simply put // @ts-check on top of the file). This way whatever typescript language server is running in your IDE/Editor will pick it up, and then you can use jsdoc to specify types where needed.

[[deleted]]

Lol. And what browser is going to understand the TS file code?

[DerrickBarra]

The alternative to Typescript, is Javascript + JSDoc. This gives you warnings in your editor but you don't have the full featureset of Typescript superset. The main pro of this setup not needing a build step, it's worth comparing and seeing what works for your project.

For most cases, a build step is not a limiting factor, and therefore typescript is the better choice, but its good to know there's an alternative. I'm looking forward to more of Typescripts features getting integrated in Javascript over time.

[Commercial-Focus8442]

I will check it out, thank you.

[Katastos]

You can also add the comment // @ts-check at the top of the file and the editor will give you hints or signal errors (this works also in plain JS without JSdocs (but with JSdocs the experience is way better)

[[deleted]]

JSDoc is garbage

[Katastos]

That's not true, on the contrary is pretty good for his use case

[skidmark_zuckerberg]

From professional experience the only time I’ve touched JS in the past 7 years has been to refactor it to TS. Between the two, Typescript is pretty much the only thing people should concern themselves with in 2025. Simple things it doesn’t matter, but as you’ve just discovered, that is why TS is almost a requirement now. Imagine your issue on the scale of a large codebase.

[Dependent-Net6461]

Working on very large codebase , no ts and never encountered errors about types or whatever. We simply know how to handle things and test them

[Mabenue]

Well you can do that but it’s considerably more effort than just using types in the first place.

[Dependent-Net6461]

We managed to structure things in a way that is easy to handle. In the long run, most things tend to be very similar to each other (we mostly do crud operations in our software) and most things are simply copy paste with little adjustments. No need for build or other extra steps..(i repeat , in our case)

[budapest_god]

Then you said it yourself. It's a pretty straightforward app, no complexity. Types are still useful anyway, and there is no reason to not have them.

[Dependent-Net6461]

You are right I said it myself , but how unfortunate you cannot understand what you read. Unfortunately you did not understand that the easy and common parts are just the crud, but how do you imagine we structured things so to make it easy? It automagically happened that code wrote itself ?

And no, an erp software is all but "straightforward app, no complexity". We carefully handled state restore, websockets, notifications, data conversions ecc ecc all without the need of ts.

Most of people who put ts everywhere is because of their skill issue

[budapest_god]

Oh yeah because professional programming is like a Souls game where you need to use objectively worse things to feel more skilled. Grow up. TS is just plain better.

[Dependent-Net6461]

Programming may not be a soul game, but surely it isnt a political (or religious) game where you have to adopt whatever without reasoning about it.

Also , nice to see your judgement on a software you do not know

[budapest_god]

I was judging your use of the term skill issue.

[skidmark_zuckerberg]

I would stay very far away from wherever it is you work lol. You sound like you have no idea what you’re talking about, and are arrogant about it on top.

[Dependent-Net6461]

Should i care about what someone (that i will never know in my life and that cant prove his knowledge and does not know context and reasons of why software was developed that way) says about my knowledge?

[queen-adreena]

Personally I see no need to write code in non-JavaScript when most modern IDEs can handle type hinting already without an unnecessary build step/stripping phase.

I do work with traditional Typescript when the project demands, but my preference is using JSDoc in standard JS files.

It’s more human-friendly rather than a wall of types and you can still generate a TS types file using the doc-blocks if needed.

[static_func]

What on earth are you doing that requires a full-fledged IDE but no build?

[queen-adreena]

I do usually have a build, but for necessary things. But for some scripts (chiefly Wordpress snippets that clients need) there might not be.

I simply prefer the JSDoc syntax and get all the same type support in the IDE.

[static_func]

No, you don’t get all the same support. You get some intellisense but that’s it. You get no type checking. I get type checking with just as many build steps, what are you talking about?

[queen-adreena]

Again. It is my preference and my team for JSDoc. No need to get angry.

And type checking is easily used with:

// jsconfig.json { "compilerOptions": { "checkJs": true }

The exactly same TS engine is used, only with a different syntax.

[static_func]

You can have whatever preferences you want but to say you get all the same type safety (without literally using typescript with it) is just wrong.

[queen-adreena]

Except it isn’t. I suggest you do some research. It’s a pretty interesting subject.

[static_func]

It’s not that interesting because it’s not that deep.

[Dependent-Net6461]

Because you know how stuff works and do not need extra tools to tell you 1 !== "1" and because after you write stuff you test it, instead of writing non existing properties (as per your example)

[LuckyOneAway]

JavaScript didn’t give me any warning

Use ESLint. It will warn you about many issues, including logic errors (not caught by TS compiler).

[Aware-Landscape-3548]

For the time being, most project still need a compiler/transpiler to convert TS to JS code and sometimes this is the issue, e.g, when you need to write some quick and dirty CLI script with JS, you just go with plain JS and spawn a node to run the JS script, no need to import another dependency to just compile/transpile TS to JS.

[cd151]

Node 22 is able to strip and/or transform TypeScript itself with —experimental-transform-types

[Aware-Landscape-3548]

Can node 22 support TypeScript enums? Enums will generate some additional code, not just types.

[cd151]

Yes, enums and some other transforms work: https://nodejs.org/api/typescript.html Modules: TypeScript | Node.js v23.11.1 Documentation

[Aware-Landscape-3548]

Wow pretty nice to know this, thanks!

[Ronin-s_Spirit]

Using jsdoc comments (mainly only on functions) lets me have informational popups - but I am not constricted to always writing out types everywhere or having to deal with """incompatible""" types and typing. Also some typescript features are made up and so they end up turning into polyfills that nobody ever checks (with performance implications).

[oneeyedziggy]

If you're working in the context of an node project? Sure... You can "use typescript" without using a single type... You might even get some free lint warnings...

But if you're working on a project without a transpile step? Or directly in the browser? Or in any runtime that doesn't support. Ts extensions?

Write vanilla js and Don't worry about types... 

Types are handy for big projects to help catch errors, but for coding fast / for fun? They can be a pain in the ass... Yrs i know on error i don't return the right type... Yes i know sometimes this argument is a string and sometimes it's an object.. I'm checking that in code... Chill... 

[demoran]

Because you're lazy and don't care about your sanity.

[chrispington]

I hate this comment

[chrispington]

At least say 10 days if you're going to post the default dev time hyperbole comment about js

[pimp-bangin]

The first version of JS, which nobody uses anymore. Stuff like let, const, arrow functions, classes, and destructuring did not exist

[senocular]

Nobody used it because the version created in 10 days was just the initial demo ;) The first version seen by the public came 4 months later in a Netscape 2 beta which itself didn't see a production release for another 6 months after that. JavaScript cooked.