The History of Browser Game Engines (Phaser, PixiJS)

Browser games used to mean Flash. Then they meant a chaotic period where everyone built their own engine. Then they settled, roughly between 2010 and 2013, into a small handful of JavaScript libraries that still power most of what you play in a tab today. The history of browser game engines is shorter and tidier than the desktop equivalent — but the milestones matter, and the four engines that emerged are still doing most of the work.

The pre-engine era: Flash and a void

Until the early 2010s, the dominant browser game runtime was Adobe Flash. Flash had its own scripting language (ActionScript), a vector renderer, and a mature toolchain. Almost every browser game on Newgrounds, Kongregate, and Armor Games was Flash. The Flash ecosystem had its own engines — Flixel, FlashPunk — but they ran inside the Flash player, not in the browser proper.

HTML5 began offering Flash-equivalent capability around 2010, with the canvas element (2008 spec, broad adoption by 2010), WebGL (2011), and Web Audio API (2011). The technology was there. The libraries weren’t yet. For a year or two, browser game development meant rolling your own engine from scratch on top of canvas, which is exactly as fun as it sounds.

Three.js (2010)

Three.js was first released in April 2010 by Ricardo Cabello (mr.doob). It was — and is — a JavaScript library that wraps WebGL with a more usable scene-graph API. Three.js handles cameras, lights, meshes, materials, and animation through a clean object model. It’s the closest thing the browser has to a universal 3D primitive.

Three.js itself isn’t a game engine — it’s a 3D rendering library. But thousands of games and interactive experiences are built directly on it. Many indie 3D browser games skip the heavier engines and use raw Three.js. The library is open source under the MIT License and remains actively developed.

The Three.js Wikipedia article covers its release history and major version milestones.

The 2013 trio: Phaser, PixiJS, Babylon.js

2013 was the year the modern browser game stack mostly arrived. Three projects launched within roughly a year of each other and settled into the niches they still occupy today.

Phaser (April 2013, Photon Storm)

Phaser was released by Photon Storm, a UK studio founded by Richard Davey. The first version targeted 2D HTML5 games with a Flixel-inspired API — sprites, groups, physics, input, audio, scenes. The goal was explicit: be the framework that lets Flash developers transition to HTML5 without rebuilding their entire mental model.

Phaser quickly became the most popular 2D HTML5 framework, and remains so through its Phaser 3 release (2018). It’s used in everything from indie browser games to commercial advertising games to educational software. The framework supports both Canvas 2D and WebGL rendering, with WebGL as the default for performance.

PixiJS (2013, Goodboy Digital)

PixiJS was developed at Goodboy Digital, a London creative agency, and released as open source in 2013. The original goal was a fast 2D rendering layer that could outperform raw canvas through WebGL acceleration while falling back to Canvas 2D when needed. PixiJS is intentionally not a game framework — it’s just a renderer.

That focus made PixiJS the go-to lower-level layer for projects that wanted to build their own engine on top. Phaser 3 uses PixiJS-influenced rendering. Many one-off games use PixiJS directly. The library is faster and lighter than full frameworks, at the cost of doing more work yourself.

Babylon.js (2013, Microsoft)

Babylon.js was created by David Catuhe and David Rousset at Microsoft, with the first public release in 2013. Unlike Three.js, Babylon.js positioned itself as a complete 3D game engine — with built-in physics, animation systems, audio, asset loaders, and a visual editor. It’s the heavyweight option for browser 3D.

Babylon.js is open source under the Apache 2.0 License and is used for serious 3D browser projects, including VR/AR experiences through WebXR. It runs alongside Three.js as one of the two dominant 3D options, with the split roughly: Three.js for “give me a rendering library,” Babylon.js for “give me a full engine.”

The interpreter era: Construct and GameMaker HTML5

Alongside the code-first frameworks, visual game makers entered the HTML5 market through the 2010s. Construct (Scirra, originally Construct Classic) added HTML5 export in 2011 and grew Construct 2 (2011) and Construct 3 (2017) as cloud-based browser-edited tools. GameMaker added HTML5 export in 2011 and refined it through GameMaker Studio (2012) onward.

These tools sit above raw frameworks. They produce JavaScript output, but the developer rarely writes JavaScript directly. For non-programmers and rapid prototypers, they remain a viable path. For developers comfortable with code, the frameworks (Phaser, PixiJS, Babylon.js, Three.js) generally win on flexibility.

