Pre loader

SciChart.js v6 Released

SciChart.js v6 Released
Summarize this article with:


SciChart.js v6 is a major infrastructure release. Download SciChart.js v6 version now.

This release lays new foundations — WebGPU support, ES modules with tree shaking, 64-bit WebAssembly for much bigger in-browser datasets, a unified 2D/3D engine, and a new chart types — that the next generation of SciChart.js will build on.

Because it’s a major version, there’s more change under the hood than usual.

Getting Started with v6

npm install scichart@6

An easy way to upgrade to the latest version is to point the AI at the Breaking Changes page.

Full details: What’s New in v6 | Breaking Changes from v5.2

1. WebGPU Support

With massive dashboards and many charts, WebGPU is a clear win over WebGL due to the ability to directly composite to the screen, on Windows, and particularly noticeable on Apple Silicon

SciChart.js F1 Demo — WebGPU vs WebGL
12 live widgets, 1920×1080, median FPS over repeated passes. SciChart.js 6.0.0-alpha.197, Chrome 153.
MachineGPUWebGPUWebGLWebGPU gain
MacBook
Apple M4, 10-core
Apple M4 (integrated)58.1 fps†28.1 fps2.1×
Windows laptop
Intel Core i7-11800H
Intel UHD Graphics (integrated)20.3 fps6.1 fps3.3×
NVIDIA RTX 3070 Laptop (discrete)58.3 fps†52.3 fps1.1×
† Around 58 fps the browser is capped by the 60 Hz display, not by the GPU — these figures are a floor, and the real WebGPU gain on those two GPUs is larger than shown.
Identical dashboard and workload on each machine; the Mac and Windows runs replay different telemetry captures, so compare the WebGPU vs WebGL ratio within a row rather than absolute fps between machines. Renderer pinned explicitly — left to its default, SciChart.js selects WebGPU on Apple Silicon and WebGL elsewhere.

SciChart.js v6 adds support for WebGPU, a newer, more modern graphics API, alongside our existing WebGL renderer — you’re not locked into one or the other.

Where WebGPU really shines is dashboards with many charts on a single page. In internal testing on our Formula 1 telemetry demo, we rendered around 20 live charts on one page at 60 FPS — something that wasn’t achievable with WebGL.

WebGPU isn’t supported on all hardware, so v6 picks it automatically only where we know it is a win (Apple Silicon Macs today) and falls back to WebGL everywhere else — existing applications need no code change. You can pin either renderer yourself with a single flag.

Check out out dashboard demos with WebGPU (Server Traffic | Oil & Gas Explorer | Semiconductors) | WebGPU docs

2. ES Modules and Tree Shaking

We’ve upgraded SciChart.js’s module system from CommonJS to ES modules (both are still shipped, so existing CommonJS-based projects keep working).

SciChart.js bundle size — v5 vs v6
Production build of each official boilerplate, total gzipped JavaScript. v5.0.0-alpha.135 vs 6.0.0-alpha.196.
Boilerplatev5v6Saved
webpack 5 + TypeScript509.1 KB219.2 KB−57%
Angular554.4 KB302.2 KB−46%
Next.js624.7 KB529.3 KB−15%
Svelte + Vite457.8 KB396.2 KB−13%
React + Vite484.8 KB428.2 KB−12%
All five combined2,630.8 KB1,875.1 KB−29%
Gzipped JavaScript only — WebAssembly, CSS and other assets excluded. Each boilerplate is built unmodified with its own toolchain, so the totals include framework and application code as well as SciChart.js.
v6 ships parallel CommonJS and ES-module builds with a per-folder sideEffects map, so bundlers that honour it can drop unused chart types; the savings therefore depend on how much of the library an app actually references.

The practical benefit is tree shaking: your bundler now includes only the parts of SciChart.js your application actually uses. Import strings are unchanged — import { SciChartSurface } from "scichart" keeps working and now shakes. The Builder API was the biggest blocker, since importing it registered every chart type; in v6 you register only the types your definitions name, which in our measurements took a Builder-based bundle from roughly 360 KB to 155 KB gzipped.

After upgrading, this should work with no changes for most projects: root imports shake automatically on webpack 5, Vite, Rollup and esbuild, all of which honour the package’s exports map and per-folder sideEffects list. Two things can silently switch it off. TypeScript projects compiling with "module": "commonjs" rewrite the import to require("scichart") before the bundler sees it, which resolves to the non-shakeable CommonJS build — set "module": "esnext" and "moduleResolution": "bundler" instead. And if you reached for registerAllTypes() as a quick migration step, remove it: it registers every built-in type again.

Check out updated boilerpates with tree shaking example | Tree shaking docs

3. Wasm 64 — Load Much More Data in the Browser

SciChart.js v5 used a 32-bit WebAssembly build, whose linear memory is hard-capped at 4GB by the WebAssembly specification itself — and in practice less than that, since the same heap also holds the engine, textures, resampling and render buffers.

v6 adds an optional 64-bit Wasm build that raises the ceiling to 16GB — four times the addressable memory in the browser. Because SciChart stores data series values as doubles, that works out at roughly 16 bytes per point for an XY series:

BuildMax heapXY pointsOHLC points
wasm32 (default)4 GB~250 million~100 million
wasm64 (opt-in)16 GB~1 billion~400 million
Upper bounds from raw storage cost, not budgets — the same heap holds the engine, render buffers and any transient copies made while appending, so plan well below these figures.

