Hi everyone! This question is not really about Three js. I’m developing an application and so far I’m using Next.js with WebGL/WebGPU: everything works, but when doing complex rendering and handling large textures, the browser gets bogged down by its limitations. Now I’m thinking about a desktop version and direct access to the GPU via Vulkan to get a noticeable performance boost.
On the one hand, the web version is attractive because of its cross-platform, instant deployment and easy support: just send the user a link and they get access right away. On the other hand, a desktop application on Qt or Electron with native Vulkan can bypass browser limitations by providing higher frame rates, big data support, offline mode and direct access to the file system.
The crux of my question: in real-world projects, how much of the performance gain in moving to Vulkan justifies the effort of creating and maintaining two versions of an application? WebGPU is actively developing - maybe its capabilities are already enough? Or is the speed and capability gap between WebGL/WebGPU and Vulkan still critical?
I’m also considering a hybrid approach, where a lightweight web version remains for regular users, and professionals download the desktop version for complex tasks (particle simulations, heavy 3D rendering, batch model conversion). I’m interested in real cases and metrics: who has already experienced this kind of separation? How is the UX and dual customer support organisation structured in your experience?
I would be grateful for any opinions/wishes on what is really better to implement on desktop (maybe AI processing or other highly loaded operations?).
Okay, you got that right. In general, what I thought to implement in the web as a lightweight inspector I have succeeded. I realise that writing your own tools offline takes time and nuances. But in general I counted on removing browser limitations by direct interaction and writing code on a more productive variant. And besides I thought to make as displaying in the future on the site some results of model processing (AI, and some other highly loaded processes).
Which limitations are you referring to? All applications have to co-exist whether they are browser based or desktop.. (with the exception of some fullscreen games)
If you try to avoid this by using electron, it will inherit the same quirks as a browser, because electron is effectively bundling a browser with your code, and presenting it as an application.
If you really need to-the-metal performance, you may be better off switching to C++ or similar.
WebGPU can be implemented with a Vulkan backend, and apprently is.. on linux chrome/chromebooks.. on Windows, it’s implemented via Dx12 (according to google “AI” so ymmv)
Chrome on PC implements WebGPU with a Vulkan backend on Linux, and with Direct3D 12 on Windows. For ChromeOS devices, the backend is Vulkan.
I think because a native desktop app isn’t confined by the browser sandbox: it talks directly to Vulkan (or other graphics APIs) with no artificial memory caps, full multithreaded command-buffer recording and custom GPU pipelines, and it can load and stream massive assets or talk to hardware and the file system without CORS or JS-thread limits. That level of “to-the-metal” control simply isn’t possible in a bundled browser environment.
I’m not sure what AI you’re referring to, but most modern AI services don’t rely on the user’s hardware. Instead, they offload intensive computations to powerful server-side GPUs, Services like Onshape.com, Meshy.ai, and Leonardo.ai follow this model, handling all the heavy lifting on their backend, so the client device only needs to handle the interface and data transmission.
True. But in an electron app, you’re still using requestAnimationFrame etc… and running through a lot of the browser mechanics.. so it’s not clear to me that there is an automatic win scenario there.
Like.. how are you going to run your javascript in some kind of non-webworker thread?
It all sounds very non-trivial to me.. though I would welcome any surprises on that front.
If I was convinced that the browser was too underpowered to achieve what I needed, I would do it in C++ and just make a real desktop app. I haven’t really encountered any scenario in the last 10 years that pulled me in that direction though. Hell maybe I’d even use Unreal or Unity or smth.
End of the day.. you probably don’t want to attempt implementing the full scenegraph/rendering/shader compilation/texture management/memory management in vulkan.. in a way that works transparently with javascript. If you did do that.. you’d basically be writing a game engine, badly.
Yeah my bad.I understand AI workloads belong on powerful server GPUs, not the client. My desktop companion isn’t about local AI inference but about truly “offline” or heavy-lift tasks that browsers struggle with: things like batch model conversions, GPU-accelerated mesh processing, high-resolution texture streaming, direct filesystem workflows or hardware integrations. What offline capabilities have you found most practical and valuable in real-world projects?
I have no intention of re-implementing a full engine in Vulkan or shoe-horning JS into native APIs. I’m familiar with mature engines like Unity and Unreal for heavy lifting, and I agree that a pure C++ desktop app makes sense if the browser truly can’t keep up.
I came here to tap into the collective experience: what have you actually found most valuable to offload into a native desktop companion? Is it batch model conversion, GPU-accelerated preprocessing, local hardware integrations, offline asset management, or something else entirely? Any real-world lessons or shortcuts would be hugely appreciated.
My experience in this area is rather outdated. I started with OpenGL then moved to WebGL and I do not want to go back to desktop 3D. As this happened long time ago, things may not be relevant to your case. Anyway, switching from desktop to browser-based 3D had these advantages and disadvantages for me:
Advantages:
freedom - I was not bound to specific DLLs/SOs
quick run - no need to compile and link things
portability - easy to run on different OSes (Windows, Linux, macOS)
mobility - perfect for mobile devices
distribution - much easier to update distros, no need to install things over and over
Disadvantages:
performance - I have to be more careful about performance, but in the past the performance gap was huge, nowadays the gap is much smaller
file access - I miss the direct access to local resources (textures, models, …) - I hate CORS and SOP
hardware access - some access to hardware is more difficult via a browser (e.g. sensors data) or needs special permissions
GPU access - WebGL/WebGPU does not provide full access to all GPU features
Personally, I have decided that freedom and mobility are much important to me than performance. But other people may weight things differently. I have also found that in most cases slow browser-based 3D rendering was my fault.
A careful evaluation whether you hit a bottleneck because of the browser, or because of your personal ineffective use of data and WebGPU, might save you a lot of time.
it’s highly unlikely that the browser will be your bottleneck. and if that’s the case then check out Web Workers, they should solve any performance issues when it comes to intensive computations