DEV Community: Daniel Martinez Morgado

I benchmarked 3 Angular timeline libraries with 10,000 bars

Daniel Martinez Morgado — Mon, 09 Nov 2026 10:09:36 +0000

I wrote ngx-lanes, so take this with the right amount of salt: I'm not a neutral party. That's why everything below is reproducible with three commands, and why I've tried hard to give the other two libraries a fair setup.

The question: how do Angular timeline libraries cope with 1,000 resources and 10,000 bars? That's a realistic size for planning screens: a fleet over two months, a hospital rota, a factory floor.

The contenders

ngx-lanes 0.1.1: my resource timeline. Rows are resources, bars are assignments.
@worktile/gantt 22.0.0 (ngx-gantt): the most established open-source Angular Gantt.
schedula-core-angular 1.4.0: the official Angular wrapper of SchedulaCore, a resource-based Gantt.

The setup

The same 10,000 bars for all three, generated with a fixed seed.
The same density: about 8 days per screen.
Each library configured the way its docs recommend. For ngx-gantt that means virtualScrollEnabled and NgxGanttModule; for schedula-core, animations off.
A production build with Angular 22, headless Chrome, a 1400 × 850 viewport, median of 3 runs.
CPU throttled 4× in Chrome to approximate a modest laptop. A fast machine hides problems your users will see.

I measured four things: time until the first bar is painted, DOM nodes after that, frame times while scrolling with the mouse wheel, and how long the main thread is blocked during the scroll.

Results (CPU throttled 4×)

Library	Load	DOM nodes	Frame p95	Slow frames	Main thread blocked while scrolling
ngx-lanes	0.46 s	344	16.8 ms	0%	0 s
ngx-gantt	1.07 s	417	49.9 ms	6.6%	1.4 s
schedula-core	66 s	186,721	1,100 ms	100%	159 s

Without throttling, ngx-lanes and ngx-gantt both scroll at a perfect 60 fps; the difference is load time (0.15 s against 0.30 s). schedula-core still takes 14 s to show the plan.

What explains the gap

schedula-core renders everything. All 10,000 bars and their decorations are in the DOM from the start: 186,721 elements. Every scroll then has to move all of them. It's a fine design for a few hundred bars; at this size it collapses.

ngx-gantt virtualizes rows, but it's a task Gantt. It shows one bar per row, so 10,000 bars become 10,000 rows under 1,000 resource headers. Its virtualization keeps the DOM small, yet a screen shows about 35 bars where ngx-lanes shows about 110. Even rendering a third of the bars, it blocks the main thread for 1.4 s across the scroll.

ngx-lanes virtualizes in both directions. It only renders rows within the viewport (plus a margin of four), and within those rows only bars within 300 px of the visible time range. Finding those bars is a binary search per resource, not a scan. The size of the DOM depends on what's on screen, not on how many bars the plan has. I explained the technique in my previous post.

Where the others win

Speed isn't everything, and ngx-lanes is new. Today:

ngx-gantt has dependency links, drag and drop, a tree table, baselines and years of production use. If you need a project Gantt with those features, it's a solid choice.
schedula-core ships themes, a built-in editing popup and, in its paid version, drag and drop, calendars and context menus.
ngx-lanes is a read-only timeline for now. Drag and drop, conflict detection and live updates are on my roadmap.

Reproduce it

Everything is in the repo: the app, the runner script and the raw results.

git clone https://github.com/dmartinezzm/ngx-lanes
cd ngx-lanes/benchmarks
npm install && npm run build
npm run bench -- --runs 3 --chrome "/path/to/chrome"

One practical note: schedula-core-angular 1.4.0 is published without entry points in its package.json, so Angular can't import it as is. The benchmark adds them with a small script that points at the package's own build output.

If you think a library is misconfigured, open an issue or a pull request and I'll rerun the numbers. And if you build planning screens in Angular, I'd love to hear which of these limits you've hit.

Rendering 10,000 bars in an Angular timeline without freezing the UI

Daniel Martinez Morgado — Mon, 09 Nov 2026 09:31:52 +0000

Planning screens are where Angular apps go to die: a row per vehicle, person or machine, a bar per booking, and suddenly the page holds tens of thousands of elements. I build this kind of screen at work, so I wrote ngx-lanes, an open-source resource timeline that keeps only what you can see in the DOM.

With 1,000 resources and 10,000 bars, the DOM holds about 22 rows and 50 to 130 bars at any moment. Here is how.

1. Index bars per resource, sorted by start

The first step happens once per data change, inside a computed(): group the bars by resource and sort them by start time. While grouping, keep the longest duration in each resource.

2. Find visible bars with a binary search

A bar is visible if it overlaps the window [from, to). Sorted by start, the bars that can overlap begin at from - maxDuration at the earliest, so a binary search jumps there and a short loop stops at the first bar that starts after to:

const first = lowerBound(items, from - maxDuration);
for (let i = first; i < items.length && items[i].start < to; i++) {
  if (items[i].end > from) result.push(items[i]);
}

No bar outside the window is ever touched, so a resource with 10,000 bars costs about the same as one with 10.

3. Virtualize rows and time

Rows are absolutely positioned at index * rowHeight inside a canvas as tall as all rows together, so the scrollbar is real. From scrollTop and the viewport height I compute the visible rows plus four rows of margin. The same idea works horizontally: only bars within 300 px of the viewport are rendered, and only the time ticks you can see.

Everything is a chain of signals: scrollTop, scrollLeft and the viewport size feed computed() values for the visible window, the ticks and the rows. The template loops over the result with @for and track, so Angular reuses the elements that stay on screen.

4. Keep the same instant centred when zooming

Switching from month to day zoom makes the canvas 36 times wider. If you set scrollLeft straight away, the browser clamps it to the old width and you land somewhere else. The fix is to wait for the render that resizes the canvas:

effect(() => {
  const scale = this.scale();
  const anchor = untracked(() => this.anchorTime);
  if (anchor === undefined) return;
  afterNextRender(
    { write: () => this.setScrollLeft(scale.toX(anchor) - this.viewport().width / 2, false) },
    { injector: this.injector },
  );
});

One more trap: a scroll you set from code fires its scroll event later, asynchronously. If that event updates the anchor, a clamped value overwrites the instant you wanted to keep, so programmatic scrolls are flagged and their event is ignored.

Try it

Demo with 1,000 resources and 10,000 bars: https://dmartinezzm.github.io/ngx-lanes/
npm install ngx-lanes (Angular 19+, zoneless or zone.js, MIT)
Code: https://github.com/dmartinezzm/ngx-lanes

I'm working on a Pro version with drag and drop, conflict detection and live updates from SignalR. If your team builds planning screens, the waitlist is on the demo site, and I'd like to hear what you plan with it.