Show HN: Fast 2kB date library alternative to Moment.js with the same API
github.com
github.com
Even if all of the corners you cut were 58kb of code bloat, that would be exactly the information we'd want to know.
So, what exactly was left on the cutting room floor? For example, I can see there are no localization files. What else?
The thing i don’t get is why for libraries like moment don’t we host the tz data on a cdn and have the library just request the cached copy at runtime? Or better yet, have the browser supply it as part of the browser api.
We are boiling the oceans compiling this into our JS.
However, it would be great if more datetime functionality can be baked into the standard library.
Timezones and locales is a HUGE drain on browser code even with Luxon. Date-fns replace Moment in a much nicer, easily tree-shaken, format but Locales?
... urrrgh.
A common lighter alternative though is date-fns: https://date-fns.org/ which reuses the native Datetime object and is architected with ES6 modules for tree-shaking so you can include only what you need.
Date-FNs: https://date-fns.org/
Luxon (from the Moment team): https://moment.github.io/luxon/
Both have strong support for ES6 tree-shaking.
However, I agree with you that the mutability of its core object instances is odd. Would also like to know why this design choice was made.
1. https://github.com/montanaflynn/human-date
2. https://jsperf.com/human-date-vs-moment-js-relative-time/1
Joking aside, when I see something advertised as "Fast" against the incumbent, I would expect to see some benchmarked data to back that claim. Do you have any?
PS: I use date-fns, which is the flavour of the day.
dayjs().diff(dayjs(), 'years');
I get an uncomfortable feeling. That's an awkward question to answer (except in some informal approximation contexts maybe).I see a part of the milliseconds to X (years in this case) conversion code was copied from moment.
At some point (still?) moment defined that for some calculations/conversions a month lasts 30 days. Needless to say this gives you all kinds of weird outcomes.
Ideally voting ring noise can be detected and filtered out, but it's probably not worth anyone's time building that sort of system unless HN had a real problem with it. And this is the first time I've seen a @dang post on it in quite some time.
Or maybe they already have it but a voting ring still gives enough juice to be useful.
If I had a voting ring or set of HN bots, why would I use them to upvote something so benign as an open source date library on github?
Open source projects are in a competitive environment and benefit from marketing tactics just like anything else.
And a project that people use certainly confers value on its creator, even if it's just a smile on their face. But it can be leveraged for other benefits like clout in the ecosystem.
As an extreme example of what you can do with a popular open source project, consider https://www.patreon.com/evanyou.
Edit: does look like it’s missing the locals as there’s an issue open for it. That pretty much explains the savings.
It’s also missing the extended date parsing which makes moment really shine.
Ok so more looking into it and it’s actually missing a lot. A bit unfair to say it’s mostly compatible all the actual complex stuff you’d want moment for seems missing.