LuxAlgo/Vela: a headless WebGL2 charting library for TypeScript

What Vela is, and the problem it targets

Most charting libraries for the web force a choice. You either take a complete charting application with its own opinions about layout, toolbars and styling, or you take a low-level canvas helper and build the axis, the crosshair, the data pipeline and the interaction model yourself. Vela positions itself between the two. The README describes the package as a headless chart with its own native renderer, and then offers a workspace layer that turns that headless chart into a full application in a single constructor call.

The intended user is a developer embedding financial charts in a web product: a trading interface, a research dashboard, an internal analytics tool. The package.json describes it as an open-source charting library with a native high-performance renderer, drawing tools, pluggable chart types and pluggable scripting engines. The audience is therefore TypeScript developers who are comfortable wiring a data provider and a container element, not traders looking for a ready-made indicator subscription.

That distinction matters because the project shares a name with a commercial product family. LuxAlgo publishes TradingView indicators and strategy tools under its own brand, and the search traffic around the name reflects that. Vela is a code library published to npm as @luxalgo/vela. If what you want is an indicator to add to a TradingView chart, this repository is not that.

The layered architecture: core, workspace, ui, plugin, providers

Vela is split into subpath exports rather than one monolithic bundle. The root export, @luxalgo/vela, holds the data model, engines, drawings, providers and the native renderer. The ./workspace export adds the assembled application: a topbar with symbol, timeframe, style and indicator controls, a status line, a symbol watermark, a bottom bar with ranges, clock and timezone, an object tree, keyboard shortcuts, named cells and sync groups, all persisted as one state document. The ./ui export is the component kit that the workspace is built from, with design tokens, overlay chrome built on Zag.js, form primitives and a KeymapManager. The ./plugin export is the extension SDK, and ./providers/binance, ./providers/coinbase and ./providers/hyperliquid are ready-to-register data providers.

The design intent is substitutability. The README states that every layer, including data providers, scripting engines and renderers, plugs in behind a public port and can be swapped without touching the rest. In practice that means you can use the headless core with your own bar data and no network at all, or use the workspace with a bundled provider and get a functioning chart app quickly.

The renderer is the part that distinguishes Vela from libraries that draw on a 2D canvas. It uses WebGL2 with a Canvas2D fallback, according to the README. The fallback matters because WebGL2 availability is not universal across browsers and hardware configurations, and a chart library that hard-requires it will fail on some machines. The README does not describe how the fallback is selected or whether it can be forced, which is worth checking in the options documentation if rendering behaviour on older hardware is a concern for your users.

Installing Vela and rendering a first chart

Vela is distributed on npm as a single package with subpath exports, so installation is one command. The README gives this as the install step:

npm install @luxalgo/vela

The fastest path to something visible is the workspace, which the README describes as a complete chart app in one call. You pass a selector for the container element and an options object. The example below is taken from the README, including the layout, symbol, timeframe, live, theme, providers and persist keys:

import { VelaWorkspace } from '@luxalgo/vela/workspace';
import { BinanceProvider } from '@luxalgo/vela/providers/binance';

const chart = new VelaWorkspace('#chart', {
    layout: false, // one chart; '2h' | '4' | '8' | … for a multi-chart grid
    symbol: 'BTCUSDT',
    timeframe: '60',
    live: true,
    theme: 'dark',
    providers: { binance: () => new BinanceProvider() },
    persist: true, // restore market, style, timezone, drawings and indicators from localStorage
});

With layout set to false you get a single chart. Setting it to a grid string such as '2h' or '4' produces a multi-chart grid under one shared topbar. The persist flag restores market, style, timezone, drawings and indicators from localStorage, which is the behaviour most applications will want and the one to test first, because it is also the most likely source of surprising state on reload.

If you want control over the data pipeline instead, the headless core is the other entry point. The README shows registering a provider explicitly and awaiting readiness:

import { Vela } from '@luxalgo/vela';
import { BinanceProvider } from '@luxalgo/vela/providers/binance';

const chart = new Vela('#chart', { symbol: 'binance:BTCUSDT', timeframe: '60', live: true });
chart.data.registerProvider('binance', new BinanceProvider());
await chart.ready();

Note the symbol format difference between the two examples: the workspace example passes 'BTCUSDT' while the headless example passes 'binance:BTCUSDT'. If a chart renders empty, that prefix is the first thing to check. For a no-network setup, the README says you can pass your own bars through the data option instead of registering a provider.

Indicators, scripting engines and the licence split

Vela ships more than 70 built-in studies according to the README: moving averages, bands and channels, momentum oscillators, trend and volatility measures, volume studies, and price-anchored overlays such as VWAP, SuperTrend and Pivot Points. These compute from the chart's own bars rather than through a scripting engine, and each gets a legend row, a settings dialog and persistence across reloads. Volume and the visible-range volume profile are included alongside them.

