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.
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?
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.
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.
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].
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.
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?
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...
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!
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.
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.
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.
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.
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?