DEV Community: Andrew Bt

How to Detect & Manage React Memory Leaks With Ease

Andrew Bt — Wed, 16 Sep 2026 16:25:22 +0000

How to Detect & Manage React Memory Leaks With Ease

Ever noticed your web app getting sluggish after a few minutes? You click a tab, and there’s a split-second delay that wasn’t there before. Eventually, the browser just gives up and crashes. If you’re building data-heavy dashboards, you’ve likely hit a React memory leak once or twice before. When components unmount but leave processes running, memory builds up until the system crashes.

Memory leaks are never fun for your users, and if you’re needing a slick, professional data visualization experience it can be frustrating. But, that’s likely why you’ve landed on this article, because you want to finally put an end to the memory leaks. To do that, you need to uncover why they’re happening and how to stop it from occurring again. As a React chart dashboard developer, I have a few tricks up my sleeve to help fellow developers overcome this bottleneck in advanced data visualization projects.

What Causes Memory Leaks in React?

So, what are the causes of memory leaks in React that developers are most likely to encounter? Usually, it’s a piece of code that does not know when to quit. Think about a subscription to a data feed or a setInterval timer. If you start these inside a useEffect hook but forget to shut them down when the user navigates away, they keep running in the background.

Another common culprit is holding onto large datasets in global variables or closures. In complex charting apps, you might be fetching millions of data points. If your component unmounts, but a lingering reference to that data remains, the Garbage Collector cannot do its job. It sees that reference and thinks, ‘Better keep this just in case’, and your RAM usage climbs.

Top Causes of Memory Leaks in React

When troubleshooting performance degradation or memory bloat, these common culprits are worth considering and looking into:

Dangling Event Listeners
Adding a listener to a window or document inside a component without removing it.
Uncleared Timers
Starting setInterval or setTimeout that continues to run after a component unmounts.
Unclosed Subscriptions
Active WebSocket connections or observable streams that persist in the background.
Closure References
Storing large datasets in variables outside the component scope or in long-lived closures.
Improper Library Disposal
Failing to call .delete() or .dispose() on low-level engines like WebGL or WebAssembly.
Persistent State References
Updating state on an unmounted component (often from an async fetch that finished too late).

How to Detect Memory Leaks in React

You cannot fix what you cannot see. A good place to start with how to detect memory leaks in React is Chrome DevTools. The Memory tab can help you out. I usually start by taking a Heap Snapshot. Then, I perform a few actions, like opening and closing a chart, and take another snapshot. If the memory usage doesn’t return to its original level, you likely have a leak.

If you want to know how to find the source of your React memory leak, the Comparison view in DevTools is a lifesaver. It shows you exactly which objects were created and not destroyed between snapshots. For those who prefer a more visual approach, the Performance tab can record memory over time. Look out for a sawtooth pattern where the memory goes up and drops slightly, but maintains a steady upward trend.

How to Avoid a Memory Leak in React

Prevention is always better than a late-night debugging session. If you want to know how to avoid memory leaks in React, start with your cleanup functions. Every useEffect that sets up a listener or a timer should return a function that tears it down. It’s a simple habit that can save hours of pain.

Using the right tools matters too. Many open-source libraries are not built for extreme scale. They might work fine for a few hundred points, but thousands, or hundreds of thousands is when they start to falter. When dealing with large datasets, you need a library that manages its own memory footprint efficiently. This is why many pros look at specialized tools that handle the heavy rendering.

SciChart’s Visual Xccelerator™ engine, for instance, offloads heavy rendering tasks to the GPU, which significantly reduces the pressure on the main JavaScript thread and the browser’s Garbage Collector. By leveraging WebAssembly and WebGL, this engine manages low-level resources directly and provides explicit disposal methods. The outcome? Your application maintains a lean memory footprint even when visualizing over 100 million data points.

Your 10-Step Checklist to Identify & Fix Memory Leaks in React

If your app feels heavy, follow this how to find memory leaks in React apps checklist:

Open Chrome DevTools and check the Memory tab.
Take an initial Heap Snapshot.
Perform the suspicious action (e.g., toggle a chart) multiple times.
Force Garbage Collection using the trash icon.
Take a second Heap Snapshot and compare.
Look for Detached DOM elements that should have been deleted.
Audit your useEffect hooks for missing cleanup functions.
Check for global variables that are accidentally storing data.
Monitor requestAnimationFrame calls to ensure they are cancelled.
Verify that third-party library instances are properly disposed of.

Want to Give SciChart a Try?

When your project demands high-performance, standard tools often fall short. This is where SciChart steps in. We built SciChart for the most demanding real-time applications. Our engine supports over 100 million data points without lag, ensuring your React charts remain responsive even under pressure and heavy loads.

One of the biggest hurdles in memory leaks in React is managing complex WebAssembly or WebGL contexts. SciChart uses our proprietary Visual Xccelerator™ engine to handle these resources for you. We provide a dedicated delete() method and specific React hooks to ensure every byte is accounted for when a component unmounts.

Ready to stop worrying about performance bottlenecks? You can get started with SciChart today and explore our extensive React chart examples and demos on GitHub. If you ever get stuck, our technical support and specialized AI assistant are ready to help you optimize your application.

SciChart offers the most advanced chart library support for React developers, making it easy to build stable, professional-grade visualizations.

Best Chart Components for Medical Patient Monitoring Systems

Andrew Bt — Wed, 16 Sep 2026 15:25:00 +0000

Smoothness and interactions on data visualizations instantly provide trust in medical settings. To achieve this, you want both the rendering and the UI to function and look slick, powered by a rendering engine and data visualization layer purpose built for real-time, smooth interactions. You also don’t want these to lag or stutter regardless of the hardware. To help you choose the best chart components for medical patient monitoring systems, we’re sharing the architecture, performance and features that really make a difference.

Are you looking to standardize on lower-cost hardware and don’t want the UI, memory, or CPU usage to be a blocker or cost barrier? Whether you’re working with multi-lead ECGs, plethysmograms, or capnograms, this breakdown isolates the engineering trade-offs and pros of each data visualization option.

What’s the Risk of Underperforming Data Visualization in Clinical Settings?

A delayed draw call or an unhandled garbage collection pause could compromise patient care. The challenge for engineers of an ICU telemetry console, for instance, is how to handle continuous, multi-channel streams of high-frequency data.

If a rendering engine cannot keep pace with incoming telemetry, the system experiences frame drops, erratic waveform scrolling, and interface freezes.

Resolving these bottlenecks requires a better understanding of the low-level rendering mechanics of specialized chart components for medical monitoring systems.

What Are the Best Chart Components for Medical Patient Monitoring Systems?

The best chart components for medical monitoring systems with telemetry displays are ones that reliably offer real-time digital signal processing pipelines.

Consistency Across Hardware & Platforms

A consistent UI in terms of look and feel is often crucial to medical device developers who may have mobile devices, tablets, web portals, embedded hardware and desktop applications in their ecosystem. SciChart is the only product that provides a consistent look and feel across all supported platforms, through its shared C++ rendering engine.

High-Performance Rendering Engines

Standard charting tools rely on the CPU for geometry computation and use vector-based rendering primitives, such as SVG or Canvas 2D contexts. Under heavy data loads, this approach results in immediate performance degradation. Advanced medical instrumentation typically benefits from GPU acceleration through graphics APIs such as DirectX, Metal, WebGL, or WebGPU. This shifts rendering workloads to the GPU, reducing visual processing overhead and helping maintain responsive user interfaces under demanding real-time conditions.

Real-Time Update Capabilities

To avoid garbage collection pauses, medical dashboards must bypass standard object allocation patterns. The chart component should implement highly efficient memory management structures, such as continuous ring buffers, that append new coordinate matrices while discarding aged samples instantaneously. True real-time components execute these operations with a flat O(1) time complexity, maintaining a stable 60 Hz or higher refresh rate under demanding conditions.

Customization & Flexibility

Medical hardware configurations frequently feature unconventional ultra-wide or vertical aspect ratios. Combine this with strict clinical design mandates and out-of-the-box UI templates quickly become insufficient.

What you require instead is granular control over rendering behaviors, specialized sweeping/scrolling modes, and custom pixel-shader effects.

Technical Support & Compliance

Even if you have access to the best chart components and customizations, that doesn’t mean you want to wait weeks or even months to get technical support when it’s needed.

Direct developer access to software engineers and responsive technical support can make all the difference. This is especially true when handling complex device certification and compliance cycles. Even better, we recommend choosing a chart library that has a successful track record of working with companies that secured HIPAA or FDA compliance for their monitoring systems. For instance, the ANNE® One neonatal monitoring platform received FDA-clearance.

What Are the Best Chart Libraries for Medical Patient Monitoring Systems?

Selecting the optimal visualization framework involves assessing the trade-offs between native execution speed, web portability, and architectural constraints.

Highcharts

Pros: Highcharts is widely recognized in web development for its clean API design and accelerated initial prototyping phases.

Cons: Despite its effectiveness in standard business intelligence applications, it struggles under the demands of real-time clinical telemetry. Highcharts relies on SVG, WebGL, and standard browser layout engines. When forced to stream multiple high-frequency channels simultaneously, rendering latency increases sharply, causing stuttering during live waveform animations.

Qt Graphs

Pros: Qt Graphs serves as a common option for native desktop application development, particularly within embedded medical devices running specialized Linux or Windows configurations. It integrates directly with the broader Qt framework, facilitating clear communication with hardware abstraction layers.

Cons: While highly effective at basic vector operations, developers often find themselves writing extensive custom rendering code to achieve fluid real-time performance.

D3.js

Pros: D3.js is a flexible choice for custom web-based data manipulation. It gives developers control over the structural mapping of data to visual primitives, making it popular for academic and custom research applications.

Cons: The major drawback involves its rendering performance. D3.js updates the browser Document Object Model directly. When dealing with complex, fast-changing medical datasets, the resulting DOM overhead can stall the main thread, making it unsuitable for live patient alarms.

SciChart

SciChart offers advanced chart library support for MedTech chart developers.

The Visual Xccelerator™ engine serves as a high-performance cross-platform bridge, translating drawing instructions directly into native graphics APIs. This includes DirectX, Metal, and WebGL. SciChart.js v6 added support for WebGPU, a more modern graphics API, alongside the existing WebGL renderer.

SciChart can perform complex rendering on the GPU while selectively employing the CPU for coordinate calculations. This preserves 64-bit precision, while maximizing rendering performance.

Our technology stack leverages WebAssembly and Memory64 to plot 1 billion points in the browser on JavaScript, and 100 billion on desktop.

Lossless data resampling, powered by SciChart’s proprietary algorithms, is useful for multi-stream rendering in real time. They preserve peaks and troughs, while enabling overlays, annotations, and smooth interactions even on low-cost hardware.

The framework delivers a compelling combination of high-speed execution, deep layout customization, and direct access to an expert engineering support team backed by an integrated AI assistant.

Try SciChart Today

Developing medical patient monitoring systems requires a graphics infrastructure that eliminates performance volatility. Relying on unoptimized graphics pipelines creates risks for your telemetry displays.
Want to see how SciChart’s specialized medical data charting solutions handle extreme data throughput for yourself? Download SciChart’s open-source chart benchmark on GitHub to review and stress-test raw rendering performance across your target hardware configurations.
Ready to build your next clinical dashboard? You can get started with SciChart.js today to integrate responsive, stable charting components directly into your medical monitoring application.

Get Started With SciChart

Frequently Asked Questions

Why do open-source charting libraries fail in medical patient monitoring systems?

Most open-source charting frameworks rely heavily on high-level web vectors or direct browser DOM manipulation. While these architectures are perfectly adequate for standard business dashboards, they lack the memory layout and allocation structures required for high-frequency telemetry. When forced to stream and redraw multiple continuous waveforms simultaneously, they trigger frequent CPU garbage collection and layout calculations, causing visible application lag.

What is the benefit of a GPU-accelerated rendering engine in MedTech software?

A hardware-accelerated engine offloads vertex processing and pixel calculations from the system CPU directly to the graphics card. This clear separation ensures that your application UI thread remains entirely unblocked, allowing operations, such as alarm processing, user inputs, and background data analysis, to run smoothly even while rendering millions of live data points.

Can JavaScript-based charts safely run inside intensive medical monitors?

Yes, provided that the underlying visualization library bypasses standard browser layout engine constraints. Frameworks that use advanced WebGL configurations deliver native rendering speeds and stable, real-time performance for JavaScript charts.

Best Cross-Platform Charting Libraries for Enterprise Apps

Andrew Bt — Wed, 16 Sep 2026 15:17:06 +0000

Building a modern enterprise app often means supporting desktop, tablet, and mobile without rebuilding the same charting layer for every platform. Users expect a consistent, responsive experience, while engineering teams must balance native performance, shared code, maintainability, and long-term support.

Those trade-offs become more challenging in data-heavy applications. A simple dashboard can tolerate ordinary web rendering. A telemetry system, trading platform, medical workflow, or industrial monitoring application usually cannot. When charts update continuously or process dense datasets, the visualization layer becomes part of the application architecture, not just a UI component.

The question is not simply “native or cross-platform?” It is whether a charting library gives your team a shared development model while still rendering efficiently on every target platform. For enterprise teams working with high-frequency, high-volume data, that often means choosing a charting SDK designed for performance rather than relying on basic wrappers or generic dashboard components.

Challenges In Cross-Platform Enterprise Development

Cross-platform enterprise development can create a scalability problem when teams have to duplicate the same charting or dashboard logic across separate platform codebases. Maintaining multiple implementations increases engineering effort, testing complexity, and the risk of feature drift across desktop, web, and mobile apps.

Lack of Customization

Many organizations turn to basic cross-platform wrappers. It feels like an easy win at first. However, relying on standard web-views or pre-built widgets can become restrictive when the chart is part of a specialist workflow. Enterprise teams may need custom interactions, unusual data layouts, synchronised views, annotations, or strict visual behaviour. If the charting layer only supports surface-level configuration, developers can end up building workarounds around the library instead of building the product.

Unresponsive UIs

Performance constraints are another roadblock. Many general-purpose charting libraries work well for standard dashboards, but need careful optimization when datasets become dense, streaming, or highly interactive. When charts update continuously, poor rendering performance can affect frame rates, responsiveness, and the overall user experience.

Delays in Getting the Product to Market

Relying on free, open-source charting libraries frequently means waiting months for critical bug fixes. For an enterprise handling compliance-heavy operations, that kind of delay is unacceptable.

Commercial pricing structures can be unpredictable at scale. Licensing can also become difficult to compare. Some vendors price by developer seat, product module, application type, deployment model, or OEM usage. For enterprise planning, the important question is how costs scale once the application moves from prototype to production.

Top Cross-Platform Data Visualization Tools for Enterprise Apps

Selecting the best cross-platform charting libraries for enterprise infrastructure requires an evaluation of how these tools handle raw data processing, cross-platform consistency, and long-term architectural maintenance. Let’s look at the main options enterprise teams are likely to consider.

Plotly

Plotly is a respected data visualization framework, particularly favored by data scientists and financial analysts. It translates complex statistical computations into interactive charts. Because it offers native bindings for multiple programming languages, engineering teams can build their data pipelines in Python or R and render the final dashboards inside web applications.

The library also offers a variety of scientific and statistical chart types out of the box. If your enterprise app requires intricate 3D scatter plots, complex contour maps, or detailed financial charts, Plotly handles the visual translation with accuracy.