64-bit mode is off by default and must be opted into, because it trades roughly 10% of throughput for 4× the memory ceiling. Enable it by setting one flag before you create any chart, then deploy scichart-64.wasm alongside your other binaries — copying the whole node_modules/scichart/_wasm/ directory covers it:

import { SciChartDefaults, EUseWasm64, SciChartSurface } from "scichart";

// wasm64 where the browser supports it, wasm32 everywhere else
SciChartDefaults.useWasm64 = EUseWasm64.Auto;

const { sciChartSurface, wasmContext } = await SciChartSurface.create("chart-div");

EUseWasm64.Auto is the setting you want: browsers with Memory64 get the 64-bit engine and everything else transparently falls back to 32-bit, with no branching in your code. EUseWasm64.Always skips feature detection and fails to load where Memory64 is missing, so reserve it for environments you control. Memory64 needs Chromium 133+ or Firefox 134+ and is not yet in Safari, so the 32-bit build remains the default path and the fallback must stay deployed.

For the background on Memory64 itself — why the 4GB wall exists, what the browser engines had to change, and where the 10% goes — see our blog post Memory64: Unlocking WebAssembly’s True Potential with 16GB of In-Browser Memory, or go straight to the Wasm 64 docs.

4. Unified 2D/3D engine

In SciChart.js v5, 2D and 3D charts ran on two separate WebAssembly engines, scichart2d.wasm and scichart3d.wasm. Each engine carried its own copy of the shared rendering code and its own memory heap. A page that showed both kinds of chart downloaded, compiled and started both engines. In v6 there is one core engine, scichart.wasm, and 3D is a small add-on, scichart-charting3d.wasm, loaded into that core the first time a 3D chart is created. 2D and 3D charts now run in the same engine instance and share its memory, so data and resources can be shared between them rather than kept in two isolated heaps. On a page with both 2D and 3D charts this saves at least 16 MB of browser memory, the starting heap of the second engine, plus the second copy of the compiled engine code. It also cuts the engine download by 22%. The saving grows as charts load more data, because v5 grew each engine’s heap separately. The single core is larger than v5’s 2D engine because it now contains the code shared by 2D and 3D, so a 2D-only page downloads about 140 KB more.

SciChart.js engine: v5 separate 2D/3D vs v6 unified
Engine files a browser downloads (wasm plus its JavaScript glue), SciChart.js 5.2.0 vs 6.0.0. Sizes are Brotli-compressed (quality 11), which is roughly what a browser downloads when the server compresses files. Memory is the starting heap reserved by each engine instance.
Page containsMeasurev5v6Change
2D and 3D charts
v5: scichart2d + scichart3d
v6: scichart + charting3d add-on
Engine instances21−1
Starting memory heap32 MB16 MB−16 MB
Engine download1.25 MB0.98 MB−22%
2D charts only
v5: scichart2d
v6: scichart
Engine download602 KB742 KB+23%
3D charts only
v5: scichart3d
v6: scichart + charting3d add-on
Engine download673 KB999 KB+48%

5. New Chart Type: Parallel Coordinate Plot

v6 introduces a brand new chart type: the Parallel Coordinate Plot, useful for visualising and comparing many variables across a dataset at once — from per-series comparison views to range highlighting across large numbers of series.

Parallel Coordinate Plot demo | Parallel Coordinate Plot docs

6. Experimental: 3D Model Loading

As part of our Formula 1 demo work, the underlying engine gained the ability to load 3D models (for example, the car model in that demo), and 3D mesh geometry can now be expressed in data space as a renderable series.

This is early — out of the box, arbitrary custom 3D models aren’t yet supported (that requires additional tooling for shaders/textures that we haven’t built yet). If loading your own 3D models into a SciChart.js scene is something you need, we’d love to hear from you — tell us about your use case and it’ll directly inform whether and how we build this out further.

3D Model demo

Also in v6

  • Sharper text at any size — all 2D axis labels, titles and data labels now render through GPU Bezier text instead of a texture atlas, so glyphs stay exact at any scale or rotation. In addition multiple font sizes reuse the same font which is faster and use less memory
  • TableDataSeries and native string columns — XyNDataSeries is now TableDataSeries, and any data series can carry dictionary-encoded text columns.
  • Contour improvements — colour each contour line by its own z-value, and draw contours at levels you choose rather than a uniform step.
  • Stacked columns with individual Y axes — each stacked group can now bind to its own Y axis, so groups on wildly different scales share one chart.
  • OHLC AutoSimplify — open and close ticks drop out as bars crowd together, and return as you zoom in.
  • SciChart Financial Tools improvements — Fibonacci annotation styling, wider dashed-line support and text render quality fixes.

Tell Us What You Think

We would love to hear a feedback regarding v6. If you:

  • hit a bug,
  • have thoughts on the WebGPU/WebGL split,
  • want to see 3D model loading extended to arbitrary models,
  • or just want to tell us how tree shaking worked out for your bundle size,

Please get in touch.

Forum | Support | Contact us

We read everything, and it shapes what ships in the final release.

Contact us to learn more

SciChart.js is a JavaScript Chart Library designed for complex, mission-critical applications. Now with a FREE community edition. If you have a question or would like to learn more about our products & services, please contact us:

CONTACT US | GET SCICHART.JS FREE

By Michael Klishevich | Jul 30, 2026
Michael, an MMath graduate and JavaScript Tech Lead, leverages his mathematical expertise to drive advanced JavaScript solutions at SciChart, enhancing high-performance, data-driven applications.

Leave a Reply

Contact us!

Not sure where to start? Contact Us. We are happy to help.

Get in touch