JavaScript has been the main language of the web for years. Its popularity probably surprised even its creator, Brendan Eich, who famously built th...
For further actions, you may consider blocking this person and/or reporting abuse
I think the root problem is our programming language don't give help to GPU programming paralell with a multi core CPU. So I think the best solution will be creating a programming language based on that root.
That's an interesting idea, and it makes me curious whether anyone is actively working on something like that.
When WebAssembly became a standard, there was a lot of talk about how JavaScript would soon be replaced. But that didn’t really happen. Instead, JavaScript kept getting faster, and WASM mostly found its niche in heavy computations, rather than replacing JS for everyday application logic.
WebGPU is also a great example here. It gives us powerful access to the GPU, but it comes with quite a bit of boilerplate and complexity, which makes it impractical to use for every situation or for every large loop in an application.
So for now, it feels like we’re still living in a world where each tool has its place: JavaScript for general logic, WebAssembly for heavy compute, and WebGPU when the workload truly benefits from massive parallelism.
A first I work a better wasm text format, if that will be working at least POC level, then maybe moving forward.
That sounds interesting! A more human-friendly text format for WASM would definitely make experimentation much easier.
Curious to see where it goes if you get a POC working, keep us posted! 🙂
Great deep dive! I really appreciate that you actually built and benchmarked this instead of just theorizing. The particle simulation results are particularly instructive - they show that GPU go brrr isn't magic; you need the right workload.
Your observation about Canvas 2D also hitting the GPU is something many developers miss. The browser's rendering pipeline has gotten incredibly sophisticated, and for simple 2D work, the abstraction overhead might not be worth dropping down to WebGPU.
The matrix multiplication results are exactly what I'd expect - this is where GPU compute truly shines. And your image processing benchmark reinforces that.
One thing I'd add: WebGPU's real killer app might be in areas we haven't fully explored yet - like running ML inference locally in the browser (imagine client-side LLMs or image models without phoning home), or complex simulations for data visualization. The privacy and latency benefits of keeping that computation client-side are huge.
The boilerplate warning about LLMs is also timely. I've noticed the same thing - Copilot and Claude often generate WebGPU code that looks right but has subtle bugs, especially around buffer management and synchronization.
Question for you: did you test power consumption or thermal throttling? I'd be curious if the GPU version runs cooler on integrated graphics vs. the CPU pegging a core at 100%.
Good luck at jsDay!
Thanks a lot for the thoughtful comment and the feedback — I really appreciate it! 🙂
I didn’t test power consumption or thermal throttling yet, but that’s actually a fantastic idea. Now that you mention it, it would be a very interesting dimension to benchmark — especially on laptops with integrated GPUs. I might add it in a future experiment.
And I completely agree with your point about ML in the browser. We’re already starting to see this happening. For example, in Transformers.js you can switch the runtime to
device: "webgpu"and inference becomes much faster compared to the CPU/WASM path. It’s a really exciting direction for client-side AI.Thanks again for the great comment — and for the jsDay wishes! 🚀
You really are such a good writer. You have this way of making technical topics feel sharp, clear, and honestly just enjoyable to read.
I loved how confident and elegant this felt without ever becoming heavy or showy. That balance is rare.
Really beautiful piece. 😊
Thank you so much — that really means a lot, especially coming from such a great writer as well! 😊
Aw, that’s really kind of you to say, thank you.
You have a very effortless way of writing that I genuinely admire, so that means a lot coming from you. 😊
Hi Sylwia,
Great post again. So interesting. You know each time i read your posts on webGPU i have the idea of getting into it (and thinking what else can be done with this) and then i hardly remember that i am already working on quite a lot which i cannot spare enough time. :) Glad that you are already doing great stuff.
Anyway, wish you great time and talk in Bologna.
Thanks a lot, I really appreciate it! 🙂
And honestly, if you’re already busy learning and working on other things, it’s totally fine to keep WebGPU on the shelf for now. It’s quite a low-level API, so it’s not necessarily something everyone needs to jump into immediately.
In many cases it’s already enough just to know that it exists and roughly what kinds of problems it’s good for — then if a use case appears one day, you know where to look.
Thank you. Exactly, so many things in my plate now, i need to carefully plan and prioritize or i will end up doing nothing :)) .
But i really enjoy your posts and demos. Keep going. best.
Great article, Sylwia
And the benchmarks really illustrate the point well. The boilerplate problem you mentioned is exactly what pushed me in a different direction.
I've been working on an open source project called Forge 4D (codeberg.org/CrowdWare), which takes a different approach: instead of writing WebGPU or Three.js by hand, you describe your 3D scenes and UI declaratively, and Godot (open source game engine) handles the rendering pipeline underneath - Vulkan and Metal included.
The idea is that for a lot of use cases - app prototypes, architectural visualizations, interactive 3D content - you don't actually need to touch GPU APIs at all. The engine does the heavy lifting, and you get 2D/3D scenes, animation, and video playback out of the box.
We also have a GreyBox → Stylized Video pipeline where a simple scene gets passed through an AI styling step (Grok) and comes out as a rendered video - no full production assets needed.
Might be interesting if you're looking at what comes after the WebGPU boilerplate layer. The project is still early but fully open source — happy to share more if you're curious!
Thanks a lot! That sounds like a really interesting approach — I’ll definitely take a look at the project.
Of course Vulkan and Metal are much more powerful and flexible than WebGPU, but they’re also significantly more verbose and complex. So building a layer that lets people work at a higher level makes a lot of sense, especially for prototyping and interactive 3D applications.
At the same time, I think in many cases WebGPU will simply be “good enough”, particularly for things like compute shaders and general GPGPU workloads in the browser. It’s not really meant to replace Vulkan or Metal — just like JavaScript was never meant to replace C++. It just needs to be good enough for a huge number of use cases.
Ofc, there are always use cases where it is better or easier to publish on the web.
Just wrote a book for devs today. If I am going to publish it via KDP I have to invest a few hours more to create a proper .epub file, fill out all formular fields on KDP and press "Publish".
A minute ago I just put it on the web without this form filling, because I wanted it to come out today on Friday the 13th for some reason. Now its online, at least the preface ;-)
Same is true for 3D Art or the like.
Congrats on publishing the book! 🎉
At least share the title — now I’m curious 🙂
I'll definitely take a look, thanks 😀
I'm blown away by the idea of leveraging WebGPU in JavaScript for tasks that really tax the GPU. It's mind-boggling to think that we can get such a significant boost in performance just by offloading tasks like matrix multiplication to the GPU. I can only imagine the kinds of possibilities this opens up for computationally intensive applications. What really has me curious is how this might impact the development of more complex simulations and graphics processing.
Totally! 🙂
We did have WebGL before, but without compute shaders it was always a bit of a workaround. If you wanted to do general computation, you basically had to pretend you were rendering something — usually some triangles — and sneak your math into fragment shaders.
With WebGPU, we finally get proper compute pipelines, so the GPU can just… compute. No more pretending we’re drawing triangles just to run some calculations 😄
That’s what makes it so exciting for simulations, data processing, and all kinds of compute-heavy tasks in the browser.
I do not understand the effort to turn the browser into OS and pages into apps.
Today it is harder to build a browser than a full OS and no one understands what these monsters do. And what is the point in running someone's external source on your machine by just clicking a link?
If the user needs the app why not sell him the binary for his machine? You make money - he gets real native performance. On the other hand if he doesn't need it - you are literally raping him by forcing him to execute unwanted code. This is EVIL :)
I think it’s a bit more nuanced than that. 🙂
In practice, many people actually prefer having applications in the browser because it’s simply convenient. You don’t need to install anything, updates are instant, and you can access the same tool from different machines. There are many examples of this — Figma is a good one. It does have a desktop app, but a lot of people still love opening it directly in the browser.
It’s also not quite the same as running arbitrary external binaries on someone’s machine. Technologies like WebGPU or WebAssembly still run inside the browser’s sandbox and security model. That’s why people often say near-native performance, not native performance — the browser remains a controlled environment.
At the end of the day, it mostly comes down to demand. Many users and companies clearly want powerful applications in the browser, so naturally the ecosystem evolves in that direction. If there’s demand, there will be supply. 🙂
That is a good step. However I am not concerned what the code can touch.
Who controls the code is the problem. When the code is binary sitting on your machine you can trust it to do do the same thing when you execute it, but that is not the case with code coming from some server. It constantly changes, maybe working today but not tomorrow, or the result today may not match the result 3 months in future. No one can start a serious project depending on unstable environment. This is the problem also with Rust which you are using. Your code today may not compile in 5 years. Huge code base may become pain to refactor and doing so may introduce issues in previously stable code. In my view someone using Rust means he is not serious about the project.
Sometimes those new languages are forced on us by the big players but their effort is to destroy independent codebases. At the end everything is just CPU instructions so constant introduction of new languages is deliberate effort to fail us.
Honestly I really like that you showed a case where WebGPU doesn’t magically win. A lot of posts about GPU compute basically assume “GPU = always faster”, but your particle example shows that the overhead and the type of workload matter a lot.
many devs (myself included until recently) mentally picture JS → CPU and WebGPU → GPU, but in reality the browser pipeline is already doing a ton of GPU work under the hood. So sometimes you’re not replacing CPU work, you’re just bypassing an already highly optimized abstraction.
The matrix multiplication result is where things get really exciting though. It really highlights that WebGPU isn’t about making everything faster, it’s about unlocking a whole category of workloads in the browser that used to be unrealistic.
Also appreciate live demo .
Thanks a lot, I really appreciate the thoughtful comment! 🙂
The particle result actually surprised me as well at first, because everywhere you read that WebGPU should win in that kind of scenario. But when I started digging into it and looking more closely at how the browser pipeline works, it began to make much more sense.
And yes, as someone who doesn’t come from a computer graphics background, the part that excites me the most is definitely things like matrix multiplication and the fact that we can finally do GPGPU-style workloads in the browser thanks to compute shaders. That really opens up a whole new category of possibilities.
Excellent points, Mila and Sylwia. This highlights exactly why I built the Alpha Protocol.
Most developers are struggling with the 'overhead' because they are operating in a stochastic environment—where the browser and the GPU are still 'guessing' how to sync. This is the Einstein Gap in action.
My infrastructure doesn't just 'use' the GPU; it enforces Deterministic Finality through a hardware-verified middleware layer. By using Synchronization Suppression (Patent 19/564,148), we eliminate the very overhead you’re seeing in the particle examples. We aren't just making workloads faster; we are making them Sovereign.
I am currently licensing this infrastructure to bridge the gap between probabilistic AI and deterministic hardware. If you're interested in how we use the 52 Theorems to bypass these 'optimized abstractions' and achieve Level 5 Autonomy, check out the Biological-Digital Seal documentation in my latest post.
The future isn't just GPGPU; it's Deterministic Quantum Infrastructure.
The Seal is active."
Great write‑up — love how you paired clear explanations with real benchmarks to show where WebGPU truly shines. Thanks Sylwia 💯
Thanks a lot, I’m glad you enjoyed it! 🙂
Now we just need this technology to become fully stable everywhere and across all platforms — then things will get really interesting. 🚀
We hit the same thing in an internal browser tool that processes geometry. Pure JS on the CPU started choking around ~200k elements. After moving the core compute step to GPU, processing time dropped from seconds to a few dozen milliseconds.
Thanks for the comment! That really confirms the point nicely. It’s great that we can now do this kind of thing in such a neat way directly in the browser with WebGPU. 🚀
Ran your demo on a mid-range laptop and watching WebGPU hit roughly 4x the throughput of an equivalent Canvas2D loop in real-time was a genuine wake-up call I've been shipping CPU-side particle systems in production for two years without questioning it, and this benchmark finally gave me the visual proof I needed to justify the refactor. It actually reminded me of some performance-focused work I came across from Nadcab Labs, where pushing compute boundaries is kind of their thing, so seeing this level of optimization surface in the browser feels like the ecosystem is finally catching up. The live side-by-side is honestly the most convincing argument you could have made, better than any blog post I've read on the topic. Bookmarked, shared with my team, and already halfway through rewriting our fluid sim. Excellent work.
Thanks a lot for the comment — that honestly made my day! 🙂
And yes, WebGPU is really amazing. At the same time it’s still not available everywhere yet, so in many real-world projects (for example in e-commerce) it’s usually a good idea to have a fallback to older technologies as well.
amazing compilation especially the matrix multiplication part Its very illustrative. I had done a similar webGPU test and in more intensive parallel computations the difference is really striking seeing these boundaries in action is always fascinating
Thanks a lot! Glad you found it interesting. 🙂
That sounds great — do you happen to have a repo for your test? I’d love to take a look. 😄
Really appreciate that you actually showed a case where WebGPU didn't win. Most articles about GPU compute just cherry-pick the impressive results and leave you thinking everything should be offloaded to the GPU.
The Canvas 2D detail is something I didn't know about — the fact that browsers already use Skia/Dawn under the hood means you're basically competing with the browser's own GPU pipeline when you use WebGPU for simple stuff. That explains a lot.
Curious about one thing: for the matrix multiplication benchmark, did you try different matrix sizes to find the crossover point where WebGPU starts beating JS? There's gotta be some threshold below which the overhead of setting up the compute pipeline actually makes it slower. Would be interesting to see where that line is.
Thanks for the great comment!
That’s a good question. In this benchmark I actually focused on larger matrices, because those are usually the cases we care about in practice.
Most real-world scenarios where matrix multiplication matters (ML, simulations, graphics, etc.) tend to involve fairly large matrices anyway. In my tests, WebGPU was already clearly winning from around N = 256, so I didn’t spend much time trying to find the exact crossover point where it starts beating JS.
It would definitely be interesting from a benchmarking perspective, though.
Unfortunately, afaik NO browser on Linux has a stable implementation of WebGPU.
That’s a fair point. Linux support has been a bit more uneven so far, mostly because WebGPU depends heavily on the GPU drivers and the underlying graphics stack (Vulkan etc.). Hopefully it will stabilize there soon as well, the ecosystem seems to be moving in that direction.
It's been "there soon" for several years now, unfortunately.
Hahahaha 🤣🤣🤣 Hopefully it won’t be that bad though. WebGPU is still a pretty new technology after all, Firefox only shipped a stable implementation of the API in December 2025, so the ecosystem is still catching up a bit.
Great benchmarks, but I think the "turbocharger" analogy misses a crucial architectural point.
WebGPU isn't just a turbo for a race car; it’s a dedicated bus lane. Even if you're driving a standard sedan (a simple task), having that dedicated lane means you never get stuck in the "traffic jam" created by the JavaScript Event Loop.
For a Senior Engineer, it’s not always about raw throughput—it’s about guaranteed latency and system responsiveness. By offloading even simple compute tasks to the GPU, we ensure the Main Thread stays 100% free for UI/UX, making the app feel "instant" regardless of the background load. It’s a design choice, not just a speed chase.
That's a really interesting way to look at it — I like the "dedicated bus lane" analogy.
You're absolutely right that offloading work from the main thread can be valuable not just for throughput but also for responsiveness. Keeping the UI thread free is often more important than squeezing out the last bit of raw performance.
At the same time, I think there's still a trade-off. For smaller workloads the setup overhead of buffers, pipelines, and dispatch can easily outweigh the benefit, which is why the particle example behaved the way it did. In many cases developers might also solve the responsiveness problem with Workers rather than GPU compute.
So for me the interesting part of WebGPU isn't necessarily replacing CPU work in general, but unlocking workloads that were previously unrealistic in the browser — things like large matrix operations, simulations, or ML-style computations.
But I really like the architectural perspective you mentioned. That's a great way to frame the discussion beyond just "GPU = faster".
Really interesting benchmark. I like that you tested practical scenarios instead of just theoretical comparisons. The particle example was surprising, but the matrix multiplication result shows exactly where GPUs shine — large parallel workloads. WebGPU definitely feels like something more frontend developers will start experimenting with soon.
Thanks a lot! I’m glad you found it interesting. 🙂
That was exactly the idea — to test a few practical scenarios instead of purely theoretical comparisons. The particle result surprised me a bit as well, but it was a good reminder that GPUs really shine only when the workload is heavily parallel.
And yes, I have the same feeling — WebGPU still feels a bit niche today, but I think more frontend developers will start experimenting with it as the ecosystem matures. 🚀
Have a great time at jsDay! Will the talks be recorded? Would be super interesting to watch 🙂
Thank you so much!
Yes, the talks will be recorded, and I’ll definitely share the recording once it’s available. 🚀
I agree with you! LLM is great to verify your code but AI get stuck in a Loop. You still need to verify the code of the AI.
Exactly, Ben — as always, right on point! 🙂
AI can be a great help, but in the end we still need to verify what it produces.
Exactly!
Great article, personally I didnt know about the WebGPU also the playground is amazing to really see how it works by firsthand
Thanks a lot! That was exactly my goal — to make it easier to see how it actually works in practice. 🙂
Amazing Post, very nice demo app had fun with it. 😊
Thanks a lot! 😊
Great deep dive!
Thanks!!! ☺️
Hi everyone, I’ve decided to sell the entire IP, codebase, and data for my latest project.
I’ve built a robust, production-ready API engine designed for grocery retail and e-commerce. Due to a shift in my personal focus, I’m looking for an immediate exit.
What you are getting:
-The Engine: High-performance
API built for speed.
Why this is valuable:
Retailers like Tesco, Walmart, or BinDawood are desperate for tools that drive Private Label conversion. My App does exactly that by suggesting safe store-brand alternatives the moment an allergen is detected.
The Deal:
I am looking for a clean, fast acquisition. If you are a developer looking for a head-start, a SaaS founder, or a retail-tech scout, this is a plug-and-play asset.
Interested? DM me here for technical documentation and price discussion. I’m available all day
Do You Finish What You Start? 🚀
TheBitForge ・ Mar 15
Do You Finish What You Start?
Quality content. Looking forward to more articles from you.
Learned something new today. Thanks for putting this together!