The trade-off shows up in rendering speed and mobile execution. Plotly relies heavily on JavaScript and web technologies. While it works for standard web dashboards and analytical reports, it’s not so good for ultra-low latency mobile experiences.

The Key Takeaway?

If you’re looking for real-time mobile tracking or need to display streaming hardware diagnostics on a tablet, Plotly will likely run into performance bottlenecks.

Highcharts

Highcharts is a mature, well-documented library that runs reliably across almost every web browser. For traditional web development, its accessibility and straightforward configuration make it a default choice for product managers who need to get dashboards up and running quickly.

The platform ensures that standard corporate dashboards look clean and professional out of the box without requiring hours of custom CSS work. It also has strong accessibility features, including keyboard navigation support through its accessibility module, which is important for many enterprise and public-sector applications.

However, Highcharts is fundamentally a web-centric tool. When you need to deploy it within native mobile environments, you’re forced to run it inside web-view components. This approach creates a distinct barrier between your application’s core native logic and the rendering layer.

The Key Takeaway?

For advanced developers trying to build cohesive, high-performance apps across desktop and mobile, managing these hybrid web-views adds unnecessary architectural complexity and introduces noticeable rendering lag when handling dense data.

ECharts

ECharts is an open-source library managed by the Apache Software Foundation. It’s capable of rendering large web datasets. It offers a declarative configuration style and built-in fluid animations, allowing development teams to create responsive visual narratives.

The framework includes data-clustering features and handles standard multi-dimensional data mapping with minimal configuration. It is a capable choice for web-based analytics platforms, including large-data visualizations, where teams need flexible configuration, responsive interaction, and a broad set of chart types.

The Key Takeaway?

The challenge with ECharts lies in its corporate support structure and cross-platform flexibility. Being a community-driven open-source project means you lack dedicated, immediate technical support channels. When a bug compromises a major enterprise deployment, you’re often forced to dig through community forums or fix the source code yourself. Like Highcharts, its architecture is rooted in the browser ecosystem, making true cross-platform consistency across native desktop and mobile frameworks difficult to sustain.

SciChart

Instead of relying on a web-view wrapper as the main rendering strategy, SciChart is built around Visual Xccelerator™, a proprietary C++ rendering engine designed for high-performance charting across platforms.

Whether you’re building React charts or JavaScript charts, or deploying complex WPF charts, SciChart uses a shared rendering architecture built around its Visual Xccelerator™ engine. We recommend exploring our GitHub chart performance suite to see for yourself.

SciChart supports up to 1 billion data points, making it an ideal choice for industries dealing with high-frequency telemetry, medical imaging, or financial data streams.

It also eliminates the friction of maintaining separate codebases by providing dedicated support for Android charts as well as macOS and iOS charts. This gives teams a dedicated charting option for Android, iOS, macOS, WPF, and JavaScript, reducing the need to rebuild the same charting experience separately for each platform or rely on web-view based rendering for mobile.

SciChart.js provides APIs and documentation to help developers implement:

Accessible charts, including support for screen readers
Color and contrast considerations
Keyboard interaction patterns.

This helps developers build charts that are more accessible to people using assistive technologies.

For enterprise planning, the platform abandons unpredictable, usage-based pricing models in favor of transparent, developer-based licensing. This prevents your operational costs from skyrocketing as your user base expands. Support burdens are also minimized through direct access to professional human developers and an integrated AI assistant.

WashU Racing used SciChart in a Vue.js live telemetry dashboard to display sensor measurements and driver inputs from a Formula SAE car. Previously, testing data had to be pulled from the car over Ethernet after each testing day. With the new dashboard, data is sent to the backend and displayed in SciChart line and scatter plots, helping the team analyze vehicle behavior during testing.

The Key Takeaway?

SciChart’s core advantage is its shared C++ rendering architecture. Visual Xccelerator targets platform graphics technologies including DirectX on Windows, Metal on iOS and macOS, OpenGL ES on Android, and WebGL in the browser. This gives developers a unified charting approach across supported platforms while preserving high-performance rendering for data-heavy applications.

How to Pinpoint the Right Option for Your Project

Choosing the ideal cross-platform visualization tools for enterprise apps requires a clear assessment of your project’s specific data demands and architecture. You can guide your decision by evaluating a few key technical metrics:

Data Density and Update Frequency

If your application only displays static, daily business metrics or basic monthly summaries, general web libraries like Highcharts or ECharts will serve you well. However, if you’re tracking real-time sensor streams, financial markets, or processing large industrial datasets, you need a hardware-accelerated solution built for speed, such as SciChart.

Target Environments

Look closely at where your app will actually live. If you’re building an application exclusively for web browsers, a JavaScript-centric tool fits perfectly. But if your roadmap includes native mobile apps, desktop systems, or cross-platform framework deployments, you need a charting framework that renders natively on each target OS without relying on sluggish embedded browser wrappers.

Total Cost of Ownership

Free, open-source software can quickly become expensive when your engineering team spends weeks writing custom workarounds or waiting for community bug fixes. We also recommend analyzing the licensing models carefully. Predictable developer licenses protect your budget far better than variable runtime or per-user tracking fees.

Find Out More About SciChart Today

If your enterprise application is hitting charting performance limits or your team is rebuilding the same visualization layer across platforms, explore SciChart’s cross-platform charting SDKs and performance demos.

Best Tools for Creating Trading Platform Charts

Andrew Bt — Wed, 09 Sep 2026 09:25:34 +0000

Building software for modern financial markets requires selecting the best tools for creating trading platform charts to ensure optimal user experiences. Developers must handle massive data pipelines without freezing UI threads. Selecting the wrong toolkit early on leads to complete structural rewrites down the line.

What Are the Challenges When Developing Finance & Trading Applications?

Financial application development presents its fair share of technical hurdles as you’re dealing with data streams updating multiple times per second.

Unreliable Rendering Speeds

The primary bottleneck, and perhaps something you’re looking to overcome, is rendering performance. When a market moves fast, your charting interface cannot lag for your end users, even if they’re using a lower-grade device. Millisecond delays can cost traders real money. Mainstream, open-source libraries can stumble when rendering millions of historical bars alongside real-time ticks.

Lack of Customization

A lack of customization presents another hurdle. Out-of-the-box templates lead to brand sameness. If your application looks identical to every competitor, you lose market edge. Dev teams often waste months fighting rigid rendering frameworks just to add custom technical indicators. Surely there’s a better way to achieve this outcome, and truly white-label your application (without costing astronomical prices)?

Poor UX on Mobile

Mobile deployment adds further complexity. Hardware constraints on smartphones make smooth rendering difficult. Delivering a fluid experience across desktop and mobile devices requires specialized engineering. Bithumb, one of South Korea’s largest crypto platforms, used SciChart to deliver a smoother experience on mobile and to fully white-label their design. Moving averages, Bollinger Bands, and volume indicators all updated in real time and with a smooth appearance on the screen.

Insufficient Technical Support

Poor technical support from open-source maintainers also slows down launch timelines. When complex charting bugs surface, waiting weeks for a community fix is frustrating.

Pricing that Scales out of Budget

Deceptive pricing at scale can also leave project budgets at risk of going over. Free tiers often become expensive when your user base grows or when you require advanced commercial features.

Top Charting Libraries for Trading Platforms

Choosing the right foundation depends heavily on your specific tech stack and performance needs. Let us look at how the popular options stack up for financial applications.

TradingView
TradingView is popular for consumer-facing market portals. They offer pre-built financial features that users instantly recognize.

The charting library is ideal if you need a standard look and feel out of the box. It includes standard technical indicators and drawing tools.

The problem is that deep custom modifications can prove difficult. You are largely locked into their ecosystem and visual style. For proprietary trading dashboards requiring completely unique interfaces, the rigid structure is limiting.

Highcharts
Highcharts offers a dedicated financial package called Highcharts Stock.

The library works for standard financial dashboards and reporting tools. It provides decent documentation and broad browser compatibility.

However, performance suffers when you push it to the limit. It relies heavily on SVG rendering, which slows down significantly when rendering hundreds of thousands of data points simultaneously.

Apache Echarts
Apache Echarts is a free, open-source visualization tool maintained by the Apache Software Foundation. It handles basic rendering tasks via Canvas or SVG.

The tool works perfectly fine for simple crypto tickers or basic portfolio overviews and costs nothing to implement initially.

The downside is the lack of specialized financial tooling. You must build complex trading features, like order book depth charts or custom indicators, completely from scratch.

D3
D3 gives you full control over the Document Object Model.

You can build absolutely anything with D3 if you have enough time, making it a flexible choice.

The cost is development velocity. D3 provides no pre-built financial charting components. You must write every line of math for candlestick rendering and zoom behaviors by hand. This slows down your product launch significantly.

SciChart
When you require extreme performance and native speed, SciChart serves as a specialized finance and trading chart library. It handles hundreds of millions of data points in real time.

The architecture uses hardware acceleration to handle intense data loads. This makes it an ideal option for heavy corporate applications, algorithmic trading desks, and complex crypto exchanges.

It fully supports modern web frameworks, allowing you to build reactive React charts or fast JavaScript charts. The library ensures your complex web dashboards remain responsive under heavy market volatility.

SciChart also offers native SDKs for iOS, Android, WPF, and other desktop platforms. This means trading firms can deliver the same low-latency charting experience across mobile apps and native desktop terminals.

The library also closes the support gap raised earlier. Every commercial license includes 5-star technical support, with SciChart aiming to respond to tickets within one business day – a sharp contrast to the multi-week waits common with community-maintained open-source libraries.

How to Evaluate Tools Based on Your Project Scope?

You must balance your performance requirements against your available development timeline. Do not choose a tool simply because it’s popular on forums.

Look closely at your platform requirements. If your product needs to run everywhere, verify the library supports native Android charts and native iOS and macOS charts efficiently. Cross-platform consistency reduces your overall engineering overhead (something that SciChart supports as standard).

Test the rendering engine with realistic simulated data loads before committing. Run stress tests with millions of data points to find where the frame rate drops. With SciChart, you can easily run your own benchmark tests in GitHub.

What Are the Best Tools & Features for Building Trading Apps with SciChart?

This hardware-accelerated engine provides specific sub-features designed specifically for professional financial software engineers.

Drawing Tools

Traders rely heavily on visual analysis to execute orders. The platform includes native drawing tools right out of the box.

Users can instantly apply trendlines, Fibonacci retracements, and custom annotations. This means you don’t need to code these interactive vector overlays from scratch.

SciTrader

For teams wanting to accelerate their launch, the SciTrader app and SDK provide a pre-built reference architecture.

This package gives you a functional trading interface layout immediately. You can modify the underlying code to match your specific data feeds and business logic. This cuts out months of foundational design work.

SciTrader is also where we’re quietly working on the next layer of SciChart’s real-time data architecture (more to be revealed on that soon).

White-labeling

The entire interface supports complete white-labeling. You can strip out default branding and match your exact corporate styling guidelines.

This flexibility prevents brand sameness. Your end users will experience a completely bespoke application that feels built entirely in-house.

Between hardware-accelerated rendering, native SDKs across mobile and desktop, and a licensing model that doesn’t punish growth, SciChart gives trading platform teams a foundation built specifically for the speed and reliability financial markets demand.

Get Started with SciChart

If you want to build a truly high-performance trading application, you need to see the technology in action. You can easily view demos and examples on the official website to test the rendering speeds yourself.

Take the next step for your development project. Try SciChart today to experience less lagging and more data rendering. If you’re building an end-user platform, try SciTrader today to jumpstart your interface design. It’s easy to get started with SciChart using their extensive developer documentation.

How to Implement Real-Time Data Visualization in React

Andrew Bt — Wed, 09 Sep 2026 09:08:24 +0000

Streaming a handful of points into a React chart is easy. Streaming a few million of them, updating dozens of times a second, is a different problem. The browser tab can grind to a halt fast. Have you ever watched a dashboard's frame rate collapse the moment a live feed kicks in? Then you already know why implementing real-time data visualization in React requires more thought than a quick npm install. This guide walks through the architecture, streaming setup, and optimization tricks that separate a demo chart from a production one. It draws on patterns used by teams at SciChart, who build chart libraries for exactly this kind of workload.

Key Takeaways

Pick a rendering engine (GPU-accelerated Canvas, WebGL, or WebAssembly) before you pick a component library. The rendering layer decides your ceiling, rather than the wrapper around it.
Keep streaming data out of React state. Push new points directly into the chart's data series instead of triggering a re-render on every tick. Batch and throttle incoming updates so the UI thread only redraws as often as the screen can actually show it, typically once per animation frame.
Use a FIFO (first in, first out) buffer or windowing strategy to cap memory growth on long-running dashboards.
SciChart supports 1 billion data points and can help teams keep dashboards responsive during multi-day monitoring sessions.

How to Choose the Right Chart Library, Core Architecture & Tech Stack

When requiring stable, real-time performance, the right chart library depends on its rendering engine. SVG-based libraries create a DOM node for every data point. Past a few thousand points, they can choke. Canvas and WebGL libraries draw pixels directly instead, so they scale far better for streaming feeds.

For dashboards handling millions of points, three questions matter more than anything:

What actually draws the pixels? Standard HTML5 Canvas is single-threaded and often runs on the CPU, although it's not strictly CPU-bound. WebGL hands rendering to the GPU instead. WebAssembly-backed engines, like SciChart's Visual Xccelerator™, go further still. They compile the rendering logic to near-native code, so the browser's JavaScript engine stops being the bottleneck.
How does the library handle appends? Look for an API that lets you push new values into an existing data series. Avoid one that expects a brand-new array on every tick.
Does it support downsampling or level-of-detail rendering? When you're zoomed out on months of tick data, you don't need every raw point drawn. A library that reduces detail at low zoom levels keeps frame rates stable, and you won't need to write custom aggregation logic yourself.

Here's a quick comparison of the three common rendering approaches:

SVG (DOM-based) Low thousands Simple charts, infrequent updates

Canvas 2D (Main Thread/CPU-Bound) Tens of thousands Moderate datasets, occasional streaming

WebGL / WebAssembly (GPU) Millions to 100M+ Real-time telemetry, trading, multi-chart dashboards

Once the rendering engine is settled, the rest of the stack tends to fall into place. You'll need a WebSocket or Server-Sent Events layer for the data feed. You'll need a state approach that keeps high-frequency updates away from React's reconciliation cycle. And you'll need a chart component with a direct, imperative way to update data.

How to Set Up a Real-Time Data Stream in React

You set up a real-time stream in React by opening a persistent connection, usually a WebSocket, then parsing each message and feeding the values straight into your chart's data series. Skip component state entirely. Below is a step-by-step pattern using SciChart.js and its React wrapper.

Step 1: Install the packages.

bash npm install scichart scichart-react

Step 2: Create the chart surface and a data series to hold streaming values.

tsx import { EAutoRange, FastLineRenderableSeries, NumericAxis, SciChartSurface, XyDataSeries } from "scichart"; import { SciChartReact } from "scichart-react"; SciChartSurface.loadWasmFromCDN(); const initChart = async (rootElement: string | HTMLDivElement) => { const { sciChartSurface, wasmContext } = await SciChartSurface.create(rootElement); sciChartSurface.xAxes.add( new NumericAxis(wasmContext, { autoRange: EAutoRange.Always }) ); sciChartSurface.yAxes.add( new NumericAxis(wasmContext, { autoRange: EAutoRange.Always }) ); const dataSeries = new XyDataSeries(wasmContext, { fifoCapacity: 5_000 }); sciChartSurface.renderableSeries.add( new FastLineRenderableSeries(wasmContext, { dataSeries, stroke: "#36C4F7", strokeThickness: 2 }) ); return { sciChartSurface, dataSeries }; }; type ChartInitResult = Awaited<ReturnType<typeof initChart>>;

