# proton-engine says version 7.1.5 in its manifest, v5.4.3 in its newest tag, and v4 in its README

> Proton is a long-running JavaScript particle animation engine with a dozen-line usage example and a renderer for canvas, WebGL, DOM, pixels, EaselJS, Pixi.js and anything you write yourself. Its documentation has drifted: the version numbers disagree with each other, the build instructions clone over a protocol that no longer works, and the renderer list names the same class twice.

**drawcall/Proton** — Javascript particle animation library

- Repository: https://github.com/drawcall/Proton
- Website: https://drawcall.github.io/Proton/
- Stars: 2,477 · Forks: 281
- Language: JavaScript
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/drawcall-proton

## Three files name three different versions

The manifest declares `"version": "7.1.5"` under the name `proton-engine`. The newest GitHub release is v5.4.3, dated 2022-04-28, followed by v5.2.7 and v5.1.5 from September 2021. The README text, meanwhile, says the library has been upgraded to the v4 version and points to the release notes for detail. So the code that npm serves is at 7.x, the newest tagged artifact is 5.4.3, and the prose still describes 4.x as current. The branch itself was last pushed on 2026-03-06, four years after that newest tag, which means the work has continued without new tags for most of the project's life. Anyone tracking this library by version number has three numbers to reconcile and no single answer in the repository about which one describes the release they are installing.

## The renderer list names EaselRenderer twice

The features section ends with a list of renderers, and it contains seven entries for six distinct ideas. `CanvasRenderer` is the canvas renderer, `DomRenderer` is described as the DOM renderer supporting hardware acceleration, `WebGLRenderer` is the WebGL one, `PixelRenderer` implements pixel animation, and `CustomRenderer` accepts any renderer you supply. Then the same class name appears twice in a row: `EaselRenderer` described as the EaselJS renderer, and `EaselRenderer` again described as the Pixi.js renderer. The second entry is describing a different integration, since a Pixi.js renderer cannot be the same object as an EaselJS one. Whichever class you reach for by that name, the README gives you one identifier for two runtimes. Since the renderer is where the drawing actually happens, that choice also decides what the efficiency claim in the same section means, and the claim is made without attaching a count to any one renderer: the file says only that tens of thousands of particles can be rendered in a page.

## The build instructions are shell commands in a javascript block

The building section tells you that node is a dependency, then shows the whole procedure in a block tagged as JavaScript:

```javascript
git clone git://github.com/drawcall/Proton.git

...
npm install
npm run build
```

Two things are wrong with those six lines. The language tag says javascript while every line is a shell command, which is why a copy-and-paste into an editor with syntax highlighting turns it into a parse error. And the clone URL uses the git protocol rather than https, which GitHub stopped serving, so that line cannot succeed today. Everything else in the file uses https, including the repository field in the manifest, so the inconsistency is confined to this block. The working equivalent is documented nowhere else in the repository.

## main resolves to a minified bundle in a committed build directory

`"main"` is `./build/proton.min.js` and `"types"` is `./build/proton.d.ts`, so what a consumer resolves is a build artifact rather than anything under `src/`. The repository tree does contain a `build/` directory at the root, which means the compiled output is tracked alongside the sources, next to `rollup.config.js`, `.babelrc.json` and `tsconfig.json`. The build itself is rollup driven: the manifest's build script sets `NODE_ENV=pub` and runs rollup with the bundle config treated as CommonJS, and the dev dependencies carry the Babel plugin chain, `@rollup/plugin-typescript`, `rollup-plugin-dts` for the declaration file and `rollup-plugin-license` to stamp the licence banner into the bundle. There is a `.npmignore` as well, so what ships is decided twice, by an ignore file and by whatever the build writes.

## TypeScript guidance is an issue link while the package ships declarations

One line near the top of the README sends anyone working in TypeScript to a specific issue thread, issue 109, for guidance on using the library. Meanwhile the manifest declares generated types and the dev dependencies include both `typescript` and `rollup-plugin-dts`, and the tree holds a `tsconfig.json`, so declarations are produced by the build rather than hand written. The result is a split picture: the types ship, but the guidance on whether and how to use them lives in a discussion attached to an old issue, and the library itself is introduced as JavaScript throughout. The examples show ES module imports from `proton-engine`, and the browser route loads a prebuilt `js/proton.web.min.js` from a script tag, so there are two consumption paths with different shapes and one page of documentation between them. The script tag path also names a specific build artifact, `js/proton.web.min.js`, a path that exists inside the example tree rather than at the published package root, so a browser user has to find that file by hand while an npm user gets `main` resolved for them.

