DEV Community: Karthick Ajan G S

Edge Computing in the Browser: How I Replaced a Backend Server with Web Workers & WASM

Karthick Ajan G S — Sun, 14 Jun 2026 09:22:33 +0000

The obsession with centralizing heavy compute on backend servers is a massive bottleneck for both cost and latency. In 2026, as more applications move to the edge, developers are realizing that the user's browser is an incredibly powerful, untapped compute engine.

Recently, I challenged myself to build a free live chess game analyzer for my developer utility suite, CipherKit. The traditional architecture for this requires passing FEN strings to a dedicated backend cluster running the Stockfish engine, which introduces network latency and scales operational costs linearly.

I wanted to achieve a 100% client-side, zero-latency experience. Here is how I offloaded the heavy lifting entirely to the browser edge.

The Architecture: WASM + Web Workers

Running a heavy calculation engine directly in JavaScript instantly blocks the main UI thread. To achieve a flawless 60fps UI, I completely decoupled the state from the computation.

The UI Thread: Handles strict DOM rendering, board states, and piece animations.
The Worker Thread: Instantiates the Stockfish engine via WebAssembly within the browser's memory.

When a live game update occurs, the main thread fires a simple FEN payload via worker.postMessage(). The Worker processes the deep-line evaluations (Depth 20+) asynchronously in the background. It then streams the evaluation lines back to the main thread without causing a single micro-freeze.

The Result

By treating the browser as the edge compute layer, the tool achieves:

Zero Server Latency: Bypassing API rate limits and network bottlenecks.
$0 Infrastructure Cost: Heavy compute is crowd-sourced to the user's local device.
Absolute Privacy: Sensitive payloads never leave the browser.

If you want to see this local asynchronous thread management in action, you can test the live analyzer (and inspect the network tab) here:
👉 CipherKit Live Chess Analyzer

Are you offloading heavy computations to the client side in your current projects, or are you still relying on traditional server clusters? Let's discuss in the comments.

How I stopped a local chess engine from freezing the browser UI

Karthick Ajan G S — Mon, 01 Jun 2026 16:42:24 +0000

When building browser-based tools that handle heavy computation—like a chess engine calculating deep positional variations—running everything on the main JavaScript thread is a recipe for disaster. The moment the engine starts thinking, the entire UI locks up. Users can't click buttons, drag pieces, or even scroll.

To solve this for a personal project, I isolated the UI state from the raw processing by offloading the entire Stockfish engine execution to a Web Worker.

The Setup

The visual board runs smoothly on the main thread, while the engine calculations run entirely in the background. They communicate asynchronously via simple message passing:

The user moves a piece on the board.
The main thread captures the new position and sends the updated FEN string to the Web Worker via worker.postMessage().
The Worker computes the engine evaluation lines in the background without touching the DOM.
The Worker streams the live evaluations back to the main thread using postMessage(), which instantly updates a lightweight evaluation bar.

This completely eliminates main-thread blocking. You can flip the board, toggle settings, and interact with the UI flawlessly even while a depth-20 calculation is running in the background.

I implemented this exact setup in a lightweight, serverless chess utility I've been polishing. If you want to check out how smooth the client-side evaluation handles, or inspect the network tab to see it running 100% locally with zero backend requests, you can play around with it here:

👉 CipherKit Chess Board Analyzer

How are you guys handling heavy local computations or WASM/Worker state management in vanilla JS architectures lately? Let's discuss in the comments!

Stop using external npm packages just to generate a UUID v4

Karthick Ajan G S — Mon, 25 May 2026 06:25:00 +0000

For years, the go-to move for generating a UUID in Node.js or the browser was installing the uuid package.

But if you are targeting modern environments, you can ditch the extra dependency entirely. Modern browsers and Node.js (19+) have native cryptographic support built right into the crypto global module.

Here is how you generate a cryptographically secure UUID v4 natively:

// Native Web Crypto API (Runs in browser and modern Node.js)
const uuid = crypto.randomUUID();
console.log(uuid); // e.g., "f81d4fae-7dec-11d0-a765-00a0c91e6bf6"

Why this matters for security
Unlike old-school math-based pseudo-random generators (⁠Math.random()⁠), ⁠crypto.randomUUID()⁠ uses the underlying operating system's hardware-backed entropy. It's fast, secure, and doesn't bloat your production bundle.
Need to generate UUIDs on the fly?
If you just need a batch of secure keys for configuration files, database testing, or environment variables, stop pasting your requirements into third-party online generators that process data on backend servers.
I built a completely offline, zero-server utility to generate these instantly in your browser:
👉 Secure Browser UUID Generator
It runs 100% client-side via the Web Crypto API, meaning your generated IDs never touch a network loop. Part of a larger privacy-first suite of tools at cipherkit.app.

Anyone willing to join me ?

Karthick Ajan G S — Sun, 12 Apr 2026 22:22:06 +0000

Karthick Ajan G S

Apr 6

CipherKit

#showdev #webdev #opensource #security

2 min read

CipherKit

Karthick Ajan G S — Mon, 06 Apr 2026 15:27:23 +0000

I built 77 free developer tools that run 100% in your browser (No tracking, no backend)

Hey DEV community 👋

If you are anything like me, you've probably had that moment of hesitation right before pasting a JWT, an AES key, or a proprietary JSON payload into a random online formatter.

Is this site logging my input? Is there a backend saving this?

I got tired of the paranoia, so I spent the last few months building CipherKit.

👉 [Live Site: https://cipherkit.app/)
👉 GitHub Repo (I'd love a star if you find it useful!)

What is CipherKit?

It is a unified suite of 77 developer utility tools. But the core rule of the project is simple: Everything must be 100% client-side.

There is no backend. There is no database. No login is required. The calculations, encryptions, and formatting happen entirely within your browser's memory using vanilla JS and the Web Crypto API. Your data never leaves your device.

What's inside the toolkit?

I split the tools into 5 main hubs to keep things organized:

🗝️ Crypto Hub: AES Encryption/Decryption, SHA-256/512 Hashing, RSA Key Pairs, Bcrypt, JWT Builder, and TOTP generation.
🔗 Encoding Hub: Base64 (Standard & URL-safe), URL, HTML Entity, Hex, and Binary encoders/decoders.
🔄 Converter Hub: Instant XML↔JSON, YAML↔JSON, CSV↔Excel, and Markdown↔PDF transformation.
💻 Dev Hub: UUID Generator, interactive Regex Tester, Cron Expression Builder, SQL Formatter, and a professional-grade Text Diff & Merge workspace.
🖼️ Image Hub: QR Code generation, SVG↔PNG conversion, multi-format Image Resizers, and color code utilities.

The Tech Stack

To keep it fast and secure, it's built with pure HTML, CSS, and JS, and hosted for free on GitHub Pages. No heavy frameworks, just instant load times.

Feedback Welcome!

Since this is built for developers, I would love to hear your thoughts.

What tools are missing from your daily workflow?
Do you catch any edge cases in the crypto implementations?
What would make you bookmark this?

Drop a comment below or open an issue on the repo!