One of our largest competitors recently published a detailed comparison between Scheduler and RevoGrid. The work included thirteen scenarios, two applications, screenshots, and a public repository. That is valuable engineering effort, but...
Our competitor implementation mounted
GanttPluginand its resource-planning view. RevoGrid's event and resource scheduling surface is the separateEventSchedulerPlugin.
That distinction changes what a test result means. In our current capability review, the target versions were RevoGrid Enterprise 2.4.0 and Bryntum Scheduler Pro 7.3.4.
The two RevoGrid surfaces are built for different questions
The implementation in the comparison uses RevoGrid Gantt:
import { GanttPlugin } from '@revolist/rv-enterprise-trial';
grid.plugins = [GanttPlugin];
The current event and resource scheduler uses a different plugin:
import { EventSchedulerPlugin } from '@revolist/revogrid-enterprise';
grid.plugins = [EventSchedulerPlugin];
These are not two names for the same UI.
Gantt resource planning asks:
- Which resources are over capacity?
- How much load is assigned by day or week?
- Which project tasks create that load?
- How do dependencies, constraints, and task dates affect the plan?
Event scheduling asks:
- What is booked against each person, room, or machine?
- Can an event be moved or resized?
- Can it be reassigned to another resource?
- Does it overlap another booking or blocked period?
- Should an invalid change be blocked, marked, confirmed, or sent to the backend for approval?
A resource-load chart may be part of a scheduling workflow, but it is not automatically a replacement for an interactive event scheduler.
A minimal resource-timeline setup
A current RevoGrid Event Scheduler resource timeline can be configured like this:
import { EventSchedulerPlugin } from '@revolist/revogrid-enterprise';
grid.plugins = [EventSchedulerPlugin];
grid.eventScheduler = {
view: 'resourceTimeline',
dateRange: {
start: '2026-08-03',
end: '2026-08-03',
},
slotMinutes: 60,
timeRange: {
start: '08:00',
end: '18:00',
},
editable: true,
allowCreate: true,
allowMove: true,
allowResize: true,
conflicts: {
enabled: true,
policy: 'mark',
scope: 'same-resource',
rules: {
overlap: 'error',
'outside-availability': 'error',
'blocked-time': 'error',
},
},
};
grid.eventSchedulerResources = [
{ id: 'room-a', name: 'Room A' },
{ id: 'room-b', name: 'Room B' },
];
grid.eventSchedulerEvents = [
{
id: 'booking-1',
resourceId: 'room-a',
title: 'Customer workshop',
startDateTime: '2026-08-03T09:00:00.000Z',
endDateTime: '2026-08-03T11:00:00.000Z',
},
];
This surface is designed around resource rows and event blocks. It supports event movement, resizing, reassignment, availability, conflict handling, grouping, and application-controlled persistence.
Dependency-driven project planning remains primarily a Gantt responsibility.
Why component mapping matters in benchmarks
Suppose a test asks:
Can a user drag a booking from Alice to Bob and update its
resourceId?
That test belongs on an interactive resource timeline.
Now consider:
Does moving a predecessor recalculate a successor according to dependency and calendar rules?
That belongs to a dependency-aware project scheduling engine.
Both are valid scheduling tests. They are not tests of the same product surface.
Before assigning a pass or fail, a benchmark should declare:
- The workflow being tested.
- The component mounted for each product.
- The business rule and expected final state.
- The exact package versions and configuration.
- Whether a difference is unsupported behavior, a defect, or simply a different declared policy.
Without that mapping, one product may be evaluated against a workflow it was not intended to implement.
Five neutral scenarios for a current Scheduler comparison
A compact Scheduler-to-Scheduler suite could start with these scenarios:
1. Render the same resource timeline
Both implementations receive the same resources, events, date range, time range, and viewport.
2. Reassign an event
Initial state:
event.resourceId = "alice"
Action:
Drag the event from Alice to Bob
Expected state:
event.resourceId = "bob"
3. Reject a same-resource overlap
The test should verify the resulting domain state, not only the visual position of the event.
4. Enforce resource availability
Move an event outside the target resource's working time under an explicitly configured blocking policy.
5. Undo a successful reassignment
One undo operation should restore the previous resource assignment and event dates.
Only after both products implement the same behaviors does a performance comparison become useful. Otherwise, faster rendering may simply mean that one setup is doing less validation or scheduling work.
This does not mean Bryntum's comparison has no value
It does provide useful evidence about the RevoGrid Gantt surface and configuration that it tested.
It also highlights real areas where Bryntum Scheduler Pro is strong: mature automatic scheduling, dependency and calendar integration, utilization tooling, conflict-resolution workflows, and a large set of turnkey scheduling features.
The narrower conclusion is this:
Results from RevoGrid Gantt resource planning should not automatically be generalized into claims about RevoGrid Event Scheduler.
For a current buying decision, the useful mapping is:
| Workflow | RevoGrid | Closest Bryntum product |
|---|---|---|
| Bookings, shifts, rooms, equipment, dispatch, resource timelines | Event Scheduler | Scheduler or Scheduler Pro |
| Task hierarchy, dependencies, constraints, critical path, baselines | Gantt | Gantt or Scheduler Pro |
| Editable operational data and analytics around the schedule | Data Grid and Pivot | Grid and related Bryntum products |
Different product philosophies
The products overlap, but they are optimized for different application shapes.
Bryntum Scheduler Pro is a strong fit when specialist scheduling logic is the center of the application and the team wants a mature collection of ready-made scheduling workflows.
RevoGrid Event Scheduler is designed for cases where scheduling is one part of a broader data-heavy SaaS, ERP, PPM, manufacturing, or operations interface. It shares a platform with the Data Grid, Pivot, and Gantt components, while allowing the host application and backend to remain responsible for canonical data, validation, persistence, and approval rules.
That is not a universal winner. It is a product-fit decision.
Public implementation
We published a small RevoGrid validation project that uses shared source data to show the distinction between:
- the Gantt resource-planning view;
- the Event Scheduler resource timeline.
It includes exact package versions, browser tests, and a live demo:
The repository validates the RevoGrid component distinction and selected Event Scheduler behaviors. It is not presented as a complete automated Bryntum-versus-RevoGrid benchmark.
Takeaway
The most useful lesson was not about defending a score.
It was about benchmark design:
Compare equivalent components, state the expected business behavior, and inspect the resulting application state—not just the screenshot.
That produces a comparison developers can reproduce and buyers can actually use.
Disclosure: I am part of the RevoGrid team. This article was drafted with AI assistance, then technically reviewed and edited by the RevoGrid team, who stand behind the examples and claims.
Top comments (0)