DEV Community: javascript

How GSTIN Checksum Validation Works (and Why It Isn't Enough)

Tarun Vaghasia — Sat, 08 Aug 2026 07:34:14 +0000

Every Indian GST invoice carries a 15-character GSTIN. If you've ever had to validate one in code, you've probably written a regex like this and called it done:

/^[0-9]{2}[A-Z]{5}[0-9]{4}[A-Z]{1}[1-9A-Z]{1}Z[0-9A-Z]{1}$/

That regex checks the shape of a GSTIN. It says nothing about whether the number is real. A typo that happens to land on a syntactically valid string will sail straight through it — and if that typo ends up on an invoice, it's the kind of thing that gets flagged months later during a GST audit.

There's a cheap next step before you go anywhere near a network call: the GSTIN has a built-in checksum character, and you can verify it in a few lines with no API and no dependency.

How the checksum works

A GSTIN is 15 characters: 33AAACC1206D1ZN. The first 14 encode the state code, the business's PAN, and an entity number. The 15th is a checksum digit computed from the other 14, using a 36-character alphabet (0-9 then A-Z) and alternating weights of 1 and 2 — the same family of algorithm as ISO 7064 MOD 37-36.

const ALPHABET = '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ';

function gstinChecksumIsValid(gstin) {
  if (!/^[0-9A-Z]{15}$/.test(gstin)) return false;

  let sum = 0;
  let factor = 1;
  for (let i = 0; i < 14; i++) {
    const codePoint = ALPHABET.indexOf(gstin[i]);
    const digit = factor * codePoint;
    sum += Math.floor(digit / 36) + (digit % 36);
    factor = factor === 1 ? 2 : 1;
  }
  const checksumIndex = (36 - (sum % 36)) % 36;
  return ALPHABET[checksumIndex] === gstin[14];
}

gstinChecksumIsValid('33AAACC1206D1ZN'); // true
gstinChecksumIsValid('33AAACC1206D1ZM'); // false — last char changed

I hand-verified this against a real, currently-registered GSTIN (Central Warehousing Corporation, 33AAACC1206D1ZN) before trusting it enough to write this post — the algorithm above reproduces the N checksum character exactly.

Python, same logic:

ALPHABET = '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ'

def gstin_checksum_is_valid(gstin: str) -> bool:
    import re
    if not re.match(r'^[0-9A-Z]{15}$', gstin):
        return False

    total = 0
    factor = 1
    for ch in gstin[:14]:
        code_point = ALPHABET.index(ch)
        digit = factor * code_point
        total += digit // 36 + digit % 36
        factor = 2 if factor == 1 else 1

    checksum_index = (36 - total % 36) % 36
    return ALPHABET[checksum_index] == gstin[14]

Drop this in ahead of any network call. It rejects a huge class of typos and malformed input for free, in constant time, offline.

What a checksum can't tell you

A checksum only proves the string is internally consistent — that it could plausibly be a GSTIN. It doesn't tell you:

whether that GSTIN is actually registered
whether the registration is still active, or was cancelled
what legal name it's registered under, so you can catch a mismatch against the invoice

You can construct a string that's checksum-valid and still refers to nobody, or to a business whose registration was cancelled last year. For that you need to ask the actual GST network, which means an API call.

That's the part I build: gstinapi.in is a REST API that takes a GSTIN and returns the legal name, registration status, taxpayer type and registered address, live from India's official GSP network — no scraping, no cached copy.

const { GstinApi } = require('gstinapi'); // npm install gstinapi

const client = new GstinApi({ apiKey: process.env.GSTIN_API_KEY });
const result = await client.lookup('33AAACC1206D1ZN');

console.log(result.data.legal_name); // CENTRAL WAREHOUSING CORPORATION
console.log(result.data.status);     // Active

from gstinapi import GstinApi  # pip install gstinapi

client = GstinApi(api_key=os.environ["GSTIN_API_KEY"])
result = client.lookup("33AAACC1206D1ZN")

print(result["data"]["legal_name"])  # CENTRAL WAREHOUSING CORPORATION
print(result["data"]["status"])      # Active

Every account gets 100 free lookups a month, no credit card, and it renews every month rather than being a one-time trial credit — plenty to validate the idea before you need volume.

Source for the client libraries: gstinapi-node and gstinapi-python. Full API reference is at gstinapi.in/docs.

If you build GSTIN validation into something, I'd like to hear where the checksum check alone was enough and where you actually needed the live lookup — drop it in the comments.

The Evolution of Scientific Computing: Why Developers Still Need Dedicated Calculators

Study HUB — Sat, 08 Aug 2026 07:10:09 +0000

As developers, we are surrounded by immense computational power. When we need to solve a math problem, our first instinct is often to fire up a Python REPL, open the Node.js terminal, or simply type Math.sin(90) into the browser's developer console. We build complex algorithms, design neural networks, and render 3D environments. Yet, despite having entire programming ecosystems at our fingertips, there is still a massive, undeniable need for a dedicated, accessible scientific calculator.
Why? Because context switching is the enemy of productivity, and raw programming languages don't always offer the immediate, visual feedback required for complex mathematical modeling.
The Hidden Complexity of Developer Math
Whether you are programming a physics engine for a new web game, calculating CSS transform matrices, or designing algorithmic trading bots, advanced mathematics is baked into the fabric of software engineering.
However, doing complex trigonometry or logarithm calculations in a raw terminal can be frustrating. You have to remember language-specific syntax, manage nested parentheses meticulously to respect the Order of Operations (PEMDAS/BODMAS), and deal with the notorious IEEE 754 double-precision floating-point format. We’ve all seen the classic 0.1 + 0.2 = 0.30000000000000004 quirk. When you are trying to verify the orbital mechanics of a simulation or the attenuation of a signal in a telecommunications app, you need a tool that handles the math cleanly and visually.
Enter the Dedicated Online Scientific Calculator
This is where having a reliable, browser-based mathematical tool becomes a game-changer. Rather than writing a script to double-check your formula, you can use a purpose-built application.
Recently, I came across the highly efficient Scientific Calculator by StudyHUB. Engineered specifically as a free open educational resource, this tool bridges the gap between raw computing and user-friendly mathematics.
Unlike basic desktop calculators, StudyHUB’s Scientific Calculator provides a fully responsive web interface packed with advanced computational capabilities. It allows you to step away from your IDE for a moment and visually construct your equations.
Features That Make a Difference
When evaluating an online scientific calculator for professional or academic use, there are a few non-negotiable features that StudyHUB nails perfectly:
Radian and Degree Toggles: If you've ever spent hours debugging a graphics rendering issue only to realize your Math library uses radians while your brain was calculating in degrees, you know this pain. A one-click toggle eliminates this cognitive load.
Advanced Trigonometry & Logarithms: Full support for hyperbolic functions (sinh, cosh, tanh), natural logarithms (ln), and inverse functions natively mapped to an intuitive UI.
Memory Registers: The inclusion of MC, MR, M+, and M- functions allows developers to store intermediate variables without needing to write them down or hold them in a clipboard.
Platform Agnostic: Because it is built as a lightweight web tool, it works flawlessly whether you are on a multi-monitor desktop setup or quickly checking a formula on your smartphone during a meeting.
A Tool for the Modern STEM Professional
While we will always rely on our code to execute math at scale, verifying the logic behind that code requires a different set of tools. Dedicated scientific calculators act as the sandbox where we can test our fundamental mathematical assumptions before translating them into syntax.
If you are a computer science student working through discrete math, or a seasoned developer fine-tuning a complex CSS animation curve, bookmarking a reliable tool is a must. Check out the StudyHUB Scientific Calculator and keep it in your developer toolkit. It’s fast, accurate, and completely free—exactly what the modern web demands.

You built your modal with a `
` and a focus trap library. The native `` does all of that.

Parsa Jiravand — Sat, 08 Aug 2026 07:00:10 +0000

Building a modal from scratch means writing the same boilerplate every time: a <div> with role="dialog", an aria-modal attribute, a tabindex="-1" to steal focus, a keydown listener to catch Escape, a focus-trap library to keep Tab cycling inside the dialog, and a click listener on the backdrop overlay you rendered yourself. It works, but you're doing the browser's job.

The <dialog> element exists to take that job back.

The baseline API

<dialog id="confirm-dialog">
  <h2>Delete item?</h2>
  <p>This cannot be undone.</p>
  <button id="cancel-btn">Cancel</button>
  <button id="confirm-btn">Confirm</button>
</dialog>

<button id="open-btn">Delete</button>

const dialog = document.getElementById('confirm-dialog');
const openBtn = document.getElementById('open-btn');
const cancelBtn = document.getElementById('cancel-btn');
const confirmBtn = document.getElementById('confirm-btn');

openBtn.addEventListener('click', () => dialog.showModal());
cancelBtn.addEventListener('click', () => dialog.close());
confirmBtn.addEventListener('click', () => {
  deleteItem();
  dialog.close();
});

That's it. The browser handles focus trapping (Tab stays inside), Escape-to-close, and ARIA role. No library. No keydown listener. No backdrop div.

`showModal()` vs `show()`

The element has two open methods and they are meaningfully different.

dialog.show() opens the dialog as a non-modal: it's visible, but the rest of the page is still interactive. Useful for inline panels, drawers, or toasts — not for blocking confirmation flows.

dialog.showModal() opens it as a modal: the browser places the dialog in the top layer — above all other content, including elements with high z-index — and blocks interaction with everything beneath. Focus is trapped inside. Escape closes it. This is what you actually want for a modal dialog.

dialog.show();      // non-modal — rest of page still interactive
dialog.showModal(); // modal — top layer, focus trapped, Escape works

Styling the backdrop

When opened with showModal(), the browser renders a backdrop behind the dialog and above the rest of the page. You style it with the ::backdrop pseudo-element:

dialog::backdrop {
  background: rgb(0 0 0 / 50%);
  backdrop-filter: blur(4px);
}

No more position: fixed; inset: 0; background: rgba(0,0,0,0.5) divs. The browser-rendered backdrop is always in the right place, covers the right things, and is animated by the dialog's own open/close transitions.

Animating open and close

The <dialog> element pairs naturally with @starting-style for entry animations. For the exit, you need a small JS helper because the dialog's close() method removes the open attribute before a CSS exit transition can play:

dialog {
  opacity: 0;
  transform: scale(0.95);
  transition: opacity 200ms, transform 200ms, display 200ms allow-discrete;
}

dialog[open] {
  opacity: 1;
  transform: scale(1);
}

@starting-style {
  dialog[open] {
    opacity: 0;
    transform: scale(0.95);
  }
}

With allow-discrete on the display transition (Chrome 117+), the browser holds the dialog in the layout for the duration of the exit transition before hiding it. For older targets, a small setTimeout before dialog.close() is the reliable fallback.

Handling backdrop clicks to close

The backdrop is not a separate element you can listen to directly. The reliable pattern uses the dialog's own click event and checks whether the click landed inside the dialog's bounding box:

dialog.addEventListener('click', (event) => {
  const rect = dialog.getBoundingClientRect();
  const clickedOutside =
    event.clientX < rect.left ||
    event.clientX > rect.right ||
    event.clientY < rect.top ||
    event.clientY > rect.bottom;

  if (clickedOutside) dialog.close();
});

The reason this works: when you click the backdrop, the <dialog> element itself receives the event — the click target is the dialog, not an element inside it. The bounding box check distinguishes backdrop clicks from content clicks cleanly.

Return value from `close()`

dialog.close() accepts an optional string argument that becomes the dialog's returnValue. This lets you communicate why the dialog closed without external state:

confirmBtn.addEventListener('click', () => dialog.close('confirmed'));
cancelBtn.addEventListener('click', () => dialog.close('cancelled'));

dialog.addEventListener('close', () => {
  if (dialog.returnValue === 'confirmed') deleteItem();
});

The close event fires whenever the dialog closes — via close(), Escape, or a <form method="dialog"> submission. Combined with returnValue, it gives you a clean interface for confirmation flows without threading state through callbacks.

The `<form method="dialog">` shortcut

If you put a <form method="dialog"> inside a <dialog>, any submit button closes the dialog automatically and sets returnValue to the button's value attribute — no JavaScript needed for the close logic:

<dialog id="confirm-dialog">
  <form method="dialog">
    <h2>Delete item?</h2>
    <button value="cancelled">Cancel</button>
    <button value="confirmed">Confirm</button>
  </form>
</dialog>

dialog.addEventListener('close', () => {
  if (dialog.returnValue === 'confirmed') deleteItem();
});

The form doesn't submit to a server — method="dialog" is a special value that routes the submission back to the dialog element itself. Useful for simple flows; for complex forms with validation, you'll still handle submission explicitly.

Browser support

<dialog> is Baseline 2022: Chrome 98, Firefox 98, Safari 15.4. Global support is above 95%. You do not need a polyfill for production today. The only missing piece in some older browsers is ::backdrop styling — the functional modal behavior (focus trap, Escape, top layer) is universally supported.

🎮 Try it yourself

▶️ Open the interactive playground →

Runs right in your browser — poke at it and watch the concept react live.

🧠 Test yourself

Think it clicked? Take the 8-question quiz →

Instant feedback, a hint on every question, and an explanation for each answer — right or wrong.

The takeaway

Search your codebase for role="dialog" and the focus-trap imports that live near it. Each one is a candidate for replacement: <dialog> with showModal() handles focus trapping, Escape, backdrop, and ARIA semantics — a library bought you those because the platform didn't provide them. It does now. Start with the simplest confirmation dialog in your UI, replace it with <dialog> and showModal(), and you'll notice what disappears: the keydown listener, the backdrop div, the z-index war, and the focus-management ceremony. What remains is the logic that was actually yours to write.

Thanks for reading! Let's stay connected:

⭐ GitHub — follow me and star the projects: github.com/parsajiravand
💬 Discord — join the frontend best-practices community: discord.gg/d9KRhuAwQ
📸 Instagram — frontend best practices, daily: @bestpractice___
💼 LinkedIn — linkedin.com/in/parsa-jiravand
✉️ Email (work & contract inquiries): bestpractice2026@gmail.com

Stop importing `uuid`. `crypto.randomUUID()` has been native since 2021.

Parsa Jiravand — Sat, 08 Aug 2026 07:00:09 +0000

The uuid npm package is one of the most downloaded libraries in the JavaScript ecosystem. The vast majority of those installs exist for one thing: uuid/v4, which generates a random unique identifier in the standard xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx format. The browser — and Node.js — have been doing this natively since 2021. No package needed.

The native API

const id = crypto.randomUUID();
// "110e8400-e29b-41d4-a716-446655440000"

That's the entire API surface. One call, no constructor, no configuration. It returns a v4 UUID string — the same format every UUID library produces, the same format your database expects.

crypto.randomUUID() lives on the Web Crypto API's crypto object, which is globally available in browsers, Node.js, Deno, Bun, and Cloudflare Workers. No import required.

Why it's safe to trust

The uuid/v4 package generates UUIDs using crypto.getRandomValues() internally — the same source crypto.randomUUID() uses. Both draw from the operating system's CSPRNG (cryptographically secure pseudorandom number generator). The native method adds nothing risky; it's the same primitive, one level closer to the metal.

// What uuid/v4 does internally (simplified):
function v4() {
  const bytes = crypto.getRandomValues(new Uint8Array(16));
  // ... set version and variant bits, format as string
  return formatted;
}

// What crypto.randomUUID() does:
const id = crypto.randomUUID(); // same operation, no library

The security profile is identical. The library adds no cryptographic benefit over the native call.

Where it works

crypto.randomUUID() is available in any secure context — HTTPS pages, localhost, Service Workers, Web Workers, and Node.js 14.17+.

// In a Service Worker
self.addEventListener('fetch', event => {
  const requestId = crypto.randomUUID();
  console.log(`[${requestId}] ${event.request.url}`);
});

// In a Web Worker
// Inside worker.js:
const taskId = crypto.randomUUID();
postMessage({ taskId, status: 'started' });

The "secure context" requirement is the only constraint. If your page is served over HTTPS (or you're on localhost), crypto is available everywhere the JavaScript runtime runs in that page — main thread, workers, service worker included.

Replacing the import

A direct swap, wherever you currently use uuid:

// Before
import { v4 as uuidv4 } from 'uuid';
const id = uuidv4();

// After
const id = crypto.randomUUID();

The output format is identical. Whether you're generating IDs in a React component, a route handler, a database model, or a logging utility — it's a one-line change per call site. Once every call is replaced, you can remove the dependency from package.json.

The one case where you still need a library

crypto.randomUUID() generates v4 UUIDs only — random, no namespace. If you need:

v5 UUIDs (namespace + name, SHA-1 hash based): still use uuid/v5
v3 UUIDs (namespace + name, MD5 hash based): still use uuid/v3
Parsing or inspecting UUID bytes, version bits, or variant: still use the library

If you're generating a unique ID for a database row, a request trace ID, a session token, or a UI list item key — v4 is the right choice. That's exactly what crypto.randomUUID() gives you.

Browser support

crypto.randomUUID() is Baseline 2022: Chrome 92 (July 2021), Firefox 95 (November 2021), Safari 15.4 (March 2022), Node.js 14.17 (May 2021). It has been in every supported browser and server runtime for years. There's nothing to polyfill for any currently-maintained target.

🎮 Try it yourself

▶️ Open the interactive playground →

Runs right in your browser — poke at it and watch the concept react live.

🧠 Test yourself

Think it clicked? Take the 9-question quiz →

Instant feedback, a hint on every question, and an explanation for each answer — right or wrong.

The takeaway

Open your package.json. If uuid is listed and your codebase only uses v4, remove it. Search for uuid/v4, uuidv4(), or import { v4 } and replace each call with crypto.randomUUID(). You get the same string format, the same randomness quality, and zero added bundle weight. For v4 UUIDs — the most common case by a wide margin — the native method is strictly better than the library it replaces.

Thanks for reading! Let's stay connected:

⭐ GitHub — follow me and star the projects: github.com/parsajiravand
💬 Discord — join the frontend best-practices community: discord.gg/d9KRhuAwQ
📸 Instagram — frontend best practices, daily: @bestpractice___
💼 LinkedIn — linkedin.com/in/parsa-jiravand
✉️ Email (work & contract inquiries): bestpractice2026@gmail.com

Building an accessible Nigerian restaurant landing page with vanilla JavaScript and hand-drawn SVG

Benjamin Fadina — Sat, 08 Aug 2026 06:59:16 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing

What I Built

Iya Bashirat Restaurant is a landing page for a fictional Nigerian restaurant
at 56 Ajayi Crowther Street, Victoria Island, Lagos.

Iya Bashirat has been cooking on the same street since 1998. Victoria Island grew
up around her: glass towers, banks, traffic that does not move. She is still
pounding yam by hand at 6am because a machine makes it gummy. That is the comfort
food I wanted. Not a trend, just a woman who never changed the recipe.

The menu is seventeen real Nigerian dishes: party jollof, abula, ofada and
ayamase, egusi with pounded yam, suya, asun, catfish pepper soup, moi moi, puff
puff, chapman, zobo, kunu aya. Each one carries its Yoruba name, a heat rating,
allergens and dietary tags.

Built with vanilla HTML, CSS and ES modules. No framework, no build step, and
not a single network request. No CDN, no web font, no analytics, no map embed,
no images. Every dish, the portrait of Iya Bashirat at the fire, and the
neighbourhood map are hand-drawn inline SVG.

What it does:

A menu that actually works as a tool. Filter by course, filter by dietary need, search across names/descriptions/allergens, sort by price or by heat. Every dish opens a detail dialog with serving size, allergens and heat level.
An order tray that hands off to WhatsApp, because that is how a Lagos restaurant genuinely takes orders. Quantities, pickup or delivery, a note for the kitchen, and it survives a page reload. No payment, no backend, no pretending.
Opening hours computed in Africa/Lagos, not in your timezone. The badge says "Open now", "Closing soon" or "Closed", the hours table marks today, and the reservation form generates its time slots from that same data, so you physically cannot request a table for a night the kitchen is shut.
Reservation form with progressive validation, a review carousel, scroll-spy navigation, light/dark theming, and toasts.

Demo

Source: https://github.com/benjaminsqlserver/food-front-end (MIT licensed)

The Order on WhatsApp buttons open a new tab, which CodePen's sandboxed
preview sometimes blocks. Open the Pen in its own tab to try the full
hand-off. The order message is composed either way.

The Pen is not a flattened copy. CodePen gives you one JS pane, and this is 17
modules wired by 40 relative imports. Instead of stripping every
import/export and hand-ordering the dependency graph, the Pen loads the real
files from the repository over jsDelivr, pinned to a git tag. main.js resolves
its own relative imports against the CDN exactly as it does when served locally.
Nothing is bundled, minified or rewritten.

Journey

I went in treating accessibility as a build constraint rather than an audit at
the end, and it changed most of my architecture decisions.

Native <dialog> instead of a hand-rolled modal. All three modals use
showModal(), which gives focus trapping, Escape-to-close, background inertness
and the top layer for free. Every one of those I would have got subtly wrong by
hand. The only thing it does not give you is an exit animation, since close()
pulls the element out of the top layer instantly. So I drive an .is-open class
and defer the real close() until the transition ends.

The filter chips are real radios and checkboxes. I nearly built them as
aria-pressed buttons. Using real form controls meant grouping, arrow-key
navigation and state announcement all came from the platform. But it exposed a
trap I had not thought about: the common .visually-hidden utility has a
:not(:focus) guard so skip links can reveal themselves, which means a hidden
radio pops back into the layout the moment someone tabs to it. Hidden form
controls need unconditional clipping, with the focus ring drawn on the label.

Contrast checking caught the thing I was proudest of. I wrote a script to
check every foreground/background pair in both themes. Everything passed except
my WhatsApp buttons: white on WhatsApp's own #25D366 is 2.2:1, nowhere near
AA. Their brand colour is inaccessible as a button fill. I darkened it to
#12803f, which still reads as WhatsApp, hits 5.0:1 with white, and still clears
3:1 as a shape against both page backgrounds.

Autoplay you can actually defend. The review carousel never starts under
prefers-reduced-motion, pauses on hover and on focus, stops in a background
tab, and always shows a visible pause control. The scrolling ribbon under the
hero stops dead and reflows to a static wrapped list when reduced motion is on.

Anchor links move focus, not just the viewport. Clicking "Menu" scrolls you
there and hands focus to the section, so the next Tab continues from where your
eye already is. It is three lines of code and almost nobody does it.

Since I had no browser automation available, I verified by writing tests: a
selector audit that proves every #id, data-* hook, aria-describedby target
and <use href> resolves; a 62-assertion jsdom suite that boots the real
modules and drives filtering, sorting, the tray totals, reservation validation and
the carousel; 19 assertions pinning the Lagos timezone logic to fixed UTC
instants; a structural accessibility audit; and the contrast check. All green.

The part I am happiest with is the artwork. Drawing seventeen dishes as SVG by
hand took longer than anything else, but it means zero image requests, zero layout
shift, perfect sharpness at any size, and the whole page still weighs less than
one photograph of a plate of jollof.

Iya Bashirat is fictional. The address, phone number, handles and reviews are
invented for this challenge, and nothing on the page contacts a real business.

Code is MIT licensed.

Making Online Registration Easier for Small Business Users

Rahul Deka — Sat, 08 Aug 2026 06:44:54 +0000

Explain that many small-business owners struggle with online registration forms because of unfamiliar terms, long forms, unclear classifications, and fear of entering something incorrectly.

Use simple language
Discuss why government or business terminology should be explained in words ordinary users understand.
Make activity selection easier
Explain the difficulty users have when choosing NIC codes and why search, examples, descriptions, and clear categories improve the experience.
Show important information before the form
Mention that users should know which details they need before starting instead of discovering requirements halfway through.
Design for mobile users
Explain the importance of readable text, clear buttons, simple navigation, and forms that work properly on smaller screens.
Make private and official services clear
Explain why websites should clearly distinguish private assistance from official government services. This improves user trust and prevents confusion.
Give users helpful resources
Here you can naturally mention your real project in your own words:

While working with Instant Udyam, I have seen how useful clear NIC-code information and step-by-step guidance can be for small-business users.

Then, if you are publishing under an Instant Udyam DEV organization and the link genuinely supports the discussion, you can reference:

Node.js Has a Test Runner Now: Field Notes on Dropping Jest for Scripts and Libraries

Ahmed Mahmoud — Sat, 08 Aug 2026 06:32:54 +0000

Headline: Node.js ships a built-in test runner — node --test executes node:test files with no Jest, no Vitest, and no config file — and paired with type stripping it runs .ts tests with zero build. I moved my scripts and small libraries onto it: node:test for structure, node:assert/strict for assertions, the built-in mock for spies and fake timers, and --experimental-test-coverage for coverage. I kept Vitest for anything that touches the DOM or renders React.

Key takeaways

The Node.js test runner lives in the built-in node:test module and runs with node --test; it needs no dependency, no config file, and has been stable since Node.js 20.
Assertions come from the built-in node:assert module — import node:assert/strict so assert.equal uses strict (===) comparison.
The mock object from node:test gives you mock.fn(), mock.method(), and mock.timers without a separate mocking library; module mocking via mock.module() is still experimental.
Combined with type stripping, node --test "src/**/*.test.ts" runs TypeScript tests with no build step on Node.js 22.18+ and Node.js 24.
Coverage is available behind --experimental-test-coverage, and output format is chosen with --test-reporter (spec, tap, dot, junit, lcov).

Can Node.js run tests without Jest or Vitest?

Yes — Node.js has a built-in test runner, and it needs zero dependencies. The runner is the node:test core module, invoked with node --test; it landed experimentally in Node.js 18 and became stable in Node.js 20. It auto-discovers test files, runs each in its own child process for isolation, and reports in a TAP-based format.

// math.test.ts
import { test } from 'node:test';
import assert from 'node:assert/strict';
import { add } from './math.ts';

test('add sums two numbers', () => {
  assert.equal(add(2, 3), 5);
});

Run it with node --test. No jest.config.js, no transform, no ts-jest.

How do I structure tests with node:test?

node:test exports test, plus describe/it and the hooks before, after, beforeEach, afterEach.

import { describe, it, beforeEach } from 'node:test';
import assert from 'node:assert/strict';

describe('Cart', () => {
  let cart: Cart;
  beforeEach(() => { cart = new Cart(); });

  it('starts empty', () => assert.equal(cart.total(), 0));
  it('sums item prices', () => {
    cart.add({ price: 10 });
    cart.add({ price: 5 });
    assert.equal(cart.total(), 15);
  });
});

Focus one test with { only: true } and --test-only, or filter with --test-name-pattern.

How do I mock functions and timers?

Mocking is built in through the mock object — no jest.fn to install.

import { test, mock } from 'node:test';
import assert from 'node:assert/strict';

test('notifies the customer once', () => {
  const notify = mock.fn();
  placeOrder({ items: [{ price: 10 }], notify });
  assert.equal(notify.mock.callCount(), 1);
});

mock.method(obj, 'name') spies on a real method, and mock.timers.enable({ apis: ['setTimeout'] }) plus mock.timers.tick(1000) gives deterministic fake timers. Full module mocking via mock.module() is still experimental, so I favor dependency injection instead.

Can I run TypeScript tests without a build step?

Yes, on Node.js 22.18+ and Node.js 24, because Node.js strips type annotations at load time.

node --test "src/**/*.test.ts"

Relative imports need the explicit .ts extension, and Node.js never type-checks — run tsc --noEmit as a separate CI gate. This removed ts-jest and the Vitest transform from every script and library repo I own.

How do I get coverage and CI reports?

Watch mode is node --test --watch. Coverage is a flag: node --test --experimental-test-coverage prints a per-file table. Reporters are chosen with --test-reporter, and you can emit several at once:

node --test \
  --test-reporter=spec \
  --test-reporter=junit --test-reporter-destination=junit.xml \
  --experimental-test-coverage

Thresholds like --test-coverage-lines=80 (Node.js 22+) fail the run below a percentage — enough to gate a PR without a coverage service.

When should I keep Vitest or Jest?

Keep them whenever a test needs a browser-like environment or a build transform the runtime lacks.

Need	Node.js test runner	Vitest / Jest
Dependencies	Zero (built in)	A framework + transform
DOM / React	No jsdom, no JSX	jsdom/happy-dom + JSX
TypeScript	Native via type stripping	esbuild/SWC transform
Snapshots	Basic, recent	Mature
Best for	Scripts, libraries, backend	Frontend, components, big suites

Backend and library code gets the built-in runner; anything that renders a component stays on Vitest.

FAQ

Q: Is the Node.js test runner production-ready?
A: Yes — the runner and node:test API are stable since Node.js 20. Only module mocking and coverage remain behind experimental flags.

Q: Do I need a config file?
A: No. node --test auto-discovers test files and takes options as CLI flags.

Q: Which assertion library does it use?
A: The built-in node:assert; import node:assert/strict for strict equality. Third-party assertion libraries still work.

Q: Can it test React components?
A: Not well — no DOM, no JSX transform. Use Vitest/Jest with jsdom for components.

Q: How does it mock ES modules?
A: Via mock.module(), still experimental. I prefer dependency injection for stable code.

Originally published on devya.dev. Also on eng-ahmed.com. Built by Devya Solutions.

Possessed by Production: The Ghost Execution That Ran Code Nobody Ever Wrote

Bhavnish — Sat, 08 Aug 2026 06:29:04 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

I deleted a single console.log statement from our payment worker, merged the PR, and went to grab tea. Ten minutes later, PagerDuty was screaming.

Memory usage on our background pods spiked to 99.8%. Outgoing webhooks failed with orphan closure errors, and Postgres rows started getting overwritten with payloads from different users.

I panicked and reverted the commit. I put the console.log back.

And just like magic... the errors stopped. Memory dropped back to 180MB. Everything went green.

Reverting a one-line PR and having production fix itself is terrifying. It means your architecture isn't actually stable—it's riding on accidental side-effects.

14 Hours in DevTools: What Happened?

If adding console.log fixes your backend, you are relying on luck and OS buffer timing.

I spent 14 hours taking heap snapshots (node --inspect) and diffing memory dumps across V8 garbage collection cycles. Here is what happened under the hood:

The Timing Trap: In Node.js, printing to stdout isn't always instant and non-blocking. That tiny log call introduces microsecond I/O pauses that inadvertently acted as an accidental sync guard.
The Floating Promise: We had a background logging task running inside an un-awaited Promise chain inside our request handler.
V8 Scope Reclamation: When console.log(user.id) was present, V8 retained an explicit reference to user in the parent scope.

When I removed the log, V8 JIT optimizations kicked in. During aggressive Garbage Collection, V8 marked the parent context as dead before the background callback finished writing to Redis. The callback resolved into an invalidated scope context.

The Broken Code

app.post('/api/checkout', async (req, res) => {
  const user = req.user;

  db.saveOrder(req.body).then(async (order) => {
    await telemetry.logTransaction(user.id, order.amount);
  });

  return res.json({ status: "queued" });});

The Fix

import { AsyncLocalStorage } from 'node:async_hooks';

app.post('/api/checkout', async (req, res) => {
  const userId = req.user.id;
  const payload = req.body;

  try {
    const result = await db.transaction(async (trx) => {
      const order = await trx.saveOrder(payload);
      await telemetry.logTransaction(userId, order.amount);
      return order;
    });

    return res.json({ status: "processed", orderId: result.id });
  } catch (err) {
    logger.error('Checkout pipeline failed', { err, userId });
    return res.status(500).json({ error: "Transaction failed" });
  }
});

What This Incident Taught Me

Accidental synchronization is real: If removing a log breaks your service, you have a race condition.

Respect V8 internals: JIT compilers are aggressive. Don't leave floating background callbacks hoping scope stays alive.

Always await your promises: Unhandled floating promises will eventually bite you under high concurrency.

Next.js Image Optimization: next/image Deep Dive for Production Apps

Aon infotech — Sat, 08 Aug 2026 06:28:08 +0000

Images consistently account for 50–70% of total page weight in most web applications. Next.js ships a built-in next/image component that handles the heavy lifting automatically — but using it correctly means understanding what it actually does, what configuration matters in production, and where the defaults fall short.

What next/image Actually Does

When you use next/image, requests go through Next.js's image optimization API at /_next/image. On each request it:

Converts to WebP or AVIF (significantly smaller than JPEG/PNG)
Resizes to the requested display dimensions
Lazy loads by default
Reserves layout space to prevent Cumulative Layout Shift
Caches the optimized output server-side Self-hosted deployments need sharp for server-side optimization:

npm install sharp

On Vercel, optimization runs at the edge automatically.

Basic Implementation

import Image from 'next/image'
import heroImage from '@/public/hero.jpg'

// Local image — dimensions extracted at build time
export function Hero() {
  return (
    <Image
      src={heroImage}
      alt="Descriptive alt text here"
      priority
    />
  )
}

// Remote image — must specify dimensions
export function ProductCard({ imageUrl }) {
  return (
    <Image
      src={imageUrl}
      alt="Product"
      width={400}
      height={300}
      sizes="(max-width: 768px) 100vw, 400px"
    />
  )
}

The `sizes` Prop — Most Commonly Misused

Without sizes, Next.js generates a single large image. With it, the browser receives multiple sizes and selects the correct one for the current viewport.

// Wrong — browser downloads large image regardless of display size
<Image src={src} alt={alt} width={800} height={600} />

// Correct — sizes match actual CSS rendering
<Image
  src={src}
  alt={alt}
  width={800}
  height={600}
  sizes="(max-width: 640px) 100vw, (max-width: 1024px) 50vw, 800px"
/>

The sizes string describes your CSS layout. If the image is full-width on mobile, half-width on tablet, and 800px fixed on desktop, write exactly that.

`fill` for Flexible Containers

When you don't know dimensions ahead of time:

<div className="relative h-64 w-full">
  <Image
    src={imageUrl}
    alt="Cover"
    fill
    className="object-cover"
    sizes="(max-width: 768px) 100vw, 50vw"
  />
</div>

The parent needs position: relative and defined dimensions. fill makes the image absolutely positioned to match the parent.

Priority Loading for LCP

The Largest Contentful Paint image should never be lazy loaded:

// Any image visible on page load — hero, banner, above-fold card
<Image
  src={heroSrc}
  alt="Hero"
  fill
  priority
  sizes="100vw"
/>

priority adds a preload link and disables lazy loading. Don't add it to off-screen images — that wastes bandwidth on content users may not scroll to.

Remote Domains Configuration

Next.js blocks external images by default. Configure remotePatterns in next.config.js:

module.exports = {
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'images.example.com',
        pathname: '/uploads/**',
      },
      {
        protocol: 'https',
        hostname: '**.cloudinary.com', // wildcard subdomain
      },
    ],
  },
}

