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

31–40 of 266 posts

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

#31

Post by breakingcups »

tmpz22 wrote: post #17
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…

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…

I think the only reason for a Go 2 would be to introduce breaking changes.

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

#32

Post by abrookewood »

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 also appreciate that they clearly covered: (i) why you shouldn't use this going forward; (ii) why you might continue to anyway; and (ii) what the alternatives are. All in all, a very well handled response.

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

#33

Post by TJSomething »

sammorrowdrums wrote: post #25
tmpz22 wrote: post #17

Earlier quoted context omitted.

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

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

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

#34

Post by dragonwriter »

hatch_q wrote: post #30
throwaway189262 wrote: post #21

Earlier quoted context omitted.

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.

> I don't think mutability is JS design flaw. It was designed for manipulating UI - computer screen, which is mutable.

You don't need, or particularly benefit from, language-level mutability to specify the next state of UI as a function of previous state plus new inputs, which is really the best way to model interactivity.

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

#35

Post by jayflux »

sammorrowdrums wrote: post #25
tmpz22 wrote: post #17

Earlier quoted context omitted.

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

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

I think the parent’s point was that things like security updates still need to happen. So there may be scrutiny if you come across a package and there hasn’t been a change for a couple of years, in the JS ecosystem it would raise red flags for many. Maybe not so much in the Go ecosystem.

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

#36

Post by breakingcups »

sammorrowdrums wrote: post #25
tmpz22 wrote: post #17

Earlier quoted context omitted.

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

Well, they do say: "We will release data updates for Moment-Timezone following IANA time zone database releases."

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

#37

Post by divbzero »

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"

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

#38

Post by throwaway189262 »

kqr wrote: post #27
throwaway189262 wrote: post #21

Earlier quoted context omitted.

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 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, somebody can randomly add more fields that you don't know about. Until recently you couldn't stop people from randomly adding fields to your objects

Nowadays JS supports stuff like freeze thaw which makes it easier

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

#39

Post by nikitaga »

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…

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 the same questions over and over.

Overall, good to see honest documentation of project status.

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

#40

Post by judofyr »

alexbanks wrote: post #23
judofyr wrote: 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.

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.

This isn’t me disagreeing with the design decision, this was their own explanation for why you shouldn’t use Moment.js in the future.

My point was that the reason we’re transitioning away from it is because of technical reason, not because it’s not being updated.

Post reply on HN