3D in the Browser: Technologies and Frameworks

3D in the Browser: Technologies and Frameworks

The web has quietly become a serious platform for 3D experiences. What started as simple spinning cubes has evolved into product configurators for major brands, data visualizations for scientists, full-scale games, and immersive AR/VR experiences — all running in a browser tab, no installation required.

The Core Technologies Powering Web 3D

At the foundation, there are a few key technologies that make all of this possible. Think of them as the layers of a cake — each builds on the one below.

WebGL 2 is the universal baseline. It's been in every browser for years, it's stable, and it has a massive ecosystem of tools and libraries. If you're building for the web today, WebGL 2 is what your code ultimately runs on, whether you write it directly or use a framework on top.

WebGPU is the shiny new arrival. It's a modern, lower-level graphics API that gives developers more direct control over the GPU — similar to Vulkan, Metal, or DirectX 12 on native platforms. It enables compute shaders (using the GPU for general math, not just graphics), better multi-threading, and more predictable performance. Browser support is growing fast: it's shipping in Chrome and Edge, available behind a flag in Firefox, and in Safari Technology Preview. For new projects where performance matters, it's worth paying attention to.

WebXR is how you bring virtual and augmented reality to the browser. It's the standard API for VR headsets like Meta Quest, Apple Vision Pro, and even simple Cardboard viewers, as well as AR on phones and tablets. WebXR handles the complex work of tracking head position, rendering stereo views, and managing controller input — so you can focus on building the experience.

WebAssembly (Wasm) deserves a mention too. It lets you run code written in C++, Rust, or other languages at near-native speed in the browser. This is how heavy engines like Unity, Unreal, and Godot can export to the web — they compile their C++ core to WebAssembly and run it alongside JavaScript.

Finally, GPU texture compression formats like Basis Universal and KTX2 let you ship textures that stay compressed in GPU memory, saving bandwidth and memory — crucial for mobile devices.

High-Level Frameworks: You Probably Don't Want to Write Raw WebGL

Writing raw WebGL is like building a car engine from scratch — possible, but rarely the best use of your time. Frameworks handle the boilerplate, provide useful abstractions, and let you think in terms of scenes, objects, and materials instead of buffers, shaders, and draw calls.

Three.js is the undisputed king of the ecosystem. It's been around since 2010, has a massive community, excellent documentation, and works with every major 3D format. It gives you a scene graph (a tree of objects), cameras, lights, materials, geometries, animation systems, post-processing effects, and loaders for GLTF, OBJ, FBX, and more. The React ecosystem has embraced it through React Three Fiber (R3F), which lets you write Three.js scenes declaratively as React components — a game-changer if you're already building with React.

Babylon.js takes a different approach — it's more like a full game engine in the browser. It has a powerful visual editor, built-in physics, a node-based material editor, excellent TypeScript support, and a first-class WebXR implementation. If you're building something game-like or need an editor-driven workflow, Babylon.js is a fantastic choice.

PlayCanvas is unique because it's cloud-native. The editor runs in your browser, your project lives in the cloud, and multiple people can collaborate in real time. It uses an entity-component system architecture and is popular with teams building playable ads, instant games, and collaborative 3D tools.

A-Frame takes a declarative, HTML-like approach. You write 3D scenes as custom HTML elements: , , . It's built on Three.js but exposes an entity-component-system that feels natural to web developers. It's especially popular for WebXR projects and educational use.

OGL is the minimalist's choice — just a few kilobytes, no opinions, just a thin layer over WebGL. Great for size-constrained projects like banner ads or when you want to build your own abstractions from scratch.

The React Ecosystem: Component-Driven 3D

If you're a React developer, React Three Fiber (R3F) is transformative. It's a React renderer for Three.js — meaning you write your 3D scene using JSX, just like your UI. , , become components. You get all of React's power: hooks for animation, context for state, suspense for async loading, and the entire React ecosystem.

The R3F ecosystem has grown rich with helpers. @react-three/drei gives you dozens of ready-made components: orbit controls, HTML overlays, text, environment maps, loaders, and more. @react-three/postprocessing brings post-processing effects. @react-three/rapier and @react-three/cannon-es add physics. You can build surprisingly complex 3D apps with very little boilerplate.

