.jpg)
If you're building customer-facing analytics, you've probably spent time evaluating charting libraries. Recharts vs D3 vs ECharts vs Highcharts and so on.
Here's the thing: picking a library is not the hard part.
The hard part is everything that happens after you pick one. And most teams don't realize this until they're deep into production, fielding support tickets about tooltips that don't match, numbers that format inconsistently, and charts that break silently on edge-case data.
This is why we built Remarkable Pro - Embeddable's production-ready component library. Not because the world needed another charting library, but because the world needed charts that actually work in production, out of the box, without months of custom engineering.
TL;DR
- The library isn't the hard part. The hard part is loading states, error handling, number formatting, timezones, locales, accessibility, theming, interactivity, and responsiveness—across every chart, every time.
- Charts fail in edge-cases, not demos. Real data is messy: missing dates, sparse series, invalid granularities, slow queries. Most charting libraries aren't built for this.
- Remarkable treats charting as a product surface, not a component collection. Theming is genuinely granular - not just colors, but behavior: export options, date presets, comparison ranges, formatting defaults, internationalisation.
- You get code, not a black box. Full extensibility without forking. Override anything, extend everything.
The illusion of "just pick a library"
When teams start building embedded analytics, the first question is usually: which charting library should we use?
It's a reasonable question. There are plenty of excellent React chart libraries to choose from—Recharts for simplicity, Nivo for variety, Visx for low-level control, ECharts for scale, Shadcn (a component library), for sheer design quality.
But here's what most teams discover 6 months in: the renderer is not the differentiator.
The real work is everything around the chart:
- Data contracts and how they evolve over time
- Loading, refetching, empty, partial, and error states
- Number formatting—currencies, locales, rounding, units
- Timezones, missing dates, invalid granularities, comparison periods
- Interactions—tooltips, click-to-filter, legends, brushing
- Theming—dark mode, semantic colors, accessibility contrast
- Responsiveness under real layout constraints
Once charts are customer-facing, every edge-case becomes a UX problem. Or worse, a support ticket.
Where charts actually break
Charts don't fail in the happy path. They fail when real data shows up.
Missing data points in a date range. Sparse or zero-heavy series. Filters that return partial results. Time granularities that don't align. Queries that take longer than expected.
Most charting libraries handle the happy path beautifully—that's what demos are for. But production data is messy, and messy data exposes every assumption baked into your visualization layer. Tooltips that show undefined. Axes that collapse. Legends that overflow. Loading spinners that never resolve.
Then there's the longtail of features that every production dashboard eventually needs: internationalization (number formats, date formats, timezones), exports (CSV, PNG etc), accessibility (keyboard nav, screen readers, contrast), mobile optimization, consistent interactions across chart types.
When you're building internal tools, you can cut corners. When you're shipping to customers, you can't. Each gap becomes a support ticket, a roadmap line item, a maintenance burden.
Most teams massively underestimate this cost.
Charting as a product surface
When we built Remarkable, we made a deliberate choice: treat charting as a product surface, not a collection of components.
What does that mean in practice?
It means theming isn't just colors and fonts. It's genuinely granular. Every product choice is themeable: export options, date range presets, comparison ranges, formatting defaults, empty/loading/error states, value labels.
Here's a concrete example. Date range pickers are everywhere in analytics. Most libraries give you a component and leave you to wire up the options yourself. In Remarkable, date ranges are defined in the theme:
type DateRangeOption = {
value: string; // e.g. 'last-7-days'
label: string; // e.g. 'Last 7 days'
dateFormat: string; // e.g. 'MMM DD'
getRange: () => TimeRange; // returns UTC-based { from, to }
};
Want to remove "Today" from every date picker? Filter the array. Want 'Last 7 days' to include / exclude the current day? Modify that option. Want to add "Month to date" with custom calculation logic? Append it. One theme change, every component updates.
// Add a custom date range option
const myRanges = [
...parentTheme.defaults.dateRangesOptions,
{
value: 'month-to-date',
label: 'Month to date',
dateFormat: 'MMM DD',
getRange: () => myCustomRangeFunction(),
},
];
This is what we mean by theming behavior, not just appearance. The same pattern applies to export formats, number formatting, comparison periods, and more. Configure once, apply everywhere. Need one chart to behave differently? Override it at the component level without forking.
The net result: a fully branded, consistent analytics experience without copy-pasting configuration or maintaining parallel codepaths.
Why extensibility is non-negotiable
Here's a truth about embedded analytics: real companies always have "one more" use-case.
Maybe it's a custom chart type for a specific vertical. Maybe it's a unique interaction pattern that matches their product. Maybe it's a data visualization that doesn't exist in any library.
If your charting system can't accommodate this, you have two options:
- Tell the customer no
- Fork the code and maintain your own version
Neither is good.
This is why Remarkable ships as code, not a black box. You get:
- All core visualizations: Bar, line, pie, donut, KPI tiles, tables, heatmaps
- All essential controls: Dropdowns, multi-selects, date pickers (UTC-safe), filters
- Full source code: Override behavior, presets, logic—whatever you need
- Building blocks: Create your own charts using the same primitives we use
You can use Remarkable out of the box and never touch the code. Or you can extend it, modify it, build on top of it. The choice is yours, and you never have to ask permission.
Most charting tools feel flexible until they hit production. That's where they usually fall apart. Remarkable was built for production from day one.
What this means for your team
If you're evaluating embedded analytics tools, you've probably noticed a gap:
- Build it yourself: Maximum control, but you're on the hook for every edge-case, every feature, every maintenance cycle
- Buy an off-the-shelf tool: Fast to start, but limited customization and a UI that never quite matches your product
Remarkable gives you the best of both worlds:
- Production-ready defaults: Charts that handle edge-cases, format correctly, theme consistently, and work accessibly—out of the box
- Full code ownership: Extend, override, or replace anything without forking
- A dedicated team: We have engineers working on Remarkable full-time, making it better, so you don't have to
This isn't about choosing between building or buying. It's about getting the benefits of both without the tradeoffs of either.
The bottom line
Most charting libraries are built to render charts. They're optimized for demos, not production.
The real value isn't the renderer. It's the system around it:
- Contracts that don't break
- States that handle gracefully
- Theming that's genuinely granular
- Accessibility that's built in
- Interaction patterns that are predictable
If these aren't standardized early, charts may look fine but behave differently. And users always notice.
Remarkable exists because we got tired of watching teams learn this the hard way. We built the charting system we wished existed—production-ready, fully extensible, and designed for the real world.
Want to see it in action? Explore Remarkable in Storybook or get started with Embeddable.
Frequently asked questions
What is Remarkable?
Remarkable is Embeddable's production-ready component library for customer-facing analytics. It includes all core visualizations (bar, line, pie, KPI tiles, tables, heatmaps), essential controls (dropdowns, date pickers, filters), and built-in features like internationalization, click-to-filter interactivity, and CSS variable-based theming.
How is Remarkable different from other charting libraries?
Most charting libraries focus on rendering. Remarkable focuses on production: edge-case handling, consistent theming, internationalization, accessibility, and extensibility. It's designed for customer-facing analytics where every inconsistency becomes a UX or support problem.
Can I customize Remarkable to match my product's design system?
Yes. Remarkable uses CSS variables for precision styling, and theming extends beyond colors to behavior: export options, date presets, formatting defaults, and more. You can also override any component without forking the codebase.
Do I need to use Embeddable to use Remarkable?
Remarkable is part of the Embeddable platform. It's designed to work with Embeddable's data layer, caching, and embedding infrastructure to deliver fast, secure, multi-tenant analytics.
Can I build custom charts with Remarkable?
Yes. Remarkable provides the building blocks we use internally, so you can create custom visualizations using the same primitives. You get full source code access—extend, modify, or replace anything.
