JavaScript
A JavaScript question is nearly always a different question underneath: which framework, whether you need types, or what to do about a codebase that grew without boundaries. This page is here to sort out which one you have.
01Overview
What the word covers, and what it does not
JavaScript is the programming language every browser runs, standardized as ECMAScript and updated on a yearly cycle. It also runs outside the browser, most commonly on Node.js. It is a language, not a framework and not an architecture: React, Vue and Angular are libraries written in it, TypeScript is a type system layered on top of it, and none of those choices is settled by the word JavaScript.
02Capabilities
Three places we write it, with different rules in each
Where JavaScript ends up on a project, and why the rules are not the same in each. Two of the three are really decisions that belong on another page, and this section says which.
- Browser
Inside a framework, in the browser
Application code for the browser normally sits inside a framework, and the decision that matters is which one. That decision is about the shape of your interface and the skills of your team, and it lives on the front-end and React pages rather than here.
- Server
On the server
Server-side JavaScript is a back-end service and we hold it to back-end standards: error handling, observability, and a deployment story. See Node.js for how we decide whether it belongs there at all.
- Plain
Plain, with no framework
Progressive enhancement on server-rendered pages, third-party embeds that load on somebody else's site, build and release scripts, and the operational glue in tools like the vehicle inspection and maintenance interfaces we build for automotive. Shipping a framework runtime for these would be absurd.
03Fit
The question underneath the question
The common failure is not picking the wrong tool, it is answering the wrong question. People ask whether to use JavaScript when what they have to decide is whether they need a framework, whether they need types, and where the module boundaries go. Each row names the decision that situation really is, and four of them link to the page that covers it.
| What you have | What that actually calls for |
|---|---|
| A server-rendered page with a few interactive pieces on it | Plain JavaScriptA framework here adds a build pipeline and a runtime to maintain, and buys nothing you can point at afterwards. |
| Real client-side state that several screens have to agree about | Different pageA framework: React, Vue or Angular, decided on your team and your interface rather than on benchmarks. |
| A codebase more than one person edits and refactors | Different pageTypes. Our TypeScript page. Without them every rename becomes a search across the project and a guess. |
| A widget that has to load on other people's pages | Plain JavaScriptDeliberately small, assuming nothing about what else is on the page. A framework is the wrong shape for a guest on somebody else's site. |
| Work that runs on the server | Different pageTreat it as a back-end service, not as more front-end code. Our Node.js page covers when that is the right runtime and when it is not. |
| "Our JavaScript has become unmaintainable" | Fix the boundariesMissing module boundaries, no tests, and often a decade of jQuery underneath. That is a modernization job. |
Scope
Two positions we take from the start. Ecosystem churn is real and mostly avoidable, so we prefer boring, widely used dependencies: every package you add is a supply-chain and an upgrade commitment on somebody else's roadmap. And "JavaScript everywhere" is a staffing convenience rather than an architecture. It is a legitimate reason to pick one runtime for a service, and we weigh it as that rather than as a technical argument. unicrew has been shipping browser and server JavaScript since 2012, under an ISO 27001:2022 certified information-security management system.
04Case studies
A system where these calls were made
One published build where the framework question, the types question and the boundaries question all came up.
See all case studies
05Stack
What it usually sits with
The five decisions this page keeps pointing at, each with a page of its own.
06Questions
What people ask when they are choosing
Answered the way we would answer them live. If yours is not here, it is a good first message.
Not always, and the test is simple: is there state that several parts of the screen have to agree about, and does it change while the user is on the page? If yes, a framework saves you from reinventing it badly. If the page is mostly server-rendered content with a menu, a modal and a form, plain JavaScript with a couple of conventions will outlive any framework choice you make today, and it will load faster.
TypeScript once more than one person is in the code or the product is expected to be refactored, which covers most products. Plain JavaScript is fine for small, single-owner code and for scripts. There is a middle option people forget: keep the files as JavaScript and let the compiler check them with JSDoc types at the boundaries. TypeScript covers how we stage that on an existing codebase.
Yes, and it is a specific discipline rather than normal feature work. We read the code before proposing anything, put tests around the parts we are about to touch so we can tell whether we broke something somebody depends on, and change one boundary at a time. jQuery being in there is not automatically a problem to solve. Legacy modernization covers how we sequence it.
It depends on your team more than on the technology, and anyone who answers this without asking about your team is selling something. Our default for interfaces with substantial client-side state is React, because the hiring pool stays deep and the ecosystem is stable. Where a team is already productive in Vue or Angular, we keep it there, because migrating for its own sake is a cost with no owner.
Three shapes, and which fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based, and we only offer it once the first read is done, because a fixed number on a codebase nobody has opened is a guess with a contract around it. Team extension is billed monthly per engineer. The rate depends on the seniority mix the work needs, so it is quoted rather than listed.
Not sure whether your question is about the language?
Describe the interface and the team, and we will tell you which decision you are actually making. If it is a framework or a modernization decision, we point you at the right conversation, starting with web development.