The pitch for browser 3D has been the same for a decade: no install, no store approval, just a URL. What changed is that the runtime finally got good enough to make that pitch honest. PlayCanvas is one of the clearest examples, an open source 3D engine built specifically for the web, with a cloud editor sitting on top of it.
What PlayCanvas Actually Is
PlayCanvas started around 2011 from Will Eastcott and Dave Evans, and moved from a proprietary platform to fully open source under the MIT license, runtime and editor both. The engine is written in JavaScript and TypeScript, and it renders through WebGL 2.0 and WebGPU with automatic fallback depending on what the visitor's browser supports.
Architecturally it is an Entity Component System. Entities are the objects in your scene, components attach behaviour, and systems do the work. If you have written anything in Unity that model will feel immediately familiar, which is a large part of why teams pick it up quickly.
The output is the interesting part. There is no native binary at the end, no app bundle, no review queue. You get web output that runs in any modern browser, which is why it shows up in product configurators, architectural visualization and interactive advertising as often as it shows up in games. Snap and Animech have both shipped production work on it.
The Cloud Editor Changes The Workflow
The editor lives in the browser and the project lives on the server, so there is no engine install and no project folder to sync. Two people opening the same scene see each other's changes, which is closer to how a design tool works than how a game engine usually works.
That has a real consequence for small teams. The artist does not need a local toolchain, the developer does not need to package a build to show someone a change, and a reviewer just gets a link. For a solo developer or a team of three, cutting that friction out matters more than any single engine feature.
Rendering And The Mobile Reality
The engine handles physically based rendering, real time lighting and shadows, post processing, physics through ammo.js, and skeletal animation. The pieces you would expect are there.
The part worth planning for is mobile. Most of the traffic to a browser game arrives on a phone, and a phone gives you a tighter memory budget, a weaker GPU and a thermal ceiling that a desktop test will never show you. Texture sizes, draw call counts and how much you load before first render are the levers that decide whether the thing feels good or feels broken, and they need to be decided early rather than optimized in at the end.
Shipping Without An App Store
Deployment is a build and a static host. No submission, no review, no update cycle waiting on a third party. You can push a fix and every player has it on their next load.
The tradeoff is that discovery is now entirely yours. An app store is a bad gatekeeper but it is also a storefront, and a URL is not. Whatever you would have spent on store optimization goes into the page the game lives on instead.
Where It Fits
PlayCanvas is a good fit when instant access is worth more than raw ceiling: a game people should be able to try in one click, a configurator embedded in a product page, an interactive piece that has to reach people who will never install anything. It is a worse fit when you need the absolute top end of visual fidelity or a deeply native platform integration.
We put together a fuller walkthrough of the engine, the editor workflow, asset handling and the performance work, over at PlayCanvas game development.