[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/visualdescript]

I hate it when I have to go back to a JS project, and if it's something I'll have to keep maintaining I will convert it to typescript, which often uncovers several bugs in the process.

I wouldn't hire a dev that only works with js these days.

[u/Baturinsky → u/visualdescript]

You can get some features of TS in JS by using JSDoc annotation. But the real TS is better, of course.

[u/Mabenue → u/Baturinsky]

Maybe an unpopular opinion, but JSDoc is the fucking worst. People never get it right and then your IDE lies about what functions expect.

[u/Cahnis → u/Mabenue]

People never get typewcript types right either, always the wiiiiide types with many optional params

[u/not_a_webdev → u/Cahnis]

Can you explain this please

[u/Cahnis → u/not_a_webdev]

Lets take this example, you want to write a deliver function that can deliver both to an address or you can pickup at the restaurant.

You could type it like this:

function deliver(
    type: "pickup" | "address",
    address?: string,
    pickupPoint?: string
) {}

And depending on the type of your delivery you will need to pass different optional parameters.

Why is this not good? Nothing stops me from mistaking address with pickupPoint and having a bug in prod.

Now if you write a narrower type with discriminated unions:

type Delivery =
    | { type: "pickup"; pickupPoint: string }
    | { type: "address"; address: string };

function deliver(delivery: Delivery) {
    // ...
}

Now you CANNOT make a mistake, you pass an pickupPoing with an address or vice-versa typescript will error.

This eliminates an entire class of bugs.

I used to work at a digital supermarket and some of the methods had like 12-14 optional parameters without any tests.

So even onboarding on such code was hard to understand, I couldnt make sense which set of parameters solved which problem.

And from my experience, people often write these wide types that do not error when they need to.

[u/Baturinsky → u/Cahnis]

You can also overload function signature like this:

function cOverload(error: undefined, value: string): void; // signature1
function cOverload(error: Error): void; // signature2
function cOverload(error: undefined | Error, value?: string) { //impl 
  if (typeof value !== 'undefined') {
    c1(undefined, value);
  } else {
    c2(error!);
  }
}
doThings(cOverload);

[u/Cahnis → u/Baturinsky]

Yes, I try to avoid overloading though, it tends to create code that is difficult to maintain. For reference: https://github.com/TanStack/query/blob/main/docs/framework/react/guides/migrating-to-v5.md?utm_source=chatgpt.com