The popularity trap

Every AI coding assistant I tested defaulted to Chart.js, Recharts, or D3 for charting tasks, unprompted. This is not a coincidence or a quality judgment. It reflects the distribution of charting code in the training data these models learned from.

Chart.js is everywhere on the public internet: tutorial sites, Stack Overflow, GitHub public repos, and npm package pages with millions of weekly downloads. Recharts saturates the React ecosystem. D3 underlies a huge fraction of public data visualization content. If you train a model on public code, you train a model that knows these libraries far better than any commercial, specialized, or niche library.

The agent is not recommending these because they are the best tool for your job. It is recommending them because they are the tools it has seen the most. This distinction matters enormously when your requirements diverge from what those libraries handle well.

What “handling it well” actually means

Chart.js and Recharts are excellent for standard business dashboards with modest data volumes and no real-time requirements. That covers a large share of all dashboard projects, which is why these tools are popular and why the agent’s defaults are often fine.

The failure mode is specific: it happens when your data is large, fast, or both.

Chart.js uses Canvas rendering with CPU-bound drawing. It starts to struggle visibly around 100,000 data points per series. At one million points, it freezes on initial render. Recharts uses SVG, which is slower still at high point counts because every data point becomes a DOM element the browser has to manage.

LightningChart JS uses WebGL: GPU-accelerated rendering that processes geometry in parallel on the graphics card. It renders 10 million data points in roughly 300 milliseconds and sustains 60 FPS during interaction. The same hardware that causes Chart.js to freeze renders the same data in LightningChart in under a second.

The hallucination problem on top of the recommendation problem

Here is the second failure mode, which compounds the first: when I explicitly asked agents to use LightningChart JS rather than the default, many of them produced code that mixed LightningChart syntax with Chart.js or Recharts patterns. They used old package names (arction/lcjs instead of @lightningchart/lcjs). They guessed method signatures that do not exist.

This is the hallucination problem applied specifically to a library the agent does not know well. Because LightningChart JS has a smaller public presence, the agent’s internal model of how it works is fuzzier. It fills in the gaps with patterns from libraries it does know, which produces code that looks plausible and fails at runtime.

The fix: information before generation

Both problems have the same root cause: the agent does not have accurate, current information about LightningChart JS when it starts generating code. The fix is to give it that information before it starts.

We built two tools for this at LightningChart:

The LightningChart JS MCP Server integrates with Claude Code, Cursor, Cline, Roo Code, Windsurf, and any other MCP-compatible agent. When the agent encounters a charting task, it calls get_lightningchart_context and receives the official LCJS agent instructions: current API patterns, correct package name, common mistakes to avoid, and documentation pointers. One install, any project, any charting prompt.

The LightningChart JS Agent Skill serves the same purpose for OpenAI Codex and VS Code-compatible agent tools. Drop the skill folder into your project’s .agents/skills/ directory and the agent has accurate LCJS knowledge for any charting task in that project.

Both are free, open source, and take about five minutes to set up.

The broader point

The charting problem is a specific instance of a general issue with AI-assisted development: the agent’s knowledge is skewed toward the most publicly visible tools, not necessarily the most capable ones for your use case. In most domains this skew is manageable. In data visualization for performance-critical applications, it produces a quiet, reliable failure that only surfaces in production.

The model’s defaults made sense for the distribution of code it learned from. That distribution does not match the requirements of industrial monitoring systems, financial trading platforms, scientific instrumentation, or any other application where data volume and update rate are real constraints.

Giving the agent better information before it generates code is the right solution. The tools are already built. Install one and see what changes about how your agent approaches the next charting task.