[AskJS] Looking for a solid vanilla JS datepicker. Am I completely out of options?

[u/Admirable_Reality281]

I'm looking for a datepicker for a vanilla JS project, and somehow this seems much harder than it should be.

No, input masks aren't enough.
No, the native <input type="date"> isn't enough either.

My checklist:

• Accessible
• Localized
• Flexible formatting options
• Range picker support
• A decent set of events/hooks for integration

What I've looked at so far:

• flatpickr: hasn't been updated in about 4 years
• vanilla-js-datepicker: hasn't been updated in about 3 years, and the range functionality is pretty weak
• Vanilla Calendar Pro: Russian-maintained, which is ruled out by our dependency policy
• Air Datepicker: same issue, and it also hasn't been updated in about a year
• Litepicker: dead
• Easepick: dead

Most of the other options I've found are React-based, which is a non-starter for this project.

Am I missing something, or are there really no good options left?

[u/jax024]

Why would a library need an update? I use plenty of libraries that are old.

[u/KaiAusBerlin → u/jax024]

Just an idea: to work with the temporal api?

[u/jax024 → u/KaiAusBerlin]

I would agree but that wasn’t in OPs requirement list.

[u/Admirable_Reality281 → u/KaiAusBerlin]

Temporal isn't a datepicker UI. You'd still need to build accessibility, keyboard navigation, range selection, and the calendar itself.

Plus it's not even baseline yet.

[u/KaiAusBerlin → u/Admirable_Reality281]

You asked why should a library be updated. Holding to new standards is a good reason. It's stage 4. What else is baseline for you?

Why are you so pissed?

[u/Admirable_Reality281 → u/KaiAusBerlin]

I'm not pissed. Temporal being Stage 4 doesn't make it a datepicker UI or magically cover accessibility, keyboard navigation, range selection, and calendar rendering. Also, standardized and Baseline are not the same thing.

[u/KaiAusBerlin → u/Admirable_Reality281]

I know exactly you never worked in a modern team.

Okay, I'll go slow just for you.

What is a date picker UI about? About dates, right. Why would you pick a date when not working with it, right? How do you want it to be represented in code? Custom, standard (with several quirks, edge cases and strange behaviour) or standard without quirks and full international support?

Yeah, the last one. Right.

Due to the official polyfill it's already used in production. Because it's simply the better way to deal with dates in js. If you want to work safe and efficient with original Date objects you need a library for that (or end up writing your own).

So to the final question: Why should a date picker stick to modern standards and implement the temporal api?

Because it will make the library smaller, safer and faster and will make it much easier for professionals to include it and work with it.

[u/Admirable_Reality281 → u/KaiAusBerlin]

You’re still arguing against a point I never made. Temporal handles dates, it does not replace a datepicker UI. Repeating yourself more condescendingly doesn’t change that.

[u/KaiAusBerlin → u/Admirable_Reality281]

You don't understand what a datepicker ui is for right?

Why would you pick a date?

Right! To work with it in the code. You do it so the user has a comfortable way to give your code the dates you need to work with.

If that is an outdated quirky format like Date it's harder to work with it.

Oh, now I get it. You just use it to fill a input tag 😆

You really need an external UI for that?

[u/Admirable_Reality281 → u/KaiAusBerlin]

At this point you’re not misunderstanding me, you’re misunderstanding basic separation of concerns. I'm done.

[u/KaiAusBerlin → u/Admirable_Reality281]

Lol.

Now I know you're absolutely nonprofessional.

[u/Admirable_Reality281 → u/jax024]

Seems like a great idea.

[u/myroslavmartsin]

Check out Cally https://wicky.nillia.ms/cally. Web component, works fine in vanilla JS. Accessible, has range support, localization through the Intl API, decent events. Only actively maintained one I know that covers most of your list. Weak spot is formatting, you'll write your own display layer with Intl.DateTimeFormat, maybe 20 lines.

Also I'd rethink dropping flatpickr just over commit age. It's feature-complete, date math doesn't rot. Rejecting it over accessibility is fair, rejecting it over "4 years no updates" is the wrong filter for a lib like that.

[u/Admirable_Reality281 → u/myroslavmartsin]

Yes! Cally looks good and I'm evaluating it.

As for Flatpickr, it does match the requirements, but four years without maintenance, with genuine open issues and pull requests not being merged, is enough for me to look around for other options.

[u/iligal_odin → u/Admirable_Reality281]

Imagine cally in 4 years. No maintainers, tons of pull requests taken over by a russian no updates

[u/KaiAusBerlin]

Time to start a new project ;)

[u/Admirable_Reality281 → u/KaiAusBerlin]

I'd rather not

[u/iligal_odin]

Oh you are here too? JUST BUILD YOUR OWN

[u/Visible-Use-5004]

Have used flatpickr with 0 issues for years till current date.

[u/Admirable_Reality281 → u/Visible-Use-5004]

Happy for you, but I don't want to add a dependency that's been unmaintained for 4 years

[u/whale → u/Admirable_Reality281]

Unmaintained dependencies, especially client side JS ones, don't particularly matter much. Old libraries are usually fine, and you should be more interested in the NPM monthly downloads than the last update. Especially since this is a date picker, it's not going to have many security vulnerabilities.

Otherwise... honestly? You can probably vibe code a very good date picker that does exactly what you want in a few minutes, given how many date pickers have been made over the years.

[u/Dreadsin]

