melonJS: one HTML5 game engine that picks its own renderer

A 2.5D engine, not a framework you fight

melonJS calls itself a modern and fully featured HTML5 game engine, and the README puts a specific scope on that word: 2.5D, designed for indie developers. Perspective and orthogonal cameras, GPU-accelerated tilemap rendering, post-processing effects, custom shaders, 3D mesh support, polygon-accurate physics, modern Tiled workflows.

The design goal is stated more bluntly than most engine READMOs state anything. The idea is that you focus on making games rather than on graphics plumbing. The rendering API follows the HTML5 Canvas patterns, with `save`, `restore`, `translate`, `rotate`, `setColor`, and `fillRect` behaving the way they do on a canvas element, and the README says outright that there are no render graphs, no shader pipelines, and no instruction sets to learn.

That is a real constraint, not just a friendly framing. If you have spent time in an engine built around explicit render graphs, the absence will feel like a limitation at first. If you have written canvas code directly, it will feel like nothing at all, which is the point.

The size and dependency claims are the other headline. The whole engine is about 250 KB minzipped of vanilla JS and TS, with no dependencies and no toolchain lock-in, bundled with esbuild. It is MIT licensed, with the LICENSE.md file at the repository root and a matching badge in the README, and the README says it is actively maintained by the team at AltByte in Singapore.

Compatibility is broad in the ordinary web sense: a standalone library that needs nothing but an HTML5-capable browser, compatible with Chrome, Safari, Firefox, Opera, and Edge, plus mobile devices. That list describes the runtime, not the rendering performance, which is where the backend choice below starts to matter.

Three renderers, one AUTO switch, and one retired path

The renderer abstraction is the feature that distinguishes this engine. You write the game once and run it on WebGPU, WebGL 2, or Canvas2D with zero code changes, and the engine handles the GPU complexity behind a unified API.

The default mode is called AUTO, and its fallback order is documented: it tries WebGPU first at startup, falls back to WebGL 2 if that is unavailable, and ultimately falls to Canvas. The README claims the entire feature set renders identically on both GPU backends, which is the claim worth pressure-testing. Blend modes are the concrete example given, since since version 20.2 tinting, masking, and the full set of CSS-style blend modes render identically on WebGPU, WebGL 2, and Canvas.

That completeness extends to texture handling. Compressed texture support covers DDS, KTX, KTX2, PVR, and PKM with automatic format detection and fallback, and hardware antialiasing is available through an `antiAlias: true` option on both GPU backends. Antialiasing survives post-processing, which is not automatic, because the offscreen targets the post-effect chain renders into are multisampled to match.

The WebGL 1 path is retired as of version 20.0. WebGL 2 is now the baseline, and devices offering only WebGL 1 fall back to the Canvas renderer under AUTO. That is a hard deadline for old hardware, and it is the single most likely reason a project targeting decade-old devices needs to pin an older engine version.

Two more systems sit underneath the renderer. There is an extensible batcher for custom rendering pipelines with backend-neutral vertex formats and draw topologies, described as declaring a layout once and describing it to either GPU backend. And there is procedural noise: `Noise` covering simplex, perlin, value, and cellular with fractal variants and domain warp, renderer-free and CPU-samplable for heightmaps, terrain, and spawn jitter, plus `NoiseTexture2d` for baking a field into a sprite image, a `Gradient` ramp, or a live tangent-space normal map for lit water. Both sit under a new `Texture2d` base alongside `TextureAtlas`.

Tiled for 2D, a glb file for 3D

Scene loading is where the engine's two halves meet, and the README treats them as parallel rather than as a 2D engine with a bolted-on 3D mode.

A single call brings an authored scene into the world: `level.load(name)`. Tiled is a first-class citizen for 2D, covering orthogonal, isometric, hexagonal, and staggered maps, animated tilesets, collision shapes, object properties, and compressed formats, with GPU-accelerated tile rendering on the GPU backends.

The 3D equivalent is glTF and GLB. You author in Blender or any DCC tool, export a `.glb`, and the whole scene loads under a `Camera3d`, including meshes, materials, cameras, lights, and node animation. The README makes the practical claim explicitly: no per-mesh wiring. Animated 3D models play back through the same animation API as a 2D `Sprite`, which is what makes the abstraction coherent rather than bolted together.

Alongside glTF there is a separate 3D path with more traditional asset handling: OBJ and MTL model loading with multi-material support, hardware depth testing, and perspective projection via `Camera3d`. The rendering model is retained, so geometry uploads to the GPU once and is redrawn from there, meaning moving, rotating, scaling, or re-tinting a mesh costs no vertex upload and no per-vertex CPU work.

Mesh textures are mipmapped and anisotropically filtered on both GPU backends, which the README targets at distant and grazing-angle geometry that would otherwise shimmer, with a per-mesh opt out using `textureFilter: "nearest"` for crisp pixel-art models.

