Ced Charts — varför vi byggde ett eget diagrambibliotek
4 KB gzip, 3 argument, noll beroenden. Hur Ced Charts ersätter ECharts och Recharts i vår plattform — och varför det spelar roll för prestanda och AI-driven utveckling.
Problemet med ECharts och Recharts
Vi har byggt dashboards för fastighetsdata sedan dag ett — temperaturkurvor, energisignaturer, förbrukningsdiagram. Som de flesta började vi med etablerade bibliotek.
ECharts (Apache) är kraftfullt men tungt. Minifierad väger det ~800 KB — mer än hela vår applikation. Konfigurationen är en djupt nästlad JSON-struktur som kräver hundratals rader för ett enkelt linjediagram. För en AI-kodassistent som ska generera diagramkod innebär det tusentals tokens bara för att sätta upp grunderna.
Recharts (React) är lättare men kräver React som runtime och en deklarativ komponentstruktur som snabbt blir verbose:
<ResponsiveContainer>
<LineChart data={data}>
<CartesianGrid strokeDasharray="3 3" />
<XAxis dataKey="timestamp" />
<YAxis />
<Tooltip />
<Legend />
<Line type="monotone" dataKey="indoor" stroke="#8884d8" />
<Line type="monotone" dataKey="outdoor" stroke="#82ca9d" />
</LineChart>
</ResponsiveContainer>
Det är 10 rader och ~80 tokens — för ett diagram med två linjer, utan enhet, referenslinjer eller synkade tooltips.
Ced Charts: 3 argument, 15 tokens
Samma diagram i Ced Charts:
ced.chart('#el', data, ['indoor', 'outdoor'])
Det är 3 argument och 15 tokens. Biblioteket auto-detekterar tidsstämplar, väljer axelformat, tilldelar färger och skapar interaktiva tooltips med sorterade värden.
Med alternativ — enhet, referenslinje, streckad serie — landar vi på ~25 tokens:
ced.chart('#el', data, {
keys: ['indoor', 'outdoor'],
unit: '°C',
mark: 21,
dash: ['outdoor']
})
Varför token-effektivitet spelar roll
Vi bygger med AI i kärnan. Våra kodassistenter genererar och modifierar diagramkod dagligen. Varje token som krävs för att beskriva ett diagram är en kostnad — i latens, i kontext, i risk för hallucination.
| ECharts | Recharts | Ced Charts | |
|---|---|---|---|
| Paketstorlek | ~800 KB | ~180 KB + React | ~4 KB gzip |
| Tokens per diagram | 200–500 | 80–150 | 15–30 |
| Beroenden | 0 (men stort) | React + D3 | 0 |
| Framework-krav | Nej | React | Nej |
| Auto-detection | Nej | Nej | Ja |
Mindre API-yta = färre fel. Ingen LLM behöver memorera 200 konfigurationsnycklar när 8 räcker.
Vad Ced Charts gör
- Linjediagram med stöd för null-gaps, streckade serier och smooth-interpolation
- Ytdiagram med gradient-fill
- Stapeldiagram med kategoriska och numeriska axlar
- Scatterplot med 2D magnetisk tooltip — snäpper till närmaste punkt, inte bara närmaste X-värde
- Dual Y-axel — vänster och höger axel med separata enheter
- Referenslinjer och band — setpoints, komfortzoner, alarmnivåer
- Synkad crosshair — grupper av diagram som följer samma datapunkt
- Automatisk Y-skalning — toggla serier i legenden, axeln anpassar sig
- Glasmorfisk tooltip — sorterade värden, tidsstämpel, seriefärgpunkter
Allt renderas som ren SVG. Inga canvas-element, inga virtuella DOM-diffar, inga runtime-beroenden.
Energisignatur: ett verkligt användningsfall
Ett av våra vanligaste diagram är energisignaturen — effekt (kW) plottad mot utomhustemperatur. Det avslöjar hur effektivt en byggnads värmesystem arbetar.
I ECharts kräver detta ~40 rader konfiguration. I Ced Charts:
ced.chart('#energy-sig', data, {
keys: ['power'],
type: 'scatter',
unit: 'kW',
xKey: 'outdoor'
})
Tooltip magnetiserar till närmaste punkt i 2D — inte bara närmaste X-värde som de flesta bibliotek gör. Det gör stor skillnad när många datapunkter delar samma utomhustemperatur.
Prestanda
Ced Charts laddar på under 5 ms. Det finns inget att hydrera, ingen treeshaking att konfigurera, inget bundler-steg. En <script>-tag och en CSS-fil — klart.
Hela koligo.se kör Lighthouse 100/100/100 med LCP på 179 ms. Diagrambiblioteket bidrar med ~4 KB till den totalen.
Open source?
Ced Charts är idag en del av vår interna Ced-framework. Vi utvärderar att släppa det som open source — om du är intresserad, hör av dig.
Prova det live på vår demo-sida.