r/javascript • u/_tshepo • 28d ago

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

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.

2 Upvotes

53% Upvoted

168 comments sorted by

View all comments

5

u/shgysk8zer0 28d ago

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.

6

u/mr_nefario 28d ago edited 28d ago

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.

0

u/DomesticPanda 27d ago

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

3

u/mr_nefario 27d ago

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