-
perspective
A data visualization and analytics component, especially well-suited for large and/or streaming datasets.
Would an accurate comparison be something like perspective? (https://perspective.finos.org/)
Is the focus on density around performance, visualization, or something else?
-
InfluxDB
Purpose built for real-time analytics at any scale. InfluxDB Platform is powered by columnar analytics, optimized for cost-efficient storage, and built with open data standards.
-
Svelte can be used with renderless components. https://imfeld.dev/writing/svelte_domless_components
Svelte can also draw on a canvas. There is Threlte: https://threlte.xyz/
-
I love information density!
I collect old newspapers and back then info density was way higher (for an _amazing_ coffee table book, google "nytimes complete front pages"). So much critical info above the fold.
I think high information density === high intelligence. Getting sort priorities right is very valuable and important.
The past few years the web seemed to be going the other way. Good to see people still rowing in the other direction.
Other examples:
I designed my blog to allow one to zoom in/zoom out to see ~20 years of posts at once (https://breckyunits.com/).
I've got some stuff coming out to make it easier to build highly information dense cheat sheets (I'm trying to get the name "Leet Sheet" to catch on - https://pldb.io/blog/leetSheets.html)
-
(Not that you're asking for advice, but hope you don't mind me sharing some anecdotal experience...)
When we had to do similar things, we found that it was much much much faster to take all that sort of stuff out of the DOM and put it into Canvas. You can still wrap React around it for the UI and controls and data passing and all that, but the actual rendering need not involve the VDOM or even the real DOM at all. With ChartJS we were able to get it to show tens of thousands of individual data points in a time-series scatterplot, each datapoint interactive and real-time, with no noticeable lag. And it was super easy to integrate into our React app. https://www.chartjs.org/
If it's not just charts, here's another canvas-based drawing lib: https://konvajs.org/docs/sandbox/20000_Nodes.html (and its React tie-in: https://konvajs.org/docs/react/Intro.html)
Not trying to discourage you from exploring Svelte if you want to, but it might be less work to just use an existing optimized drawing lib.
-
> Not that you're asking for advice,
The cunningham's-law-optimal way is to not ask, surely. Either that or the some programmers equivalent of the "death drive".
> canvas
Indeed, the canvas is basically inevitable, but it's a bespoke chart that has both temporal and non-temporal data in it (not sure what the terminology should be, but imagine plotting market expectations of interest rates in future and what expectations were historically displayed relative to current levels - but repeated ~200 times), so the existing chart libraries aren't particularly helpful and can get in the way of being able to click on stuff.
Anecdotally I find that programmers are very good at writing charts for the kinds of data they understand (time series, time series of their stock options, etc), but even the "generic" (e.g. grammar of graphics) libraries can still struggle with simple combinations of those domains.
Obviously you can just treat the charting library as a black-box for which you derive coordinate transformations and make things appear in the right place but not a great bus-factor for that kind of code.
I use https://github.com/leeoniya/uPlot for sparklines and so on, very fast.
-
VS Code Editor which is based on Electron, is really fast, even with large codebase & many open tabs. Their monaco engine (https://microsoft.github.io/monaco-editor/) uses custom, virtual code processor that is optimized for surgically updating underlying DOM. It also uses WebGL + canvas rendering to show minimap of the file.
Similar approach (custom virtual processor) is leveraged by Google docs/sheets.
Canvas rendering may be the last resort when nothing worked.
-
As far as I know, VSCode/Monaco does use viewport virtualization.
Take it with a huge grain of salt, I haven't researched this really and generally am not very familiar with the Monaco or VsCode source. I'm on mobile, so not inspecting a Monaco instance either.
The Monaco repository seems to contain some files only in minified form, and refers to the VsCode repo.
Skimming through the interfaces there, it definitely seems to have hints for viewport virtualization.
https://github.com/microsoft/vscode/blob/2c46cf10d6773e690cb...
Apart from that, WebWorkers seem to be used heavily to move the language server logic out of the main thread (completely different topic).
Back to the thread: what I wanted to say is that "surgical DOM updates" might be good, but DOM _size_ is the main issue for rendering.
If you're updating frequently, sure, heavy-handed DOM updates have an effect too. But that's not as severe as people think I assume.
But keeping DOM elements consistent instead of replacing large subtrees is without alternative anyway, regardless how optimized browser rendering and parsing will ever be, because of focus states for example.
Also worth noting that querying layout via JS is similarly expensive (not related to Svelte either).
Tl;dr: React might be less performant than Svelte, but a React "render" is not as expensive as a browser rendering the changed DOM.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
Related posts
-
Looking for a library to aid with creating APIs for graphs, charts, etc
-
Observable tutorial: Analyze data in a JavaScript-native data notebook
-
GraphQL Postgres Metrics Dashboard with Cube
-
How to make a graphics tool similar to Canva or Adobe Illustrator?
-
Comprehensive Guide to Git Branching, Merging, and Pull Requests