Lighting exists on both sides of the 2.5D line. In 2D, `Light2d` is a first-class `Renderable` supporting multiple dynamic lights, radial-gradient falloff, illumination-only mode, and procedural rendering through `drawLight`, with optional per-pixel normal-map shading on sprites. In 3D, `Light3d` provides directional, point, spot, and ambient lights added to the world like `Light2d`, using half-Lambert diffuse with ambient fill, quadratic falloff, and cone angles on the punctual types.

A dependency-free runtime on top of a large toolchain

The README's claim of no dependencies and no toolchain lock-in is true of the published package and needs qualification when you look at the repository, because the two statements describe different things.

The runtime side checks out. The engine is a single tree-shakeable ES module, described as a full game stack including physics, tilemaps, audio, input, cameras, tweens, particles, and UI, with no dependency sprawl and no library stitching. Physics in particular is handled through adapters rather than baked in, and the publishing scripts in the root package.json show adapters for planck and matter published as separate packages alongside the engine.

The development side is the opposite. The repository is a pnpm workspace monorepo. There is a turbo.json and a pnpm-workspace.yaml and a packages directory, vitest.workspace.ts at the root, biome.json for formatting, eslint.config.mjs, lefthook.yml for git hooks, a tsconfig.json, and a scripts directory. The root package.json lists devDependencies including Biome at 2.5.9, ESLint 10, vitest 4 with browser and Playwright providers, lefthook, and TypeScript type packages.

Both facts are true and the reconciliation is straightforward. Consumers of the npm package get an engine with no runtime dependencies and no build step imposed on them. Contributors to the repository get a typed, linted, tested, multi-package workspace. The claim in the README is about the first group.

There is a smaller discrepancy worth noting because it confuses people looking at the repository. GitHub labels the repository language as JavaScript. The tree is TypeScript. There is a tsconfig.json at the root, the test command references `packages/melonjs/vitest.config.ts`, and the repository topics include typescript alongside javascript. The README hedges by describing the code as vanilla JS and TS, which is accurate but flatters the JavaScript label.

Publishing is driven through GitHub Actions rather than by hand. The root package.json exposes paired scripts per package, including dry-run variants, so melonjs itself, a debug plugin, a tiled-inflate plugin, a spine plugin, and the matter and planck adapters each publish through a publish workflow with an optional dry-run flag. The plugins named there are a decent index of what the maintainers consider the common gaps: debug tooling, compressed Tiled maps, and Spine animation support.

Release cadence, versioning, and the state of the repository

melonJS is on version 20 and moving quickly. Three recent releases are 20.4.0 on 2026-09-09, 20.5.0 on 2026-09-15, and 20.6.0 on 2026-09-16, and the last push to the repository was 2026-09-22. A major version number that increments in the twenties with minor releases several times a month is a project that is shipping rather than maintaining.

That has a practical consequence. The README's own feature notes are versioned, with WebGL 1 retiring at 20.0 and blend modes reaching full parity at 20.2. When you read documentation about what the engine supports, check which version it describes, because a page written for 19.x will send you looking for a WebGL 1 fallback that no longer exists.

The root package.json carries a version of 0.0.0 and a name of melonjs-monorepo. That is not a mistake and not a stale release; it is a workspace root that is never published. The published artifact is the melonjs package inside the packages directory, and the publish scripts confirm it by targeting package names rather than the root.

Scale and community signals are healthy. The repository has 6,398 stars, 661 forks, and only 19 open issues, which is a low ratio for a project this size. It ships a BACKERS.md, a CONTRIBUTING.md, and a CODE_OF_CONDUCT.md carrying Contributor Covenant 2.1, and the README links a Discord server. Topics cover 2d-game-engine, canvas2d, html5, es6, tiled, webgl, webgpu, webaudio, web3, hacktoberfest, and contributions-welcome.

One item in the tree is worth naming because it is unusual: a `.claude-plugin` directory at the root. Whatever tooling convention it represents, its presence tells you the maintainers are building for agent-assisted contribution workflows, which matches the hacktoberfest and contributions-welcome topics and predicts more outside pull requests than the issue count suggests.

Editorial conclusion

melonJS has made a specific bet, and the numbers say it is working: a quarter megabyte minzipped, zero runtime dependencies, one rendering API across three backends, and a release every week or two through the 20.x line. That combination suits a particular kind of game, which is a 2D or 2.5D indie title where you want to own your build pipeline rather than adopt someone else's editor. Three things to weigh before committing. The Canvas2D-shaped API is a deliberate constraint, so if you arrive expecting render graphs and shader pipelines you will have to unlearn some expectations. The 3D support is real but young relative to the 2D half, since glTF scenes under Camera3d and OBJ/MTL loading are a different maturity level from a decade of Tiled workflow. And the WebGL 1 path is gone as of 20.0, so WebGL 2 is the GPU baseline and older devices land on the Canvas renderer. If you can accept the first and ship in 2D, the rest is detail you can check per project by reading the renderer support page for the platforms you target.

Frequently asked questions

Official sources

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