Day.js – Fast 2kB alternative to Moment.js with the same modern API
If you are considering switching to a (different) date library, I would suggest to hold off. ECMAScript is about to introduce a native date and time API that is much better than the current Date functionality. It may also make the need for a third-party date library obsolete (as long as you do not need to parse custom date formats).
- https://github.com/tc39/proposal-temporal
- https://github.com/tc39/proposal-temporal#polyfills
- https://tc39.es/proposal-temporal/
- https://tc39.es/proposal-temporal/docs/index.html
- https://github.com/tc39/proposal-temporal/issues/1450
- https://tc39.es/proposal-temporal/docs/parse-draft.html
As far as I know, issue #1450 is the last remaining blocker for the standardization. I'd assume that this will be resolved in the next months. So Temporal will likely be officially released with ECMAScript 2023, but browser vendors and other implementors will start shipping it before the offical release.
> Moment.js with the same modern API
Moment.js objects are mutable [0], and this library's objects are ... immutable.
I have not used moment.js or other date libraries in a long while. But how does this compare to Luxon? (https://moment.github.io/luxon/#/why)
Day.js seems cool, but when I was evaluating these libraries I noticed the ‘startOf’ function doesn’t take a time zone argument… I guess it just presumes you want the system offset?
https://day.js.org/docs/en/manipulate/start-of
I can’t trust a date/time library that’s blasé about time zones at the API level. Undefined behavior around time zones causes a steady stream of off-by-one bugs in your codebase if you’re not vigilant.
Why is this good/better compared to date-fns?
I never use any date library and I never had a problem with it.
I just use what the native Date() object offers.
Other devs always say "Just wait, one day it will fall on your feet".
But this has been going on for many years, in which my software has served millions of users and nothing ever fell on my feet. I think the complexity of a library like this (423 files, 1433 commits, 53004 lines of code) would have created more problems during this time. So not using one is a net positive.
Any minimal code example of what is prone to break without a date library and how this date library is supposed to prevent it?
What is the obsession with xKB? With tracking, analytics, monitoring and gazillion other scripts, I'd wager that an average webpage size is probably closer to 1MB.
Checked some of the popular sites (caching enabled)-
Amazon.com - 4.8MB
Google.com - 2.5MB
If you need timezone support, be careful, there’s a few critical timezones bugs you can find in GitHub issues that made us switch to Luxon.
I love dayjs! I’ve been using it for the past 4 years in most projects and I have no issue at all. Current company used moment, but recently they also changed to dayjs as well. Love to see the author being very active in github as well :)
Moment.js gets a lot smaller if you apply the same trick Day.js is using here, that is, to just load the locales that you need.
See https://medium.com/rise-engineering/how-we-managed-to-shed-3... for an example. Takes Moment.js from 364KB to 59KB. Still much larger than 2KB, but perhaps small enough.
I'm a fan of Moment... it's served me well for most of a decade, including in some really heavy scheduling/timetable applications. The size of importing Moment is really fairly negligible for a full-scale single page app. The one drawback I find with it is the overhead for creating new Moment objects. You never want to, for instance, run through a for/next loop of SQL dates and convert each into a Moment for sorting. If you must have them as Moments, you really need to cache once and compare later. Usually in my code I even avoid writing `new Moment()` within a control structure that only needs the current day or hour, and I set up an interval to run permanently in a utility class to just cache a recent Moment every 10 seconds or so, for comparison wherever else it's needed in the code.
That's the only real issue for me with Moment and I'm not sure this lib would change that... especially if I need to extend it for various uses every time it's called, which for me would be a rather large drawback that would end up polluting lots of modules with extra lines of code for specific date comparison purposes.
It's embarrassing we never evolved the date api which comes with the browser.
That said, I tend to err on writing a custom function / importing only a custom function over importing an entire library just to run a 2 lines function.
not bad, a quick skim of the repo shows that the locale file sizes might be 50% or less as compared to Moment.js - approx. 1 kB per locale from day compared to 2+ kB per locale from moment
Interesting to see the support for luxon. When moment was announced as a done project they recommend a number of alternatives; one of those was luxon. Date-fns was also in there, and given I was already using it I carried on my merry way! I'm curious what the difference between luxon and date-fns is. Npm trends are interesting
Luxon has been my go to lib for date and time but will try this out.
Btw most libraries (luxon, dayjs) that use Intl api to do timezone manipulation in chrome and nodejs and are excruciatingly slow. So slow that pods would get restarted because they would fail to respond to health check while doing the timezone manipulation, on moderate traffic (50req/s). I still use moment-timezone because it comes with it's own tzdata and it's 100x faster.
Not sure if this is a gotcha, but how does one make a JS date object (across Safari, FF and Chrome) that refers to the same day of the year regardless of timezone?
Very awesome to see Moment JS have a legacy. What a great api
I highly recommend date-fns instead as that uses the native Date object. It doesn’t use a wrapper.
There's an error in the documentation. What's the standard procedure to submit a pull request or bug report here? The docs subdirectory just links to the website and I couldn't find them in the gh-pages branch, either.
I prefer date-fns https://date-fns.org
It’s functional and tree shakable!
I’ll have to check out Day.js next time though.
Pet peeve: would be nice if they offered a Chapter View or Single Page View or PDF of their documentation.
undefined
I'd love to see how different this is from moment.js
you can find small alternative with https://bundlephobia.com/
Hopefully there will be Night.js to complement it.
i’ve definitely enjoyed using this but it would be nice it there was better TS support for some of the extensions
>Fast
Where are the benchmarks?