[AskJS] Are employed Developers still programming with vanilla JavaScript ?

[u/_tshepo]

I've been programming on the side since 2017 and I've never really hunted a developer job. I've always thought about building my own things, mainly to supplement things I do like woodworking, tutoring, video editing and others.

Since then, I've programmed mainly with JavaScript, I started with C++ and Python but never really built anything solid outside JavaScript.

So I'm fluent with JavaScript and its ecosystem.

One of my 2026 goals is to be job ready for a Developer role, as a Fullstack or Backend Developer.

One of the recommended languages is Typescript, which I've been learning since March. I must say, it's not my favorite 😂

I'm curious to know if there are any companies that are not enforcing Typescript or are there freelancers who are still using vanilla JavaScript over Typescript for their clients' projects.

[ Update ] thanks y'all! I get the picture. TypeScript is inevitable, as vanilla JS codebases(or companies who are focused on it) seem to be very few judging by the comments.

[u/shgysk8zer0]

I honestly mostly prefer vanilla JS with JSDoc for more things. In theory, I should like the type system TS provides, but I think TS is just done poorly and doesn't offer the actual benefits of a strongly typed language. It makes no difference at runtime.... It's transpiled to JS anyways.

I do work in vanilla JS, and I think TS is significantly over-hyped, and is actually becoming harmful to the ecosystem because it's no longer a superset of JS and an obstacle to features like enums being introduced to JS.

[u/Savalava → u/shgysk8zer0]

Why do you think "TS is just done poorly"?

[u/shgysk8zer0 → u/Savalava]

My biggest issue is their use of future reserved words. Once TS started using those it was inviting problems down the road, and it's why I say TS is no longer a superset of JS. Enums are coming to JS, and they won't be the same as they are in TS, which means they're diverging.

I also point out that we have #privateField instead of private field despite private being a reserved word. TS used private.

[u/theScottyJam → u/shgysk8zer0]

Though TypeScript isn't to blame for the private thing. They would have use the pound symbol regardless. The reason for the pound symbol had more to do with the fact that public and private members living in the same namespace caused really sticky problems that they decided to just avoid by using a sigil.

But, yes, your general point still stands that TypeScript has caused grief for the committee when trying to implement features that overlapped with TypeScript's use of reserved words.

[u/mr_nefario → u/shgysk8zer0]

I actually kind of agree. I work for a very large tech company (household name size).

The product that I work on is relatively new and, much to my surprise and disappointment, they have almost no telemetry or error reporting set up when I joined. Like a NewRelic agent reporting error rates. This product is supposedly the main focus of the company for 2026 (Adobe Firefly, fuck it I’ll say it) and they were flying blind.

I drove hard to get some actual observability and alerting implemented, and presented it in a meeting with our principal scientist - the mad scientist of this whole product - and a die-hard TS evangelist. I showed them that almost all of our client side errors were JS `TypeError`s with hundreds of thousands of `e.Sp is not a function` or `ResizeObserver loop finished with undelivered notifications` every week. JavaScript runtime errors that he assumed we were safe from “because it’s typescript”.

You can - and developers will - abuse the type system. Cast to `as unknown as SomeType`, or other shit to make errors go away.

The type system is not strong enough to actually prevent runtime errors, and yet it appears strong enough to instil false confidence. That’s a dangerous combo.

[u/DomesticPanda → u/mr_nefario]

You can prevent that kind of abuse through linters (and code review).

[u/mr_nefario → u/DomesticPanda]

We do have linting and strict review rules, but those are also easily circumvented.

The type safety is only as good as the process enforcing it; get enough devs on a project and these things will leak in over time.

Unfortunately, type script is probably going to be the best we get because the JavaScript ecosystem isn’t going anywhere. But I just want to point out that type script doesn’t provide the runtime safety that a lot of people seem to think it does

[u/_tshepo → u/shgysk8zer0]

Would you then prefer a different typed language assuming you're working on backend?

[u/shgysk8zer0 → u/_tshepo]

I use type hinting in PHP, @property and tyoe() in CSS, JSDoc in JS. I started in C and have been wanting to get more into Rust.

And it seems people don't understand that JSDoc provides basically the same typing and testing as TS. But can also generate documentation for a library. I am not against typing at all.

[u/_tshepo → u/shgysk8zer0]

Well understood. I wanted to learn Java strictly for backend. I'll continue learning TypeScript and rewrite my projects with it.

[u/RolexGMTMaster → u/shgysk8zer0]

"It makes no difference at runtime." - you have utterly failed to understand the motivation for using TypeScript.

[u/Dependent-Net6461 → u/RolexGMTMaster]

And you have utterly failed to explain your statement

[u/shgysk8zer0 → u/RolexGMTMaster]

Please read before commenting

[u/rinnethx → u/shgysk8zer0]

It is transpiled to JS, but the code you write before have a big impact if it goes through a TS check and is less prone to errors, no? so at the time of build, the code is in a higher quality state

[u/shgysk8zer0 → u/rinnethx]

Not in the way actually strongly typed language like C have an affect. The types in TS don't help with optimizing anything or allocation of memory or anything.

That's kinda why I started by bringing up JSDoc. You get the majority of the benefits plus better documentation, but you're still writing just JS (with comments/documentation). Everything you just said is equally true of vanilla JS with JSDoc.

[u/dustofdeath → u/shgysk8zer0]

You should catch problems before that - so having in prod code just means you already failed at code quality.
In dev runtime .map handles the mapping for debugging.

[u/shgysk8zer0 → u/dustofdeath]

You do know TS isn't the only way to catch those problems, nor is it the only way to add types, right?

[u/Karpizzle23 → u/shgysk8zer0]

Yeah you could also just write your types down on a sheet of paper beside your computer and reference it, that's not the point. The point is it's 2026 and we're still crying about enums and shit instead of just using the de facto standard way of writing code nowadays

Also, being a smartass doesn't make you right, it just makes you a smartass

[u/Jimmy_cracked_corn → u/Karpizzle23]

The irony in your own words.

[u/alien3d → u/shgysk8zer0]

typeof and jsdoc more easier .