The fifoCapacity setting is doing quiet, important work here. Once the series hits 5,000 points, old values drop off as new ones arrive. Memory usage stays flat, no matter how long the dashboard runs.

Step 3: Open the WebSocket connection and push data straight into the series.

tsx type Sample = { x: number; y: number }; const connectStream = (dataSeries: XyDataSeries) => { const socket = new WebSocket("wss://example.com/telemetry"); socket.onmessage = ({ data }) => { const sample = JSON.parse(data) as Partial<Sample>; if (Number.isFinite(sample.x) && Number.isFinite(sample.y)) { dataSeries.append(sample.x!, sample.y!); } }; return () =>

socket.close(); };

Notice what's missing here: no setState, no re-render, no component update. The chart's own rendering engine handles the redraw internally. That's exactly why this pattern holds up under high-frequency data, where a state-driven approach would fall over.

How to Connect Streaming Data to the Chart Component

You connect streaming data to a chart component by wiring the WebSocket to the chart's onInit and cleanup callbacks. The connection opens when the chart mounts. It closes when the chart unmounts. With SciChartReact, that looks like this:

tsx const handleInit = ({ dataSeries }: ChartInitResult) => connectStream(dataSeries); export function RealtimeChart() { return ( <SciChartReact initChart={initChart} onInit={handleInit} style={{ width: "100%", height: 500 }} /> ); }

A few things worth calling out. This is where most real-time React charts fall apart in practice:

Never store the raw stream in React state: State updates trigger reconciliation. Reconciliation on every WebSocket message is what causes the jank you're trying to avoid.

Batch messages if your feed outpaces the screen: Say your server pushes updates every 5 milliseconds, but the browser only repaints every 16. Buffer the values and flush them once per frame with requestAnimationFrame.

Handle reconnection on purpose: A dropped WebSocket shouldn't silently freeze the chart. Exponential backoff on socket.onclose keeps the dashboard honest about its own connection state.

Clean up on unmount: Leaving sockets open after a component unmounts is a common cause of memory leaks in dashboards with several chart tabs.

What Are the Most Impactful React Chart Optimization Techniques?

The techniques that matter most: keep streaming data out of component state, batch updates to the browser's paint cycle, cap memory with a FIFO buffer, and offload heavy work to Web Workers. Here's how each one plays out.

Bypass React state for hot data: Update the chart's data series through its own API. Don't route every tick through useState or useReducer. This is usually the single biggest lever for real-time dashboards.

Throttle to the paint cycle, not the data rate: Wrap append calls in requestAnimationFrame, so the chart redraws once per frame no matter how fast the feed fires.

Cap series length with FIFO buffers: Unbounded arrays are a slow memory leak in disguise. A fixed-capacity buffer keeps memory and render cost steady on dashboards that run for days.

Offload parsing and aggregation to Web Workers: JSON parsing and rolling averages don't need to fight rendering for the main thread. Move them to a worker and free it up for paint operations.

Downsample at low zoom levels: You rarely need every raw point when a user views a week of data at a glance. A chart that reduces points at low zoom keeps frame rates steady, and shows full detail again once the user zooms back in.

Memoize static chart configuration: Axis definitions, themes, and annotations that stay the same shouldn't be rebuilt on every render. Wrap them in useMemo instead.

Used together, these techniques let a chart hold a steady frame rate through hours, or days, of updates. Without them, performance tends to degrade slowly as the DOM or memory footprint grows.

Scale to Complex Real-Time Charts with SciChart

Once your architecture, streaming setup, and optimization patterns are in place, the ceiling on what you can visualize comes down to the rendering engine. SciChart's React Charts run on a WebAssembly and GPU-accelerated engine called Visual Xccelerator™. It's built for continuous updates, multi-chart dashboards, and datasets that would stall a DOM-based or CPU-only renderer.

This performance matters for teams building multi-pane trading dashboards, medical telemetry monitors, or SCADA systems where the data never stops arriving.

The library also supports deep customization: annotations, point-by-point coloring, and custom interaction behaviors.

If you're building a dashboard that needs to hold up under real-time, high-volume data, browse the React Chart Demos to see live, streaming examples running in the browser. Explore the possibilities with our React Charts support, and see how it handles your own dataset.

React vs Angular Chart Comparison: Selecting Your JS Stack

Andrew Bt — Tue, 08 Sep 2026 15:30:14 +0000

Both React and Angular are well-known JavaScript ecosystems that offer robust component models, but they handle rendering, state changes, and high-frequency data streaming. While they offer these, they do so in fundamentally distinct ways. If your engineering team is building financial trading platforms, medical monitoring tools, or IoT analytics dashboards, picking the wrong framework can lead to severe rendering bottlenecks, re-render overhead, or expensive architectural rewrites later on.

At SciChart, we specialize in high-performance data visualization across both ecosystems. Our canvas and WebGL-powered rendering engine removes the framework selection risk entirely, ensuring your charts run smoothly at 60 FPS regardless of your underlying stack. Below is an in-depth, unbiased comparison of React and Angular to help you determine which JS framework best suits your charting requirements.

Key Takeaways

Architecture Differences: React relies on a flexible virtual DOM and an unopinionated ecosystem, whereas Angular provides a fully integrated, opinionated framework powered by fine-grained change detection and native TypeScript.
Rendering Performance: For standard UI re-renders, React’s lightweight core offers minimal initial bundle overhead. However, under continuous real-time data streams, framework change detection alone can become a bottleneck unless paired with GPU-accelerated rendering.
Enterprise Scaling: Angular excels in strict, multi-team enterprise environments with built-in forms and dependency injection. React offers rapid prototyping velocity and a vast talent pool.
Framework Agnosticism: High-performance charting engines like SciChart support both React and Angular natively, processing 1 billion data points per dataset in WebGL.

What Are the Key Differences Between React and Angular?

React is an unopinionated UI library focused on component rendering, leaving architecture, routing, and state choices to the developer. Angular, on the other hand, is a full-featured, batteries-included framework that provides a rigid structure out of the box, including routing, form handling, and dependency injection.

When comparing both frameworks, the core difference lies in their philosophy:

React (Library): You assemble your own technology stack. You might pair React with TanStack Query for data fetching, Zustand or Redux for state, and React Hook Form for user input.
Angular (Framework): Everything is curated by Google. Running ng new gives you a complete, standardized architecture that looks identical across different development teams.

For charting applications, this architectural difference dictates how components interact with data feeds. React requires explicit hooks (useState, useMemo) to control data propagation, while Angular uses services, RxJS observables, and modern Signals to stream updates to the UI.

Which Framework Performs Better for Real-Time Data Visualization, React or Angular?

Both frameworks achieve comparable real-time rendering speeds when properly optimized. That being said, our in-house developers and community find that React often edges out Angular in raw initial load speed due to its smaller runtime footprint. Angular narrows this performance gap at scale using specialized change detection strategies, such as OnPush and Signals.

In real-time charting, performance is measured by how fast the framework receives a stream of incoming data points and updates the display without dropping below 60 FPS.

React in Real-Time: React’s functional updates and concurrent rendering allow non-urgent UI updates to pause while priority frames render. However, un-memoized component trees can cause cascading re-renders during high-frequency data bursts.
Angular in Real-Time: Angular historically suffered from global change detection overhead via Zone.js. Modern Angular mitigates this with Signals and fine-grained reactive updates, allowing specific chart components to re-render without evaluating the entire application DOM tree.

With the right chart library support, you have the capacity to achieve the same performance across both React and Angular. This is something you can explore for yourself with our React 1 million points demo and Angular 1 million points demo.

Does React or Angular Handle Large Datasets More Efficiently in Charts?

Neither framework’s core DOM manipulation can efficiently process millions of raw data points directly in the document tree without severe performance degradation. When handling large datasets, both React and Angular rely on offloading rendering tasks to HTML5 Canvas or WebGL.

Framework overhead becomes negligible when data processing is decoupled from the DOM. Standard browser DOM elements (and SVG nodes) break down when rendering over 10,000 items simultaneously due to large-scale browser reflow calculations. To achieve the high performance you’re rooting for, application architects use WebGL-backed chart libraries that bypass standard framework re-render cycles entirely.

What Are the Performance Implications of Virtual DOM vs Change Detection for Charts?

React’s virtual DOM calculates UI diffs in memory before updating the screen. Whereas Angular uses a directional change detection tree to check bound values. For charting, frequent DOM diffing or full-tree change detection both introduce processing CPU lag if tied directly to rapid dataset updates.

To visualize how these mechanisms differ during chart rendering, we’ve put together the below structural pipeline:

Data Update Trigger

State change via useState / useReducer.

Property mutation via Zone.js or Signal write.

Re-render Scope

Re-evaluates component function and its children.

Scans component tree top-down unless OnPush is active.

Optimization Strategy

Wrap child charts in React.memo or use useCallback.

Use ChangeDetectionStrategy.OnPush or Signals.

DOM Overhead

In-memory tree comparison (diffing) before batching.

Checks bound properties against previous values in DOM bindings.

When building real-time dashboards, rendering every incoming data point through the Virtual DOM or Change Detection tree is a huge waste of CPU cycles. High-performance applications counteract this by decoupling data ingestion from the framework lifecycle. This means chart buffers are updated directly on the GPU.

Which Framework Has Stronger Charting Library Support: React or Angular?

React has a broader volume of third-party open-source charting wrappers due to its larger market share. But that doesn’t mean that Angular lacks support. It offers more unified, enterprise-grade component suites. However, specialized charting libraries support both frameworks with full feature parity.

Many open-source charting tools built specifically for React or Angular rely on SVG or basic 2D Canvas rendering. While these tools work well for simple bar charts or static pie charts, they struggle when pushed to handle real-time streaming or datasets exceeding hundreds of thousands of points.

SciChart provides a framework-agnostic, high-performance engine that integrates seamlessly into both React and Angular applications. By leveraging our WebAssembly and WebGL Visual Xccelerator™ rendering engine, developers get identical, ultra-fast rendering performance in both ecosystems.

Is React or Angular Easier to Learn for Building Data-Heavy Applications?

React is easier to learn initially. That’s thanks to its smaller core API surface and flexible JavaScript concepts. Angular requires a steeper initial learning curve because developers must learn TypeScript, RxJS, and strict architectural rules before building their first complex view.

React Learning Path: Developers learn components, props, and state in a few days. However, the learning curve can spike when structuring complex client-side state, selecting third-party libraries, and preventing performance memory leaks in custom charting components.
Angular Learning Path: Developers must master dependency injection, decorators, services, and reactive streams upfront. Once mastered, the long-term maintenance curve plateaus as every Angular developer follows identical patterns.

React vs Angular: Which Is Better for Enterprise Applications?

Angular is traditionally favored for large, multi-team enterprise applications due to its strict structure and built-in tooling.

React is preferred by enterprise teams seeking granular flexibility and modularity.

Enterprise software requirements differ from simple web apps. According to Stack Overflow developer survey data, React maintains an overall popularity lead with 44.7% adoption among developers compared to Angular’s 18.2%. However, Angular maintains strong dominance in banking, healthcare, automotive, and defense sectors.

How Does TypeScript Support Compare Between React and Angular?

Angular requires TypeScript natively across the entire framework, integrating type safety directly into template compilation and dependency injection. React treats TypeScript as optional, though it enjoys first-class type definition support across modern build tooling, such as Vite.

For engineering leads coming from C#, C++, or Java backgrounds, Angular’s native TypeScript integration should feel immediately natural. Types are strictly enforced in component templates and service layers.

In React, TypeScript strictness is left to team discipline. Incomplete type definitions in third-party libraries can occasionally introduce any types into client code bases.

Does Bundle Size Affect Chart-Heavy React or Angular Applications?

Yes, bundle size often directly impacts initial page load speeds and Time to Interactive metrics. You may see this at play particularly on mobile devices or constrained networks. React applications typically start with significantly smaller bundle sizes (~65 KB gzipped for basic setups) compared to Angular applications (~180 KB gzipped baseline).

However, as applications grow to encompass 50+ complex views, enterprise state management, routing, and form validation, the bundle size gap narrows substantially. Angular’s aggressive tree-shaking compiler and route-level lazy loading ensure that code is only delivered when required by the user.

Can You Use the Same Charting Library for Both React and Angular?

Yes, advanced charting solutions like SciChart are built with a framework-agnostic and cross-platform core. This paves the way for engineering teams to use the exact same underlying rendering engine across both React and Angular applications.

Using a framework-agnostic charting engine provides significant benefits for your enterprise:

Cross-Team Standardization: Web development teams building in React and Angular share the exact same charting codebase, configuration parameters, and visualization logic.
No Re-learning Curve: Developers switching between framework teams don’t need to learn a new charting API.
Consistent Visual Performance: WebGL acceleration ensures identical 60 FPS performance across all framework targets.

Which Framework Should Startups Choose for Data Visualization Projects?

Startups should generally choose React charts for data visualization projects. The support is compatible with small engineering teams looking to build rapid prototypes, iterate on dashboard layouts, and hire frontend developers quickly. However, if your startup’s engineering team consists primarily of full-stack developers with strong C# or Java backgrounds, the structured environment of Angular charts can significantly speed up early development by eliminating architectural debate.

A SciChart Developer’s Perspective on React vs Angular

“I enjoy working with React because it stays out of the way. It’s quick to learn, flexible, almost everyone knows how it works, and makes it easy to build a dashboard around a specialist charting engine like SciChart.
Angular takes longer to get comfortable with, but its structure is valuable on large projects with several teams.
But, for chart performance, I wouldn’t choose one over the other. Keep fast-moving data outside the framework’s state system and let SciChart handle the rendering, the best choice is usually whichever framework your team works with most confidently, no matter if it’s React, Angular, Vue or even Svelte.” Andrei Vascul, software engineer and React and Angular specialist at SciChart.

Should You Choose React or Angular for Your Next Charting Project?

The choice between building a React vs Angular chart application ultimately depends on your team’s background and scaling plans.

Choose React if: You want maximum flexibility, faster initial load times, access to the largest JS talent pool, or are already utilizing React across other web properties.
Choose Angular if: You’re managing a large enterprise engineering team, require built-in forms and dependency injection, or want strict coding conventions out of the box.

SciChart eliminates framework lock-in by delivering hardware-accelerated, high-performance charting across both React and Angular. Explore the possibilities with our Angular and React Charts support:

Try SciChart today and download our free community edition.
View live interactive demos for React Chart Demos and Angular Chart Demos.

Does a React Chart Library Need to be Native?

Andrew Bt — Tue, 08 Sep 2026 14:57:32 +0000

Ask five developers whether a React chart library needs to be native and you will likely get five different answers. Some swear by native modules for rendering real-time data. Others have shipped fast, canvas-based charts without touching React Native at all. The truth sits somewhere in between. It depends on how a library renders its data, not on whether it’s technically native. SciChart, a chart library built for advanced React and JavaScript developers, takes the second path. This guide explains why.

Key Takeaways

