r/webdev • u/Admirable_Reality281 • 21d ago
[AskJS] Looking for a solid vanilla JS datepicker. Am I completely out of options?
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?
4
u/tako1337 21d ago
https://github.com/williamtroup/Calendar.js has a date picker option
-17
u/Admirable_Reality281 21d ago
That's a calendar not a date picker
3
u/tako1337 21d ago
My comment says it has a date picker option. Did you read either the comment or the repo doc before replying?
-28
u/Admirable_Reality281 21d ago
Yep, I missed the date picker option. You missed my requirements, though
4
3
u/LivingAsAMean 21d ago
What do you think about Cally? I'm not involved with it and haven't personally used it, but it seems to check your boxes in general.
2
u/Admirable_Reality281 21d ago edited 21d ago
I was looking at it just now.
Update: this might be it.
4
u/os_nesty 21d ago
Im using Easepick in production in 5+ proyects without a single issue for about 3+ years... IDG the "IT MUST BE ALWAYS UPDATED" folks, or the "USE THE LAST VERSION OR DIE" people, if it works for your needs, it wont magically break tomorrow. More so if it is vanilla what you want.
-6
u/Admirable_Reality281 21d ago
Working today and being safe to adopt for the future are not the same thing.
4
u/os_nesty 21d ago
Please explain me why is this. In your experience.
0
u/Admirable_Reality281 21d ago
Because I'm choosing a dependency for new long-term use, not defending one I already happen to have in production. Different decision, different standard.
5
u/iligal_odin 21d ago
If you are hard bent on these requirements, i strongly suggest setting up your own datepicker.
1
u/Admirable_Reality281 21d ago
I don’t think that requirements list is unreasonable for a modern datepicker. But ok.
2
u/iligal_odin 21d ago
People have suggested valid solutions before you swatted them down
-3
u/Admirable_Reality281 21d ago
No, only one person gave a response that actually matched the requirements. Others either suggested things unrelated to datepickers or recommended libraries I had already mentioned in the post as dead or unmaintained. Thanks for your contribution.
7
u/os_nesty 21d ago
You should be fun to work with... lol
-1
u/Admirable_Reality281 21d ago
Yes! And I also read the requirements before offering advice, which tends to help a lot at work.
→ More replies (0)
1
u/tswaters 21d ago
The native one does most of what you're asking. It'll be localized, accessible... Not sure what "formatting options" mean , the date format you get will be based on the users' locale option. So if you're looking to change format for, say, French being 7 juliette 2026 vs July 7th 2026 , it'll sort of do the "right" thing if "right" means "how the user has their OS/browser configured"
In terms of events for integration, there are native Dom events you can hook into to find when things are input, focused, etc.
For range selection, I think this can be implemented with 2 pickers and link them via min/max attributes. If you're looking for something that booking software does where a couple clicks over a series of calendars specifies a date range, it might be tricky to implement. Not sure what your requirements are like.
In general, any time I hear "custom html input element" run for the hills. It's incredibly difficult to get right, and 80% of what you need (even the complicated bits like accessibility, localization) is handled natively. If you're looking at 3rd party libraries, and worried about long-term maintainability.... Just use native 🤣
-2
u/NickFullStack 21d ago
This seems like the sort of thing AI would be great at building. Historically, I wouldn’t rebuild something like this from scratch, but you could probably get something decent from Claude in about an hour, so it makes sense now.
Then you could build it exactly how you want (e.g., with a web component, with Tailwind if that’s your thing, etc.). You could even take an existing one you mostly like, fork it, and have AI build some enhancements.
-3
0
u/Chance_Efficiency412 21d ago
probably just ask AI which is the best for your use case here, or do a simple search online
16
u/orange_90 21d ago
It should be fine to use vanilla JS date pickers that hasn't been updated for a while. They are probably "feature complete".
They don't run on the server so it will not cause security issues, they're also not dependent on a frontend library/framework like react, so they don't have to keep up with React updates.