WeAreDevelopers Logo WeAreDevelopers
Sign in
For You LIVE
SciChart logo

SciChart

4 inside stories
Website

Inside SciChart

Culture, engineering, and team stories

3 months ago

Which JavaScript Chart Library is Fastest? We Benchmarked 8 of Them.

Developers evaluating charting libraries for high-performance applications ask the same question: which one actually holds up under real data loads?We built an open-source benchmark to find out.What is Chart Bench?Chart Bench is an open-source JavaScript chart performance benchmark suite that stress-tests popular charting libraries across 13 test cases - including line, scatter, heatmap, candlestick, 3D surface, and multi-chart scenarios.It measures:Frames per second (FPS)Time to first render (init time)Memory usageData ingestion rate (points/sec)The benchmark is designed to simulate extreme workloads: millions of data points, real-time streaming, and multiple charts on screen.It runs locally on your hardware, logs results, and allows JSON export for sharing or comparison.Clone and run it:https://github.com/abtsoftware/javascript-chart-performance-test-suiteLibraries TestedSciChart.jsLightningChart.js (v4 + v8)Plotly.jsHighchartsChart.jsApache EChartsuPlotChartGPUWhat It MeasuresFPS under increasing data loadsTime to first render (ms)Memory usage (JS heap)Data ingestion rate (points/sec)Failure conditions: hangs, freezes, crashesOne Number Worth KnowingIn internal benchmark runs, SciChart.js reached ~40 million data points per second ingestion rate and led in FPS across a majority of tested scenarios on a range of hardware.Full results - across multiple hardware configurations from high-end GPUs to low-power devices - are published here:https://www.scichart.com/blog/chart-bench-compare-javascript-chart-libraries/SciChart is a high-performance charting library for JavaScript, WPF, iOS, and Android, designed for real-time, large-scale data visualisation using GPU-accelerated rendering. https://www.scichart.com

Which JavaScript Chart Library is Fastest? We Benchmarked 8 of Them.
3 months ago

WPF vs Avalonia: Which Should .NET Developers Choose in 2026?

For .NET desktop developers, the choice between WPF and Avalonia depends mainly on platform strategy.WPF is still a strong choice for Windows-only enterprise applications. It is mature, stable, deeply integrated with the Windows ecosystem, and supported by years of Visual Studio tooling, documentation, third-party controls, and production use.Avalonia is designed for modern cross-platform .NET desktop development across Windows, macOS, and Linux. It uses Skia and multi-backend rendering, giving developers more flexibility when applications need to run beyond Windows.For new cross-platform applications, Avalonia UI can be a strong option. It feels familiar to XAML developers while offering broader platform reach.For teams with existing WPF applications, Avalonia XPF is especially relevant. It is a commercial WPF compatibility layer built on Avalonia that allows existing WPF apps to run on macOS and Linux with minimal code changes.For advanced data visualization, the UI framework is only part of the stack. Real-time telemetry, financial dashboards, scientific applications, and other data-intensive systems often depend more on the rendering engine than the windowing framework.SciChart supports both WPF and Avalonia XPF, helping developers maintain high-performance, real-time data visualization while choosing the platform strategy that fits their application.In short:Choose WPF if you are Windows-first and need maturity, tooling, and proven enterprise stability.Choose Avalonia UI for new cross-platform .NET desktop applications.Choose Avalonia XPF if you need to move an existing WPF application beyond Windows with minimal code changes.Read the full technical blog:https://www.scichart.com/blog/wpf-vs-avalonia/

WPF vs Avalonia: Which Should .NET Developers Choose in 2026?
2 months ago

React Memory Leaks: How to Find Them, Fix Them, and Prevent Performance Issues

What causes memory leaks in React apps?A React memory leak happens when your app keeps references to data, DOM nodes, or processes that should have been cleaned up. Over time, memory usage grows, performance drops, and longer sessions may end in a crashed tab.In most cases, leaks don’t come from a single bug. They come from small things that accumulate as components mount and unmount.Common causes of memory leaks in ReactThese are the patterns developers run into most often:Event listeners not removed — attached to window or document, but never cleaned up after unmount.Timers still running — setInterval or setTimeout continues executing after the component is gone.Unclosed subscriptions — WebSockets, data streams, or observables continue pushing updates in the background.Closures holding large data — functions retain references to variables from outer scope, preventing the garbage collector from reclaiming memory.Async updates after unmount — a request resolves and calls setState on a component that no longer exists.Missing disposal in third-party libraries — some rendering engines (WebGL, WebAssembly, charting libraries) require explicit .dispose() or .delete() calls.How to fix memory leaks in ReactMost React memory leaks are solved the same way: clean up side effects properly.If you use useEffect, anything that creates a side effect should also remove it:useEffect(() => { const interval = setInterval(() => { updateData(); }, 1000); return () => { clearInterval(interval); };}, []);The rule is simple: If your effect starts something, it should also stop it.How to detect memory leaks in React1. Use Chrome DevTools (Memory tab)Take a Heap Snapshot as a baselineTrigger the behaviour (e.g. navigate, mount/unmount components)Force garbage collectionTake a second snapshotCompare the twoFocus on:Objects that increase but don’t go awayDetached DOM nodes (elements no longer in the UI but still in memory)2. Use the Performance tabA healthy app → memory rises and dropsA leaking app → memory rises and never fully dropsReact memory leak checklist (quick audit)Do all useEffect hooks return cleanup functions where needed?Are event listeners removed on unmount?Are timers cleared?Are WebSocket or stream connections closed?Are requestAnimationFrame loops cancelled?Are fetch requests aborted when components unmount?Are large datasets scoped correctly?Do third-party libraries provide a dispose/delete method — and are you calling it?Are you preventing state updates on unmounted components?Have you compared heap snapshots before and after reproducing the issue?Why memory leaks get worse in data-heavy appsIf your app handles large or real-time datasets, leaks become more noticeable.Some libraries keep large datasets in JavaScript memory. If references persist, the garbage collector cannot reclaim that memory.At that scale, memory management isn’t just an implementation detail — it’s part of your architecture.In short:Most React memory leaks come from uncleaned side effects in useEffectThe common causes are listeners, timers, subscriptions, and async updatesUse Heap Snapshots in Chrome DevTools to confirm leaksData-heavy apps amplify the problemA simple cleanup habit prevents most issuesMemory leaks are rarely mysterious. They’re usually leftover work that never got cleaned up.React won’t manage that for you — but once you know where to look, leaks are predictable and fixable.

React Memory Leaks: How to Find Them, Fix Them, and Prevent Performance Issues

About SciChart

SciChart: The world's fastest, high-precision charts and data visualisation for complex, bespoke, cross-platform applications.

With APIs for JavaScript, WPF, iOS and Android our ultra-high-performance data visualisation toolkits enable you to see the new opportunities for growth and performance improvement that would otherwise have been invisible.