The Practical Developer

Two visitors open the same bookshop page a minute apart. The first one buys the last copy of a title. The second visitor's page still says one copy is in stock, because the data was fetched once at load and never checked again. She clicks buy, and the order fails at checkout. That gap is the problem TanStack Query is built for. Data from a server is not like the state inside your app. It lives somewhere else, it changes without telling you, it can fail to arrive, and a copy fetched five minutes ago may be wrong. TanStack Query keeps a cache of that server data, refetches it when it goes stale, and retries when a request fails. What I would check before using it My judgement is that TanStack Query earns its place the moment two parts of an app need the same server data, or one screen needs that data to stay fresh. A single fetch on a page that never changes does not need it; a plain fetch inside useEffect does that job with less to learn. The value shows up when the same book li...

A small shop's checkout script starts as twenty lines in one file, then three developers edit it. One prefers single quotes, another double quotes. One writes two-space indents, another tabs, and a third leaves a half-finished discount variable behind after a refactor. Nothing is broken: the script runs and the totals are right. But every pull request now carries an argument about style, and real problems, like that unused variable, hide in the noise. Two tools usually police this: a linter for mistakes and a formatter for style, each with its own config. Biome folds both jobs into one binary, and this post puts that claim to the test on a real file. What I would check before using it My judgement is that Biome is worth trying once more than one person touches the JavaScript, because that is when style arguments start costing review time. First, I would check whether one tool can cover the rules you rely on. Biome ships with a linter and a formatter in one package, so there is ...

A customer fills in a checkout form and picks two ceramic mugs and a linen tote. Somewhere between the form and the server, the quantity turns into the string "2" instead of the number 2. TypeScript does not catch it, because TypeScript checks code before it runs, not data arriving while the program is live. The server adds the quantity to the total and the maths produces nonsense, or the order saves with a quantity nobody can fulfil. The bug is not in the form or in the maths. It is in the gap between what the code expects and what actually arrives. Zod closes that gap: describe the shape of the data once, and check every order against it. What I would check before using it My judgement is that Zod is worth adding the moment your code receives data it did not create: a checkout form, a webhook from a payment provider, a response from another team's API. At a boundary, types are only a promise, and Zod is the check that the promise holds. The first thing I would check i...

A small bookshop wants an API. Customers should be able to list the books and place an order, and the shop owner wants it live this week on a cheap host. Next month she might move it to a Node server or a serverless host that charges per request. Most frameworks are tied to one runtime, so the usual answer is to write the API once and rewrite it when the host changes. The routes and validation stay the same; only the plumbing changes. Hono exists for exactly this situation. It is a tiny web framework that runs the same code on Node, Cloudflare Workers, Deno, and Bun, so the API stays put when the host changes. What I would check before using it My judgement: reach for Hono when the API is small and you are not sure where it will run. A bookshop API, a webhook receiver, or a small service in front of a database are the honest cases. The code stays short, and moving from Node to a serverless host means changing the adapter, not the routes. If the API will live on one Node server foreve...

A customer adds a ceramic mug to their basket on a small shop's website, then waits. The order page says Processing, and nothing changes until they refresh. The server knew the order shipped ten minutes ago, but the page had no way of hearing about it. The usual fix is polling: the page asks the server "anything new?" every few seconds. Most of those requests get the answer "no", yet each one opens and closes a connection for nothing. WebSockets exist for exactly this gap. One connection stays open, the server pushes a message the moment something changes, and the page updates without asking again. The question is whether your page needs a live wire at all. A WebSocket starts as an ordinary HTTP request that asks the server to upgrade the connection. If the server agrees, that same connection stays open for two-way messages, and either side can send at any time. That is the whole idea. The rest of this post is about deciding when that open connection earns its ...

You change one line in the checkout code, a discount that should only apply above fifty dollars, and now you need to know whether anything else broke. The honest answer is that you do not know, and guessing costs more than checking. Running the shop by hand means adding items to the cart, applying the code, and doing the maths yourself, every single time you change anything. A test runner takes that job over. Vitest watches your files, reruns the checks the moment you save, and tells you in under a second whether the totals still add up. This post sets it up on a small shop cart, breaks one test on purpose, and fixes it. What I would check before using it My judgement is that Vitest is the right default when the project already runs on Vite, and a good choice for most new JavaScript and TypeScript projects besides. If your front end builds with Vite, Vitest reuses the same config, the same plugins, and the same module handling, so setup is quick. Its test API will also feel familia...

