Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We now consider Moment.js to be a legacy project in maintenance mode

momentjs.com

Post reply on HN
Print view View original

51–60 of 266 posts

Re: We now consider Moment.js to be a legacy project in maintenance mode

#51

Post by Ndymium »

throwaway189262 wrote: post #38
kqr wrote: post #27

Earlier quoted context omitted.

> Until very recently it was impossible to make objects immutable in JS. Even now its really only done using third party libraries. There's a big difference between "literally impossible to mutate" (only important in the most security-critical contexts) and "designed around immutability as the default" (which is what is desired in most of the real world.) The former not being possible is not a reason to exclude the l…

With JS, until recently, it was nearly impossible to design immutable API's. Everything takes JSON based objects which have no field accessors. All the objects underneath are just hashmaps with string keys. When all your objects are hashmaps you can't really make fields immutable. Even if you wrote getters, someone can just reassign the function reference. Even if you check your fields in incoming object parameters,…

Object.freeze() has been available since IE 9, Firefox 4, Chrome 6 etc. Not really "recently" in web terms.

Re: We now consider Moment.js to be a legacy project in maintenance mode

#52

Post by dmit »

Please pardon this drive-by assessment of JS calendar libraries by a casual user.

moment.js: Mutable. Thank you, next.

Luxon: Takes the effort to implement `Interval`, which would be `Range` in any proper language, but somehow avoids providing separate `Date` and `Time` objects.

Day.js: When you kinda like moment.js, but your bundler says it's too fat.

date-fns: The finest of pure, curry-able functions over the minefield that is Javascript's `Date` object.

js-joda: If Javascript didn't have classes already, this project would probably port the entire Java runtime to JS just to replicate them. Likely the most correct handling of date/time stuff available for the browser, but damn, at what cost?

------------

Edit: this turned out way too negative, my bad. All I wanted was a library that offered:

0) Type definitions.

1) Immutable classes of `Date` (year, month, day), `Time` (hour, minute, etc), `DateTime` (the prior two combined), `Instant` (for a certain moment on the global timeline), and `Duration`.

1b) `DateTime` should probably be split into two separate things, one of which is aware of time zones.

2) All the obvious date arithmetic functions - duration between dates, adding/subtracting durations, etc etc.

Re: We now consider Moment.js to be a legacy project in maintenance mode

#54

Post by marci »

sammorrowdrums wrote: post #49
TJSomething wrote: post #33

Earlier quoted context omitted.

The article specifically states that they're going to keep Moment-Timezone up to date. Which is important, because the timezone database has changed approximately 4 times a year for the last 5 years ( https://mm.icann.org/pipermail/tz-announce/ ).

Let's just hope no random country decides to use 100 minutes an hour or something one day.

Like France and China did, once upon a time.

https://en.wikipedia.org/wiki/French_Republican_calendar#Dec...

https://en.wikipedia.org/wiki/Traditional_Chinese_timekeepin...

Re: We now consider Moment.js to be a legacy project in maintenance mode

#55

Post by d--b »

tannhaeuser wrote: post #50

Shouldn't software strive to perfection when done (like, say, LaTeX) rather than being obsolete when not anymore maintained?

As the author says, the library caters to a language that is no longer in use - aka. javascript 2010 - and keeping up with the evolution of javascript would be making breaking changes, which have been accomplished by other projects by now. What would be the point?

Re: We now consider Moment.js to be a legacy project in maintenance mode

#56

Post by nikitaga »

Klonoar wrote: post #41
nikitaga wrote: post #39

Earlier quoted context omitted.

Is this really what a "done" software is? "Should not be used for new projects" is not "done" imo, it's more like "unfixable" and "obsolete". No prejudice at all against Moment.js or its devs, but this is essentially what they're saying. And the purpose and tone of the article does not seem to be an apology at all, but rather simply setting the expectations for future work so that the maintainers don't have to answer…

...but there's nothing to "fix", it works as intended. You might want to do things differently nowadays, is all - that's not on Moment. Re: "obsolete"... jQuery is somewhere laughing, having gone through this already.

> ...but there's nothing to "fix", it works as intended

If there were nothing to fix, they wouldn't be telling people not to start new projects with Moment. They actually do mention a few significant issues that they can't / won't fix in Moment such as bundle size and mutability.

I will concede that perhaps Moment was "done" at some point before, some years back. When it was quite complete, yet was still the best way to do reliably work with timezoned dates in JS. But as Intl support improved, and better designed alternatives grew, it got rather obsolete, and will get more obsolete over time.

jQuery for comparison, while largely obsolete for rich web app development, is still very relevant to ecommerce, website-development-for-hire and other niches, and it will probably stay that way for a long time because it's the right design for those problems. Moment isn't the right design for any problem anymore, unless, as the article says, you need to support old browsers.

Re: We now consider Moment.js to be a legacy project in maintenance mode

#57

Post by spyckie2 »

tannhaeuser wrote: post #50

Shouldn't software strive to perfection when done (like, say, LaTeX) rather than being obsolete when not anymore maintained?

Some software exists to "bridge the gap" for deficiencies in other areas of the software ecosystem. Javascript date api really sucked from 2002-at least 2016 (arguably still does? haven't really followed) and so these libraries come in to close the gap. Similar to JQuery.

Moment can be thought of as an instance (or build) of the iterative development of a strong usable, robust and bug free javascript api for dates. It's just that moment is the major release version that is still extremely popular but is a dead end in terms of design. Eventually the end goal is a solid, community agreed upon standard lib and in between versions (moment in this case) should be obsoleted while also not breaking existing code bases.

But read the attached article, it does a much better job of explaining than I do.

Re: We now consider Moment.js to be a legacy project in maintenance mode

#58

Post by thayne »

jasonkester wrote: post #5

Good for them. Open Source seems to have an irrational fear of done . Done is good. Done should be the goal. But it’s not. Because if you’re not adding new features and pushing code changes every day, your project is abandoned , dead . To quote another thread from two minutes ago: “I’m quite sad to see the end of Moment.js” I wish the was a way to fix this attitude. So that project maintainers didn’t need to write tw…

Not adding new features might mean the project is "done" but not fixing bugs is an indication it is abandoned, and I have yet to find useful software that doesn't have bugs. And note that moment.js will continue to get bugfixes, just not new features.
Post reply on HN