LittleJS: a tiny HTML5 game engine with 2D, 3D and Box2D built in

What LittleJS is for, and who it is aimed at

LittleJS is a JavaScript game engine for the browser. The README describes it as "a fast, lightweight, and fully open source HTML5 game engine designed for simplicity and performance", and the package.json describes it as "Tiny and Fast HTML5 Game Engine". The stated feature set covers 2D and 3D rendering, physics, particles, sound and input handling, all in a package with no dependencies.

The audience is narrower than the feature list suggests. The README names size coding competitions directly, pointing at Js13kGames and a separate js13k branch that it says builds to a 7KB zip. It also lists TypeScript and module support with example projects for both, a Vite starter template, and an AI section with templates and prompts tuned for LLM-assisted workflows. So the project is aimed at people writing game code by hand, often in a single file, often against a byte budget.

That framing matters when you evaluate it. LittleJS does not present itself as a general-purpose engine you configure through an editor. It presents itself as a library you write against, with functions like gameInit and gameRender as the entry points. If your team's workflow assumes a scene graph you click on, this is a different shape of tool.

How the engine is put together: canvas, objects and plugins

The rendering layer is described in the README as a "WebGL2 + Canvas2D hybrid rendering system". Both paths share the same canvas, which is also how the 3D renderer is described: it "shares the canvas with your 2D game". That single shared surface is the central architectural decision. You do not run two contexts side by side, so a 3D object and a 2D sprite can be drawn in the same frame without compositing tricks.

3D objects are described as having "the same physics, children and timers as 2D". In other words, the 3D support is an extension of the existing object model rather than a separate scene graph. The README lists height map terrain with collision and raycasts, shadow maps, colored lights, specular, emissive glow, fog, and orbit, chase and first person cameras with mouse picking. There is also an optional Three.js plugin described as "an alternative renderer", which is a notable split: the built-in renderer is the default, and Three.js is a swap-in path for people who want it.

Physics comes in two layers. There is an arcade physics system with collision handling plus tilemap collision and raycasting, and separately "Full Box2D integration" using Box2D v2.3.1 compiled to wasm. Pathfinding is a plugin, described as grid-based A* with optional path smoothing. Audio supports mp3, ogg and wave files, and there is a ZzFX integration for generating sounds without asset files. The repository layout reflects the plugin model: top-level plugins/, src/, dist/, tools/ and test/ directories, with examples split into folders such as box2d, threejs, tweenSystem and particles.

Installing LittleJS and getting a first game on screen

There are two documented starting points. The npm package is named littlejsengine, and the README gives a single install command for it. The package's main entry is dist/littlejs.esm.js, with a production export pointing at dist/littlejs.esm.min.js and types at dist/littlejs.d.ts.

npm install littlejsengine

The second path is the Vite starter, which the README presents as an empty template. It uses degit to copy the template directory, then installs and starts a dev server.

npx degit KilledByAPixel/LittleJS/examples/vite-starter my-game
cd my-game
npm install
npm run dev

If you would rather not use a bundler at all, the README's minimal example is a plain HTML file that loads the engine from the installed package and defines the five engine callbacks. Note that gameRenderPost is where the hello world text is drawn, using drawTextScreen with mainCanvasSize scaled by .5 and a font size of 80.

<!DOCTYPE html>
<script src="node_modules/littlejsengine/dist/littlejs.js"></script>
<script>
function gameInit() {}
function gameUpdate() {}
function gameUpdatePost() {}
function gameRender() {}
function gameRenderPost() { drawTextScreen('Hello World!', mainCanvasSize.scale(.5), 80); }
engineInit(gameInit, gameUpdate, gameUpdatePost, gameRender, gameRenderPost);
</script>

What you should see is the text "Hello World!" centered on the canvas. The engine's own build script is npm run build, which runs node src/engineBuild.mjs, and the package requires Node 18 or newer according to its engines field. For learning the API, the repository points at a REFERENCE.md quick reference sheet, an FAQ.md, a Breakout tutorial directory, and a set of 80+ single-file demos under examples/shorts.

Where LittleJS gets awkward

The honest limitation is the one implied by the whole design: there is no editor. The README lists a live example browser with a code editor and an effect design tool for particles, and it mentions importing level data from Tiled or other JSON, but there is no scene editor in the repository, no prefab system described, and no asset pipeline beyond loading sprite sheets at runtime or importing TexturePacker and Aseprite atlases. Level authoring happens in Tiled and arrives as JSON. Everything else is code.