Use remotePatterns over the deprecated domains array — it gives you path-level control.

Quality, Format, and Cache Configuration

module.exports = {
  images: {
    quality: 80,                    // default 75 — increase for sharper images
    formats: ['image/avif', 'image/webp'], // AVIF first, WebP fallback
    deviceSizes: [640, 750, 828, 1080, 1200, 1920],
    minimumCacheTTL: 60 * 60 * 24, // cache for 24h instead of default 60s
  },
}

AVIF compresses better than WebP but encodes slower. Browser negotiation handles the format selection — keep both in the array.

Blur Placeholder

// Local image — blur data generated at build time automatically
<Image
  src={productImage}
  alt="Product"
  placeholder="blur"
/>

// Remote image — provide base64 blurDataURL
<Image
  src={remoteUrl}
  alt="Product"
  placeholder="blur"
  blurDataURL="data:image/jpeg;base64,/9j/4AAQ..."
  width={800}
  height={600}
/>

The blur shows immediately while the full image loads. Perceived performance improves significantly even when actual load time stays the same.

Production Gotchas

Sharp is not optional for self-hosted apps. Without it, Next.js falls back to a slower path or disables optimization entirely.

Memory watch on high-traffic sites. Each unique URL/size combination gets cached. Applications serving user-uploaded images with unique filenames can exhaust cache memory. Set a reasonable minimumCacheTTL and monitor.

