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

211–220 of 266 posts

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

#211

Post by sebazzz »

Ambroos wrote: post #108
Semaphor wrote: post #65

Earlier quoted context omitted.

The whole Intl namespace is a godsend.

Until you start seeing times like 24:45 in your app. The spec has some really strange behaviour in it that defaults to "1-24"-hour time instead of the common "0-23" if you specify hour12: false. Only Chrome seems to have actually implemented the spec this strictly, they don't want to change it: https://bugs.chromium.org/p/chromium/issues/detail?id=104579...

It isn't the pure javascript feeling without a few cross-browser quirks.

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

#212

Post by superfrank »

firebaze wrote: post #200

Our favorite bug for newbies using moment.js: const somedate = moment(...somedate...); const oneMonthLater = somedate.add(1, 'M'); const dateToCheck = ...; // between somedate and somedate + 1 month if (dateToCheck.isBetween(somedate, oneMonthLater)) { // do something } The puzzled looks when the tests fail. I'll miss that. Seriously.

Just to confirm that I remember Moment correctly, the code in the if statement never runs because .add mutates somedate, so somedate and oneMonthLater are the same, correct?

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

#213

Post by dragonwriter »

DougBTX wrote: post #115
scoopertrooper wrote: post #106

Earlier quoted context omitted.

So your projects have no dependencies? You just write everything from scratch? Your code is perfect the first time you write it? I'm utterly confused by this comment.

A project can't be more stable than its dependencies and tooling, but that doesn't mean that the only way to be stable is to have no dependencies. Some programming languages make guarantees that old code will build in new versions (eg, ISO C even refuses to introduce new warnings for code that would previously build without warnings), while others will introduce backwards incompatible changes in minor releases. How m…

> A project can't be more stable than its dependencies

Sure it can; there's no reason a project has to take every upstream update, if, for instance, it vendors dependencies, or otherwise doesn't directly depend on the remotely maintained source.

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

#214

Post by dragonwriter »

scoopertrooper wrote: post #125
DougBTX wrote: post #115

Earlier quoted context omitted.

A project can't be more stable than its dependencies and tooling, but that doesn't mean that the only way to be stable is to have no dependencies. Some programming languages make guarantees that old code will build in new versions (eg, ISO C even refuses to introduce new warnings for code that would previously build without warnings), while others will introduce backwards incompatible changes in minor releases. How m…

Library and framework maintainers will eventually stop updating previous major versions. So you manage to tread water just fine till your major version reaches EOL, then you've found yourself in the position of having to change over to a completely new API on a schedule set by the maintainer of the dependency.

> Library and framework maintainers will eventually stop updating previous major versions.

And, if it's open source and it's easier than switching to a new dependency, you can just adopt maintenance of the dependency—not necessarily generally, just enough to address any bugs induced in or evolution in needs for the project(s) you have that depend on it.

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

#215

Post by dragonwriter »

lfischer wrote: post #132
scoopertrooper wrote: post #106

Earlier quoted context omitted.

So your projects have no dependencies? You just write everything from scratch? Your code is perfect the first time you write it? I'm utterly confused by this comment.

Imagine a CSV parser written in Java. I can imagine quite well that it would rarely need updates, as CSV does not evolve and I find it reasonable to write such code with no external dependencies except the Java standard library, which almost never breaks backward compatibility.

> Imagine a CSV parser written in Java. I can imagine quite well that it would rarely need updates, as CSV does not evolve

CSV, which isn't even a standard and the closest thing to a standard is a description of the breadth of different behaviors seen under the name at a particular point in time with some notes about their relative frequencies and respective practical issues, does, in fact, evolve.

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

#216

Post by bbotond »

glintik wrote: post #73
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…

"moment.js: Mutable. Thank you, next." Mutable is not bad, buddy. You live in mutable world.

Mutability, in this case, can be pretty unexpected.

Just like you don't expect the expression a + 5 to change the value of a but to return a new number, most people don't expect myDate.add(5, 'days') to change the value of myDate.

I know that moment values are mutable, yet I often forget it while writing code and make dangerous mistakes because of how unnatural it is to see an arithmetic expression that is not immutable.

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

#217

Post by xwdv »

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…

Done is fine. But Done is the first step to Dead.

Times change, and when open source software doesn't change with the times it becomes vulnerable for some newer, shinier, more intuitive thing to pop up and take over. Software simply isn't going to reach some "Done" state and then have people using it for 100 years with no changes. Pretty soon, no one uses the project that is "Done" anymore, because it's old and does things the old ways, and not long after that, it's "Dead".

Time to die.

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

#218

Post by elliekelly »

mekkkkkk wrote: post #84
ShorsHammer wrote: post #79

Earlier quoted context omitted.

Does clearly-stated and overt semantic versioning not solve this?

How so? Semantic versioning shows no indication of project status. It's just a set of numbers that defines the impact of changes since the last set of numbers.

I'm pretty sure SemVer allows for alpha and beta releases. Why not extend that versioning convention to include an omega release as well? (Is "omega release" even a thing? I'm imagining it as the last stable release - it will be maintained but no new features will be added. Which I think I would consider different from EOL.)

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

#219

Post by folmar »

dragonwriter wrote: post #215
lfischer wrote: post #132

Earlier quoted context omitted.

Imagine a CSV parser written in Java. I can imagine quite well that it would rarely need updates, as CSV does not evolve and I find it reasonable to write such code with no external dependencies except the Java standard library, which almost never breaks backward compatibility.

> Imagine a CSV parser written in Java. I can imagine quite well that it would rarely need updates, as CSV does not evolve CSV, which isn't even a standard and the closest thing to a standard is a description of the breadth of different behaviors seen under the name at a particular point in time with some notes about their relative frequencies and respective practical issues, does, in fact, evolve.

Depending on your needs RFC 4180 might be your CSV standard.

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

#220

Post by balls187 »

superfrank wrote: post #212
firebaze wrote: post #200

Our favorite bug for newbies using moment.js: const somedate = moment(...somedate...); const oneMonthLater = somedate.add(1, 'M'); const dateToCheck = ...; // between somedate and somedate + 1 month if (dateToCheck.isBetween(somedate, oneMonthLater)) { // do something } The puzzled looks when the tests fail. I'll miss that. Seriously.

Just to confirm that I remember Moment correctly, the code in the if statement never runs because .add mutates somedate, so somedate and oneMonthLater are the same, correct?

Yes, `somedate` is mutable.
Post reply on HN