Live data from Hacker News

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

momentjs.com

21–30 of 266 posts

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

#21
post #14

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…

> 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” In this case, the reason why Moment.js is "dead" and not "done" is because it has fundamental flaws in its design: Mutable objects + huge bundle size which doesn't work well with tree-shaking.

Huge bundle sizes and mutability are JS design flaws.

Until very recently it was impossible to make objects immutable in JS. Even now its really only done using third party libraries.

Huge bundle size is only a problem because tree shaking is done on a "module" level. Most languages are static enough that it's called dead code elimination and doesn't need to use tree pruning. You can tell statically that the code is not used.

Moment isn't compatible with modern workarounds which I don't blame it for. The way JS is, immutability and true dead code elimination will probably show up as built in features in a few years and make all this obsolete again

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

#22

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…

To some extent I don't think this means moment is dead although I don't assume a lot of new developers will be choosing it for their projects. Even starting a few years back I replaced it with Luxon and haven't looked back.

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

#23
post #14

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…

> 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” In this case, the reason why Moment.js is "dead" and not "done" is because it has fundamental flaws in its design: Mutable objects + huge bundle size which doesn't work well with tree-shaking.

Just because you disagree with a design decision doesn't change the done/dead debate. It's done, because its maintainers have agreed the project has gone as far as it needs to go, and its current iteration is stable. You (as always) can choose not to use a project you do not agree with; that has no bearing on the project's status.

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

#25
post #17

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…

MomentJS may be an exception but any JavaScript project with a large number of node_modules or testing/distribution pipelines pinned to build systems like gulp or webpack are highly likely to break from year to year as they become incompatible with a version of node or one of the dependencies is taken over by a potentially malicious actor. For this reason any JavaScript ecosystem based project must receive increased…

A significant issue though is that timezones change. For example the EU is ditching daylight savings time in 2021[1].

So actually there are many libraries and tools that could be done and just work forever, timezone stuff is much more dynamic than I'd ever realised.

FWIW I loved moment and made the move this year to date-fns[2] as I trusted browser availablity of the prerequisites enough to finally switch, and I do like working with it, but its focus on lightweight makes it less "magic" than Moment.

- [1] https://www.insider.com/europe-to-get-rid-of-daylight-saving...

- [2] https://date-fns.org/

(edit formatting)

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

#26
Hell yes. I wish more projects would open to the idea of “moving over” when they’re done. Most developers have this idea that if they add an “alternatives” section to their Readme they’re losing something.

Moment’s developers realized that their job is done and that there are potentially better solutions now.

How refreshing is that?

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

#27
post #14

Earlier quoted context omitted.

> 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” In this case, the reason why Moment.js is "dead" and not "done" is because it has fundamental flaws in its design: Mutable objects + huge bundle size which doesn't work well with tree-shaking.

Huge bundle sizes and mutability are JS design flaws. Until very recently it was impossible to make objects immutable in JS. Even now its really only done using third party libraries. Huge bundle size is only a problem because tree shaking is done on a "module" level. Most languages are static enough that it's called dead code elimination and doesn't need to use tree pruning. You can tell statically that the code is…

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

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

#28
post #11

This might be an even better reason to use it. It's purely in bug fixing and maintenance mode at this point. Which means for projects it will probably be super stable and won't change too much. This by itself is really valuable.

I don't see this tiny upside outweighing the many deal-breaking downsides of moment.js. Especially since Luxon is already incredibly stable.

Besides, this announcement probably makes moment.js less stable than it was previously, since the web will continue to change but it won't change with it.

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

#30
post #14

Earlier quoted context omitted.

> 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” In this case, the reason why Moment.js is "dead" and not "done" is because it has fundamental flaws in its design: Mutable objects + huge bundle size which doesn't work well with tree-shaking.

Huge bundle sizes and mutability are JS design flaws. Until very recently it was impossible to make objects immutable in JS. Even now its really only done using third party libraries. Huge bundle size is only a problem because tree shaking is done on a "module" level. Most languages are static enough that it's called dead code elimination and doesn't need to use tree pruning. You can tell statically that the code is…

I don't think mutability is JS design flaw. It was designed for manipulating UI - computer screen, which is mutable. If it was designed for printing (an immutable interface) i'd agree with you. Bigger problem is that people started using javascript for server side, for which is (was) totally unfit for.
Post reply on HN