SVGs bypass the optimizer. SVG files are served as-is — the optimizer is designed for raster images. Handle SVGs with SVGR or as static assets.

Build-time vs request-time dimensions. Local imports have their dimensions extracted at build time. Remote URLs need width and height specified in the component or fill layout.

Measuring the Impact

Track these before and after switching to next/image:

LCP score in Core Web Vitals (primary image performance metric)
Total image transfer size in DevTools Network tab filtered by Img
CLS score — proper dimension reservation eliminates most image-related layout shift For most apps serving photographic content, correctly configured next/image reduces image payload by 50–70% and brings CLS to near zero.

For AI-generated imagery like the content at Pixova's free sketch generator, the WebP conversion from PNG source files typically produces 40–60% size reduction — meaningful at scale when thousands of users are loading AI-generated images daily.

I Tried Building JavaScript Games Without a Game Engine. Here's What I Learned

Ravindra Reddy Chitla — Sat, 08 Aug 2026 05:50:43 +0000

I am a digital marketer, not a professional developer or game developer. Most of my career has been focused on SEO, growth marketing, paid acquisition, content, and digital strategy. When I started building GamesMom, however, I found myself learning much more about web development than I expected.

GamesMom is a collection of free educational games and learning activities for kids that run directly in the browser. The site includes math games, word games, typing games, memory games, puzzle games, classroom games, quizzes, and other interactive activities. The idea was simple: make games that children can open and play without downloading an application or creating an account.