The Unity/Unreal/Godot export wave

Major desktop engines added HTML5 export targets across the 2010s. Unity’s WebGL export landed in 2015, with steady improvements through subsequent versions. Unreal Engine had HTML5 export for a period (officially deprecated, but community-maintained). Godot’s HTML5 export is current and well-supported.

These exports use WebAssembly under the hood — the engine runtime compiles to Wasm, and your game code runs inside that runtime. The resulting bundles are larger than native JavaScript engines (often several MB versus a few hundred KB) but allow the developer to use the engine’s native workflow and export to the browser as one of many targets.

The trade-off is real. For small browser games, a Phaser or PixiJS project ships faster, smaller, and loads quicker than a Unity WebGL build. For larger projects with established Unity workflows, the export is the natural path.

The Three.js extension layer

Three.js is so widely used that an ecosystem of extensions has grown around it. React Three Fiber (2019) wraps Three.js in React’s component model, making it dramatically easier to compose 3D scenes declaratively. Drei (a sibling library) provides ready-made components — cameras, lights, controls — that compose with Three Fiber.

For browser 3D in 2026, the common stack for modern web games is Three.js plus React Three Fiber plus a small physics library like Rapier or Cannon. The combined stack is more capable than Three.js alone but more lightweight than Babylon.js.

The rise of Bevy and Rust-based engines

Newer entrants exist outside the JavaScript world. Bevy is a Rust game engine launched in 2020 that exports to the browser through WebAssembly. It’s not dominant yet, but it’s growing — particularly for projects that want strict type safety and high performance.

For most browser game projects, Bevy and similar Wasm-first engines are premature. The bundle sizes are larger, the tooling less mature, and the ecosystem narrower than JavaScript. But for performance-critical or simulation-heavy games, they’re a real option.

Why these engines won

Each of the four dominant projects (Three.js, Phaser, PixiJS, Babylon.js) won its niche through a combination of timing, open-source licensing, and active maintenance. They all released in the 2010-2013 window when HTML5 was maturing and Flash was visibly dying. They all had clear use cases that didn’t overlap too much. And they all maintained momentum through the rest of the decade.

By 2017 or so, starting a new browser game engine project from scratch made very little sense unless you had a specific reason. The four major libraries covered the space well enough that most developers picked one and got to work.

What this means for new developers

If you’re building 2D, start with Phaser or PixiJS. Phaser if you want a framework with batteries included; PixiJS if you want a faster renderer and don’t mind writing more glue. If you’re building 3D, start with Three.js (lighter) or Babylon.js (heavier, more batteries). All four are mature, well documented, and battle tested.

For more on what an HTML5 game actually is at the technical level, see our piece on HTML5 games.

Frequently asked questions

When did Three.js come out?

Three.js was first released in April 2010 by Ricardo Cabello (known online as mr.doob). It’s a 3D JavaScript library that wraps WebGL with a usable scene-graph API and has been actively developed under MIT License ever since.

When did Phaser come out?

Phaser was released in April 2013 by Photon Storm, a UK studio founded by Richard Davey. It became the most popular 2D HTML5 game framework within a few years of release and remains so through Phaser 3 (2018) and later versions.

Is PixiJS a game engine?

No, PixiJS is a 2D rendering library, not a full game engine. It handles drawing sprites and managing the WebGL/Canvas pipeline but doesn’t include physics, input handling, or scene management. Engines like Phaser sit on top of PixiJS-style renderers.

What’s the difference between Three.js and Babylon.js?

Three.js is a 3D rendering library — give me a scene, give me objects, render them. Babylon.js is a complete 3D game engine with physics, animation, audio, and asset management built in. Three.js is lighter; Babylon.js is more capable out of the box.

Should I use Unity WebGL or a JavaScript engine for browser games?

For small browser games, JavaScript engines like Phaser ship smaller and load faster. For large projects with existing Unity workflows, Unity WebGL export makes sense. The native JavaScript engines are usually the better choice for browser-first projects.

The takeaway

Browser game engines arrived in a narrow window between 2010 and 2013 and then stopped multiplying. Three.js, Phaser, PixiJS, and Babylon.js cover the space well enough that the next decade has been about refinement rather than reinvention. If you’re picking an engine for a new browser project today, you’re picking from these four (or their direct successors) — and that’s fine. They’re good. For a glimpse of what a tiny vanilla-JavaScript game can do without any of them, the Chrome Dino game still runs in around 100 KB.