Custom scripts are a separate matter. The README states plainly that Vela ships no scripting engine. You install an addon for the language you want, or you write one against the public ScriptingEngine port. The repository points to @luxalgo/vela-pinets for Pine Script, installed alongside the pinets runtime. That addon is AGPL-3.0 because the PineTS runtime it executes is AGPL-3.0, while Vela itself stays Apache-2.0 and carries no Pine code.

This is the most consequential licensing detail in the project. Apache-2.0 and AGPL-3.0 impose very different obligations, and the split is deliberate: the permissive core stays permissive, and the copyleft runtime lives in a separate package. If you enable Pine Script support, you are pulling an AGPL-3.0 dependency into your build. Whether that is acceptable depends on how you distribute your application, and that is a question for your own legal review rather than something the README resolves. The API for registering the engine is a single call, shown in the README as chart.registerEngine('pine', new PineEngine()) followed by chart.addIndicator with the script source. The README also documents chart.runIndicator(source) for execute-and-inject with structured errors, and handle.context() for reading a running script's state including its return value, described as read-only snapshots that are worker-safe.

The plugin SDK and where it stops

The plugin SDK exposes two registration functions from @luxalgo/vela/plugin. registerChartType accepts an id, a label and a barTransform with full and next functions, and the README says a registered chart type automatically appears in the workspace's style dropdown. registerRendererLayer accepts an id, a placement such as 'above-data', and a create function returning an object with mount and render methods, where render receives bars, data, coords, scale and bounds. The README notes that a chart type's dataEngine pushes to its layer's channel with zero extra wiring, and that the layer's id doubles as its data channel name.

That is a small surface area, and it is the right shape for adding a price style or an overlay that paints every frame. It is not a general plugin system. There is no documented mechanism in the README for replacing the axis renderer, the interaction layer or the workspace chrome through the SDK; those live in the ui and workspace packages. If your requirement is a chart that looks structurally different from what the workspace provides, the headless core plus your own chrome is the intended route, not a plugin.

The SDK documentation lives at docs/contributing/plugin-sdk.md. The fact that it sits under contributing rather than under user guides is a signal about maturity: the extension path is documented, but it is documented alongside the setup guide for people working on Vela itself.

What Vela does not do, and when to pick something else

The clearest boundary is scripting. If your product's core value is running user-authored Pine Script, Vela delegates that entirely to a separate AGPL-3.0 package. A library that embeds a scripting runtime directly, or a hosted charting service that executes scripts server-side, removes that dependency question but changes your deployment model. The trade-off is real in both directions: Vela keeps the core permissive and the runtime optional, at the cost of an extra install and a licence you have to evaluate.

The second boundary is data. Vela ships providers for Binance, Coinbase and Hyperliquid. That covers crypto venues. If you need equities, futures or FX data, the README's answer is to supply your own bars through the data option, which means you own the polling, the backfill and the reconnect logic. A library that bundles a broad market-data catalogue would save that work, but it would also couple your chart to a vendor.

The third is scope. Vela is a charting library, not an analysis platform. There is no mention in the README of alerting, backtesting, order placement or portfolio tracking. If those are requirements, you are building them on top, and Vela is only the rendering and data-model layer underneath. Teams that want a complete trading front end out of the box will find the workspace helpful but incomplete for that purpose.

Maintenance, versioning and upgrade cost

The repository is not archived, and the last push was on 2026-09-16. The package version in package.json is 0.7.5, which places the project before 1.0. No releases were retrieved, so there is no published release history to reason about here, and the README does not document a deprecation policy or a compatibility guarantee across minor versions.

For a pre-1.0 library, that combination is the main upgrade risk. The public surface is broad: subpath exports for the core, workspace, ui, plugin, widget and three providers, each with its own type definitions and both ESM and CJS builds. A breaking change in the workspace options or the plugin registration signature would touch application code directly. The CHANGELOG.md file exists at the repository root, and that is where to look before bumping the dependency rather than assuming semantic versioning will protect you below 1.0.

The licence is Apache-2.0, and the repository includes both a LICENSE and a NOTICE file. Apache-2.0 is permissive and includes an explicit patent grant, which is generally the reason projects choose it over MIT. The NOTICE file carries attribution requirements that travel with redistribution. The AGPL-3.0 status of the Pine Script addon is the separate consideration described above. None of this is legal advice; the point is that the two licences in play impose different obligations and the boundary between them is a package boundary you control by choosing whether to install the addon.

Editorial conclusion

Adopt Vela if you are building a web product that needs a chart you can drive from code and extend with your own chart types, layers or data providers. Do not adopt it expecting a hosted TradingView replacement or a ready-made strategy marketplace: the repository is a rendering and data-model library, and the only scripting runtime it points to is the separately licensed @luxalgo/vela-pinets addon. Before committing, verify three things in your own environment: that a VelaWorkspace instance mounts against your DOM and restores state with persist: true, that the provider you intend to use (Binance, Coinbase or Hyperliquid) covers your symbols and timeframes, and that your bundler resolves the subpath exports such as ./workspace and ./providers/binance rather than only the root entry.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. LuxAlgo/Vela on GitHub
4. Project website
5. README