Two things keep coming up in web development conversations lately: WebAssembly and edge computing. They're often mentioned together, they sound like they'd fix everything, and for most websites they won't. They're still worth understanding, because for the right problem they make a big difference.
WebAssembly in one paragraph
WebAssembly, or Wasm, is a compact format for code that browsers (and now servers) can run at close to native speed. You write in a language like Rust, C++ or Go, compile it to a Wasm module, and run it inside a sandbox that limits what it can touch. It doesn't replace JavaScript. JavaScript still runs the page; Wasm takes over the heavy lifting where JavaScript struggles.
You've probably used it without knowing. Browser-based design tools, video editors, PDF viewers and some games use Wasm for the parts that need real speed.
Edge computing in one paragraph
Normally your site answers every request from one place, say a data centre in Frankfurt. Someone in Dhaka waits for the round trip. Edge platforms run your code in dozens or hundreds of locations, so the nearest one answers.
It's related to a CDN but not the same thing. A CDN mostly stores copies of files near users. Edge computing also runs your code there, so it can make decisions: redirect, check a login, pick a language, or build a response.
Why they show up together
Wasm modules start quickly and run in a tight sandbox, which suits edge platforms well. Many of them let you deploy Wasm, so a single module can run in the browser, on your server and at the edge. That portability is the appealing part.
Where they help
If your web app does heavy work on files, like resizing images, converting documents or processing audio, doing it in the browser with Wasm saves a trip to your server. It also means private files never leave the user's machine, which is a real selling point for some products.
If you have global users and a slow first response, edge code can handle simple logic (authentication checks, redirects, A/B tests) before the request ever reaches your main server.
Where they don't
A content site or a typical business website usually gets most of the possible gain from good caching, optimised images and a sensible hosting region. That's far less work than learning a new platform.
Edge doesn't help much if every request still needs your central database. The code runs near the user, but the data is still far away, so you've moved the delay rather than removed it. There are edge-friendly databases, but that's a bigger change.
And there's the people side. Debugging a compiled module running across many locations is harder than debugging a PHP page. Make sure you have someone who enjoys that.
How we'd decide
Start with a measured problem: a slow API in a distant region, or a task that freezes the browser tab. Try the cheap fixes first. Add CDN caching, compress images, move the work to a background job. If that isn't enough, pilot Wasm or edge on one small feature and compare timings and costs against what you had.
If a vendor tells you the whole site needs to move to the edge, ask what number it will improve, and by how much. A good answer has a figure in it.
