Web Data Visualization: Architecture, Rendering, Production — a Practitioner's Guide

"Web data visualization" hides three questions that guides consistently blur together: which tool to pick, how to render it in a browser, and how to integrate it properly into a site or product. Tool roundups answer the first (poorly) and ignore the other two. This guide does the opposite: it starts from the three decisions a web dataviz project actually has to make — architecture, rendering technique, and production constraints — with the rules of thumb we use on our own dashboard projects.

Decision 1 — Embedded BI, JavaScript library, or custom build?

This is the founding trade-off, and no roundup frames it: listicles put Power BI and Chart.js in the same list, as if a BI platform and a charting library answered the same need. There are three paths:

• Embedded BI (Metabase, Superset, Power BI Embedded…): the fastest way to put internal dashboards in front of teams. Limits: capped visual customization, often rigid iframe embedding, and the serious embedding features (multi-tenant, row-level security) are frequently paid — we detailed those traps in our open source tools guide.
• A JavaScript library (ECharts, D3, Plotly, Chart.js…): the right call as soon as visualization is part of your product — your design system, custom interactions, full control. The real cost: front-end development, plus owning everything the BI tool used to do for you (filters, exports, permissions).
• Full custom (data + API + dedicated interface): when the visualization is the product — data frescoes, business tools, decision interfaces. That's specialist agency territory; it's ours.

On budgets, let's be frank since nobody else is: a custom web dashboard is priced in development days, not licenses. French dev marketplace barometers place a ~5-screen dashboard between €7,500 and €13,600; in practice the budget depends mostly on the state of your data upstream — half the work in a dataviz project happens before the first pixel, in collection and reliability.

Decision 2 — SVG, canvas or WebGL: the rendering technique

Nearly absent from published guides, yet decisive as volume grows. The browser gives you three techniques:

• SVG: every point is a DOM element. Ideal up to a few thousand elements: inspectable, stylable in CSS, and above all accessible (screen readers can traverse it). Beyond that, the DOM becomes the bottleneck.
• Canvas: the chart becomes a drawn image. Rendering cost no longer depends on DOM size — tens of thousands of points stay smooth. The trade: nothing is inspectable, and accessibility and fine-grained interactions must be rebuilt by hand.
• WebGL: the GPU takes over, for hundreds of thousands of points and beyond. Reserve it for cases that truly need it — in a developer-forum thread, someone wanted to render 10 million lidar points; the community's answer sums up the state of the art: unrealistic as is, aggregate server-side and cap what the browser receives.

The rule we apply: the browser is not a database. Before picking a rendering technique, reduce volume server-side (aggregation, sampling, tiling) — a readable chart rarely exceeds a few thousand meaningful points. The SVG/canvas choice then becomes a matter of comfort, not survival.

Decision 3 — The libraries still alive in 2026

Recommending a library means committing your product's maintenance for years. In August 2026 we measured the actual state of the most-recommended dataviz libraries (license, latest release, activity) — the full study is here. The web-side essentials:

Library	Latest release	Status (Aug. 2026)
Apache ECharts	May 2026	Active — our default for embedded work
Plotly.js	Jul. 2026	Active
Cytoscape.js (graphs)	Aug. 2026	Active
Leaflet (maps)	May 2023 (v2 alpha)	Stable, slow-moving
D3.js	Mar. 2024	Stable and "finished" — powerful, but no longer evolving
Chartist.js	Sep. 2025	Slowing

Worth noting: D3, the most recommended tool in every roundup, hasn't shipped a release since March 2024. Not a reason to panic — it's a stable library — but adopting a "finished" tool in 2026 is not the same commitment as adopting an actively developed one, and no listicle makes that distinction.

What production demands (and demos forget)

Responsive is not shrinking. A dashboard designed for a desktop screen doesn't "scale down" to mobile: it gets rethought — fewer series, touch interactions, display thresholds. Designing the mobile version first forces the right priorities.

Accessibility, the sector's total blind spot. Accessibility rules (mandatory for the French public sector under RGAA and, since 2025, for a large share of digital services in the EU) apply to charts too — and the accessibility content cluster and the dataviz cluster completely ignore each other. The viable minimum: a text alternative that carries the chart's information, the data available as a table, sufficient contrast, and keyboard navigation. A technical detail that follows from Decision 2: SVG exposes its elements to the DOM, hence to assistive technologies — canvas doesn't. For a public-sector actor, that criterion alone can settle the rendering choice.

Performance is won server-side. Lazy-loading off-screen charts, upstream aggregation, query caching: slow dashboards are rarely slow because of the rendering library.

Frequently asked questions

Do you need a developer for web data visualization? For an internal dashboard: often not — a BI tool will do. As soon as the visualization integrates into your site or product — your brand, your interactions, your users — yes, and it's front-end development work in its own right.

Which JavaScript library should you pick in 2026? Our short answer: ECharts by default (Apache-2.0, fast canvas, themeable), Plotly for scientific leanings, D3 when you need absolute custom control and know what you're signing up for. The long answer is in our verified comparison.

How many points can a web chart display? Technically: thousands in SVG, tens of thousands in canvas, more in WebGL. In practice the real question is editorial: past a few thousand points nobody reads anything — aggregate server-side.

Must a web dashboard be accessibility-compliant? For the French public sector, yes, charts included. For the private sector the obligation is spreading — and an accessible chart (text alternative, data table, contrast) is a better-designed chart anyway.

A dashboard or visualization project to integrate into your product? It's been our job since 2011 — let's talk.