// the find
phaserjs/phaser
Phaser is a fun, free and fast 2D game framework for making HTML5 games for desktop and mobile web browsers, supporting Canvas and WebGL rendering.
Phaser is a mature HTML5 game framework that's been around for over a decade, now on version 4 with a completely rewritten WebGL renderer. It targets JavaScript/TypeScript developers building browser games, and has strong support for niche platforms like YouTube Playables, Discord Activities, and Facebook Instant Games. The v4 release is a real architectural overhaul, not a marketing bump.
- The new render node architecture in v4 is a genuine improvement: proper WebGL state management, context loss handling, index buffers for quads (1/3 fewer vertex uploads), and smarter multi-texture batching. These are real perf wins, not just claimed ones.
- SpriteGPULayer and TilemapGPULayer are impressive additions - storing member data in static GPU buffers and rendering everything in a single draw call is the right approach for large sprite counts, and the per-pixel tilemap shader is a clever solution to the tile-count scaling problem.
- The `skills/` folder of AI agent context files is a smart, practical idea. It's structured knowledge for coding agents rather than just hoping LLMs have absorbed the docs. The v3-to-v4 migration skill in particular shows awareness of how developers actually use AI tools.
- 345KB gzip for the full build including physics, particles, tilemaps, tweens, audio - that's genuinely compact. The unminified 8MB is explained honestly (it's JSDoc), which is refreshingly straightforward.
- The v3 to v4 migration is a real pain point. The renderer, tint system, FX/Masks, Shader API, and several classes (Mesh, BitmapMask, Point) are breaking changes. Anyone with a non-trivial v3 codebase is looking at significant rework, and 'point your AI at the migration guide' is not a complete answer.
- Matter.js physics integration has always been awkward in Phaser - it's a third-party library bolted on with a thin wrapper, and the v4 docs don't suggest this has changed. Arcade physics is fast but limited; anything complex quickly requires working around the abstraction layer.
- v4 is recent and the example library (2000+ examples) is heavily v3-era. Developers will frequently find relevant examples that use the old pipeline API, old FX system, or the removed Mesh object - the mismatch between available learning material and the new API is a real friction point.
- No built-in support for ECS or any data-oriented design patterns. The scene/gameobject inheritance model works fine for small games but becomes messy at scale, and there's no official guidance on architectural patterns for larger projects beyond the basic scene structure.