
Show HN: Fast 2kB date library alternative to Moment.js with the same API - iamkun
https://github.com/xx45/dayjs
======
always_good
If you're going to compare yourself to an existing library, you really need to
explain the trade-offs you made in comparison.

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?

~~~
tbrock
Time-zone support is one.

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.

~~~
RandomBK
Regarding your CDN suggestion, that is already effectively the case if the
library is hosted on a CDN. Creating a hybrid baked-in/CDN solution is only
going to complicate the situation with little to no improvement.

However, it would be great if more datetime functionality can be baked into
the standard library.

~~~
scottmf
There’s a stage 1 proposal for better date/time features

[https://github.com/tc39/proposal-temporal](https://github.com/tc39/proposal-
temporal)

------
paulirish
Worth pointing out that the Moment.js eng team also built
[https://moment.github.io/luxon/](https://moment.github.io/luxon/) as a
faster, lighter, more modern alternative to their LTS project.
[https://moment.github.io/luxon/docs/manual/why.html](https://moment.github.io/luxon/docs/manual/why.html)

~~~
abritinthebay
"lighter"... not.. by much.

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.

------
manigandham
The inevitable cycle of these datetime libraries: Moment.js was originally a
lightweight date parsing system that got big because of all the locales and
extended functionality. If you need it, it's the only one that does it well
and there's no easy way to make that smaller.

A common lighter alternative though is date-fns: [https://date-
fns.org/](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.

~~~
kitten_mittens_
If you’re using a bundler, it’s not that hard to remove extra locales.
Functionality on the other hand...

------
WorldMaker
Other good options to explore:

Date-FNs: [https://date-fns.org/](https://date-fns.org/)

Luxon (from the Moment team):
[https://moment.github.io/luxon/](https://moment.github.io/luxon/)

Both have strong support for ES6 tree-shaking.

~~~
gedy
Also fecha.js for formatting:
[https://github.com/taylorhakes/fecha](https://github.com/taylorhakes/fecha)

------
mherrmann
I think you should have made a non-compatible API. MomentJS's is pretty
horrible in my opinion. Why on earth are the Moment objects mutable? Unless
there's a good reason (performance?) it's just a pain to have to call weird
setters all the time and have to worry about whether you're not accidentally
changing an object passed as a function parameter. Python's datetime gets this
right in my opinion.

~~~
thefifthsetpin
They did make a non-compatible API, and it is immutable. The HN title is just
wrong. The actual project was just trying to explain that their API would be
familiar to moment js users. They didn't mean to imply stringent API
compatibility.

------
redka
Most notably relative time formats[1] are missing.

[1]
[https://momentjs.com/docs/#/displaying/fromnow/](https://momentjs.com/docs/#/displaying/fromnow/)

~~~
anonfunction
I built a library called human-date[1] that does this as a replacement for
moment.js. It is ~30x faster according to this benchmark[2]. The API is not
the same but very easy to use[3].

1\. [https://github.com/montanaflynn/human-
date](https://github.com/montanaflynn/human-date)

2\. [https://jsperf.com/human-date-vs-moment-js-relative-
time/1](https://jsperf.com/human-date-vs-moment-js-relative-time/1)

3\.
[http://jsbin.com/cahokafuci/edit?html,js,console](http://jsbin.com/cahokafuci/edit?html,js,console)

------
maxnoe
I see no mention of timezones! Please don't claim you have the same api if you
and say you delivered in in 2kB if you removed the hardest and most useful
part.

------
notyourday
Does this library pass the semi-annual demonstration that one should really
not use a new datetime library?

------
donatj
I'd like to request adding `.d.ts` files so us Typescript lovers can make easy
use of it.

------
yitchelle
Fast - does that mean it's time keeping is running ahead of the actual time.
:-)

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?

------
boubiyeah
moment doesn't have a modern API. It's a bloated, non modular and mutable
mess. It's also pretty much abandonned. The cycle continues :)

PS: I use date-fns, which is the flavour of the day.

~~~
modzu
^ yes anyone using moment do not forget to clone() or you are in for surprises
:)

------
smhg
When I see things like

    
    
      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.

~~~
underwater
I ended up writing a simple date library that used objects with year, month
and day keys to represent dates. It made it much easier to define operations
like “the same day next month” in a way that didn’t break down on edge cases,
and using plain objects worked much more nicely with Redux, et al.
[https://github.com/joshduck/simple-
day/blob/master/src/Simpl...](https://github.com/joshduck/simple-
day/blob/master/src/SimpleDay.js)

------
kennydude
You can reduce most of Moment's size by stripping half the languages it comes
with. It has a lot of stuff there, for a reason.

------
jeremija
I hope it's immutable!

------
dang
This thread shows signs of having been upvoted and commented on by booster
accounts. That's against the rules and we ban accounts and sites that do that,
so please don't do that!

[https://news.ycombinator.com/newsfaq.html](https://news.ycombinator.com/newsfaq.html)

~~~
johnfn
How come it’s still allowed on the front page in that case?

~~~
always_good
I suppose there's the dilemma of being able to nuke your competitors by using
a voting ring on their own posts.

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.

------
zazzaz
You saved my day!!! Tired of 60kb+ moment.js, especially in mobile site.

~~~
iampims
I’m curious how the 58kb savings are achieved. Which functionality has not
been implemented? I couldn’t find a list that highlights the differences
between the two libraries.

~~~
dawnerd
Came to ask the same. If you’re gonna say it’s mostly compatible tell me
what’s not going to work. Is it all the time zone data? All the localization
stuff?

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.

~~~
TheRealPomax
Therein lies the trick. Calling yourself "API compatible" in no way implies
actual compatibility.

