A lot of the browser 3D talk here defaults to three.js, and for good reason, but it is a rendering library rather than an engine and the gap shows up the moment you need scenes, physics and a build pipeline. This is a short breakdown of where PlayCanvas sits for anyone weighing that choice.
The Runtime Is Small
PlayCanvas ships under 300KB gzipped. It renders through WebGPU where the browser supports it, which is worth roughly 25 to 50 percent on complex scenes, and it falls back to WebGL 2 automatically rather than making you branch on it yourself.
It Is An Engine, Not A Renderer
The architecture is entity component system. You compose entities from models, cameras, lights, physics bodies and scripts, which keeps a project navigable as it grows. Scripting is plain JavaScript and TypeScript, so there is no new shader language or build toolchain to adopt for normal work.
The Editor Is Collaborative
The editor runs in the browser and several people can work on the same scene at once, the way a shared document works. That removes the usual pain of syncing large binary assets through version control, which is where a lot of small teams quietly lose time.
Where It Costs You
The cloud editor is the tradeoff. Your project lives on their infrastructure, and while the engine itself is MIT licensed, the editor workflow is the part you are buying into. If that matters to your team it is worth deciding early, rather than after the asset pipeline is built.
Full write-up with the deployment and performance details: PlayCanvas game development