In the browser, JavaScript is not a decision anybody gets to make.
Somebody has told you the system will be written in JavaScript and you want to know what that commits you to. Mostly it commits you to the ordinary thing. A browser runs JavaScript and nothing else, so every screen your staff click through is running it already.
The decision that matters sits one level above the language. Plain JavaScript or TypeScript. A framework, or two hundred lines added to the site you already pay for. Those choices change what the system costs to keep.
JavaScript is the language a web browser runs directly. Anything that happens on a page without the page reloading is JavaScript. The search box that filters as you type, the invoice total that changes when you edit a quantity, the map that moves under your finger. Through Node.js, the same language also runs on servers.
Where it earns its place.
What it is genuinely good at
- Screens that answer without reloading the page
- Adding behaviour to a site or an application that already works
- One language from the screen a clerk uses down to the API behind it
- Small, contained work: a form, a calculator, a chart on an existing page
Where we use it
Everywhere a person looks at a screen, and on the server side often enough that the same developer can follow a field from the form to the database.
- Dashboards and admin panels
- Customer and employee portals
- Forms, filters and search on existing sites
- APIs on Node.js
- React Native apps for Android and iOS
Plain JavaScript, or TypeScript on top of it
TypeScript is the same language with the shape of your data written down. We decide this on the first day. The answer depends on how long the code has to live.
- Plain JavaScript for a script, a prototype, or a page that will not grow
- TypeScript for anything several people will change over years
- Types catch the renamed field before your accounts team finds it
- An existing codebase can take types gradually, one file at a time
Adding types to a working system is not urgent. It becomes worth paying for when the same kind of bug keeps coming back after every release.
The work we do on it
- Screens
- State
- APIs
- Tests
- Bundle size
- Support
- Building the screens and the logic behind them
- Connecting to your APIs and to anything outside
- Automated checks on the parts that would hurt if they broke
- Cutting down how much code the browser has to download
- Taking over and tidying JavaScript another team wrote
The phone your customer actually holds
Your code is downloaded and run on a mid-range Android phone on a patchy connection. It was written on a fast laptop on office wifi. That gap is where most complaints about slow software come from.
- Sending less code to the browser in the first place
- Rendering on the server so the first screen is plain HTML
- Measuring on a real phone, not on a developer machine
When this is the right choice.
- You have a site or an application and want parts of it to answer without reloading
- The team who will keep it afterwards already writes JavaScript
- You want one language across the web app, the API and the mobile app
- The job is a screen or a feature rather than a whole new system
- You are adding to a WordPress, PHP or Laravel site rather than replacing it
When it is not.
- A rule the customer must not be able to change, because anything sent to the browser can be read and edited there
- A large system your own team will hold for years, where plain JavaScript without types gets expensive to change
- Heavy number work, model training or scientific processing, where Python has the tools and the people
- A page that is mostly text, where every extra script makes it slower on an ordinary connection
Questions we are asked about it.
Is JavaScript the same thing as Java?
No. The names are an accident of marketing from the 1990s and the two are unrelated. Java is used mostly for large back-end systems and native Android. JavaScript runs in the browser, and on servers through Node.js.
Should we be using TypeScript instead?
For a system that will live for years, yes, and it is what we start new work in. For a one-off script that will not change again, the extra setup buys little. The question is how many people will edit this code after the people who wrote it have moved on.
Is JavaScript secure enough for a business application?
The language is not what decides that. Anything sent to the browser can be read and changed by whoever opens the page, so the rules that matter are checked on the server every single time. We treat the browser as a screen, never as the place a permission is decided.
Can you work on JavaScript somebody else wrote?
Yes, and a good part of our work is exactly that. We read it, get it building again, add the checks that are missing, then change it. Rewriting is a decision we would rather put to you with reasons than take quietly.
Our site feels slow. Is JavaScript the reason?
Sometimes, and it is worth measuring before anybody rewrites anything. Slowness usually comes from the amount of code the browser downloads, from images, or from an API that takes seconds to answer. Each has a different fix and only one of them is the language.
Do we need a framework like React at all?
Not always. A handful of interactive pieces on an otherwise ordinary site can be plain JavaScript, and that is cheaper to keep. A framework starts paying when the same pieces appear on thirty screens and have to behave identically.
Services that use it.
What it sits with.
Not sure JavaScript is the right choice?
Tell us what the software has to do and who opens it. If something else fits better, we will say so, and say why.
- No obligation
- We reply the same working day
- Your details stay private