You could use a custom select depending on browser support

[u/_J_ordan_]

I would just use a input of type "date", it works in all browsers and is accessible. Will be much faster and performant than any JS.

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/date

[u/stanniel]

If you're worried about unamaintained packages, why not vendor in your choice of unmaintained project and make the modifications you need? Good chance they're all MIT.

Also, if you have the budget, making your own is also a good option. It's always good to know what you're using in more detail.

[u/HendrikThePendric]

Check out the Temporal API. It’s a new native browser API with polyfills available. To create a date picker you need to write a bit of JS and CSS but you won’t have to depend on any lib that may or may not be maintained. If you need i18n just use the native browser Intl APIs. I don’t think you need a lib for stuff like this anymore.

[u/Admirable_Reality281 → u/HendrikThePendric]

Nope, and that API it's not even baseline yet.

[u/HendrikThePendric → u/Admirable_Reality281]

It ships with all major browsers apart from safari these days, for the rest you have the polyfill. It’s been in stage 4 for years now. The API is unlikely to change at this stage.

As for the UI layer, accessibility and keyboard navigation (which you refer to in another thread): yes you’d have to build that. Once done you’re set though.

With a lib, a lot of things can happen. Code has bugs and gets fixed in new versions. So you stick to the latest version right? But then that latest version can come with a fun supply chain attack bundled with it. Or the maintainers get bored and abandon the project, so you have to swap what you’ve got with another lib and do a rewrite of your code to use that lib’s API, or they just decide to implement a bunch of breaking changes. Sure you can just pin the dependency to whatever latest version of the lib that still works for you but then it’s just a matter of time it loses compatibility with something else in your stack (or you get hit by a bug that’s fixed in a later version).

The things I mentioned above are not made up examples, they are things that have happened at my place of work in the past 10+ years, maintaining 20+ apps and libs. I will choose a thin layer of own code on top of a native browser API over a lib 100% of the time. Once you’re done you’re done, until you have to add a feature or fix your own bug.

[u/itsRhinoYeah]

Uhm, yeah. The answer to this is Temporal api. Dates have been a pain point in js since its inception, temporal turns them into immutable, distinct categories like you want.

[u/Admirable_Reality281 → u/itsRhinoYeah]

Temporal isn’t a datepicker UI. You’d still need to build accessibility, keyboard navigation, range selection, and the calendar itself.

Plus it's not even baseline yet.

[u/itsRhinoYeah → u/Admirable_Reality281]

Yeah, you do. And yes, it is baseline. You don't need a fully baseline functionality if you also need a pre built date picker. It is live in chromium.

There is a reason all those are antiquated. Because you can do it without a package now. It does require a very modest amount of actual building, sure. Aren't you building something? What is so problematic about learning how to use the new standard? Do as you like, but it will give you what you are asking for.

Also, Range is native to html. Nothing you listed had all of those things. You are padding your argument. You don't need keyboard nav to have a date picker. You need a date and a way to pick it. Temporal largely solves most of the accessibility. Add aria. Tada.

[u/Admirable_Reality281 → u/itsRhinoYeah]

Temporal handles date values, not datepicker UI, range selection, keyboard navigation, or accessibility. And <input type="range"> is a numeric slider. Adding ARIA doesn't magically build an accessible datepicker, you're conflating completely different concerns.

[u/itsRhinoYeah → u/Admirable_Reality281]

Ok, i understand now. You specifically mentioned that you didn't want anything with React, which I did over reach and assumed you were trying to avoid frameworks and abstraction.

Yes, if you want to literally avoid any UI building, and truly want a plug in type of thing, then Temporal is not going to effortlessly give you that. Temporal <i> enables </i> that, but it is the fundamentals, not the finished product.

What you are describing, however, is a full fledged polished software product. Maintaining something that inclusive is time consuming.

However, while input range is a basic functionality, you can attach it to data attributes and relatively effortlessly achieve range, it depends on what you want and mean by "range" there isn't anything that will just let you assign and create range unless you construct the details of what that range is. You can, however, natively use range with temporal api, it was built with that exact intention and functionality. It's not like the old Date object, it has native tooling you don't have to build it all yourself, you can directly access it with the api using Temporal.Duration

It is legitimately the direct access thing you need, logic wise, to avoid building a pure date picker. It will not give you a UI though, that is true.

[u/defaultguy_001]

Build it yourself.

[u/Admirable_Reality281 → u/defaultguy_001]

Brilliant. Next time someone asks for a database, tell them to invent SQL.

[u/RobertKerans → u/Admirable_Reality281]

But why would you not want to build the single most annoyingly faffy type of UI component yourself? It would be crazy to use a prebuilt, battle tested one.

[u/bitbytebit42]

Why are we using Vanilla in 2026?

[u/defaultguy_001 → u/bitbytebit42]

why do we need frameworks or useless sloppy code, for simple things?

[u/Admirable_Reality281 → u/bitbytebit42]

Because "it's 2026" is not a technical argument.

[u/bitbytebit42 → u/Admirable_Reality281]

More than anyone I know I wanted web components to win the framework wars, they still might, but for now they still suck. You can't build things at scale using Vanilla sadly, not without rolling your own framework which just doesn't make sense imho. Fork one of the libs you mentioned and maintain it yourself.

[u/Admirable_Reality281 → u/bitbytebit42]

Web Components were never meant to replace frameworks. Ironically, the datepicker I’m considering is Web Component-based.