Being native is not what makes a chart fast. The rendering method matters more, WebGL versus DOM or SVG.
React and React Native share a component model. They render to different targets though, the browser DOM versus native mobile UI.
SciChart’s JavaScript and React charts use WebGL rendering. They support 1 billion data points per dataset, and they do not require React Native.
SciChart does not currently ship a dedicated React Native package. However, you can still embed it using a WebView workaround.
Skipping native support is rarely a real issue. It mostly matters for deep native gesture handling or fully offline mobile apps.

What Is React Native vs React?

React is a JavaScript library for building web interfaces. It uses a virtual DOM to update what shows in the browser. React Native takes React’s component model and applies it to mobile apps. It renders to native iOS and Android UI components instead of the DOM.

That is the core split. React writes to HTML elements. React Native writes to native views on iOS and Android, skipping the browser entirely. If you’re asking what is React Native vs React from a syntax view, they look almost the same. JSX, hooks, props, state, all familiar. The difference shows up in the rendering stage.

For chart libraries, this matters a lot. Most high-performance charting relies on the browser’s rendering pipeline, whether that’s canvas, SVG, or WebGL. React Native has no DOM, meaning a chart library built for the web cannot just drop straight in.

React vs React Native, Which Do You Need?

You need React for a web app, dashboard, or browser tool. You need React Native for a mobile app with native performance and platform-specific UI. The choice usually comes down to where you deploy, rather than which syntax you like more.

Some teams try to skip the decision. They build once and hope to ship everywhere. That works fine for standard UI, buttons, lists, and forms. It works less well for data-dense components such as charts. A React vs React Native decision for chart-heavy apps should weigh up rendering performance.

Building a browser app or an Electron-style desktop tool? React with a WebGL-based chart library has the potential to get you further, faster. Shipping a native mobile app first? Start with React Native, then decide how to handle charting inside it.

Is React Native Still Relevant in 2026?

Yes. React Native remains a common pick for cross-platform mobile work, especially for startups building one codebase across iOS and Android. It has not been replaced by newer frameworks. It now competes with Flutter and native-first tools, such as Kotlin Multiplatform.

Developers now expect near-native performance from React Native apps. Meta’s ongoing work on the new architecture, Fabric and TurboModules, has closed much of the old performance gap. This means that the standard app UI holds up well.

Where it still struggles is heavy, data-dense rendering, which happens to be the workload that charting libraries can handle. React Native hasn’t lost relevance. But you just want to weigh up whether any JavaScript-bridge framework suits pushing millions of points to the screen sixty times a second.

Does SciChart Support React Native?

SciChart does not ship a dedicated React Native package right now. Its JavaScript and React charts are built for browser-based WebGL rendering. That is what gives you the 1 billion data points per dataset performance the library is known for. But, that rendering approach needs canvas access, and React Native does not expose canvas the way a browser does.

SciChart’s own setup documentation for React Native confirms this. The library is built around web rendering technology first. That does not lock React Native developers out though. It just means a slightly different setup path, covered below, instead of a simple npm install.

Building a fully native app with no web layer at all? SciChart’s current JavaScript and React products are not the direct fit here. Got any flexibility to render a web view inside your app? Then you can likely still get the same performance and customization you would get on the web.

Is Not Using React Native an Issue?

For most charting use cases, no. The performance ceiling for SciChart’s charts comes from WebGL rendering, rather than React Native compatibility.
It only becomes an issue in narrower cases, such as building a fully offline mobile app with no WebView allowed. Some regulated or embedded environments restrict this. If you need your chart inside a tightly customized native navigation stack with limited memory, the WebView route adds overhead you might want to avoid.

For dashboards, trading apps, scientific tools, and most business intelligence products accessed through a mobile shell, the gap is small. Users see a smooth, responsive chart either way.

How to Set Up SciChart in React Native

You can bring SciChart’s JavaScript charts into a React Native app with a WebView component. You render the chart as you would on the web, then display it inside your native app shell. Here is the general approach:

Add a WebView package, such as react-native-webview, to your React Native project.
Host your SciChart JavaScript or React chart as a standalone web page, or bundle it locally.
Load that page inside the WebView component on your React Native screen.
Pass data between your native app and the chart using the WebView’s messaging bridge, postMessage and onMessage.
Style the WebView container to match your app’s layout, since the chart renders inside the web content.

This keeps SciChart’s full WebGL performance. The chart still runs in a real browser engine. It’s just wrapped inside your native app instead of a standalone browser tab.

What Workarounds Are Available?

Beyond the standard WebView approach, a few workaround variations help depending on your app’s needs.

Local bundling: Package the chart’s HTML, JavaScript, and assets inside your app bundle instead of fetching from a server. Handy for offline-first apps or faster loading.
Hybrid screens: Use native React Native UI for navigation and forms, then drop into a WebView only for the chart screen. Keeps most of the app feeling fully native.
Data-bridge batching: Batch data updates before sending them across the WebView bridge. Skip streaming point by point, and you cut messaging overhead on busy datasets.
Server-rendered snapshots: For less interactive cases, render a static chart image on the server first. Load the interactive WebView version only on demand, and initial load feels faster.

None of these require rebuilding SciChart itself. They are integration patterns. Each one keeps the same rendering engine and dataset capacity while working around React Native’s missing DOM.

For WebView workarounds, we recommend visiting these GitHub resources:

How to Import an iOS Library into React Native
You are also able to import a native iOS/Android chart library into React Native, using the below steps:

Install Pod: Add pod ‘JGProgressHUD’ to your ios/Podfile and run cd ios && pod install.
Create Files: Open workspace in Xcode, create a Cocoa Touch Class for your module name (e.g., LoadingOverlay.h and LoadingOverlay.m).
Expose to Bridge: In LoadingOverlay.h and .m, register the module using RCT_EXPORT_MODULE() and define a bridge method using RCT_EXPORT_METHOD(…) (e.g., toggle:(BOOL)show).
Implement Native UI: Instantiate JGProgressHUD, attach it to the key application window (UIApplication.sharedApplication.keyWindow.rootViewController.view), and trigger .showInView or .dismiss based on the passed boolean.
How to Import an Android Library into React Native
Add Dependency: In android/app/build.gradle, add implementation ‘com.kaopiz:kprogresshud:1.2.0’ inside dependencies.
Create Java Module & Package: Add LoadingOverlay.java (extends ReactContextBaseJavaModule) and LoadingOverlayPackager.java (implements ReactPackage) beside MainActivity.java.
Register Module: Register new LoadingOverlayPackager() inside MainApplication.java under getPackages().
Implement Native UI: Use @ReactMethod to create toggle(Boolean show). Retrieve the current activity (getCurrentActivity()), instantiate KProgressHUD.create(activity), and call .show() or .dismiss().

Call Bridge from React Native for iOS and Android

Import NativeModules from React Native and call your newly exposed bridge function anywhere in your JavaScript code:

JavaScript import { NativeModules } from 'react-native'; const { LoadingOverlay } = NativeModules; // Show native overlay LoadingOverlay.toggle(true); // Hide native overlay after delay setTimeout(() => { LoadingOverlay.toggle(false); }, 3000);

Building Fast Charts Without React Native

None of this makes React Native the wrong choice. It also does not make going native a requirement for good chart performance. What matters is matching your rendering approach to your actual workload. SciChart’s WebGL-based charts handle datasets up to 1 billion points in JavaScript and React. That performance holds up whether you run in a browser tab or wrap it inside a React Native WebView.

Weighing up your options for a data-heavy build? Try SciChart today and see how the React Charts library handles your dataset. You can also explore the possibilities with our React Chart Demos to watch real-time rendering in action before you commit to an architecture.

FAQs

Is React Native the same as React?

No. React Native uses React’s component syntax, but it renders to native mobile UI instead of the browser DOM. Code written for one does not run directly in the other. Most concepts and logic still carry over easily.

What Is the difference between React and React Native?

React targets web browsers and renders HTML elements. React Native targets iOS and Android, rendering native platform views. The difference between React and React Native comes down to the rendering target and the available APIs, as opposed to the JavaScript logic itself.

Should you learn React or React Native first?

Learn React first. It covers the basics, components, state, hooks, and props that React Native builds on directly. Once you know React well, picking up React Native mostly means learning its native-specific APIs and layout rules so you don’t have to start over.

The Software War Behind Formula 1 That Nobody Talks About

Andrew Bt — Fri, 29 May 2026 12:23:10 +0000

When people think about what wins a Formula 1 championship, they think about aerodynamics. Engine power. Tyre strategy. The driver.

They rarely think about the engineer staring at a screen in the pit wall, watching hundreds of data channels update in real time, trying to catch a 40-millisecond anomaly in the power unit before it becomes a DNF.

But increasingly, that's where races are won and lost.

F1 has quietly become one of the most data-intensive engineering environments on the planet. And the software that sits between raw sensor data and human decisions is under enormous pressure - pressure that most general-purpose tools simply weren't built to handle.

The scale of the data problem

A modern F1 car runs somewhere north of 300 IoT telemetry sensors. Wheel speeds, brake temperatures, tyre pressures, fuel flow, throttle position, DRS actuation, suspension travel, GPS position, g-forces across three axes - all streaming simultaneously, many at several hundred Hz.

On a race weekend, a single car generates hundreds of gigabytes of data. The engineers watching it in real time can't wait for post-processing. A tyre that's about to blister, a power unit running hot, an undercut window opening up - these are decisions made in seconds, based on live data.

The challenge isn't just storing or transmitting the data. It's also displaying it. Fast enough, accurately enough, across enough channels at once, that a human engineer can actually make sense of it.

Why this is harder than it sounds

Plotting a handful of sensor channels on a chart isn't hard. Plotting hundreds of channels, updating multiple times per second, across split screens in a pit wall environment, while an engineer is actively zooming in on a specific corner of a specific lap from three laps ago - that's a different problem entirely.

The transients that matter in F1 often last milliseconds. A spike in brake temperature. A momentary loss of downforce through a corner. If your visualization is downsampling the data to keep up with rendering, those events disappear. You're looking at a smoothed version of reality, and the thing you needed to catch isn't there anymore.

This is where most off-the-shelf charting libraries fall over. They were designed for slower, simpler data. They handle downsampling gracefully because for most use cases, downsampling is fine. In F1 it isn't.

What we do about it

We've been embedded in F1 for years now, and at this point we're used by 9 out of 10 teams on the grid. Our GPU-accelerated rendering engine underpins telemetry systems, pit wall dashboards, simulation correlation tools, power unit development workflows, tyre performance modelling, wind tunnel data interpretation, and ECU analysis across the paddock.

The reason teams use us comes down to one thing: we don't drop data.
Because we render directly on the GPU rather than on the CPU through Canvas or SVG, the rendering cost doesn't scale with the volume of data the way it does with conventional libraries. A single visualization in a production F1 environment might be pulling tens of millions of data points. It still needs to feel instant. With GPU rendering, it does.

That means engineers are always looking at the full signal. Not a summary of it. Not an approximation. The actual data, at full resolution, rendered fast enough to interact with in real time.

The cost cap changed everything

Something shifted in F1 a few years ago with the introduction of the budget cap. Before the cap, teams with the biggest budgets could throw hardware and headcount at every problem. Now everyone is working within the same financial ceiling.

That's pushed teams toward a software-first engineering philosophy. If you can't outspend your rivals on wind tunnel time or manufacturing, you'd better be getting more insight out of the data you already have.

Simulation, correlation, sensor fusion - these workflows have become genuinely competitive differentiators.

And all of them depend on data visualization. Data you can't see clearly is data you can't act on.

New teams coming into F1 are building their software infrastructure before they've built the car. That tells you something about where the sport's priorities have shifted.

F1 as a proving ground

One of the things we've noticed over the years is that F1 acts as a kind of stress test for data telemetry, storage and visualization technology. The requirements - high frequency, low latency, full signal fidelity, real-time interaction - are extreme. Solutions that work in F1 tend to work everywhere else too.

The same rendering engine we use in pit wall telemetry also powers real-time patient monitoring in ICUs, live institutional or high-frequency trading dashboards handling thousands to millions of ticks per second, and aerospace simulation. The domains are completely different but the underlying data problem is the same: too much signal, moving too fast, where missing something has real consequences.

F1 just happens to be the environment where those requirements are most visible - and most unforgiving.

What this looks like as a developer

If you're building anything in this space - motorsport engineering tools, high frequency data dashboards, anything where signal integrity matters at scale - the questions worth asking are:
What happens to my chart at a million data points? Does it downsample, or does it render everything? What's the frame rate when 50 channels are updating simultaneously? Can an engineer view the dashboard, zoom, pan, or annotate without the UI blocking?

If the answers involve workarounds, you've found your ceiling. The rendering architecture is the constraint, and it's worth treating it as a first-class engineering decision rather than something you pick a library for and move on.

We've been lucky to work with teams where these decisions genuinely matter - where the software on the pit wall is part of what gets a car across the finish line first. That's a standard that keeps us honest.

Andrew Burnett-Thompson is CEO and Founder of SciChart. He started the company out of personal necessity, writing the first version during his commute into London. SciChart now powers data visualization across Formula 1, healthcare, finance, and aerospace. He holds a doctorate in electrical engineering and is a top-2% contributor on Stack Overflow.

Disclaimer: Image is generated by AI.

Why Your Chart Library Is the Bottleneck You Never Suspected by Andrew Burnett-Thompson, CEO & Founder of SciChart

Andrew Bt — Wed, 27 May 2026 09:52:25 +0000

You've spent weeks building a real-time dashboard. The backend is fast. The data pipeline is solid. Your websocket is humming along.
Then you drop in a chart library and everything falls apart.
60fps becomes 6fps. The browser tab is eating 2GB of RAM. Users are telling you the UI feels sluggish. So you start adding debouncing, virtualization, downsampling workarounds... and it gets marginally better. But the core problem doesn't go away. Eventually you end up with a 25-person team writing an extraordinarily complicated server-side to handle the data aggregation that the client can’t.

We've watched this happen more times than we can count. It's actually the reason SciChart exists. I hit this exact wall designing trading software when working in Investment Banking in London. Trying to build a trading system that could handle long histories of tick data, bid-asks and historical market data was impossible when none of the available chart libraries could handle it.

So, I started building SciChart while commuting on the train to work in London every day. A side project, which was started as a personal necessity, grew into something outstanding that is now used in all kinds of verticals: medical devices, patient monitoring, finance & trading apps, stock exchanges, industrial telemetry IoT and more.

Here’s what we figured out.

Most chart libraries weren't built for your use case

The mental model behind most charting libraries is basically: render a bar chart of monthly sales, draw a line graph of annual temperatures. Static or slow-moving data. That assumption is baked deep into the architecture.
Under the hood, they're using SVG or Canvas 2D. Both work fine at hundreds of data points. At 100,000+ points - the volumes you run into with financial tick data, medical waveforms, or industrial sensor streams - they start to buckle.

SVG is DOM-based, so every data point becomes a DOM node. The browser has to lay out, paint, and composite all of it every frame. At scale, that's just not viable.

Canvas 2D is better but it's still CPU-bound and single-threaded. The GPU in every modern device sits there doing nothing while your chart struggles.

What we did differently

When we started building SciChart in 2011, we decided to use a GPU-accelerated rendering engine - the same kind of technology that runs video games. At the time it felt like an unusual choice for a charting library. In hindsight it was the only decision that made sense.

A GPU exists specifically to process massive amounts of geometry data very fast. Hundreds of millions of vertices per second is normal. So instead of looping through data points in JavaScript and drawing lines on a canvas, you upload data directly to GPU memory and let the hardware handle the rendering.

