LUME HTML and WebGL for Interactive Web Scenes

LUME Targets Browser Scenes Built from HTML

LUME addresses web developers who want interactive 2D or 3D graphics while retaining HTML as the application interface. Instead of requiring every scene entity to be constructed through renderer-specific JavaScript, LUME exposes graphics concepts as custom elements. That makes it most relevant to products where spatial objects, interface controls, and ordinary DOM content need to coexist.

The repository describes LUME as a toolkit rather than a single rendering primitive. Its main package supports CSS3D, WebGL, and a combination of both. CSS3D is appropriate when the scene consists of transformed HTML elements, while WebGL is the documented path for GPU-rendered geometry and materials. Supporting both paths allows an application to choose the rendering model that fits a scene instead of forcing every object into one system.

LUME is aimed at engineers working within browser constraints. The package is written in TypeScript, publishes declaration files, uses ESM, and presents scene components through an HTML syntax associated with the project. It can suit designers who prefer composing a scene through markup as well as developers who want reusable Web Components around graphics behavior. The React and React TypeScript directories in the repository show integration examples, although the README does not identify them as a separate React renderer.

The approach is less compelling for a small isolated effect or a renderer that is already embedded in an application with its own scene graph, asset pipeline, and lifecycle rules. LUME is most meaningful when declarative scene structure reduces the amount of bespoke renderer setup. If HTML components are not part of the product design, its defining abstraction adds a layer without delivering an obvious advantage.

LUME Packages Separate Elements, Behaviors, and WebGL

The repository organizes LUME into packages that can be used independently or together. The main `lume` package provides the graphics-oriented HTML elements and re-exports features from the lower-level packages. This makes it the normal package for application authors who do not need to separate the foundation from the graphics API.

`@lume/element` is the custom-element system beneath those graphics tags. The README describes it as a way to define new HTML elements with custom-element lifecycle behavior. `element-behaviors` extends that model by allowing multiple behavior classes to be associated with one element. Each behavior has lifecycle methods similar to custom elements, so concerns can be composed without requiring every feature to be part of a single element definition.

That separation can help teams that need their own HTML elements around LUME. A product-specific control or scene element can use the same element foundation without becoming part of the `lume` package itself. However, the README does not provide a complete mapping of every lower-level export re-exported by the umbrella package. An application should inspect the installed package declarations before relying on a particular import path.

The lower-level `glas` package follows a different route. It is described as a WebGL engine written in AssemblyScript and marked WIP. AssemblyScript compiles a TypeScript-like language to WebAssembly, but the README does not document supported render features, browser restrictions, initialization requirements, or a compatibility matrix. The project consequently has two layers with different maturity signals: the package suite is publicly usable under alpha version numbers, while the README explicitly marks `glas` as work in progress.

Installing LUME and Launching the Repository Examples

The README gives `npm` as the direct installation route for application projects. That command installs the umbrella package and is the only installation command the README states.

npm install lume

The root `package.json` declares the package version as `0.3.0-alpha.46`. It points JavaScript consumers to `dist/index.js`, TypeScript consumers to `dist/index.d.ts`, and identifies the package as ESM through the `"type": "module"` field. The manifest also requires Node.js 14 or newer for the repository package. These facts concern the package definition and do not replace browser compatibility checks.

For a source checkout, `package.json` defines an examples script that runs `five-server`, watches `dist` and `examples`, and opens the examples directory. That is a documented first-use path because it uses files already present in the repository rather than an invented server command.