## npm start runs rollup in watch mode and an HTTP server on port 3001

The start script is a single line that runs two processes at once under concurrently, with the labels ROLLUP and HTTP and distinct colours. One of them sets `NODE_ENV=dev` and starts rollup in watch mode with inline source maps; the other is a static server told to listen on 3001. The README then tells you to visit `http://localhost:3001/example/` after starting it, misspelling visit, and the example tree in fact has an index page and ten directories, covering behaviour, emitter, game, helloworld, initialize, lib, render, sparks and zone. A third script, `page`, runs `node ./script/makeexamplepage`, which is how those example pages get assembled. The lint story is separate again, running eslint over `src` with a config file named `eslintrc.json` at the root, next to an `.eslintignore`.

## The badges point at npm twice and at a service that no longer runs

The header is HTML with six anchors and no visible content inside them. Two of them point at the package on npm, one at the npmjs.org host and one at npmjs.com, which are the same destination written twice. Two more point at the package on cdnjs and at the issue tracker. One points at Travis CI, and the tree still carries a `.travis.yml` together with a manifest script named travis whose entire body is `npm run lint`, so the continuous integration story is a lint run behind a badge for a service that is no longer offered. The last anchor has `href='#'`, a link to nothing. The library's own examples are served from a github.io address over plain http in both the README and the manifest homepage field, while the badges and every other link use https.

## The remarks give integration advice without units or defaults

The remarks section is where the library explains itself, and it reads as a collection of tips rather than a specification. `Proton.Span` is called the most important concept in the engine, used everywhere, with `Proton.getSpan` offered as an alternative name; wind, rain and snow are produced by calling the `emitter.preEmit` method to pre-render a scene; using `Proton.Body` and `Proton.Color` together is advised against the canvas renderer in favour of WebGL; and a `Proton.Cyclone` behaviour was added for vortex effects with a CodeSandbox demo. Two of those are switches without defaults you can check. One says Euler integration is more accurate, marked default false, as `Proton.USE_CLOCK`. The other says that if the frame rate exceeds 60 and you want to hold a stable 60 you must set `proton.fps = 60`, which ties correctness to the display refresh rate of whatever machine the page happens to open on.

## Conclusion

Use it when you want particle effects in canvas or WebGL quickly and are willing to read the source, because the usage example really is a dozen lines and the emitter model is small enough to hold in your head. Do not expect a maintained package with coherent release tracking: the manifest, the tags and the README each name a different version, the newest tag predates the last commit by four years, and the documentation lives on somebody else's subdomain. Before you pin a version, check which build you actually get from the registry, because `main` resolves to a committed minified bundle rather than to source. Before you build from source, replace the clone line, since it uses the git protocol that GitHub turned off. And if you are reaching for it in TypeScript, note that the guidance for that lives in an old issue thread rather than in the repository, even though the package does ship generated declarations.

## FAQ

### How do I install the proton-engine particle library?

Run `npm install proton-engine --save` and import the default export from `proton-engine`, or drop `js/proton.web.min.js` into a page with a script tag. The package was renamed from `proton-js` to `proton-engine`, so older install instructions elsewhere will use the old name.

### Which renderers does Proton provide?

The README lists `CanvasRenderer`, `DomRenderer` for DOM with hardware acceleration, `WebGLRenderer`, `PixelRenderer` for pixel animation, an `EaselRenderer` for EaselJS, another entry also named `EaselRenderer` for Pixi.js, and `CustomRenderer` for anything you write yourself.

### What version of Proton is current?

The manifest says 7.1.5, the newest GitHub release tag is v5.4.3 from 2022-04-28, and the README says the library has been upgraded to v4. The branch was last pushed on 2026-03-06, so untagged work is well ahead of the newest release.

### How do I build Proton from source?

Clone the repository, then run `npm install` and `npm run build`, which invokes rollup in publish mode. `npm start` runs rollup in watch mode alongside a static server on port 3001, where the examples are served.

### How do I keep Proton running at a stable 60 FPS?

Set `proton.fps = 60` when the browser refresh rate is above 60 or the surrounding game engine has a fixed frame rate, as the remarks section advises. It also documents `Proton.USE_CLOCK` for Euler integration, default false.

## Sources

- [drawcall/Proton on GitHub](https://github.com/drawcall/Proton)
- [License: MIT](https://github.com/drawcall/Proton/blob/master/LICENSE)
- [Project website](https://drawcall.github.io/Proton/)
- [README](https://github.com/drawcall/Proton/blob/master/README.md)
- [Releases](https://github.com/drawcall/Proton/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/drawcall-proton