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

171–180 of 266 posts

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

#171

Post by duxup »

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…

> So that project maintainers didn’t need to write two page apologies

They don't need to write me an apology, but just a notice like this one is very nice so I can be sure what is up.

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

#172

Post by rspeele »

The longer I code the more I value stability. That is not to say that stuff like immutability doesn't impress me -- I certainly do prefer an immutable data type for things like dates, strings, vectors, etc.

But as long as the API doesn't completely suck, that stuff is worth less to me than stability. Updating libraries, especially in the world of JS, is always a fingers crossed moment hoping nothing will break. As long as there are no security flaws I am happier with no updates than with continual nice-to-have additions and changes to the API -- especially if those nice-to-haves come with opinionated deprecations to the "old and busted" way of doing things.

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

#173

Post by ehsankia »

divbzero wrote: post #37

TIL: Intl.DateTimeFormat [1] has good browser support [2] and allows for nifty tricks like > new Intl.DateTimeFormat('zh', { hour: 'numeric' }).format(new Date) [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... "MDN: Intl.DateTimeFormat" [2]: https://caniuse.com/mdn-javascript_builtins_intl_datetimefor... "Can I Use: Intl.DateTimeFormat"

Not sure if this is a stupid suggestion, but could there be a drop-in replacement for moment which uses Intl and other modern browser APIs, otherwise fetches the full moment.js? Or does MomentJS already do that?

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

#174

Post by michaelanckaert »

PaulStatezny wrote: post #163
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…

> I wish the[re] was a way to fix this attitude. This isn't a universal attitude. Numerous language ecosystems exist where it's completely normal to use dependencies that haven't been updated in a while _because_ they warrant no change. This is a problem with the general attitude of the community of JavaScript developers. And they're too stuck in their JS ecosystem bubble to realize this isn't necessarily "normal" or…

I agree and unfortunately that attitude is spreading beyond the JS community.

A great example is the issue newcomers to Common Lisp face. I don't want to get in specifics regarding the Lisp community here but one common complaint is that only "old libraries" are available and no recent releases.

Side note: Although I'm not sure it initially started in the JS community, it is by far the most affected community. Besides that issue it also suffers from Not Invented Here syndrome.

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

#175

Post by conradfr »

I guess this post motivated me to finally try Luxon (I didn't evaluate the other alternatives) and I migrated the frontend of a side-project from Moment.js.

https://moment.github.io/luxon/docs/manual/moment.html helps getting up to speed.

I was doing mostly basic things and it has been straightforward (note that I don't have tests): https://github.com/conradfr/ProgRadio/commit/d52d9aed219281f...

edit: halved my app.js' size (before gzip).

edit2: Needed a new polyfill for timezones on IE11

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

#177

Post by hn_throwaway_99 »

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…

I disagree. Software can go into 'maintenance mode', that's fine, but there is otherwise no difference between done, abandoned and dead.

For a real example, look at lodash. You could easily argue it's 'done' and that it has better alternatives now, but look what happened: a security bug was discovered, the original author pretty much abandoned it, and it took about a week to figure out how to get a working build while meanwhile many thousands of other projects were failing due to npm audit checks.

The fact is even if nothing really needs to change in your project, the ecosystem around it can change requiring updates to your code.

It's fine to say "This project needs no new features and is in maintenance mode", but otherwise, if you're not willing to deploy new releases, "done", "dead" and "abandoned" all mean exactly the same thing.

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

#178

Post by fendy3002 »

thrownaway954 wrote: post #169

could someone take the time and explain to a moron like me why the mutability of moment is bad? i just don't get it. moment has always been my goto library for dealing with dates in javascript.

Disclaimer: I too use moment in my daily project

Example snippet (CMIIW, it's as I remembered):

    let date1 = moment("2020-01-01");
    let date2 = date1.add(2, "days");
    console.log(date1.format("YYYY-MM-DD")); // 2020-01-03
    date2.add(2, "days");
    console.log(date1.format("YYYY-MM-DD")); // 2020-01-05
Usually the date1.add operation won't change the date1 value, and any operation to date2 won't change date1, but it isn't. It's made worse because people like to return moment object outside function scope, so operation outside can modify the object inside and weird bugs happen.

It's actually a manageable problem IF you know the behavior, and only using moment object reference inside scope, and using immutable objects as parameter / return, such as milliseconds timestamp and js date.

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

#179

Post by brundolf »

jeroenhd wrote: post #158
dmit wrote: post #52

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 mine…

Can you explain why you find mutability to be a showstopper? Is this a front end developer thing? I like my consts and all where relevant, but I don't see why mutability is such a problem. Javascript is an imperative language where almost everything more complicated than a number is mutable. I see the lack of creating copies of objects with every operation as a benefit because of the RAM and CPU cycles it saves. Is i…

Treating it as a dealbreaker seems a bit strong, but immutability has become very popular among JS devs recently. JS has pretty respectable functional-programming features, libraries like Immutable.js have cropped up to add memory-saving immutable data structures, and major frameworks like React and Redux play much more naturally with immutable data than mutable. The overall goal is scalability through reduction of side-effects. Whether the trade off is worth it or not, it's absolutely the fashion right now.

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

#180

Post by momokoko »

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…

The issue is that this model of opensource is different than the Linux distribution model of opensource.

In the Linux distribution model, Debian, Red Hat, etc maintain older libraries in maintenance mode. Patching them for security or other less glamorous fixes and adjustments.

In the Github, NPM model of opensource, the original author also controls the default means of distribution. There is not 3rd party like Debian in the middle to maintain it when the original authors leave. So many thousands of projects will still point to an abandoned distribution channel as opposed to simply an abandoned project.

There are likely solutions, and this is not to say that the second model is better or worse. It is only to describe that it is not as simple as a project being considered "done".

Post reply on HN