```

After the script starts, open an existing page such as `examples/gltf-model.html` or `examples/shader-material.html`. The example filename identifies the feature being exercised, but the README does not document the asset paths, server configuration, expected browser output, or required import setup for each page. The repository itself is therefore the authoritative source for the first run. Start with one example matching the intended scene rather than treating the whole directory as one installation test.

LUME Examples Expose Models, Shaders, Cameras, and Layout

The examples directory gives a more precise view of LUME's intended feature set than its short GPU-oriented description. Model-related pages include `examples/3ds-model.html`, `examples/fbx-model.html`, `examples/gltf-model.html`, and `examples/gltf-model-draco.html`. Geometry and drawing appear through `examples/ply-geometry.html`, `examples/line.html`, and `examples/instanced-mesh.html`. Other pages address camera behavior, automatic layout, and shaders.

This collection suggests several different evaluation paths. A GLTF or FBX project should begin with its corresponding page and verify model loading, materials, lighting, and scene setup there. A geometry-focused project should inspect the PLY and instanced-mesh examples. A web interface dominated by HTML can examine `examples/autolayout.html`, while a project centered on custom rendering should start with `examples/shader-material.html`.

The examples do not by themselves establish production parity between formats. The README does not state whether Draco compression requires special handling in every application, whether format support is delegated to separate loaders, or whether all examples use the same initialization path. It also does not document rollback for an example that fails in a particular browser. Those points should be checked in the exact page and dependency version being evaluated.

TypeScript declarations are a useful adoption feature for teams that need editor and compile-time information around LUME elements. However, generated declarations cannot compensate for API volatility in an alpha package. Developers should review the `dist/index.d.ts` output for the installed version rather than assume that examples or documentation match the latest repository state. Repository examples and published package artifacts can move at different release points.

LUME Versus Three.js, CSS3D, and Direct WebGL

LUME instead makes HTML elements the primary composition surface and can use CSS3D or WebGL beneath those elements.

Pure CSS3D is a narrower alternative. It fits interfaces composed from transformed HTML elements and avoids requiring WebGL for every visual element. LUME can use CSS3D, but it also documents a WebGL path and mixed rendering. That broader choice can suit an interface with both DOM controls and rendered geometry, though it also requires teams to establish which layer owns each object.

Direct WebGL code is another option for products with a specialized renderer, performance instrumentation, physics integration, or an existing asset pipeline. Such a project may value direct ownership of shaders, buffers, and frame lifecycles more than HTML markup. Adopting LUME would introduce custom-element semantics and an alpha package layer around an area the team may already control.

LUME is the better fit when spatial objects need to participate in an HTML-based application architecture. Three.js is the stronger alternative for a general JavaScript scene graph, and direct CSS3D is sufficient when no GPU-rendered mesh is required. The decision should follow the rendering path required by the product, not the project's GPU-oriented description.

LUME Maintenance, Licensing, and Upgrade Boundaries

The repository is not archived, and its last push was on 2026-09-08. That fact records commit activity, but it does not prove a stable release policy. The listed recent releases are `v0.3.0-alpha.44` from 2024-10-05, `v0.3.0-alpha.43` from 2024-10-05, and `v0.3.0-alpha.42` from 2024-04-29. The root package version is newer at `0.3.0-alpha.46`, so repository code and release tags are not aligned in a way that the README explains.

Upgrade planning should account for that alpha status. The documentation does not state how long old versions remain available, whether alpha tags follow semantic-version compatibility, or what procedure restores a previous working version. `package.json` includes scripts such as `release:alpha:patch`, `release:alpha:minor`, and `release:alpha:major`, but it does not provide a consumer rollback policy. Pinning a known package version is consequently more defensible than tracking repository `main` as a deployment source.

LUME uses the MIT license, which is permissive and permits modification and distribution under its conditions. Applications should preserve the applicable license notice. The root manifest does not show license metadata for every workspace, so teams that redistribute lower-level packages should inspect each package separately rather than assume that the root declaration covers every dependency.

Performance should also remain an evaluation item. The README states that `glas` is a WebGL engine written in AssemblyScript, but it gives no benchmark results, scene sizes, frame-rate figures, or memory measurements. Browser support and rendering performance therefore need verification against the exact example and intended production scene.

Editorial conclusion

Adopt LUME for a browser application that benefits from scene markup, custom elements, and WebGL integrated with HTML. Do not select it when an alpha API, a WIP engine path, or undocumented browser requirements would threaten the delivery schedule. First verify the chosen package version, browser support, asset formats, build output, and upgrade differences for the examples your project intends to use.

Frequently asked questions

Official sources

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