The upshot is that rendering performance doesn't fall off a cliff as your dataset grows. We regularly demo charts with tens or hundreds of millions of data-points running in the browser in real time. On desktop, that maximum point-count runs up to to 100 Billion data-points. That's not a marketing number - you see it for yourself in our demos (JavaScript, WPF).

What this actually unlocks in practice:

You stop aggregating and decimating. Aggregating means discarding signal. In finance that's a missed trade. In a clinical setting that could be a missed arrhythmia. When rendering is fast enough, you show the full data.

You stop writing compensatory code. Debouncing, chunked rendering, web workers bolted onto your chart component - all of that is just working around a renderer that can't keep up. A fast enough renderer means less code to maintain.

Your main thread stays free. Because the GPU renders asynchronously, JavaScript is unblocked. Users can pan and zoom through live data without the whole UI freezing.

What this looks like in a real deployment

One of the hardest things we power is real-time patient monitoring. Think 16 ECG channels, each streaming at 500Hz, all displayed at once on a clinical workstation while a clinician is actively using the interface - zooming into anomalies, annotating, scrubbing through history.

A conventional library can't do this at full resolution. You'd have to aggregate or decimate, which in a clinical context is a real problem. With GPU rendering it's not a hard problem anymore. We're deployed in operating theatres and ICUs.

The same architecture holds up in F1 telemetry (hundreds of sensor channels, transients measured in milliseconds), trading infrastructure (millions of ticks, zero tolerable latency), and aerospace simulation.

https://www.youtube.com/watch?v=H_gOdC9sNRs

The rendering pipeline in plain terms

For anyone who wants to understand what's actually happening:
Data arrives from your websocket or buffer and gets written into a typed array (Float64Array). That array gets uploaded to a GPU vertex buffer - GPU memory bandwidth is in the hundreds of GB/s so this is nearly instant.

A vertex shader maps your data coordinates to screen coordinates. A fragment shader handles colors. Both run in parallel across thousands of GPU cores. The result gets composited into your UI by the browser's compositor.

The CPU and main thread are not in the critical path for any of that. Your JavaScript is free to handle new incoming data while the GPU is already drawing the previous frame.

The question worth asking your chart vendor

If you're building with real-time streaming data, large explorable historical datasets, or anything where signal fidelity matters, your charting library's rendering architecture is a real architectural decision. Worth the same scrutiny as your database or state management.

The practical test: ask what happens at a million data points. If the answer mentions decimating, chunking, aggregating or web workers as a workaround, you've found your ceiling.

A bit about SciChart

SciChart ships charting libraries for JavaScript/TypeScript, React, Angular, WPF/.NET, iOS (Swift, Objective-C), Android (Kotlin, Java), and macOS. We're used by 10,000+ customers across 90 countries - F1 teams, hospital networks, hedge funds, aerospace companies.

We picked up Healthcare Tech of the Year at the National Technology Awards this year, which was genuinely nice to receive. But the thing I'm most proud of is the rendering engine itself - the fact that developers using SciChart don't have to think about performance. They can just focus on what the data means.

If you're running into limits with your current library, drop a comment or get in touch. Always interested to hear what people are actually building.

The live demo gallery at demo.scichart.com runs in the browser. The performance demo is worth a look.

Andrew Burnett-Thompson is CEO and Founder of SciChart. Doctorate in electrical engineering, top 2% on Stack Overflow, been building high-performance visualization software for over a decade.

Creating a React Dashboard with SciChart.js, SciChart-React and Deepseek AI

Andrew Bt — Wed, 15 Apr 2026 07:57:11 +0000

Introduction

Data visualization is a critical aspect of modern web applications, enabling users to understand complex data at a glance. With the rise of powerful React chart library like SciChart.js, developers can now create stunning, high-performance visualizations with ease. When combined with React, a popular JavaScript library for building user interfaces with interactive dashboards, the possibilities are endless.

In this blog, we’ll explore how to build a dynamic dashboard that showcases five different chart types, all seamlessly integrated into a single view. The dashboard is designed to be interactive, with tooltips, legends and zooming and panning behaviours to allow you to inspect data on the fly. We’ll also apply the Navy theme from SciChart.js to give the dashboard a sleek, professional look.

We’ll show the power of generative AI tools in creating this React Dashboard layout by using Deepseek R1, an open source competitor to Chat GPT and show the prompts used and what changes were required to get the dashboard working. We’ll code the entire tutorial in codesandbox.

Key Takeaways

How to integrate SciChart.js into a React application.
Creating and customizing five different chart types: React Line Chart, React Scatter Chart, React Stacked Column Chart, React Mountain Chart, and React Pie Chart.
Applying a custom theme (Navy theme) to all charts for a cohesive look.
Applying legends, zooming and panning and tooltip behaviours.
Concluding on the limitations and pros/cons of using AI such as Chat GPT or Deepseek for creating react dashboards and where this technology could go next.

Who is this for?

Frontend Developers looking to enhance their data visualization skills.
React Developers interested in integrating advanced charting libraries.
Data Enthusiasts who want to create interactive dashboards for data analysis.

Getting Started

Creating the Input Prompt

We begin the tutorial by using Deepseek, an open source competitor to Chat GPT which scores highly in coding benchmarks, and operates at a fraction of the cost of Open AIs solutions.

We’ll start with our first prompt.

Create a dashboard in react with 5 charts using SciChart.js and scichart-react. Each chart should be hosted in a <SciChartReact/> component. initChart should not be inline but be a separate function.

The charts should be arranged in two rows. The first row should have two charts: a line chart (top left) and a scatter chart (top right).

The second row should have three charts: A stacked column chart (bottom left), a Mountain chart (bottom middle) and a pie chart (bottom right). Create some dummy data to upload to the charts and create the dashboard.

Choose the theme SciChartJsNavyTheme to apply to each chart. Do not set any Series Colors or Fill/Stroke on the chart series, as these will be applied automatically by the theme.

Ensure all SciChart type imports are “import { A, B, C } from ‘scichart'”

Deepseek gets straight to work on the output, recommending correctly to npm install scichart scichart-react. It then provides JSX output to include in your application.

The first output from DeepSeek provided good, but slightly incorrect code. We’re going to modify and correct it later. Here it is the initial draft of dashboard.jsx in full:

dashboard.jsx version #1 with errors

import React from "react";
import {
  SciChartSurface,
  NumericAxis,
  FastLineRenderableSeries,
  XyDataSeries,
  EllipsePointMarker,
  FastScatterRenderableSeries,
  StackedColumnCollection,
  StackedColumnRenderableSeries,
  FastMountainRenderableSeries,
  PieChart,
  PieSegment,
  SciChartJsNavyTheme,
} from "scichart";
import { SciChartReact } from "scichart-react";

// Initialize the line chart
const initLineChart = async (rootElement) => {
  const { sciChartSurface, wasmContext } = await SciChartSurface.create(rootElement, 
  {
    theme: new SciChartJsNavyTheme(),
  });
  const xAxis = new NumericAxis(wasmContext);
  const yAxis = new NumericAxis(wasmContext);
  sciChartSurface.xAxes.add(xAxis);
  sciChartSurface.yAxes.add(yAxis);

  const lineSeries = new FastLineRenderableSeries(wasmContext, {
    dataSeries: new XyDataSeries(wasmContext, {
      xValues: [1, 2, 3, 4, 5],
      yValues: [2, 4, 6, 8, 10],
    }),
  });
  sciChartSurface.renderableSeries.add(lineSeries);
  return sciChartSurface;
};

// Initialize the scatter chart
const initScatterChart = async (rootElement) => {
  const { sciChartSurface, wasmContext } = await SciChartSurface.create(rootElement,
  {
    theme: new SciChartJsNavyTheme(),
  });
  const xAxis = new NumericAxis(wasmContext);
  const yAxis = new NumericAxis(wasmContext);
  sciChartSurface.xAxes.add(xAxis);
  sciChartSurface.yAxes.add(yAxis);

  const scatterSeries = new FastScatterRenderableSeries(wasmContext, {
    dataSeries: new XyDataSeries(wasmContext, {
      xValues: [1, 2, 3, 4, 5],
      yValues: [3, 5, 7, 9, 11],
    }),
    pointMarker: new EllipsePointMarker(wasmContext, { width: 10, height: 10 }),
  });
  sciChartSurface.renderableSeries.add(scatterSeries);
  return sciChartSurface;
};

// Initialize the stacked column chart
const initStackedColumnChart = async (rootElement) => {
  const { sciChartSurface, wasmContext } = await SciChartSurface.create(rootElement, 
  {
    theme: new SciChartJsNavyTheme(),
  });
  const xAxis = new NumericAxis(wasmContext);
  const yAxis = new NumericAxis(wasmContext);
  sciChartSurface.xAxes.add(xAxis);
  sciChartSurface.yAxes.add(yAxis);

  const stackedColumnCollection = new StackedColumnCollection(wasmContext);
  const series1 = new StackedColumnRenderableSeries(wasmContext, {
    dataSeries: new XyDataSeries(wasmContext, {
      xValues: [1, 2, 3, 4, 5],
      yValues: [2, 3, 4, 5, 6],
    }),
  });
  const series2 = new StackedColumnRenderableSeries(wasmContext, {
    dataSeries: new XyDataSeries(wasmContext, {
      xValues: [1, 2, 3, 4, 5],
      yValues: [1, 2, 3, 4, 5],
    }),
  });
  stackedColumnCollection.add(series1, series2);
  sciChartSurface.renderableSeries.add(stackedColumnCollection);
  return sciChartSurface;
};

// Initialize the mountain chart
const initMountainChart = async (rootElement) => {
  const { sciChartSurface, wasmContext } = await SciChartSurface.create(rootElement, 
  {
    theme: new SciChartJsNavyTheme(),
  });
  const xAxis = new NumericAxis(wasmContext);
  const yAxis = new NumericAxis(wasmContext);
  sciChartSurface.xAxes.add(xAxis);
  sciChartSurface.yAxes.add(yAxis);

  const mountainSeries = new FastMountainRenderableSeries(wasmContext, {
    dataSeries: new XyDataSeries(wasmContext, {
      xValues: [1, 2, 3, 4, 5],
      yValues: [5, 4, 3, 2, 1],
    }),
  });
  sciChartSurface.renderableSeries.add(mountainSeries);
  return sciChartSurface;
};

// Initialize the pie chart
const initPieChart = async (rootElement) => {
  const { sciChartSurface, wasmContext } = await SciChartSurface.create(rootElement, 
  {
    theme: new SciChartJsNavyTheme(),
  });
  const pieChart = new PieChart(wasmContext, {
    segments: [
      new PieSegment({ value: 30, title: "Segment 1" }),
      new PieSegment({ value: 20, title: "Segment 2" }),
      new PieSegment({ value: 50, title: "Segment 3" }),
    ],
  });
  sciChartSurface.renderableSeries.add(pieChart);
  return sciChartSurface;
};

// Dashboard component
const Dashboard = () => {
  return (
    <div style={{ display: "flex", flexDirection: "column", gap: "20px" }}>
      {/* First row */}
      <div style={{ display: "flex", gap: "20px" }}>
        <div style={{ flex: 1 }}>
          <SciChartReact initChart={initLineChart} 
                 style={{ width: "100%", height: "400px" }} />
        </div>
        <div style={{ flex: 1 }}>
          <SciChartReact initChart={initScatterChart} 
                 style={{ width: "100%", height: "400px" }} />
        </div>
      </div>

      {/* Second row */}
      <div style={{ display: "flex", gap: "20px" }}>
        <div style={{ flex: 1 }}>
          <SciChartReact initChart={initStackedColumnChart} 
                 style={{ width: "100%", height: "400px" }} />
        </div>
        <div style={{ flex: 1 }}>
          <SciChartReact initChart={initMountainChart} 
                 style={{ width: "100%", height: "400px" }} />
        </div>
        <div style={{ flex: 1 }}>
          <SciChartReact initChart={initPieChart} 
                 style={{ width: "100%", height: "400px" }} />
        </div>
      </div>
    </div>
  );
};

export default Dashboard;

Creating a Project in CodeSandbox

Let’s export this into an IDE. For the purpose of this tutorial we’ll use codesandbox which provides a ready-made IDE in browser with full npm, JavaScript and react support.

On the homepage of codesandbox, click ‘Create’ to create a new sandbox.

Choose React(TS) as a template. This will create a new react project with npm and TypeScript or JavaScript support.

In the dependencies section, add scichart and scichart-react. This is equivalent to npm install scichart scichart-react in your IDE. Package.json should update as follows:

Next, create a file called dashboard.jsx. Paste in the code outputted by the above prompt. NOTE the code is incorrect, as AI’s aren’t perfect yet, but we’ll make some minor changes to get it compiling.

Now, modify the default App.tsx to contain a component:

import "./styles.css";
import Dashboard from "./dashboard";

export default function App() {
  return (
    <div className="App">
      <Dashboard />
    </div>
  );
}

You should see something like this. Promising, but it isn’t quite working. In the next section we’ll work through the errors to get a working React Dashboard.

Getting the Dashboard Working

Let’s start working through the errors.

Error #1: Check types are correct

AIs such as ChatGPT or Deepseek often make subtle errors in syntax. This is because they are trained on the whole internet but may not have specific knowledge about a particular library like SciChart. These can be easily fixed with a little knowledge of the library and the scichart.js documentation.

For example, in dashboard.jsx, FastScatterRenderableSeries is incorrect – this should be XyScatterRenderableSeries. Check for other badly imported types or type errors. Codesandbox will point out syntax errors as well as have autocomplete (intellisense) for type information found in the SciChart library.

Error #2: Could not load SciChart WebAssembly module

Could not load SciChart WebAssembly module. Check your build process and ensure that your scichart2d.wasm, scichart2d.data and scichart2d.js files are from the same version
This error occurs because you need to either package wasm & data files or load them from CDN. You can find out how to do this here.

Add a call to SciChartSurface.loadWasmFromCDN() at the start of your Dashboard react component.