Ayesha manages a small online shop. Each morning she checks yesterday's paid orders and marks parcels ready to ship. Her dashboard talks to a small Node.js API, and every request has to answer one question first: is this really Ayesha? The usual answer is a session stored on the server, but that means a database lookup on every request, and it breaks when the API grows a second server. A JSON Web Token, a JWT, answers the same question without the lookup. The token carries who the caller is, and the server checks the token's signature instead of asking a database. This post builds that check with nothing but Node.js built-in crypto, and shows where it breaks if you use it carelessly. What I would check before using it My judgement, from building small APIs for years, is this: a JWT is the right call when several services need to check who is calling without sharing a database, and the wrong call when you need to cancel access instantly. The first check is revocation. A token ...

Some of the most used desktop apps, VS Code, Slack, Discord, and the Figma desktop app among them, are not written in native desktop languages at all. They are web apps wrapped in Electron, a framework that lets developers build desktop software with HTML, CSS, and JavaScript. One codebase, three operating systems, and a team that already knows web development: that combination explains Electron's spread, and also its controversies, because every Electron app ships its own browser and its own Node runtime, and users notice the size and the memory. Electron apps have two kinds of process. The main process, one per app, runs Node.js and owns the operating system side: windows, menus, file access, and the system tray. Each window runs a renderer process, essentially a Chromium browser tab, that displays the HTML interface and runs the frontend code. The two talk through inter-process communication, or IPC: the renderer asks, for example to open a file dialog, and the main process acts...

An online shop sells a water bottle, and the product page shows one photo from the front. Customers cannot see the back, cannot judge the size, and cannot tell how the cap works, so they ask questions, or they buy elsewhere. A spinning 3D model would answer all of it, but the web is flat by default: HTML and CSS lay out rectangles, and the browser's low-level 3D API, WebGL, takes hundreds of lines to draw a single cube. That is the gap Three.js closes. It wraps the graphics pipeline in friendly concepts, scenes, cameras, lights, and meshes, so a developer can build a 3D product viewer or a data visualisation in an afternoon instead of a month. A minimal scene follows the same pattern every time: create a scene, add a mesh, add a light, point a camera at it, and animate it in a loop, each frame rotating the mesh slightly so it appears to move. That loop is the heartbeat of every Three.js app. What I would check before using it My judgement, from building web pages and watching 3D...

It is the end of the month, and a studio needs one number per client: how much was paid, and how much is outstanding. The invoices sit in a JSON file and the script to total them is thirty lines, yet the job needs a toolchain: TypeScript compiled or run through a loader, a separate test runner, a build step for a script that reads one file. That gap is what Bun is aimed at: it runs JavaScript and TypeScript, with no compile step, and bundles a package installer, a test runner, and a server into one binary. The question is whether one tool doing four jobs makes your scripts simpler, or just moves the complexity out of sight. What I would check before using it My judgement, from running small scripts and services on Node for years, is this: Bun is a good fit for scripts, command line tools, and small servers where startup time and a short setup matter. A thirty line invoice report, a file watcher, a webhook receiver, or a local API for a demo are exactly the jobs where Bun shines, bec...

A nightly script reads a file of orders, adds up the paid ones, and writes a summary for the morning. In Node that script runs with full access to the disk, the network, and every environment variable, and so does every dependency it imports. Nothing asks first. Deno starts from the opposite assumption: a script gets nothing until you grant it, file by file and host by host. That single difference is the whole pitch. Deno is a JavaScript and TypeScript runtime built by the same person who created Node, as a second attempt with the lessons learned. The question is whether the stricter model and the built-in TypeScript are worth changing runtimes for. What I would check before using it My judgement, from years of building web applications, is this: Deno is the better runtime for new scripts, command line tools, and small services, and the wrong move for a large existing Node codebase. Five checks. First, the job. A script that reads files and writes a report is the ideal Deno program, ...

A shop page lists forty orders. The owner wants the unpaid rows highlighted, the paid total shown at the bottom, and a button that hides the paid ones. In plain JavaScript that job is a loop, a class toggle, a running total, and a click handler, spread across twenty lines that each do one small thing. jQuery shrinks it to a few lines: pick the rows with a selector, add a class, add up the numbers. That is why it spread so fast in the late 2000s, and why it turns up in older codebases today. The question is not whether jQuery works. It does. The question is whether a new project in 2026 should still reach for it. What I would check before using it My judgement, from years of building and reviewing web applications, is this: jQuery is the right tool for keeping an existing site running, and a reasonable one for a simple page, but the wrong starting point for a new application. I would check five things before deciding. First, the codebase. If the site already uses jQuery in dozens of p...