That has a cost that does not show up until the project grows. A team of artists cannot work in the engine. Iteration on layout means editing data in an external tool or editing numbers in source. The README does not document a hot-reload workflow outside the Vite starter, and it does not describe any rollback, versioning or migration story for saved level data.

There is a second boundary worth naming. The README states the engine is compatible with "all modern web browsers and mobile devices", which is a browser target, not a native one. The examples directory does contain an electron folder, but the README does not describe a supported desktop packaging path, and nothing in the repository describes console, iOS or Android store distribution. If your requirement is a shipped mobile app rather than a web page, this is the wrong layer to start from.

Size coding has its own trap. The js13k branch is described as building to a 7KB zip, but that is a separate branch with its own constraints, not the default main branch output. Assuming the main build is that small would be a mistake.

Picking between LittleJS and a full engine like Three.js

The most direct comparison in the README is the one the project makes itself: the optional Three.js plugin, described as "an alternative renderer". That framing is precise. Three.js is a rendering library, and LittleJS is a game engine that happens to include a renderer. If you adopt Three.js, you get a mature rendering layer and you assemble the rest yourself: the update loop, input, collision, audio, particles and object lifecycle are yours to write or to source elsewhere. If you adopt LittleJS, those systems arrive together and are designed to talk to each other, with 3D objects sharing physics, children and timers with 2D objects.

The trade is depth against integration. Three.js has a much larger ecosystem of loaders, controls and post-processing, and the plugin implies you can keep that ecosystem if you want it. LittleJS gives you a smaller API surface, which the README argues is a benefit for LLM-assisted development: "The entire API is small and well documented so LLMs can produce high quality results". That is a claim about API size, not a measured outcome, and it should be read as a design intention rather than a result.

A second reference point is Box2D. LittleJS integrates Box2D v2.3.1 as wasm rather than reimplementing a rigid body solver, which is the pragmatic choice: you get a real physics engine behind a plugin boundary, and you can ignore it entirely and use the arcade physics if your game only needs AABB collision and tilemap raycasts.

Maintenance, licence and what upgrades cost you

The repository is not archived, and the last push was on 2026-09-23. Releases are frequent and versioned semantically: v1.19.3 on 2026-09-22, v1.18.26 on 2026-08-16, and v1.18.15 on 2026-05-25. The release titles tell you what to expect from an upgrade. v1.19.3 is labelled "LittleJS 3D, audio effects, object shaders", v1.18.26 is "Touch gamepad, texture sheets, three.js plugin", and v1.18.15 is "UI anchors, circle gradients, 2d noise, stability hardening". Feature work lands in minor versions; patch releases carry fixes.

That cadence is the upgrade cost. The engine ships as a single bundle with a generated type definition file, so an upgrade means replacing dist/ and re-checking that your game still renders and that any plugin you rely on still matches. The repository has a test directory and the package defines npm test as node --test over test/**/*.test.mjs, so the project tests itself, but those tests cover the engine, not your game. The README does not describe a deprecation policy or a migration guide for breaking changes, so pinning a version in package.json and reading the release title before bumping is the practical approach.

The licence is MIT, stated in the README, in package.json and in the LICENSE file, with a COPYRIGHT.txt alongside it. MIT is permissive: it allows commercial use and modification, and it requires that the copyright notice and permission notice be preserved. The package's files field publishes dist/, src/, plugins/, COPYRIGHT.txt and FAQ.md, so the notice ships with the package. This is a description of the licence text, not legal advice; check the actual terms with your own counsel if your situation is unusual.

Editorial conclusion

Adopt LittleJS for small browser games, jam entries and anything where the download size matters, and start from the Vite template rather than wiring the script tag by hand. Skip it if you expect a visual scene editor, a built-in asset pipeline or a large third-party plugin market, because the README describes none of those. Before committing, run npm run build against your own game and confirm the dist output matches the size you are budgeting for, since the repository ships a Node.js build system that you are expected to drive yourself.

Frequently asked questions

Official sources

1. KilledByAPixel/LittleJS on GitHub
2. License: MIT
3. Project website
4. README
5. Releases