// Dashboard component
const Dashboard = () => {

  SciChartSurface.loadWasmFromCDN(); // Add this call
  return (
    <div style={{ display: "flex", flexDirection: "column", gap: "20px" }}>
      {/* First row */}
      <div style={{ display: "flex", gap: "20px" }}>
        <div style={{ flex: 1 }}>
        ...

Error #3: _scichart.PieChart is not a constructor

OK so DeepSeek has totally messed this one up, but no worry, we can find out the real syntax for creating a pie chart from the SciChart JavaScript Pie Chart demo.

Here’s the incorrect code outputted by AI:

// Initialize the pie chart
const initPieChart = async (rootElement) => {
  const { sciChartSurface, wasmContext } = await SciChartSurface.create(
    rootElement,
    {
      theme: new SciChartJsNavyTheme(),
    }
  );
  const pieChart = new PieChart(wasmContext, {
    segments: [
      new PieSegment({ value: 30, title: "Segment 1" }),
      new PieSegment({ value: 20, title: "Segment 2" }),
      new PieSegment({ value: 50, title: "Segment 3" }),
    ],
  });
  sciChartSurface.renderableSeries.add(pieChart);
  return sciChartSurface;
};

And here’s the correct code.

const initPieChart = async (rootElement) => {
  const sciChartSurface = await SciChartPieSurface.create(rootElement, {
    theme: new SciChartJsNavyTheme(),
  });
  const pieChartData = [
    { value: 40, text: "Segment 1" },
    { value: 30, text: "Segment 2" },
    { value: 20, text: "Segment 3" },
    { value: 10, text: "Segment 4" },
  ];

  pieChartData.forEach((segment) =>
    sciChartSurface.pieSegments.add(new PieSegment(segment))
  );
  return sciChartSurface;
};

Error #4: “initChart” function should resolve to an object with “sciChartSurface” property ({ sciChartSurface })

This error is related to the use of scichart-react, which expects an initialization function with a return value of { sciChartSurface }

Here’s the incorrect code for each of the charts that are initialized by AI:

// Initialize the line chart
const initLineChart = async (rootElement) => {
  const { sciChartSurface, wasmContext } = await SciChartSurface.create(rootElement, {
      theme: new SciChartJsNavyTheme(),
  });
  const xAxis = new NumericAxis(wasmContext);
  const yAxis = new NumericAxis(wasmContext);
  sciChartSurface.xAxes.add(xAxis);
  sciChartSurface.yAxes.add(yAxis);

  const lineSeries = new FastLineRenderableSeries(wasmContext, {
    dataSeries: new XyDataSeries(wasmContext, {
      xValues: [1, 2, 3, 4, 5],
      yValues: [2, 4, 6, 8, 10],
    }),
  });
  sciChartSurface.renderableSeries.add(lineSeries);
  return sciChartSurface; // this line is incorrect, 
  // modify to return { sciChartSurface }
};

And here’s how to correct it:

// Initialize the line chart
const initLineChart = async (rootElement) => {
  const { sciChartSurface, wasmContext } = await SciChartSurface.create(rootElement, {
      theme: new SciChartJsNavyTheme(),
  });
  // ... 
  return { sciChartSurface }; // This is the correct return value
};

Do this for each of the charts.

The complete React Dashboard

Hurrah! You should now have a working dashboard. It looks a bit bland but we’ll modify it in the next sections.

Here’s the working code for dashboard.jsx:

dashboard.jsx version #2 working dashboard

import React from "react";
import {
  SciChartSurface,
  NumericAxis,
  FastLineRenderableSeries,
  XyDataSeries,
  EllipsePointMarker,
  XyScatterRenderableSeries,
  StackedColumnCollection,
  StackedColumnRenderableSeries,
  FastMountainRenderableSeries,
  SciChartPieSurface,
  PieSegment,
  SciChartJsNavyTheme,
} from "scichart";
import { SciChartReact } from "scichart-react";

// Initialize the line chart
const initLineChart = async (rootElement) => {
  const { sciChartSurface, wasmContext } = await SciChartSurface.create(
    rootElement,
    {
      theme: new SciChartJsNavyTheme(),
    }
  );
  const xAxis = new NumericAxis(wasmContext);
  const yAxis = new NumericAxis(wasmContext);
  sciChartSurface.xAxes.add(xAxis);
  sciChartSurface.yAxes.add(yAxis);

  const lineSeries = new FastLineRenderableSeries(wasmContext, {
    dataSeries: new XyDataSeries(wasmContext, {
      xValues: [1, 2, 3, 4, 5],
      yValues: [2, 4, 6, 8, 10],
    }),
  });
  sciChartSurface.renderableSeries.add(lineSeries);
  return { sciChartSurface };
};

// Initialize the scatter chart
const initScatterChart = async (rootElement) => {
  const { sciChartSurface, wasmContext } = await SciChartSurface.create(
    rootElement,
    {
      theme: new SciChartJsNavyTheme(),
    }
  );
  const xAxis = new NumericAxis(wasmContext);
  const yAxis = new NumericAxis(wasmContext);
  sciChartSurface.xAxes.add(xAxis);
  sciChartSurface.yAxes.add(yAxis);

  const scatterSeries = new XyScatterRenderableSeries(wasmContext, {
    dataSeries: new XyDataSeries(wasmContext, {
      xValues: [1, 2, 3, 4, 5],
      yValues: [3, 5, 7, 9, 11],
    }),
    pointMarker: new EllipsePointMarker(wasmContext, { width: 10, height: 10 }),
  });
  sciChartSurface.renderableSeries.add(scatterSeries);
  return { sciChartSurface };
};

// Initialize the stacked column chart
const initStackedColumnChart = async (rootElement) => {
  const { sciChartSurface, wasmContext } = await SciChartSurface.create(
    rootElement,
    {
      theme: new SciChartJsNavyTheme(),
    }
  );
  const xAxis = new NumericAxis(wasmContext);
  const yAxis = new NumericAxis(wasmContext);
  sciChartSurface.xAxes.add(xAxis);
  sciChartSurface.yAxes.add(yAxis);

  const stackedColumnCollection = new StackedColumnCollection(wasmContext);
  const series1 = new StackedColumnRenderableSeries(wasmContext, {
    dataSeries: new XyDataSeries(wasmContext, {
      xValues: [1, 2, 3, 4, 5],
      yValues: [2, 3, 4, 5, 6],
    }),
  });
  const series2 = new StackedColumnRenderableSeries(wasmContext, {
    dataSeries: new XyDataSeries(wasmContext, {
      xValues: [1, 2, 3, 4, 5],
      yValues: [1, 2, 3, 4, 5],
    }),
  });
  stackedColumnCollection.add(series1, series2);
  sciChartSurface.renderableSeries.add(stackedColumnCollection);
  return { sciChartSurface };
};

// Initialize the mountain chart
const initMountainChart = async (rootElement) => {
  const { sciChartSurface, wasmContext } = await SciChartSurface.create(
    rootElement,
    {
      theme: new SciChartJsNavyTheme(),
    }
  );
  const xAxis = new NumericAxis(wasmContext);
  const yAxis = new NumericAxis(wasmContext);
  sciChartSurface.xAxes.add(xAxis);
  sciChartSurface.yAxes.add(yAxis);

  const mountainSeries = new FastMountainRenderableSeries(wasmContext, {
    dataSeries: new XyDataSeries(wasmContext, {
      xValues: [1, 2, 3, 4, 5],
      yValues: [5, 4, 3, 2, 1],
    }),
  });
  sciChartSurface.renderableSeries.add(mountainSeries);
  return { sciChartSurface };
};

// Initialize the pie chart
const initPieChart = async (rootElement) => {
  const sciChartSurface = await SciChartPieSurface.create(rootElement, {
    theme: new SciChartJsNavyTheme(),
  });
  const pieChartData = [
    { value: 40, text: "Segment 1" },
    { value: 30, text: "Segment 2" },
    { value: 20, text: "Segment 3" },
    { value: 10, text: "Segment 4" },
  ];

  pieChartData.forEach((segment) =>
    sciChartSurface.pieSegments.add(new PieSegment(segment))
  );
  return { sciChartSurface };
};

// Dashboard component
const Dashboard = () => {
  SciChartSurface.loadWasmFromCDN();
  return (
    <div style={{ display: "flex", flexDirection: "column", gap: "20px" }}>
      {/* First row */}
      <div style={{ display: "flex", gap: "20px" }}>
        <div style={{ flex: 1 }}>
          <SciChartReact
            initChart={initLineChart}
            style={{ width: "100%", height: "400px" }}
          />
        </div>
        <div style={{ flex: 1 }}>
          <SciChartReact
            initChart={initScatterChart}
            style={{ width: "100%", height: "400px" }}
          />
        </div>
      </div>

      {/* Second row */}
      <div style={{ display: "flex", gap: "20px" }}>
        <div style={{ flex: 1 }}>
          <SciChartReact
            initChart={initStackedColumnChart}
            style={{ width: "100%", height: "400px" }}
          />
        </div>
        <div style={{ flex: 1 }}>
          <SciChartReact
            initChart={initMountainChart}
            style={{ width: "100%", height: "400px" }}
          />
        </div>
        <div style={{ flex: 1 }}>
          <SciChartReact
            initChart={initPieChart}
            style={{ width: "100%", height: "400px" }}
          />
        </div>
      </div>
    </div>
  );
};

export default Dashboard;

Adding Styles to the React Dashboard

SciChart themes are pretty powerful. The SciChartJsNavyTheme contains a set of predefined series colors which look good with the background color of the chart. However, for some series you’ll get an unimaginative grey when not setting series colors.

Let’s leverage Deepseek again to modify the code with a new prompt passing in the working code and requesting the changes.

I’ve modified the code you created to correct some errors. Namely, FastScatterRenderableSeries should be XyScatterRenderableSeries. initChart functions should return { sciChartSurface }. Pie charts should be created using ‘SciChartPieSurface.create’.

Here is my working code which renders a dashboard without errors

`

// PASTE THE WORKING DASHBOARD.JSX CODE IN HERE

`

I would like you to modify this code using pleasing pastel colors which work with the background color which is #22365B.

Choose stroke colors from the list #274b92, #47bde6, #ae418d, #e97064, #68bcae

Choose fill colors from the list #274b9288, #47bde688, #ae418d88, #e9706488, #68bcae88

Apply these to the following properties: FastLineRenderableSeries.stroke, FastMountainRenderableSeries.fill, StackedColumnRenderableSeries.stroke and fill, EllipsePointMarker.stroke and fill, PieSegment pass color to the object in the constructor.

Set the background to the body equal a darker shade which matches #22365B.

Because we’ve given the AI working code, it should modify it straight away without errors. Here’s the output dashboard.jsx with styles and colors.

dashboard.jsx version #3 with styles

import React from "react";
import {
  SciChartSurface,
  NumericAxis,
  FastLineRenderableSeries,
  XyDataSeries,
  EllipsePointMarker,
  XyScatterRenderableSeries,
  StackedColumnCollection,
  StackedColumnRenderableSeries,
  FastMountainRenderableSeries,
  SciChartPieSurface,
  PieSegment,
  SciChartJsNavyTheme,
} from "scichart";
import { SciChartReact } from "scichart-react";

// Define pastel colors
const strokeColors = ["#274b92", "#47bde6", "#ae418d", "#e97064", "#68bcae"];
const fillColors = ["#274b9288", "#47bde688", "#ae418d88", "#e9706488", "#68bcae88"];

// Initialize the line chart
const initLineChart = async (rootElement) => {
  const { sciChartSurface, wasmContext } = await SciChartSurface.create(rootElement, 
  {
    theme: new SciChartJsNavyTheme(),
  });
  const xAxis = new NumericAxis(wasmContext);
  const yAxis = new NumericAxis(wasmContext);
  sciChartSurface.xAxes.add(xAxis);
  sciChartSurface.yAxes.add(yAxis);

  const lineSeries = new FastLineRenderableSeries(wasmContext, {
    dataSeries: new XyDataSeries(wasmContext, {
      xValues: [1, 2, 3, 4, 5],
      yValues: [2, 4, 6, 8, 10],
    }),
    stroke: strokeColors[0], // Apply stroke color
  });
  sciChartSurface.renderableSeries.add(lineSeries);
  return { sciChartSurface };
};

// Initialize the scatter chart
const initScatterChart = async (rootElement) => {
  const { sciChartSurface, wasmContext } = await SciChartSurface.create(rootElement, 
  {
    theme: new SciChartJsNavyTheme(),
  });
  const xAxis = new NumericAxis(wasmContext);
  const yAxis = new NumericAxis(wasmContext);
  sciChartSurface.xAxes.add(xAxis);
  sciChartSurface.yAxes.add(yAxis);

  const scatterSeries = new XyScatterRenderableSeries(wasmContext, {
    dataSeries: new XyDataSeries(wasmContext, {
      xValues: [1, 2, 3, 4, 5],
      yValues: [3, 5, 7, 9, 11],
    }),
    pointMarker: new EllipsePointMarker(wasmContext, {
      width: 10,
      height: 10,
      stroke: strokeColors[1], // Apply stroke color
      fill: fillColors[1], // Apply fill color
    }),
  });
  sciChartSurface.renderableSeries.add(scatterSeries);
  return { sciChartSurface };
};

// Initialize the stacked column chart
const initStackedColumnChart = async (rootElement) => {
  const { sciChartSurface, wasmContext } = await SciChartSurface.create(rootElement, 
  {
    theme: new SciChartJsNavyTheme(),
  });
  const xAxis = new NumericAxis(wasmContext);
  const yAxis = new NumericAxis(wasmContext);
  sciChartSurface.xAxes.add(xAxis);
  sciChartSurface.yAxes.add(yAxis);

  const stackedColumnCollection = new StackedColumnCollection(wasmContext);
  const series1 = new StackedColumnRenderableSeries(wasmContext, {
    dataSeries: new XyDataSeries(wasmContext, {
      xValues: [1, 2, 3, 4, 5],
      yValues: [2, 3, 4, 5, 6],
    }),
    stroke: strokeColors[2], // Apply stroke color
    fill: fillColors[2], // Apply fill color
  });
  const series2 = new StackedColumnRenderableSeries(wasmContext, {
    dataSeries: new XyDataSeries(wasmContext, {
      xValues: [1, 2, 3, 4, 5],
      yValues: [1, 2, 3, 4, 5],
    }),
    stroke: strokeColors[3], // Apply stroke color
    fill: fillColors[3], // Apply fill color
  });
  stackedColumnCollection.add(series1, series2);
  sciChartSurface.renderableSeries.add(stackedColumnCollection);
  return { sciChartSurface };
};

// Initialize the mountain chart
const initMountainChart = async (rootElement) => {
  const { sciChartSurface, wasmContext } = await SciChartSurface.create(rootElement, 
  {
    theme: new SciChartJsNavyTheme(),
  });
  const xAxis = new NumericAxis(wasmContext);
  const yAxis = new NumericAxis(wasmContext);
  sciChartSurface.xAxes.add(xAxis);
  sciChartSurface.yAxes.add(yAxis);

  const mountainSeries = new FastMountainRenderableSeries(wasmContext, {
    dataSeries: new XyDataSeries(wasmContext, {
      xValues: [1, 2, 3, 4, 5],
      yValues: [5, 4, 3, 2, 1],
    }),
    fill: fillColors[4], // Apply fill color
  });
  sciChartSurface.renderableSeries.add(mountainSeries);
  return { sciChartSurface };
};

// Initialize the pie chart
const initPieChart = async (rootElement) => {
  const sciChartSurface = await SciChartPieSurface.create(rootElement, {
    theme: new SciChartJsNavyTheme(),
  });
  const pieChartData = [
    { value: 40, text: "Segment 1", color: strokeColors[0] },
    { value: 30, text: "Segment 2", color: strokeColors[1] },
    { value: 20, text: "Segment 3", color: strokeColors[2] },
    { value: 10, text: "Segment 4", color: strokeColors[3] },
  ];

  pieChartData.forEach((segment) =>
    sciChartSurface.pieSegments.add(new PieSegment(segment))
  );
  return { sciChartSurface };
};

// Dashboard component
const Dashboard = () => {
  SciChartSurface.loadWasmFromCDN();
  return (
    <div style={{ display: "flex", flexDirection: "column", gap: "20px", 
               backgroundColor: "#1a2a4a", padding: "20px" }}>
      {/* First row */}
      <div style={{ display: "flex", gap: "20px" }}>
        <div style={{ flex: 1 }}>
          <SciChartReact
            initChart={initLineChart}
            style={{ width: "100%", height: "400px" }}
          />
        </div>
        <div style={{ flex: 1 }}>
          <SciChartReact
            initChart={initScatterChart}
            style={{ width: "100%", height: "400px" }}
          />
        </div>
      </div>

      {/* Second row */}
      <div style={{ display: "flex", gap: "20px" }}>
        <div style={{ flex: 1 }}>
          <SciChartReact
            initChart={initStackedColumnChart}
            style={{ width: "100%", height: "400px" }}
          />
        </div>
        <div style={{ flex: 1 }}>
          <SciChartReact
            initChart={initMountainChart}
            style={{ width: "100%", height: "400px" }}
          />
        </div>
        <div style={{ flex: 1 }}>
          <SciChartReact
            initChart={initPieChart}
            style={{ width: "100%", height: "400px" }}
          />
        </div>
      </div>
    </div>
  );
};

export default Dashboard;

This is looking a lot better!

Adding a Legend and Tooltips

The AI chat history should now have a working piece of code in it. If it doesn’t, fix the code and include it in your prompt.

Now we’re going to add a legend and tooltips to the chart. It’s actually pretty easy to do this but I want to show the power of using generating AI tools like Chat GPT or Deepseek to modify the code.

Start a new prompt:

Here is my current working code which renders a dashboard without errors:

`

// PASTE YOUR CURRENT WORKING CODE HERE

`

Modify this code as follows.

For each SciChartSurface which is not a SciChartPieSurface, add a Legend using the LegendModifier

For each XyDataSeries, set the dataSeriesName property to a dummy string.

For each SciChartSurface which is not a SciChartPieSurface, add a Tooltip using the RolloverModifier. set showRolloverLine: true and showTooltip: true

For each SciChartSurface which is not a SciChartPieSurface, add mouse wheel, zoompan and zoom extents modifiers Deepseek AI gets straight to work and outputs some new code: Let’s update dashboard.jsx with the new code:

Final dashboard.jsx version #4 with tooltips, legends, zooming

import React from "react";
import {
  SciChartSurface,
  NumericAxis,
  FastLineRenderableSeries,
  XyDataSeries,
  EllipsePointMarker,
  XyScatterRenderableSeries,
  StackedColumnCollection,
  StackedColumnRenderableSeries,
  FastMountainRenderableSeries,
  SciChartPieSurface,
  PieSegment,
  SciChartJsNavyTheme,
  LegendModifier,
  RolloverModifier,
  MouseWheelZoomModifier,
  ZoomPanModifier,
  ZoomExtentsModifier,
} from "scichart";
import { SciChartReact } from "scichart-react";

// Define pastel colors
const strokeColors = ["#274b92", "#47bde6", "#ae418d", "#e97064", "#68bcae"];
const fillColors = [
  "#274b9288",
  "#47bde688",
  "#ae418d88",
  "#e9706488",
  "#68bcae88",
];

// Initialize the line chart
const initLineChart = async (rootElement) => {
  const { sciChartSurface, wasmContext } = await SciChartSurface.create(
    rootElement,
    {
      theme: new SciChartJsNavyTheme(),
    }
  );
  const xAxis = new NumericAxis(wasmContext);
  const yAxis = new NumericAxis(wasmContext);
  sciChartSurface.xAxes.add(xAxis);
  sciChartSurface.yAxes.add(yAxis);

  const lineSeries = new FastLineRenderableSeries(wasmContext, {
    dataSeries: new XyDataSeries(wasmContext, {
      xValues: [1, 2, 3, 4, 5],
      yValues: [2, 4, 6, 8, 10],
      dataSeriesName: "Line Series", // Set dataSeriesName
    }),
    stroke: strokeColors[0], // Apply stroke color
  });
  sciChartSurface.renderableSeries.add(lineSeries);

  // Add modifiers
  sciChartSurface.chartModifiers.add(new LegendModifier());
  sciChartSurface.chartModifiers.add(
    new RolloverModifier({ showRolloverLine: true, showTooltip: true })
  );
  sciChartSurface.chartModifiers.add(new MouseWheelZoomModifier());
  sciChartSurface.chartModifiers.add(new ZoomPanModifier());
  sciChartSurface.chartModifiers.add(new ZoomExtentsModifier());

  return { sciChartSurface };
};

// Initialize the scatter chart
const initScatterChart = async (rootElement) => {
  const { sciChartSurface, wasmContext } = await SciChartSurface.create(
    rootElement,
    {
      theme: new SciChartJsNavyTheme(),
    }
  );
  const xAxis = new NumericAxis(wasmContext);
  const yAxis = new NumericAxis(wasmContext);
  sciChartSurface.xAxes.add(xAxis);
  sciChartSurface.yAxes.add(yAxis);

  const scatterSeries = new XyScatterRenderableSeries(wasmContext, {
    dataSeries: new XyDataSeries(wasmContext, {
      xValues: [1, 2, 3, 4, 5],
      yValues: [3, 5, 7, 9, 11],
      dataSeriesName: "Scatter Series", // Set dataSeriesName
    }),
    pointMarker: new EllipsePointMarker(wasmContext, {
      width: 10,
      height: 10,
      stroke: strokeColors[1], // Apply stroke color
      fill: fillColors[1], // Apply fill color
    }),
  });
  sciChartSurface.renderableSeries.add(scatterSeries);

  // Add modifiers
  sciChartSurface.chartModifiers.add(new LegendModifier());
  sciChartSurface.chartModifiers.add(
    new RolloverModifier({ showRolloverLine: true, showTooltip: true })
  );
  sciChartSurface.chartModifiers.add(new MouseWheelZoomModifier());
  sciChartSurface.chartModifiers.add(new ZoomPanModifier());
  sciChartSurface.chartModifiers.add(new ZoomExtentsModifier());

  return { sciChartSurface };
};

// Initialize the stacked column chart
const initStackedColumnChart = async (rootElement) => {
  const { sciChartSurface, wasmContext } = await SciChartSurface.create(
    rootElement,
    {
      theme: new SciChartJsNavyTheme(),
    }
  );
  const xAxis = new NumericAxis(wasmContext);
  const yAxis = new NumericAxis(wasmContext);
  sciChartSurface.xAxes.add(xAxis);
  sciChartSurface.yAxes.add(yAxis);

  const stackedColumnCollection = new StackedColumnCollection(wasmContext);
  const series1 = new StackedColumnRenderableSeries(wasmContext, {
    dataSeries: new XyDataSeries(wasmContext, {
      xValues: [1, 2, 3, 4, 5],
      yValues: [2, 3, 4, 5, 6],
      dataSeriesName: "Stacked Column Series 1", // Set dataSeriesName
    }),
    stroke: strokeColors[2], // Apply stroke color
    fill: fillColors[2], // Apply fill color
  });
  const series2 = new StackedColumnRenderableSeries(wasmContext, {
    dataSeries: new XyDataSeries(wasmContext, {
      xValues: [1, 2, 3, 4, 5],
      yValues: [1, 2, 3, 4, 5],
      dataSeriesName: "Stacked Column Series 2", // Set dataSeriesName
    }),
    stroke: strokeColors[3], // Apply stroke color
    fill: fillColors[3], // Apply fill color
  });
  stackedColumnCollection.add(series1, series2);
  sciChartSurface.renderableSeries.add(stackedColumnCollection);

  // Add modifiers
  sciChartSurface.chartModifiers.add(new LegendModifier());
  sciChartSurface.chartModifiers.add(
    new RolloverModifier({ showRolloverLine: true, showTooltip: true })
  );
  sciChartSurface.chartModifiers.add(new MouseWheelZoomModifier());
  sciChartSurface.chartModifiers.add(new ZoomPanModifier());
  sciChartSurface.chartModifiers.add(new ZoomExtentsModifier());

  return { sciChartSurface };
};

// Initialize the mountain chart
const initMountainChart = async (rootElement) => {
  const { sciChartSurface, wasmContext } = await SciChartSurface.create(
    rootElement,
    {
      theme: new SciChartJsNavyTheme(),
    }
  );
  const xAxis = new NumericAxis(wasmContext);
  const yAxis = new NumericAxis(wasmContext);
  sciChartSurface.xAxes.add(xAxis);
  sciChartSurface.yAxes.add(yAxis);

  const mountainSeries = new FastMountainRenderableSeries(wasmContext, {
    dataSeries: new XyDataSeries(wasmContext, {
      xValues: [1, 2, 3, 4, 5],
      yValues: [5, 4, 3, 2, 1],
      dataSeriesName: "Mountain Series", // Set dataSeriesName
    }),
    fill: fillColors[4], // Apply fill color
  });
  sciChartSurface.renderableSeries.add(mountainSeries);

  // Add modifiers
  sciChartSurface.chartModifiers.add(new LegendModifier());
  sciChartSurface.chartModifiers.add(
    new RolloverModifier({ showRolloverLine: true, showTooltip: true })
  );
  sciChartSurface.chartModifiers.add(new MouseWheelZoomModifier());
  sciChartSurface.chartModifiers.add(new ZoomPanModifier());
  sciChartSurface.chartModifiers.add(new ZoomExtentsModifier());

  return { sciChartSurface };
};

// Initialize the pie chart
const initPieChart = async (rootElement) => {
  const sciChartSurface = await SciChartPieSurface.create(rootElement, {
    theme: new SciChartJsNavyTheme(),
  });
  const pieChartData = [
    { value: 40, text: "Segment 1", color: strokeColors[0] },
    { value: 30, text: "Segment 2", color: strokeColors[1] },
    { value: 20, text: "Segment 3", color: strokeColors[2] },
    { value: 10, text: "Segment 4", color: strokeColors[3] },
  ];

  pieChartData.forEach((segment) =>
    sciChartSurface.pieSegments.add(new PieSegment(segment))
  );

  return { sciChartSurface };
};

// Dashboard component
const Dashboard = () => {
  SciChartSurface.loadWasmFromCDN();
  return (
    <div
      style={{
        display: "flex",
        flexDirection: "column",
        gap: "20px",
        backgroundColor: "#1a2a4a",
        padding: "20px",
      }}
    >
      {/* First row */}
      <div style={{ display: "flex", gap: "20px" }}>
        <div style={{ flex: 1 }}>
          <SciChartReact
            initChart={initLineChart}
            style={{ width: "100%", height: "400px" }}
          />
        </div>
        <div style={{ flex: 1 }}>
          <SciChartReact
            initChart={initScatterChart}
            style={{ width: "100%", height: "400px" }}
          />
        </div>
      </div>

      {/* Second row */}
      <div style={{ display: "flex", gap: "20px" }}>
        <div style={{ flex: 1 }}>
          <SciChartReact
            initChart={initStackedColumnChart}
            style={{ width: "100%", height: "400px" }}
          />
        </div>
        <div style={{ flex: 1 }}>
          <SciChartReact
            initChart={initMountainChart}
            style={{ width: "100%", height: "400px" }}
          />
        </div>
        <div style={{ flex: 1 }}>
          <SciChartReact
            initChart={initPieChart}
            style={{ width: "100%", height: "400px" }}
          />
        </div>
      </div>
    </div>
  );
};

export default Dashboard;

Here’s the (almost final) dashboard result with legend, tooltip and zooming interactions.

Final Tweaking to the Dashboard Example

There’s a little bit of tweaking we need to do here, but the code functionally works. Namely if you hover the chart you’ll see some tooltips are very bright with white text and can’t be read.

This is because the RolloverModifier by default uses the RenderableSeries.stroke as a tooltip container colour, and the foreground of the container is always white.

You can change this using the RenderableSeries.rolloverModifierProps property which allows setting of tooltip styles on a per-series basis.

Adjust the code one last time:

// Initialize the scatter chart
const initScatterChart = async (rootElement) => {
  // ... 
  // after the declaration of scatterSeries, set rollover props

  scatterSeries.rolloverModifierProps.tooltipTextColor = "#333";
  // ...
}


// Initialize the mountain chart
const initMountainChart = async (rootElement) => {
  // ... 
  // after the declaration of mountainSeries, set rollover props

  mountainSeries.rolloverModifierProps.tooltipTextColor = "#333";
  // ...
}

That should be it! Here’s the final working dashboard with React Line Chart, React Scatter Chart, React Stacked Column Chart and React Pie Chart below:

Conclusion

How the final React Dashboard Works

The code in this tutorial creates a dashboard with multiple SciChart visualizations using React. Let’s break it down step by step:

Imports & Setup:

Imports necessary SciChart components (chart types, axes, series, modifiers)
Defines color palettes for consistent styling
Uses SciChartReact wrapper component for React integration, for correct react component lifecycle

Chart Initialization Functions:

Each chart type has its own initialization function that:
Creates a SciChartSurface with a dark theme
Adds X/Y axes
Configures data series and visual styling
Adds interactive features (zoom, pan, legend, tooltips)
Returns the chart surface for React to manage

Chart Types Demonstrated:

Line Chart: Simple line graph with FastLineRenderableSeries
Scatter Plot: Uses XyScatterRenderableSeries with circular markers
Stacked Columns: Multiple column series combined in StackedColumnCollection
Mountain Chart: Area chart using FastMountainRenderableSeries
Pie Chart: Created with SciChartPieSurface and PieSegment

Interactive Features (via Chart Modifiers):

LegendModifier: Shows data series legend
RolloverModifier: Tooltips on hover
MouseWheelZoomModifier: Zoom with scroll wheel
ZoomPanModifier: Drag to pan
ZoomExtentsModifier: Double-click to reset zoom

Dashboard Layout:

Uses flexbox for responsive grid layout
First row has 2 charts (line + scatter)
Second row has 3 charts (stacked columns + mountain + pie)
Each chart is wrapped in SciChartReact component with initialization function

Key React-SciChart Integration:

SciChartReact handles component lifecycle (mount/unmount)
initChart prop passes the initialization function
WASM library loaded once from CDN using loadWasmFromCDN()

Styling:

Consistent navy theme across all charts
Pastel color palette defined at top
Responsive sizing using percentage-based dimensions
Dark background container for the dashboard

This code achieves a responsive dashboard with 5 different chart types, interactive visualization features (zoom, tooltips, panning), consistent theming and styling, efficient React integration with SciChart’s WebAssembly rendering and demonstrates multiple chart types working together.

As an user, you can now modify the data series values/format, adjust styling through color arrays and chart properties, rearrange the dashboard layout, add/remove chart modifiers or create new chart types using different renderable series.

Remember that SciChart requires WebAssembly (WASM), which is why we use async initialization and the loadWasmFromCDN() call.

Further Work

What else could you do with this?

Here are some ideas to explore both with generative-AI and by going through the SciChart documentation.

Experiment with adding hover behaviours and triggering on-selected drilldowns using the SeriesSelectionModifier
Adding grid splitters between the charts and enabling dynamic responsive dashboards for mobile as well as web views.
Experimenting with dynamic data and real-time updates as SciChart excels in this area.

Final Comments about Deepseek and Generative AI

Generative AI has come a long way since the original version of Chat GPT two years ago. It is now quite a competent coder and able to understand complex concepts, capable of developing dashboards rapidly using libraries like SciChart.js and scichart-react.

While the code it produces isn’t perfect, and does contain errors, a competent developer combined with the solid documentation & examples that SciChart has to offer can create code quickly and make rapid progress in applications.

Powering Research. Development. Innovation worldwide

Andrew Bt — Tue, 24 Jun 2025 15:06:38 +0000

At SciChart we are proud to support Innovation & Research worldwide. As part of an educational license program, we grant licenses in many cases for free, or at low cost to Universities for non-profit R&D worldwide. We have astounding list of over 145 Universities which use SciChart in their projects, including MIT, Stanford, Imperial College London and more. These projects have powered cutting-edge research and advanced the frontiers of science, using our high-performance, real-time charting libraries to visualise data.

List of Projects Showcased in this Article

We’ve taken a handful of the best student & University research projects to showcase in this article. For a look at what SciChart can do, and some of the incredible research, read on!

Project 1: The University of Illinois reduced cancer screening time from weeks to hours in research of methods being used for classification of tissue thin sections identifying tumorous regions.
Project 2: The NTNU Norwegian University students built an electric race car from scratch and participate in Formula Student every year. They have created their own dashboard to monitor and adjust car performance with the data from more than 300 sensors.
Project 3: A FH Joanneum University student developed a wearable device and App, enabling researchers to conduct vital signs analysis from raw sensor data for personal health. The main goal is to increase diagnostic accuracy.
Project 4: A student at Vellore Institute of Technology and created a low-cost non-invasive healthcare solution for the clinical needs of India and the rest of the world, a cheap portable ECG device that could achieve medical grade clarity with realtime data plotting.
Project 15 MIT students have created a robotic smart shoe with the skin surface like sensors. Its telemetry data prevents robot from falling. The ultimate goal is to assist elderly with fall prevention and athletes with training data.

Project 1: High-Definition Realtime Visualization of IR QCL Spectroscopy for Diagnostic Tissue Imaging

The University of Illinois departments of Bioengineering, Mechanical Science & Electrical Computer Engineering were researching alternatives to Fourier-transform infrared spectroscopy for use in Medical Diagnostics and methods being used for classification of tissue thin sections identifying tumorous regions.

Despite exponential growth of the field and its world-wide research, the clinical sphere has been limited by data management. With over a 100 million data points generated in realtime, current imaging technologies were limited to less than 1% of the data set.

This study turned into the cutting-edge research project where SciChart’s WPF charting library is used to display Realtime High Definition Heatmaps from Quantum Cascade Laser (QCL) Infrared (IR) Spectroscopy.

SciChart helped with handling over 1 million points of data in real time with the capacity to increase to 10 million. This allowed the advent of HD Realtime IR imaging and reduced the screening time from weeks to hours. In this field time is indeed the invaluable resource.

Project 2: Data visualization of more than 300 race car sensors

Revolve team from NTNU used SciChart’s High Performance WPF Charting Library to handle their complex data from over 300 sensors in their electric Race Car.

Revolve NTNU Norwegian University of Science & Technology is an independent student organization engaged in Formula Student, Europe’s most established educational motorsport competition. Creating new iterations of their Race Car each year, Revolve needed to be able to visualization their multi-stream, high-bandwidth data from their hundreds of sensors in Realtime to ensure top performance and allow for torque vectoring and testing of their car.

Realtime race visualisation for Formula race cars using SciChart. Showing Battery Management System Heatmap, Scatter Maps, Damper Rate, Realtime Laps Map, Break Sensor Data and more.

The charting library allowed the team to do performance analysis and testing, they are ranked number 10 in the world now and surely are some of the most talented engineering students in the world.

Project 3: Medical-grade wearable device that offers real-time physiological data acquisition

A student from FH Joanneum University of Applied Science has developed an Android Application to record acquired sensor data via Bluetooth and to allow synchronization with the Empatica(E4) and Google Fit cloud storage solutions.

The E4 is a medical-grade wearable device that offers real-time physiological data acquisition.

Since there is no universal standard for data exchange the goal is to enable the researchers to conduct in-depth analysis from the raw sensors data visualised and exported. The SciChart Android Charting library was used to visualise the raw data received from sensors via Bluetooth.

The E4 wearable device and the Android application data visualization
It measures blood volume pulse (BVP), from which heart rate variability can be derived. The 3-axis accelerometer captures motion-based activity. An EDA sensor (GSR Sensor) measures the constantly fluctuating changes in certain electrical properties of the skin. An infrared thermopile reads peripheral skin temperature.

As the result of the study the heart rate variability (HRV) was calculated using the interbeat interval between all successive heartbeats.

Needless to say, that the implications of the personal health devices can increase diagnostic accuracy, enhance physician efficiency and allow more convenient data collection.

Project 4: Visualization of ECG signals in Realtime on a low cost portable device

A student at Vellore Institute of Technology, Vellore as a part of Cardea Labs & Cardea Biomedical Technologies Pvt. Ltd team had a challenge to create a low-cost non-invasive healthcare solution for the clinical needs of India and the rest of the world. It had to be an affordable portable ECG device that could achieve medical grade clarity, therefore the challenge was in the reliable realtime data visualization with smooth interactions.

SciChart’s WPF extensive charting library was used to create the FIFO functionality required, which generated a Realtime scrolling ECG monitor. The chart is dynamically updating at 250 points per second with data acquisition through Bluetooth connection for an ECG device derived from the miBEAT hardware platform.

This was combined with export function that allowed users to export in numerous formats, so the data could be collated outside of the application. The session window allows to Pan, Zoom & Scroll making the UI intuitive and user friendly, all this being used on smaller portable devices.

From the Author
My students’ years were enriched by being a part of Students’ Organizations. I was a member and a leader of a local group of the Board of European Students of Technology – a non-profit organization with the mission to empower diversity. I also joined the Enactus team at Graceland University during my exchange year abroad program. Enactus is an organization has the vision to create better more sustainable world. These experiences shaped me and my career as it is now. This is where I gained my skills to land the first job and my drive to progress at what I do.

I am happy to work at a place that supports students as much. SciChart has an academic free license for the students’ university projects and research. SciChart is an innovative company at its heart and investing into students, who have the spirit and unstoppable willingness to make a difference gives us an interesting mix.

Project 5: MIT / Realtime Android charting for Robotics Telemetry

MIT Biomimetic Robotics Lab used SciChart for Android to display and interpret Realtime telemetry data from Smart shoe sensors designed to capture measurements of force-data during movement.

Organic organisms contain an abundance of surface skin sensors that can determine pressure, vibrations and forces which in turn feedback and allow calibration of movement. The Biomimetic Robotics lab at MIT aimed to develop a similar multi-axis force sensor for use in the next generation of legged robots by mapping the local sampling of stress inside their custom polymeric footpad.

SciChart’s Android charts were used in the application for reading and visualising multiple streams of data at 1kHz amounting to hundreds of thousands of data points, collected from smart shoe telemetry.

The team’s goal is to use these force sensing shoes not only in robotics, such as the famous Cheetah Robot, but also to help assist the elderly and disabled during walking for fall prevention and mitigation as well as to provide athletes with training data.

Enjoyed our Case Studies?

Find more case studies here: Desktop Case Studies, Mobile Case Studies, Consultancy Project Case Studies.

p.s. Interesting, that the sphere where students’ projects have been performed align perfectly with the domains of commercials SciChart customers, including 60% of top global semiconductor companies, 80% of global MedTech, 80% of top US Banks, All top F1 Teams, Top Global Petrochemical companies and thousands more.

p.p.s.Vrije Universiteit Amsterdam, ranked in the top 100 of global universities is now teaching SciChart to its computer science students in the construction of real time applications. SciChart is being taught at several leading educational establishments meaning that our software is being used to train the next generation of the workforce in cutting edge technology.

SciChart – The Fastest WPF Charts. Period. 2021 Test Results Update

Andrew Bt — Tue, 24 Jun 2025 14:55:00 +0000

Introduction

Performance has always been one of the main aims of SciChart’s WPF chart libraries. Our customers include engineering, financial and medical companies who demand the very best performance, flexibility, reliability, integrity of our staff as well as excellent customer service.

We’re proud to announce that SciChart WPF is used by not one, but directly by five Formula One teams! As well as indirect usage in all F1 teams via vendor software in some shape or form.

Defence companies and even governments that demand reliability of our software and integrity of our engineers are repeat customers of SciChart. Medical companies who create cutting edge medical-devices, participate in bleeding edge cancer research use SciChart. They all require high performance.

SciChart is used in demanding applications. 5 Formula One teams use SciChart!

Having the Fastest WPF Charts is a great selling point but it’s not the only reason to use our Software.

SciChart WPF is also incredible easy to use, flexible and has a depth of features like no other.
SciChart has an intuitive, XAML & MVVM-friendly API out of the box.
Hundreds of customers rate SciChart 5-stars so we’re doing something right.

You can find more reasons at Why SciChart: The Best WPF Charts.

Nevertheless, WPF Chart Performance matters to our customers, so we test exhaustively to ensure that SciChart WPF has the best possible performance your demanding applications.

So how do we do that?

SciChart WPF – Fastest WPF Charts by a mile

We’ve previously talked about SciChart WPF being the Best WPF Chart, and the Fastest WPF Chart control. If you haven’t read it, have a look at SciChart WPF v6 ‘Xccelerated Edition’ Up to 100x (10,000%) Faster WPF Charts where we discuss why we focussed on improving performance in 2019/2020, the steps we’ve taken to ensure that every aspect of our pipeline is optimised and some test results vs. competitors.

Using claims such as ‘Best’ or ‘Fastest’ on our website and marketing is bold but they are backed up by solid data! We’ve carried out extensive performance testing in-house. I’m going to share some of the latest test results below.

Updated WPF Chart Performance Comparison (November 2021)

It’s worth a note that Open Source WPF charts and almost all Commercial WPF Charts don’t come close to SciChart’s performance. As a result they cannot even register on our demanding test suite. So instead, we’ve compared the latest test results vs. our strongest competitor in terms of performance.

We’ve constructed a WPF Chart Performance Test Suite with over 70 test high-stress test cases covering a wide variety of conditions to assess performance between SciChart & ‘Competitor A’.

Test cases are varied and include:

Thousands of line series. Up to 4,000 series on screen with 4,000 datapoints per series.
Realtime line series (scrolling, old data discarded). Up to 10 Billion datapoints on screen with 1 Million new data-points per second.
Realtime line series with old data kept on screen. Chart auto-fit enabled. Up to 25 Million new data-points appended per second.
Scatter charts & Scatter (XY) line series. Up to 30 Million data-points.
Other WPF chart types including Candlestick, Columns, Bars, Area, Mountain. Up to 30 Million data-points.

Here are the test results below:

SciChart vs. ‘Competitor A’ 2021 Test Results

WPF Chart Performance Comparison between SciChart WPF & Competitor A, November 2021.

Note: Why have we hidden the test case names? Because in-depth expert analysis of chart performance is valuable and we don’t want to tip our competitors off!

WPF Chart Rendering Speed: FPS or ‘Frames per Second’

On the Green/Yellow/Red column you can see FPS. This stands for ‘Frames per Second’ and is a measure of how many times the chart draws per second. This number is averaged out over the window for each test.

The maximum FPS for SciChart is capped at 60 FPS
The average FPS for SciChart over 70 test cases is 47 FPS
The median FPS for SciChart over the test cases is 58.2 FPS

Meanwhile …

Competitor A also achieved a max of 60 FPS (capped at 60)
An average of 22 FPS
and a median of just 9 FPS

Over 70 demanding WPF Chart Performance test cases, SciChart outperformed the strongest competitor on the market by an average (mean) of 455% faster rendering. A max of 3,893% faster rendering and a median of 156% faster rendering was observed in like-for-like WPF Chart Performance tests.

Note: Several tests performed by Competitor A have FPS=0. This means that a prior test scored low, hanged or crashed and the test was halted for this test group. In this case the SciChart performance increase was effectively infinite, so how can we calculate speed improvement?

What we can do is multiply FPS x Number of data-points in the group to determine a speed score or ‘Datapoints per second’. Then, calculate a maximum speed increase based on which chart was able to render or draw the highest number of data-points.

SciChart (Left Column) vs. Competitor A (Right Column). Tests in a Group with an FPS below 2 or where the competitor chart failed were halted

Each Test group was a specific WPF Chart test case. In Test Group 5, Competitor A struggled to draw 1,000,000 (1 Million) data-points at 2 FPS for this test case while SciChart was able to draw 10,000,000 (10 Million) datapoints at 58.7 FPS.

Thus the Data-point per second calculation is:

SciChart: 58.7 x 10M = Can render 587,000,000 data-points per second
Competitor A: 2 x 1M = Can render 2Million data-points per second
Result: SciChart is up to 293.5 x faster for this test case!

Test Group 6 was another WPF Chart Type. Competitor A struggled to draw only 10,000 data-points at 1.5 FPS while SciChart was able to draw 10,000,000 (10 Million) datapoints at 58.5 FPS.

SciChart: 58.7 x 10M = Can render 585,000,000 data-points per second
Competitor A: 1.5 x 10k = Can render 15,000 data-points per second
Result: SciChart is up to 39,000 x faster for this test case!
So there you have it.

In Demanding WPF Chart Performance tests, SciChart 🥇 was able to outperform ‘Competitor A’ (the 2nd fastest WPF Chart 🥈) by rendering 39,000x more data-points per second in one test case and 293.5x more data-points per second in another test case, by using the Datapoints Per Second methodology above.

WPF Chart CPU Usage

CPU usage is also important to our users. What if the chart is the fastest but uses all the CPU resources, making the rest of your application slow?

SciChart is strictly single threaded for rendering, and while we allow you to append data from a background thread (SciChart WPF is thread safe: we handle the locking & synchronisation), there’s very little parallel processing inside SciChart itself. Instead we favour fastest single-threaded path for code, using low-level optimisations as part of our Visual Xccelerator® Engine typically only found in the gaming industry.

SciChart CPU usage is on average 5% lower than competitor A for the 70 WPF Performance test cases we carried out.
SciChart CPU usage is a median of 7% lower over the test cases carried out.

WPF Chart Memory Usage

Memory in a C# .NET application is also very important. What we found in our testing was that SciChart used considerably less memory than Competitor A to achieve it’s record high performance, meaning there is more memory available for the rest of your application.

At SciChart we’ve optimised not only rendering performance (being fully GPU accelerated), CPU usage (using low-level gaming industry optimization techniques) but also memory making us suitable for the most demanding applications.

SciChart: Experts in High Performance Charts & Data Visualization

At SciChart we are experts in our field. I personally hold a Masters Degree (MEng) and PhD in Electronics, covering the topics of electronic hardware design, embedded systems and signal processing. You can see this post on Linked In here with some of the work I’ve done in this field.

I’ve designed pieces of low-cost electronic measurement hardware which outperformed much more expensive scientific instruments in terms of accuracy. I’ve written algorithms for Fast Fourier Transform on GPUs before the days of nVidia Cuda or OpenCL, have coded several algorithms and hand-tuned the performance of critical sections of C++ & C# code. My team and I understand at a very low level what’s happening on-chip when you process data or perform certain operations in software.

At SciChart we are a team of low-level software optimisation experts. Our experience spans not just C# .NET and WPF, but also Graphics, GPU acceleration, languages such as C++, Swift, Kotlin, Typescript, multiple 3d libraries such as DirectX, OpenGL/OpenGLES, WebGL, Metal and low level performance optimization techniques used in the gaming industry.

We’ve transferred that knowledge into SciChart to bring you an incredibly complex piece of software which looks simple on the surface: SciChart WPF – The Best (and Fastest) WPF Chart. All in a package which is easy to use and ‘just works’ out of the box.

Do you need more Performance in WPF Applications with Charts?

If you do find a use-case where SciChart performs less than optimal, then do contact us. We often have customers reach out with performance issues but it turns out a small tweak in the usage of the library can result in huge performance improvements.

We’ve also carried out bespoke consultancy work for customers in the F1 sector and Financial services to performance tune their apps. Integrating SciChart to a large or complex app requires sometimes the knowledge from our engineers to get the best possible performance out of the library.