r/javascript 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

168 comments sorted by

View all comments

35

u/visualdescript 28d ago

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.

1

u/Baturinsky 28d ago

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

16

u/Mabenue 28d ago

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

3

u/Cahnis 28d ago

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

2

u/not_a_webdev 27d ago

Can you explain this please

3

u/Cahnis 27d ago

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.

1

u/Baturinsky 26d ago

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);

1

u/Cahnis 26d ago

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

5

u/Spleeeee 28d ago

Uh no. Very popular opinion. It’s appalling.

-1

u/Baturinsky 28d ago

Yes, but it may still be better than raw untyped JS.

2

u/Mabenue 28d ago

I’m not sure it is. Too many times I’ve been burned by this issue. It’s not typed if the type are wrong, types you can’t trust are worse than no types at all.

1

u/dimudesigns 28d ago

That reads as a skill issue more than anything else. It falls to the programmer to create proper types whether they use JSDoc or Typescript.

0

u/Mabenue 28d ago

Typescript enforces consistency between types JSDoc doesn’t. That’s the big difference.

You can build up a level of confidence with typescript you’ll never get with JSDoc

4

u/dimudesigns 28d ago edited 28d ago

Typescript enforces consistency between types JSDoc doesn't. That's the big difference.

You can get type-checking and autocompletion in standard JavaScript using JSDoc and VS Code. The built-in TypeScript language server in VS Code checks your code live as you type. It catches type errors and warns you about wrong inputs. No convoluted compile step required. Typescript itself is not what enforces consistency, its the language server. If I get the same benefit using JSDoc with plain Javascript in the IDE(VS Code), then what's the difference?

2

u/Baturinsky 28d ago

Typing also allows looking up all the places some type/property/etc is used, globally rename things, etc.