Hire JavaScript Developers

The strongest argument for JavaScript is not any single framework but the fact that one language covers both ends of a product. Sazinga AdBoard, Factory, Rentals and Comply all share types between their TypeScript services and their front ends, so a change to an API contract fails at compile time rather than in someone’s browser three weeks later.

TypeScript is the language teams actually write; JavaScript is the runtime they still have to understand. Almost every serious defect we see in this stack lives in that gap — the types were correct, the code compiled, and the program did something else at runtime because of an event loop, a cached module, a build flag or a shared helper nobody re-read.

A shared helper is a contract, and contracts drift

Our own contact form ships a small done() helper that finishes a submission: anything under a 400 status redirects the visitor to the thank-you page. Reasonable, until the health endpoint was routed through the same helper and started answering 303 to every monitoring check that was not asking for JSON. The endpoint was correct. The helper was correct. The composition was wrong, and no type in the system was in a position to object.

The fix is not a rule about helpers, it is a habit: when a function’s name describes a user journey rather than a value, treat every new caller as a new specification. The endpoint now answers directly, and returns 503 when its database is unreachable, so a silent fall back to disk storage shows up without anyone reading logs.

The build is part of the program

JavaScript projects are configured in code, which means the configuration can be wrong in exactly the ways code is wrong. A default in our own build script derived the canonical host from an environment variable that fell back to the staging domain — so every build produced that day carried noindex, nofollow and canonical tags pointing at the wrong host. Deploying it would have removed the entire site from search.

Two things came out of that and both are general. Pass such settings as an explicit command-line flag rather than an environment variable, because a flag behaves identically from cmd, PowerShell and bash where an exported variable does not. And check the artefact, not the process — the staged build is now inspected on the server before the swap, and the deploy aborts if the homepage is noindex or the canonical is wrong.

What we interview for

Framework labels are the least useful thing on a JavaScript CV, because the language depth underneath them is what transfers. Four questions do most of the filtering.

• Type an API response that has three legitimate shapes. We are watching for a discriminated union and a narrowing check, not for any with a comment.
• A Node process’s memory keeps climbing over a week. What do you capture, and when.
• A bundle grew by 400KB after a dependency bump. How do you find out what is in it.
• Something works in development and fails in the production build. Name three causes.

Engineers with genuine language depth move between React, Angular and a server codebase in the same week. Framework specialists frequently cannot, and the interview should find that out before the project does.

Where JavaScript is the wrong choice

It is the wrong choice for CPU-bound work. A single-threaded event loop handling a long synchronous computation stops serving everything else, and worker threads recover the throughput at the cost of the shared-memory model that made the language pleasant in the first place. Numerical work, image and video processing and heavy batch transforms belong somewhere else.

It is also the wrong choice where the deployment target rewards a single static binary or a small runtime footprint, and it is a poor fit for teams without the discipline to keep dependencies under control, because the ecosystem’s greatest strength is also how a small utility acquires ninety transitive packages and a supply-chain problem.

The monorepo question, answered honestly

Sharing types between a client and a server removes a real class of bug, and that is the entire argument for a monorepo here. It is not free: one dependency graph means one upgrade decision, and a shared type that changes forces every consumer to be correct at the same moment.

That trade is worth making when the same team owns both ends and deploys them together. It is usually not worth making across teams with independent release cycles, where a generated client from a published contract gives most of the safety and none of the coupling. Anyone who recommends the same answer for both situations has only worked in one of them.