Most date pickers still use the same interaction model they have used for years:
- Open the calendar.
- See one month.
- Click an arrow.
- See the next month.
- Repeat until you reach the date you want.
That works reasonably well on desktop.
On mobile, it often feels strangely outdated.
We already scroll through almost everything on a phone: feeds, contacts, settings, maps, messages, product lists.
So why do date pickers still make us tap through months one at a time?
That question became one of the main ideas behind RollDate, an open-source JavaScript date picker built around continuous scrolling.
The problem with month-by-month navigation
Imagine you need to select a date three months from now.
With a traditional date picker, the interaction usually looks like this:
tap → wait → scan → tap → wait → scan → tap
The problem becomes more noticeable when selecting dates further away.
The UI forces the user to repeatedly interact with navigation controls instead of simply moving through time.
On a desktop this is mostly an inconvenience.
On a phone, where scrolling is one of the most natural gestures available, it feels unnecessary.
What if the calendar behaved like a list?
The alternative is simple:
make the calendar itself scrollable.
Instead of treating every month as a separate screen, treat dates as one continuous timeline.
The user can scroll naturally:
August → September → October → November
without repeatedly pressing navigation buttons.
That is the basic interaction model behind RollDate.
The calendar can still have navigation controls. Scrolling does not need to completely replace buttons.
The important difference is that buttons become an alternative navigation method rather than the only way to move through dates.
Why this works especially well on mobile
Scrolling has several useful properties on touch devices.
1. The gesture is already familiar
Users do not need to learn anything new.
They already know how to scroll a list.
A calendar can take advantage of the same interaction model.
2. Moving across several months is faster
Selecting a date several months away no longer requires repeated clicks on a small arrow.
A quick swipe can move through a much larger period.
3. The calendar feels continuous
Traditional date pickers often present time as isolated pages.
A scrolling calendar presents it as a continuous sequence.
That is a small conceptual difference, but it changes how the component feels.
But scrolling introduces new problems
Making a calendar scroll is easy.
Making an infinite scrolling calendar that remains predictable is considerably less easy.
Once months can continuously appear above and below the viewport, several questions show up:
- How many dates should exist in the DOM?
- When should old dates be removed?
- How do you preserve scroll position after adding content above the viewport?
- How do range and multi-date selections behave across distant months?
- How do you keep keyboard navigation predictable?
- How do you prevent performance from degrading after a lot of scrolling?
This is where a simple UI idea turns into an engineering problem.
Rendering an infinite calendar
The obvious implementation would be to keep adding months forever.
That also happens to be a terrible implementation.
After enough scrolling, the DOM would contain hundreds or thousands of date elements that the user cannot even see.
Instead, RollDate keeps the rendered calendar around the visible area and dynamically manages the surrounding dates.
Conceptually, the component behaves more like a virtualized list than a traditional calendar.
The goal is simple:
The user should feel like the calendar is infinite, while the browser should not have to render an infinite amount of content.
This becomes increasingly important on mobile devices, where unnecessary DOM work and layout recalculations are much easier to notice.
Range selection makes things more interesting
Scrolling also changes how date ranges feel.
A range may begin in one month and end several months later.
The user should be able to:
- select the start date,
- scroll naturally,
- select the end date,
- clearly see which dates belong to the range.
The calendar should not care whether those dates happen to be in the same rendered month.
That sounds obvious from the user’s perspective.
Internally, however, the selection state has to remain independent from whatever portion of the calendar currently exists in the DOM.
The UI is temporary.
The selected dates are not.
That separation turned out to be an important part of the component architecture.
Scrolling should not eliminate other navigation
There is another trap here.
A scroll-first date picker should not become a scroll-only date picker.
Different users prefer different interaction methods, and different interfaces have different requirements.
RollDate therefore supports traditional navigation controls as well.
The idea is not:
Buttons are bad.
It is:
Buttons should not be the only way to move through time.
On desktop, clicking may be convenient.
On mobile, scrolling may be faster.
A component can support both without forcing developers to choose one interaction model for every device.
Performance matters more than the animation
It is tempting to focus on smooth scrolling because that is the visible part of the component.
But the more important work happens underneath.
A useful scrolling date picker needs to avoid:
- uncontrolled DOM growth,
- unnecessary re-renders,
- expensive calculations during scroll events,
- losing selection state when dates are recycled,
- unexpected scroll jumps when content changes.
The animation can look perfect and the component can still be badly designed.
For reusable UI libraries, predictable behavior matters more than flashy transitions.
Building RollDate
I originally started RollDate because I wanted a date picker that behaved differently from the usual month-by-month components.
The project eventually became a dependency-free JavaScript date picker with support for:
- single-date selection,
- range selection,
- multiple-date selection,
- continuous scrolling,
- button navigation,
- localization,
- keyboard navigation,
- TypeScript definitions.
It is open source under the MIT license and has zero runtime dependencies.
The project is still evolving, and building it has made one thing increasingly clear to me:
small UI components are rarely actually small.
A date picker looks like a grid with some numbers.
Then you start dealing with date boundaries, localization, accessibility, keyboard interaction, range state, mobile behavior, rendering performance and scrolling.
Suddenly that little calendar has opinions about half of frontend engineering.
Try the scroll-first approach
If you want to see how this interaction feels in practice, there is an interactive demo:
You can also experiment with configuration options in the playground:
Documentation:
Source code:
npm:
The project website is:
I’m interested in one broader question beyond RollDate itself:
Should mobile date pickers still be designed around month-by-month navigation, or has scrolling become the more natural default interaction?
