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

151–160 of 266 posts

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

#151

Post by mrw34 »

mfru wrote: post #140
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…

It would seem to be quite easy to do something like: https://img.shields.io/badge/Maintenance-Legacy-success or https://img.shields.io/badge/Maintenance Level-Done-success and have that as a convention. Additionally to being easy to implement, it is literally a 3 second task for maintainers to add something like this into their Readme.

https://www.repostatus.org is a similar idea

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

#152

Post by sheetjs »

jasonkester wrote: post #92
tutfbhuf wrote: post #72

Earlier quoted context omitted.

> One of the problems is that GitHub is full of OSS libraries where the last commit was three years or more ago and you have no idea (without forensically analysing commits, issues, etc.) whether it's because the project is done or because the maintainer(s) lost interest, had other priorities, etc. I don't think there's any at least medium sized project that is considered to be done but not abandoned/legacy and does…

You might benefit from flipping this around and asking yourself why you're not able to ship software that remains shipped without intervention. And why you can't even imagine a world where that would be possible. If you spend some time and effort removing whatever obstacles you have in place that are keeping you from being able to do that, you'll have a lot more free time to spend building new things. For what it's w…

> If you spend some time and effort removing whatever obstacles you have in place that are keeping you from being able to do that

This is literally impossible for many JS libraries. Chromium / NodeJS / other JS environments are themselves constantly changing. Irrespective of the evolving timezone info, the core MomentJS can only be "done" for a particular set of browser versions. Each bug pertaining to dates, like https://bugs.chromium.org/p/v8/issues/detail?id=7863 , is a potential browser/engine version for which Moment needs a fix.

> this world does in fact exist

It only exists for certain proprietary software and SaaS developers because of the hard work of open source developers to keep up with the changing landscape. If everyone adopted your attitude, you would be forced to contend with the true nature of the ecosystem directly.

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

#153

Post by tyingq »

jrochkind1 wrote: post #150
tyingq wrote: post #148

Earlier quoted context omitted.

They seem to not recommend it solely because it doesn't support immutability or tree shaking.

Another important reason mentioned is that it includes heavy-weight internationalization locale files that are not needed in recent browsers -- "for the size alone." I don't know at what point the adjective "solely" stops being appropriate. Those who have been developing it for years and are most familiar with it, and the alternatives, discourage it's use in new projects, although also outline the exceptions that in…

"You are going to take a stand to disagree with them, based on superior understanding?"

Uh, no. I read their list and the two things I cited (from their stated reasons) seemed to be the key drivers.

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

#154

Post by [deleted] »

sheetjs wrote: post #145
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.

CSV is a very bad example. Yes, it is easy to throw together a simple regex to parse simple RFC4180 CSV strings, but Excel is its own black box with a huge number of hacks. For example, en-US excel will automagically parse TRUE and "TRUE" to be the logical value TRUE. The way to get Excel to see a literal string TRUE is to make a formula ="TRUE". Many CSV writers implement this hack specifically assuming files will b…

[deleted]

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

#155

Post by chrisseaton »

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.

Don’t you have to update the project source code at least a few times a year to add new versions of Java to the CI?

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

#156

Post by chasd00 »

throwaway189262 wrote: post #42
hatch_q wrote: post #30

Earlier quoted context omitted.

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.

JS just has a very simple, flawed design. It's still a rather bad language from a design perspective. One of the shortcuts is that all objects are hashmaps. Fully mutable hashmaps with string keys. You can do this: obj.prop = "hi"; obj["prop"] = "bye"; And you set the same field. And you can do that to any object, reassigning any field type. Most languages have static number of fields in an object, or at least static…

javascript gets a lot of heat from folks wishing it was a different language. It's just different, works differently, does things atypical of most languages. You can fight it or learn it.

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

#157

Post by btbuildem »

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…

Precisely! Working with Erlang, I come across libraries that haven't been touched in years. Sometimes that means they're experimental projects that have been abandoned, but more often than not it means the're done. Complete. All bug fixed, all functionality implemented, stable, safe to use and unlikely to change. I'll take that any day over the twitchy, look-away-for-a-second-and-your-build-chain-is-broken JS way of things.

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

#158

Post by jeroenhd »

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 it because the API returns a reference to an object as well as updating said object? That's the API I'd expect, personally; if I want to do an addition of 1 to i, I'd write i += 1 and expect i to have incremented. I don't see why moment.add() should behave differently?

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

#160

Post by turdnagel »

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…

Basically, unexpected behavior. One of the "footguns" is that it's easy to write to a Moment object when you mean to be reading from it. And by the way, you can mutate objects declared with `const` in JS - you just can't reassign them.
Post reply on HN