I initially assumed that building browser games would require a dedicated game engine or a large JavaScript framework. After experimenting with different approaches, I found that many of the games I wanted to create could be built with ordinary HTML, CSS, and JavaScript.

That was probably the most useful lesson I learned from the project. You don't always need a complicated technology stack to create an interactive web experience.

I Started With the Simplest Approach

When you're not a professional developer, it is tempting to look for the most sophisticated solution available. I did this too.

I spent time looking at frameworks, game engines, libraries, and different ways of structuring interactive applications. Eventually I started asking a much simpler question: what does this particular game actually need?

A basic educational game might need to display a question, accept an answer, update a score, show feedback, and move to the next question. Another might need a timer, a few buttons, and some randomization.

Those requirements don't automatically justify a game engine.

For simple browser games, the browser already provides a lot of what you need.

HTML, CSS and JavaScript Can Go a Long Way

The basic combination is surprisingly capable.

HTML provides the structure of the page. CSS controls the visual presentation and responsive layout. JavaScript handles the interaction and game logic.

That combination was enough for many of the interactive experiences I wanted to create.

This also made the project easier for me to understand. Instead of learning a large development environment before I could build anything, I could take one problem at a time and learn the JavaScript or browser feature required to solve it.

That approach was much less intimidating.

Understanding Events Changed Everything

