Hacker News new | comments | show | ask | jobs | submit login
Show HN: Fast 2kB date library alternative to Moment.js with the same API (github.com)
122 points by iamkun 6 months ago | hide | past | web | favorite | 39 comments



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?


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.


Time zone is the main reason to use moment.js. it's like saying you jave a jquery competitor, but you removed ajax and events support. But hey you can still do dom manipulation.


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.


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

https://github.com/tc39/proposal-temporal


Worth pointing out that the Moment.js eng team also built 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


"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.


Discovered Luxon the other day, and while I mostly write Node so I can't speak to its lightness, I really appreciate the way it works. Much nicer API.


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/ which reuses the native Datetime object and is architected with ES6 modules for tree-shaking so you can include only what you need.


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


Other good options to explore:

Date-FNs: https://date-fns.org/

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

Both have strong support for ES6 tree-shaking.


Also fecha.js for formatting: https://github.com/taylorhakes/fecha


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.


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.


For JS usage, I am actually - on the whole - a big fan of moment.

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.


Most notably relative time formats[1] are missing.

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


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

2. https://jsperf.com/human-date-vs-moment-js-relative-time/1

3. http://jsbin.com/cahokafuci/edit?html,js,console


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.


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


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


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?


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.


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


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.


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...


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.


I hope it's immutable!


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


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


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.


Normally it wouldn't be, but in cases where the submission is otherwise good and the community is having a good discussion, we sometimes post a comment and leave it at that.


weird. now I am wondering:

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?


The same reason you might buy Github stars: people are more likely to use/share/respect something that's been socially vetted.

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.


A bad actor could have commit and publish access, and is looking to make the library more popular before committing and publishing some kind of attack.


oh boy, I ve been banned for all kinds of reasons here and there. but booster accounts... I mean why can't bots have human rights? lol

zazzaz 6 months ago [flagged]

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


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.


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.


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




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: