I got tired of laggy timelines, so I've been using Tempis

Nikolas Howard — Sat, 24 Oct 2026 14:23:04 +0000

Every few months I end up needing a timeline in some app. A scheduling view, a project plan, a feed of events plotted against time. And every few months I rediscover that most timeline components fall apart once you give them real data. Fifty items, fine. A couple thousand? Scroll goes choppy, memory creeps up, and hovering over anything feels like wading through syrup.

The reason is usually the same. These libraries keep a DOM node for every single item. The browser is great at a lot of things, but keeping thousands of absolutely-positioned divs in sync while you pan around is not really one of them.

Tempis takes the other route and draws everything to a canvas. One element, no per-item nodes. So the question of "how many items can I show" stops being about your layout engine and starts being about how much you actually want on screen. It's held up fine for me past 5,000 items, and the whole thing is under 18 KB gzipped with zero dependencies, which I appreciated more than I expected to. Nothing else to audit, nothing else to break.

Here's the smallest thing that does something useful:

import { TempisTimeline } from '@tempis/timeline';

const timeline = new TempisTimeline('#canvas', {
  responsive: true,
  items: [
    { id: 1, label: 'Design',  start: '2026-01-05', end: '2026-01-15', grouping: 'Frontend' },
    { id: 2, label: 'Build',   start: '2026-01-12', end: '2026-01-28', grouping: 'Frontend' },
    { id: 3, label: 'Launch',  start: '2026-01-30', grouping: 'Frontend' },
    { id: 4, label: 'API',     start: '2026-01-08', end: '2026-01-25', grouping: 'Backend' },
  ],
  range: { start: '2026-01-01', end: '2026-02-01', position: 'bottom' }
});

An item with a start and end is a range. An item with just a start is a point in time. When they overlap, they stack themselves, so you're not doing lane-assignment math by hand. The grouping field is what splits those four items into a Frontend row and a Backend row, and you can collapse groups, sort them your own way, and let people click a legend to filter by category. That legend-plus-grouping combo is the thing I reach for most, honestly. It turns a flat wall of bars into something you can actually read.

If you're not on a build step, there's a CDN drop-in:

<script src="https://unpkg.com/@tempis/timeline/dist/tempis_timeline.min.js"></script>
<script>
  new tempis_timeline.TempisTimeline('#canvas', { /* same options */ });
</script>

Past the basics, the stuff that's saved me time: dependencies between items with the connector arrows routed automatically (and it doesn't fall over in RTL layouts), bands for drawing reference markers and lines across the whole thing, per-item styling when you need one bar to stand out, and animated focus() to glide over to a specific item or date instead of teleporting. You can export the current view to a PNG if someone wants a screenshot for a deck. And if you've already standardized on Luxon or Day.js, there's a date adapter so you don't have to fight it over date handling.

The interactivity comes through callbacks, nothing exotic:

new TempisTimeline('#canvas', {
  items,
  onItemClick: (id) => openDetails(id),
  onItemContextClick: (id, pos) => showMenu(id, pos),
  onRangeChange: (start, end) => fetchVisibleData(start, end),
});

That last one is quietly the useful one. onRangeChange fires as the visible window moves, so you can lazy-load and only pull the data that's actually in view instead of shipping everything up front. For a live feed or a big historical dataset that's the difference between snappy and not.

There's a React wrapper too, @tempis/react, if you'd rather not manage the instance lifecycle yourself:

import { TempisTimeline } from '@tempis/react';

function App() {
  return (
    <TempisTimeline
      items={items}
      options={{ responsive: true }}
      onItemClick={(id) => console.log('clicked', id)}
      height={400}
    />
  );
}

items, categories, bands, and dependencies are props that sync on their own. When you need to do something imperative, like focus an item, grab the current range, or export an image, you reach for a ref:

const ref = useRef<TempisTimelineRef>(null);
// ...
ref.current?.focus({ id: 1, animate: true });

It's all TypeScript with real declarations, and the React package re-exports the core types so you're not installing two things just to import TempisTimelineItem.

One bit of honesty before you npm install: Tempis is source-available, not MIT. It's free for personal projects, learning, and evaluation, but commercial use that makes money needs a paid licence. Worth a look at the LICENSE so there are no surprises later.

If you want to poke at it before writing any code, the examples page has live demos, and the getting started docs go deeper than this post does. If you end up building something with it, I'd genuinely like to hear what. The timeline UIs people come up with are always more interesting than the demos.

I tried to use vis.js… then SSR and performance got in the way

Nikolas Howard — Fri, 05 Jun 2026 12:29:12 +0000

I needed a timeline for a reporting feature.

Not just something interactive in the browser, but something that could also be rendered server-side and exported (PDFs, images, etc).

It also needed to show dependencies between items, not just a flat set of events.

Seemed straightforward enough.

Started with vis.js

vis.js was a pretty solid choice.

It’s been around forever, lots of features, decent docs. I figured it’d cover everything.

And to be fair it worked fine at first.

Until the requirements stopped being “demo-sized”.

Requirement #1: server-side rendering

This is where things immediately got messy.

The timeline needed to:

render on the server
be consistent (same output every time)
plug into a reporting pipeline

vis.js is very DOM/browser-driven, so SSR was basically:

not supported unless we also wanted to also have to deal with a headless browser
possible with hacks I didn’t want to maintain long-term

That alone was a pretty big red flag.

Requirement #2: dependencies between items

This one turned out to be just as awkward.

The timeline wasn’t just visualising events, it needed to show relationships:

item A blocks item B
task C depends on task D finishing
chains of related work across time

In practice, that means links between items, not just items on a timeline.

vis.js doesn’t really handle this cleanly out of the box:

no first-class concept of dependencies
you end up hacking it together yourself
quickly gets messy when the data isn't trivial

Then the data got bigger

Once I started feeding in more realistic data, things slowed down fast.

Nothing crazy either, just enough items to resemble a real product:

scrolling started to feel heavy
zooming wasn’t smooth
lots of DOM nodes getting created

Add dependencies on top of that, and things got even harder to reason about.

It just didn’t feel like something I’d want in production.

React didn’t help much either

Trying to wrap vis.js cleanly in React felt… off.

Lots of imperative code, lifecycle juggling, things getting out of sync.

It worked, but it never felt like it fit.

At that point it was easier to start over

I didn’t originally plan to build a timeline library, but it got to the point where working around everything was more effort than just doing it properly.

So I built Tempis.

👉 https://tempis.dev

The main decision: stop relying on the DOM

Most of the issues came back to one thing:

too much DOM

So I switched to a canvas-based approach instead.

That ended up solving a lot of problems at once:

far fewer rendering bottlenecks
smoother interactions
more predictable output (important for reports)
a cleaner way to render relationships between items
it's super easy to render a canvas to an image

What it’s actually aimed at

This isn’t really a “toy timeline” library.

It’s for things like:

reporting views
product roadmaps
activity timelines
scheduling / Gantt-style interfaces
anything where you have a lot of time-based data
and especially where items are connected, not just listed

DEV Community: Nikolas Howard