One of the most important concepts I encountered was the browser event system.

A player clicks a button. They press a keyboard key. They select an answer. They interact with something on a touchscreen.

JavaScript can listen for these actions and respond.

For example, a simple interaction can look like this:

button.addEventListener("click", () => {
checkAnswer();
});

There isn't much code here, but understanding what is happening is important. The browser waits for an event, JavaScript receives it, and the application responds.

Once I understood that pattern, many game interactions became easier to think about.

Timers Are Simple Until You Start Testing Them

Timers are another feature that looks trivial until you actually build something around them.

A timed math game, typing game, countdown activity, or classroom timer needs to know when the timer starts, when it stops, and what happens when the time reaches zero.

A simple implementation can use JavaScript's built in timing functions.

let timerId;

function startTimer() {
clearInterval(timerId);

timerId = setInterval(() => {
updateTimer();
}, 1000);
}

function stopTimer() {
clearInterval(timerId);
}

The important lesson for me wasn't memorizing setInterval().

It was understanding that every temporary process needs a clear lifecycle. If something starts, you need to know when it should stop.

That principle applies to much more than games.

Randomness Makes Games Replayable

A lot of educational games become more useful when the experience changes each time someone plays.

A math game can generate different questions. A word game can select different words. A memory activity can shuffle cards. A quiz can select questions from a larger pool.

