Most Apps Are Slower Than They Need to Be — Here’s Why (Live Demo🛸)

Source: Dev.to

The Browser Is More Than a UI Layer

We’re a quarter into the 21st century, and the browser has quietly evolved into something much more than just a UI layer. It can:

• run complex computations,
• leverage the GPU,
• process audio,
• simulate physics, and
• even run machine‑learning models.

And yet… most of the time we still treat it like a tool for forms and dashboards.

I wanted to show what happens when we actually take advantage of what the platform already gives us.

A Quick Recap of the Event

The jsday conference in Bologna has just come to an end, and it was honestly amazing. If you’re wondering whether it’s worth attending events like this — it absolutely is. It’s an endless source of inspiration, far beyond what you get from articles or tutorials.

If you have a minute, I’d really appreciate a like on my LinkedIn post.

WebGPU + WebAssembly: Why Talk About Them Together?

If you’ve been following my posts, you probably know that my talk was about WebGPU and WebAssembly, and what we can gain by using them in the browser.

• WebAssembly runs on the CPU and lets us execute low‑level, compiled code directly in the browser.
• WebGPU, as the name suggests, gives us access to the GPU — not in some abstracted, limited way, but in a relatively direct and powerful form.

They are complementary by design.

Further Reading

• Will WebAssembly Kill JavaScript? Let’s Find Out (Live Demo)
• Why WebGPU Feels Like the Future of the Web (Live Demo)

A Concrete Example

Instead of talking about them in isolation, I built a small demo that combines both technologies.

• Repo:
• Live demo:

What does it do?
You type text into an input field, the text is converted into particles, and when you click‑and‑drag your mouse across it… the text explodes.

Completely useless? Yes.
Slightly addictive? Also yes 😅

Step 1 – Canvas 2D

The text from the input is rendered into an image bitmap using plain JavaScript and Canvas 2D. This is exactly the kind of task where classic browser APIs are already perfectly sufficient, and there’s no real reason to move it elsewhere — especially for a demo like this.

Step 2 – WebAssembly

The bitmap is passed to WebAssembly, where a deliberately “somewhat over‑engineered” algorithm maps the image into particles. I wanted WASM to actually have something meaningful to do, and let’s be honest — it also just looks cooler this way.

Benchmark: WebAssembly is roughly 2–3× faster than an equivalent JavaScript implementation (even after heavily optimizing the JS version).

In this demo the difference doesn’t matter much because the step runs only once during rebuild, but the order‑of‑magnitude gain becomes critical when the operation must be performed hundreds or thousands of times.

Step 3 – WebGPU

The particles are passed to WebGPU — and this is where the browser really starts to flex.

The same browser, the same app, the same machine — but a totally different level of performance, simply by using the right tool for the job.

When Do You Need This?

This isn’t your typical frontend CRUD setup. You probably don’t need WebGPU to build a dashboard or a form, and in many cases the real bottleneck is the network, not computation.

However, there are entire classes of problems where this approach makes a huge difference:

• Real‑time data visualization
• Physics simulations
• Graphics‑heavy interfaces
• Audio processing
• Games
• Image or video transformations
• Matrix‑heavy workloads (e.g., machine learning, LLMs) running directly in the browser

And the funny thing is, you don’t need this… until suddenly you really do. A product evolves, requirements grow, performance becomes an issue, or you want to move part of the workload from the backend to the client. That’s when things start getting interesting.

How Is the Demo Structured?

If you take a look at the repository, you’ll notice something important: this is just a regular React app.

• No exotic architecture, no “from another planet” stack.
• Yes, there’s Rust compiled to WASM and WebGPU shaders, but they’re simply embedded into a standard frontend setup.
• The rest of the app looks exactly like something you could start in your project tomorrow.

That was intentional. I wanted to show that this isn’t some distant, experimental playground reserved for niche use cases. It’s something you can already integrate into real‑world applications — incrementally, when you actually need it.

Note: WebGPU is not yet universally supported, so you’ll need a fallback strategy. But for a large portion of users there’s little reason not to start exploring it.

Takeaway

The browser is no longer just a place where we render UI.
It’s a serious compute platform — one that already gives us access to both CPU and GPU, right out of the box.

• You don’t need WebAssembly or WebGPU in every project. Most of the time you’ll be perfectly fine without them.
• When you start hitting performance limits, or your problem shifts from simple UI to heavy computation, those tools become game‑changers.

“moving data around” to “actually computing things”… you might realize that the platform already had the solution all along.
And all you had to do was use it. 🚀