For WebXR in React, there's React XR, which brings the same declarative approach to AR/VR development.

File Formats: glTF Is the JPEG of 3D

If you're putting 3D on the web, glTF 2.0 (GL Transmission Format) is the standard. It's often called the "JPEG of 3D" — a royalty-free, efficient, runtime-ready format maintained by the Khronos Group (the same folks behind WebGL and WebGPU).

glTF comes in two flavors: .gltf (JSON + separate binary/data files) and .glb (everything in a single binary file). For the web, .glb is usually preferred — one file, one request, easy caching.

glTF supports physically-based rendering (PBR) materials out of the box — metallic/roughness workflow, normal maps, occlusion maps, emissive maps. It handles animations, skeletal rigging (skinning), and morph targets (blend shapes). For compression, Draco reduces geometry size dramatically, and KTX2/Basis Universal handles texture compression that stays compressed on the GPU.

Other formats exist — USDZ for Apple's AR Quick Look, FBX and OBJ as legacy interchange formats — but for web delivery, glTF is the answer. Avoid FBX/OBJ for production web use; they're verbose, lack standardization, and don't compress well.

The Asset Pipeline: From Modeling to Browser

Getting a 3D model from your modeling software into the browser efficiently involves a few steps.

Modeling happens in tools like Blender (free and excellent), Maya, Cinema 4D, or Modo. When exporting, use the official Khronos glTF exporter for Blender — it's maintained by the spec authors and produces the cleanest output.

Optimization is where the magic happens for web performance. glTF Transform (a command-line tool) can apply Draco geometry compression, resize and compress textures to KTX2/BasisU, generate mipmaps, remove unused data, and more. Meshoptimizer further compresses vertex and index buffers. The glTF Validator catches spec violations before you ship.

For hosting, use a CDN with proper CORS headers and support for HTTP Range requests — this enables progressive loading of large models. Some teams use specialized 3D CDNs that handle format conversion and optimization on the fly.

Physics and Interaction: Making It Feel Real

Static 3D is pretty; interactive 3D is engaging. For physics, the main options in the JavaScript/Wasm world are Cannon-es (a lightweight port of Cannon.js), Rapier (a fast, modern Rust-based engine compiled to Wasm, with excellent R3F integration via @react-three/rapier), Ammo.js (a port of the industry-standard Bullet physics — powerful but heavy), and Jolt Physics (a newer, very fast Wasm port).

For interaction, raycasting is the fundamental technique — shooting an invisible ray from the camera through the mouse/finger position to see what 3D object was hit. Libraries provide ready-made controls: OrbitControls for rotating around an object, DragControls for moving things, TransformControls for gizmo-style translation/rotation/scaling. In WebXR, you get controller-based interaction — pointing, grabbing, teleporting — handled by the framework's XR integration.

Performance Budgets: Keeping It Smooth

The web is a hostile environment for performance. Users are on everything from flagship phones to five-year-old laptops. Targeting 60 frames per second means you have 16.6 milliseconds per frame. For VR, you need 90fps (11.1ms) or even 120fps (8.3ms).

Rough budgets to aim for: under 100k triangles for mobile, under 1M for desktop. Under 50 draw calls is ideal; under 200 is acceptable. Texture memory under 100MB on mobile, 500MB on desktop. Shader complexity matters — avoid dynamic branching, limit texture samples, keep instruction counts low.

Profiling tools are your friends. Chrome DevTools' Performance tab, Spector.js for frame capture, three.js's built-in stats panel, and detect-gpu for tiering devices at runtime. The key insight: measure on real devices, not just your development machine.

Progressive Enhancement: Graceful Degradation

Not every device can run your fancy 3D scene. Progressive enhancement means providing a usable experience everywhere, then layering on 3D where supported.

Start with a 2D fallback — a hero image, a carousel, a static chart. Detect WebGL support (and WebGPU, WebXR) at runtime. For low-end devices, serve lower-polygon models, smaller textures, and disable expensive effects like shadows, bloom, or screen-space reflections. Tools like three.js's detectGPU or the WebGL Report can help classify device capability tiers.

The goal isn't to make everything look identical everywhere — it's to make the core experience work everywhere, and make it shine where the hardware allows.