JavaScript provides simple tools for random selection.

const index = Math.floor(Math.random() * items.length);
const item = items[index];

The interesting part comes after that.

You need to think about whether something can repeat too often, whether the difficulty remains appropriate, and whether the player is actually getting a different experience.

For example, one of the quizzes currently available on GamesMom selects questions from a larger pool and shuffles both the questions and answer positions between rounds.

That turns a simple randomization function into an actual product decision.

Not Every Game Needs Canvas

Before working on the project, I assumed that interactive games would naturally require Canvas.

That isn't always the case.

If a game is primarily made up of questions, text, buttons, cards, scores, and simple interactions, ordinary HTML elements can work very well.

JavaScript can update the page when something changes:

scoreElement.textContent = score;
questionElement.textContent = currentQuestion;

For many educational games, this approach is perfectly reasonable.

It also has a practical advantage. Normal HTML elements can work naturally with browser features such as text selection, zooming, keyboard interaction, and accessibility tools.

For the types of games I was building, I didn't need to make everything a custom graphical surface.

Mobile Testing Changed My Thinking

One of the biggest differences between building a normal website and building browser games is interaction.

A button that works well with a mouse may not work well on a phone.

A small card can be easy to click with a cursor and frustrating to tap with a finger.

As I tested games on different screen sizes, I became much more aware of touch targets, spacing, responsive layouts, font sizes, and the amount of information displayed on the screen.

GamesMom is intended to work across phones, tablets, laptops, and classroom displays, so responsive design became part of the development process rather than something to consider at the end.

Accessibility Is Part of the User Experience

I also learned that building games for children changes the way you think about accessibility.

An interactive element needs to be easy to identify and use. Text needs to remain readable. Controls should not depend entirely on a mouse. The interface needs to remain usable across different screen sizes.

This doesn't require an advanced accessibility framework.

It requires paying attention.

Keyboard navigation, visible focus states, readable typography, appropriate contrast, sensible touch targets, and simple interactions can make a significant difference.

The more I worked on the project, the more I realized that accessibility isn't something you bolt onto a finished website. It is part of the interface from the beginning.

Performance Becomes More Important as the Site Grows

A single game can hide a lot of inefficiency.

When you start building a larger collection of browser games, those decisions become more important.

Images need to be appropriately sized. JavaScript should do useful work rather than unnecessary work. Pages shouldn't load resources that the visitor doesn't need. Animations shouldn't exist simply because they look impressive.

This is one reason I liked keeping the individual games relatively focused.

Someone playing a typing game shouldn't need to load the resources required by an unrelated memory game.

Keeping experiences focused can improve both the development process and the experience for the person using the site.

Reusable Code Is Useful, But There Is a Limit

One of the biggest lessons from building multiple games was learning where reuse makes sense.

Some functionality naturally repeats. Scores, buttons, timers, result screens, and common interface elements can often follow the same patterns.

But the actual experience of each game should still feel appropriate to what the player is doing.

If you make everything too reusable, you can end up forcing completely different games into the same structure.

The goal isn't to make every game identical.

The goal is to avoid solving the same technical problem repeatedly.

What Building Games Taught Me About Development

The biggest lesson wasn't a particular JavaScript function or browser API.

It was learning how to break unfamiliar technical problems into smaller problems.

Coming from digital marketing, I didn't approach GamesMom with years of software engineering experience. I approached it by learning what I needed, testing different approaches, reading documentation, using development tools, and fixing problems as they appeared.

That experience changed how I look at websites.

As a marketer, it is easy to think about a website primarily in terms of traffic, rankings, conversions, content, and acquisition.

Building the product myself made me think more about what happens underneath those metrics.

Performance affects the user experience. Interface decisions affect engagement. Accessibility affects who can use the product. Architecture affects how easily a site can grow.

Those things are connected.

What I Would Do Differently

If I started again, I would spend more time defining the common building blocks before creating a large number of games.

I would also test on mobile devices earlier and establish accessibility and performance standards before the number of pages and games became large.

Most importantly, I would avoid adding technology simply because it is popular.

If a simple JavaScript solution works, there is no prize for making it complicated.

If a project eventually reaches the point where a framework or game engine solves a real problem, then introduce it.

The technology should respond to the requirements of the product.

You Don't Have to Be a Developer to Start Building

I wouldn't describe myself as a developer because that isn't my profession.

But building GamesMom taught me that the barrier between marketing and development is much lower than I previously thought.

You don't need to know everything before starting a technical project.

You need to be willing to learn enough to solve the next problem.

That might mean learning JavaScript today, responsive web design tomorrow, and performance optimization next week.

The process is incremental.

You don't have to become an expert in everything before you build your first useful thing.

I started GamesMom because I wanted to create free educational games and learning activities that children could use directly in a browser. Along the way, the project became an unexpected education in web development.

I learned that HTML, CSS, and JavaScript can go surprisingly far when the problem is relatively simple. I learned that good mobile experiences require more than making a desktop layout responsive. I learned that accessibility and performance need to be considered early. Most importantly, I learned that adding more technology isn't automatically the answer to a technical problem.

Sometimes the best solution is the simplest one you understand well enough to improve.

And that may be the most useful thing I took away from building browser games as a marketer rather than a developer.

How I Built an AI Customer Support Chatbot for Shopify That Resolved 80% of Tickets

Khanzadi Wazir Ali — Sat, 08 Aug 2026 05:23:11 +0000

My client was drowning in support tickets. Same questions, every single day.

Their team was spending 20+ hours a week just answering repetitive queries. That's when they came to me — and I built them an AI chatbot that changed everything.

The Problem
The store was getting ~150 support messages per week. 80% of them were the same 10 questions. This was slow, expensive, and burning out the team.

The Stack
OpenAI API (GPT-4)
Node.js + Express.js
Shopify REST API
n8n (workflow automation)
The Results
Metric Before After
Tickets resolved without human 20% 80%+
Avg response time 4 hours instant
Monthly support cost $1,200 ~$200
What I Learned
Context is everything. A chatbot that pulls live data is 10x more useful than one answering from static text.

Always build an escape hatch. The escalation flow made the client trust the system.

Prompt engineering matters more than model size.

AI Coding Assistants vs Full Stack Developers: Where Each Works Best in 2026

Kundan Parmar — Sat, 08 Aug 2026 04:53:45 +0000

Let me tell you about a conversation I had with a startup founder last quarter.

He'd spent six weeks trying to build his SaaS product using an AI coding assistant. No developers on payroll. Just him, a few smart prompts, and a lot of optimism. The prototype worked beautifully in his local environment. Then he tried to connect a payment gateway. Then add user roles. Then make the thing actually secure enough to show investors.

Three weeks later, he called us. The codebase was a tangle of AI-generated functions that worked individually but contradicted each other at the seams. No developer on his team could untangle it because there was no team. Just layers of confident, wrong code.

He's not alone. And I'm not sharing this to bash AI tools -- I use them every day and they genuinely save me hours. The point is that the "AI vs developers" conversation keeps getting framed as a competition when it's really a question of fit. Different problems. Different tools. Getting that wrong in either direction costs you time and money.

What Full Stack Development Actually Covers

People use "full stack" loosely, so let's be clear about what it means in practice.

A full stack developer owns the entire product experience from the database schema through to what a user sees on screen. That means designing how data is stored, writing the logic that processes it, building the API that connects backend to frontend, and assembling the UI that users interact with. In 2026, most full stack developers working on serious products also handle deployment, cloud infrastructure, and increasingly, AI feature integration -- connecting LLM APIs, setting up vector search, wiring retrieval pipelines.

What it doesn't mean: one developer doing the work of a ten-person team forever. Full stack means you can navigate the whole system without needing a translator between layers. It doesn't mean infinite bandwidth.

The technologies vary. React and Next.js dominate on the frontend right now. Node.js, Python (FastAPI in particular has grown quickly), and Go handle the backend depending on the use case. PostgreSQL holds the top database spot by adoption. MongoDB remains the go-to for flexible document-heavy applications. TypeScript has stopped being optional -- if you're not using it in 2026 on a professional codebase, teams notice.

Also Read: Why Full-Stack MERN Developers Deliver Faster

The Honest Picture on AI Coding Tools

Here's what AI coding assistants are genuinely good at, from someone who watches development teams use them daily.

Autocomplete that actually understands context. The days of tab-completion that guesses the variable name are over. Tools like GitHub Copilot and Cursor now follow the logic of what you're building and suggest the next logical block of code, not just the next word. For repetitive patterns -- API routes, form validation, test boilerplate -- this is legitimately fast.

Explaining code you didn't write. This one gets underestimated. When a developer joins a project mid-stream and needs to understand what a 400-line function does, asking an AI to explain it is faster and often clearer than reading documentation that may not exist. Same with legacy code that predates your team.

First-draft unit tests. Writing tests for a well-defined function with clear inputs and outputs is exactly the kind of bounded, predictable task AI handles well. Not integration tests. Not tests that need to understand business rules and edge cases. But the routine test coverage that developers avoid because it's tedious -- AI can do a lot of that.

Where it breaks down is less obvious but more expensive when it happens. AI tools have no memory between sessions. They have no awareness of decisions your team made three months ago and why. They don't know that you migrated away from a particular library because of a security issue, or that a specific pattern is banned in your codebase because it caused a production incident. Every prompt starts fresh. For greenfield projects with simple architecture, that's manageable. For real products with real history, it's a constant friction point.

The deeper issue is quality verification. GitHub Copilot generates roughly 46% of code for active users, but only about 30% of its suggestions get accepted without modification. That's not a failure -- that's how it's supposed to work. The problem is when teams stop doing that verification step because the code looks right and shipping feels urgent. An independent analysis published in late 2025 found significantly more issues in AI-coauthored pull requests than in human-written code. The code gets generated faster. The problems just move downstream.

Also Read: What Is a Full Stack Developer? How to Hire One Who Delivers

Is Full Stack Development Still Worth Investing In?

I get this question from engineering managers and founders more often now than I did two years ago.

The answer is yes, and the data actually supports it pretty clearly. The World Economic Forum's 2025 Future of Jobs report listed software developers among the top growing roles in raw headcount, not just percentage growth. The Bureau of Labor Statistics has 17% growth projected for software developers through 2033. Gartner's position is that generative AI creates new engineering roles, not fewer of them -- their prediction that 80% of engineers will need to upskill through 2027 is often quoted as a warning sign, but their actual conclusion is that AI expands what engineers do, not that it contracts who does it.

What has changed is the entry-level market. Routine tasks that used to fill a junior developer's first year -- generating boilerplate, writing straightforward CRUD functions, producing templated reports -- have been significantly absorbed by AI tools. Many engineering teams have raised their expectations for new hires accordingly. "Junior" in 2026 means something different than it did in 2022.

But mid-level and senior full stack developers who can architect systems, make real tradeoff decisions, and own code in production? Demand is solid. If anything, the premium on genuine seniority has gone up because AI tools can now do a convincing impression of a junior developer. Teams need people who can tell the difference between code that works and code that will hold up.

Also Read: Hire React Native Developers: Real App Cost Breakdown

Where AI Coding Assistants Actually Win

Specific scenarios where the tool beats the developer, or at least matches them at a fraction of the cost:

Building a prototype quickly. If you need to demonstrate a concept to investors or test a product hypothesis, AI-assisted scaffolding gets you to something clickable in days rather than weeks. The code doesn't need to be production-quality. It needs to show the idea. AI tools are genuinely good at that.

Accelerating experienced developers. The productivity gains from AI tools are most significant when the person using them already knows what good code looks like. A senior developer using Copilot can move at a pace that would've required a small team a few years ago. That's not replacing developers -- it's compressing timelines for developers who already have the judgment to use AI outputs selectively.

Documentation and code explanation. This is quietly one of the most valuable use cases and it rarely gets mentioned. Writing documentation is something most developers would rather avoid. AI tools write a coherent first draft in seconds. Explaining what a function does, generating README files, writing API documentation -- all of this is low-risk, high-value territory for AI assistance.

Repetitive test generation. When a developer needs 40 unit tests for 40 similar functions, that's a job for AI. It's also exactly the kind of work that burns out good engineers.

Also Read: Why US SaaS Companies Still Choose MERN Stack for Faster Product Development

Where Full Stack Developers Are Irreplaceable

Architecture is the clearest answer. Deciding how a system is structured -- what services exist, how they communicate, where data lives, how the application handles scale and failure -- is not something you can prompt your way through. These decisions have long consequences. A wrong call on your data model in month one costs you in month fourteen, usually at the worst possible moment.

Security is another. I've watched AI-generated authentication code that looked perfectly functional contain vulnerabilities that only became visible when someone with security experience reviewed it. AI tools don't have a threat model. They don't reason about attack surfaces. They generate code that passes a surface-level review and falls apart under scrutiny.

Domain-specific business logic is the third area where AI tools genuinely struggle. Your application's rules about how a particular workflow operates, what edge cases matter, why a specific exception exists in the codebase -- that knowledge lives in your team's heads and in your commit history. AI has none of it.

And then there's production. When something breaks at 2am and your customers are affected, you need a developer who owns the system and knows where to look. AI tools don't carry pagers.

AI Tools Full Stack Developers Are Actually Using in 2026

The landscape has consolidated a bit from the fragmented market of 2023-2024. Most professional development teams are working with some combination of these:

GitHub Copilot remains the most widely adopted -- 90% of Fortune 100 companies use it according to Microsoft's own reporting, which gives you a sense of how mainstream it's become. It handles inline autocomplete well and integrates cleanly with most IDEs.

Cursor has built a strong following among individual developers and smaller teams. Its agent mode can operate across multiple files simultaneously, which makes it useful for refactoring and larger structural changes. It requires more active developer oversight on complex tasks.

Claude Code handles multi-step engineering work more thoughtfully than most tools -- it can reason about tradeoffs, work across large codebases, and flag its own uncertainty, which is actually useful. Increasingly used for architecture questions and codebase explanation.

The common thread: none of these tools are autonomous. They're accelerators. The developer decides what to build, reviews what gets generated, and owns what ships.

The Decision That Actually Matters

The question most engineering leaders should be asking isn't "AI or developers?" It's "for this specific problem, which one is right?"

Greenfield prototype with low complexity, tight timeline, and a team that just needs to test a hypothesis? Start with AI-assisted development. Get something in front of users. Then bring in a dedicated full stack development team to rebuild what's worth keeping on a proper foundation.

Production application with real users, real data, real security requirements, and a need for ongoing iteration? You need developers who own the code. AI tools help them move faster. They don't replace the judgment.

Maintenance-heavy product with a large existing codebase? AI tools help here -- code explanation, test generation, documentation -- but you still need at least one developer who knows the system well enough to validate what the tool produces.

Hidden Brains has helped teams navigate this exact tradeoff across fintech, healthcare, eCommerce, and logistics. The pattern we see consistently: companies that use AI tools to speed up their developers ship better software than companies that try to replace developers with AI tools entirely. The difference isn't ideological. It's practical.

Frequently Asked Questions

What does a full stack developer do day to day?

On any given day, a full stack developer might be designing a new database table, writing the API endpoint that reads from it, building the UI component that displays the data, and reviewing a pull request from a teammate. They're expected to move fluidly between frontend and backend concerns without needing a handoff between specialists. In 2026, most full stack roles also involve working with cloud infrastructure and, increasingly, integrating AI features directly into product functionality.

Can AI build a full stack application without a developer?

For a very simple application -- a basic form that collects data and stores it, or a static marketing page with minor interactivity -- AI tools can get you most of the way there. For anything that needs real user authentication, third-party integrations, custom business logic, security hardening, or the ability to scale beyond a handful of users, you'll hit walls that require a developer's judgment to navigate. The code will generate. The system won't hold.

Will AI replace full stack developers?

Not in the timeframe most headlines suggest. Entry-level roles that were mostly boilerplate have been affected -- there's no honest way to say otherwise. But the developers who can design systems, review AI output critically, handle security and performance at scale, and translate business requirements into technical architecture are in more demand now, not less. Gartner's own research concludes that AI creates new engineering roles. The Bureau of Labor Statistics projects strong job growth for software developers through 2033. The job is changing shape. It's not disappearing.

What is the best technology stack for web application development in 2026?

There isn't one universal answer, and anyone who tells you otherwise is selling something. React or Next.js handles most frontend requirements well. For the backend, Node.js suits JavaScript-centric teams; Python with FastAPI is the better choice if your product has any data processing or AI workload; Go makes sense if raw performance at scale is a priority from the start. PostgreSQL is the default database choice for most relational data. TypeScript across the stack has become standard professional practice. The choice should fit your team's existing skills, your product's actual requirements, and your scaling timeline.

What is full-stack AI development?

Full-stack AI development refers to building applications where AI features are integrated throughout the product -- not bolted on as an afterthought. This might include an LLM-powered assistant in the frontend UI, a vector database backing semantic search in the backend, an ML model influencing business logic in the application layer, and AI-assisted code generation in the development workflow itself. It requires developers who understand both traditional full stack architecture and how AI components fit into it. The demand for developers fluent in both has grown considerably in 2026.

Should I hire a full stack developer or a dedicated development team?

For a focused product with a clear scope and a 3-6 month timeline, a strong senior full stack developer can often handle it. For anything with multiple parallel workstreams, complex integrations, or a need for specialization across frontend experience, backend architecture, and DevOps, a small coordinated team consistently outperforms a single generalist. The math changes depending on your timeline and risk tolerance. A dedicated team is also more resilient -- a single developer leaving mid-project is a much more serious disruption than losing one member of a five-person team.

How much does full stack development cost?

Rates vary considerably. In the US market, senior full stack contractors typically run $100-180/hour. Staff augmentation through a vetted development partner generally ranges from $60-150/hour per developer and includes recruiting overhead, legal compliance, and talent replacement guarantees that direct hiring doesn't. Full-time senior developer salaries in competitive US markets range from $140,000 to $220,000+. For fixed-scope projects, pricing depends heavily on architecture complexity, third-party integration requirements, and how well-defined the specifications are before development starts.

How long does full stack development take?

A realistic MVP with user authentication, core features, and basic deployment takes 8-12 weeks with a competent focused team. More complex products -- multi-tenant SaaS, marketplace platforms, products with AI features or complex integrations -- typically take 4-9 months through a first stable release. These timelines include design, development, testing, and deployment iterations. Projects that skip testing to hit a timeline usually spend that time (and more) on post-launch fixes.

DEV Community: javascript

How GSTIN Checksum Validation Works (and Why It Isn't Enough)

How the checksum works

What a checksum can't tell you

The Evolution of Scientific Computing: Why Developers Still Need Dedicated Calculators

You built your modal with a `` and a focus trap library. The native `` does all of that.

The baseline API

showModal() vs show()

Styling the backdrop

Animating open and close

Handling backdrop clicks to close

Return value from close()

The <form method="dialog"> shortcut

Browser support

🎮 Try it yourself

🧠 Test yourself

The takeaway

Stop importing `uuid`. `crypto.randomUUID()` has been native since 2021.

The native API

Why it's safe to trust

Where it works

Replacing the import

The one case where you still need a library

Browser support

🎮 Try it yourself

🧠 Test yourself

The takeaway

Building an accessible Nigerian restaurant landing page with vanilla JavaScript and hand-drawn SVG

What I Built

Demo

Journey

Making Online Registration Easier for Small Business Users

Node.js Has a Test Runner Now: Field Notes on Dropping Jest for Scripts and Libraries

Key takeaways

Can Node.js run tests without Jest or Vitest?

How do I structure tests with node:test?

How do I mock functions and timers?

Can I run TypeScript tests without a build step?

How do I get coverage and CI reports?

When should I keep Vitest or Jest?

FAQ

Possessed by Production: The Ghost Execution That Ran Code Nobody Ever Wrote

14 Hours in DevTools: What Happened?

The Broken Code

The Fix

What This Incident Taught Me

Next.js Image Optimization: next/image Deep Dive for Production Apps

What next/image Actually Does

Basic Implementation

The sizes Prop — Most Commonly Misused

fill for Flexible Containers

Priority Loading for LCP

Remote Domains Configuration

Quality, Format, and Cache Configuration

Blur Placeholder

Production Gotchas

Measuring the Impact

I Tried Building JavaScript Games Without a Game Engine. Here's What I Learned

How I Built an AI Customer Support Chatbot for Shopify That Resolved 80% of Tickets

AI Coding Assistants vs Full Stack Developers: Where Each Works Best in 2026

What Full Stack Development Actually Covers

The Honest Picture on AI Coding Tools

Is Full Stack Development Still Worth Investing In?

Where AI Coding Assistants Actually Win

Where Full Stack Developers Are Irreplaceable

AI Tools Full Stack Developers Are Actually Using in 2026

The Decision That Actually Matters

Frequently Asked Questions

What does a full stack developer do day to day?

Can AI build a full stack application without a developer?

Will AI replace full stack developers?

What is the best technology stack for web application development in 2026?

What is full-stack AI development?

Should I hire a full stack developer or a dedicated development team?

How much does full stack development cost?

How long does full stack development take?

You built your modal with a `
` and a focus trap library. The native `` does all of that.

`showModal()` vs `show()`

Return value from `close()`

The `<form method="dialog">` shortcut

The `sizes` Prop — Most Commonly Misused

`fill` for Flexible Containers