
We now consider Moment.js to be a legacy project in maintenance mode - maple3142
https://momentjs.com/docs/#/-project-status/
======
jasonkester
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 two page apologies for finishing their thing.

~~~
bartread
> I wish the was a way to fix this attitude. So that project maintainers
> didn’t need to write two page apologies for finishing their thing.

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.

And you have no idea because they haven't said. They haven't told anyone: it's
just drifted into an unclear state of unmaintained-ness.

I would suggest rather that what the Moment.js team have done here should be
the _norm_ : i.e., clear communication of the situation. That situation, as
here, might be "done", or it might be "the thing's only half finished but we
don't care enough to carry on any more", or something completely different.
These are all good reasons to stop working on something even if they're
potentially frustrating for users. E.g., in the "don't care" scenario, people
have the option to step in and pick up maintenance, fork the project, or
simply not use it.

Doesn't matter: understanding the state of a potential dependency in terms of
maintenance and development is the key factor that will enable people to make
an informed decision about whether to use it or not.

~~~
tutfbhuf
> 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 not receive any commits.

Any non-trivial project that has no commit since the last three years is
abandoned. Even in the case a project is considered to be done/finished, in
order to not abandon it you have to maintain it: fix security issues, update
outdated dependencies, update tooling so that you can still run/compile with
non outdated tools and so on.

~~~
jasonkester
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 worth, this world does in fact exist. And there are lots of us
living in it. Here's hoping you find a way to join us!

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

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

~~~
sheetjs
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 be read back in Excel. So now your parser, if you're
trying to process data like Excel, has to do the same.

So then you discover that this is actually localized! If you set your UI
language to French (France), Excel will treat VRAI and FAUX as booleans while
TRUE and FALSE are treated as literal strings.

What you thought was a simple CSV parser now has to handle localization as
well. So that CSV parser library can roll its own dodgy localization support,
use a tried and true solution, or just choose not to support the feature. Each
choice has its own drawbacks

------
qwertox
A big "Thank you!" to the developers of Moment.js. For the last 8 years or so
it has always been the first library I included in any new JS-project.

I didn't even bother looking for alternatives, so I didn't know about Intl,
Luxon & day.js until today.

The size of the library has always been one of these things where I thought
that the benefits outweigh the costs, and I knew that it wouldn't be like this
forever. To me, this time in the future has come now, and I will switch to
day.js (or Luxon, day.js has its size on its side, but I still need to
compare).

No other library has filled a huge gap in JavaScript like Moment.js did for so
many years.

On a note aside: I wish HTML had a <time>-tag, so we could also settle the
timezone problem in publications like rocket launches or starting times of
keynotes once and for all, where the publisher would use something like <time
tz="Europe/Berlin">2020-09-15 10:26:48</time> and the browser would show it to
the reader in the reader's local timezone.

~~~
yesbabyyes
> On a note aside: I wish HTML had a <time>-tag, so we could also settle the
> timezone problem in publications like rocket launches or starting times of
> keynotes once and for all, where the publisher would use something like
> <time tz="Europe/Berlin">2020-09-15 10:26:48</time> and the browser would
> show it to the reader in the reader's local timezone.

While the browser won't convert it automatically, this is what the HTML
<time>⁰ tag is for. The publisher can use <time
datetime="2020-09-15T10:26:48+2">2020-09-15 10:26:48</time> and include a
script which will read the datetime attribute and convert it to the browser's
local time zone.

⁰ [https://developer.mozilla.org/en-
US/docs/Web/HTML/Element/ti...](https://developer.mozilla.org/en-
US/docs/Web/HTML/Element/time)

------
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)
      < "下午11时"
    

[1]: [https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat) "MDN:
Intl.DateTimeFormat"

[2]: [https://caniuse.com/mdn-
javascript_builtins_intl_datetimefor...](https://caniuse.com/mdn-
javascript_builtins_intl_datetimeformat_format) "Can I Use:
Intl.DateTimeFormat"

~~~
Semaphor
The whole Intl namespace is a godsend.

~~~
Ambroos
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...](https://bugs.chromium.org/p/chromium/issues/detail?id=1045791)

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

------
ashtonkem
Pretty reasonable stance, all in all. Modern practices have changed, and
favoring not breaking huge chunks of the existing web chasing new usages (that
may already be accomplished well by other libraries) is a reasonable and
professional stance.

------
cjkarr
I don't know if the Moment.js folks are reading this, but THANK YOU for your
commitment to stability and security fixes.

Not all of us are in a situation where we're iterating through the JavaScript
new hotness every couple years and still have significant legacy systems to
maintain and support.

~~~
mj1586
Yes, and you're welcome.

~~~
Roboprog
Thank you.

I pulled in moment.js 5 years ago for a suite of state death and birth
certificate registration apps we are working on.

Due to the amount of “business logic” and small staff size on these, they take
years to roll out. I appreciate that this library will “hold still” for a few
years.

Not all of us are churning out a new e-commerce app every 3 months. E.g. we
replaced the birth certificate app from the 80s, and I expect some version of
our app to be around for at least a decade, albeit with patches for new
browsers on the front end and new Java app servers on the back end.

------
dmit
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<DateTime>` 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 minefield that is
Javascript's `Date` object.

js-joda: If Javascript didn't have classes already, this project would
probably port the entire Java runtime to JS just to replicate them. Likely the
most correct handling of date/time stuff available for the browser, but damn,
at what cost?

\------------

Edit: this turned out way too negative, my bad. All I wanted was a library
that offered:

0) Type definitions.

1) Immutable classes of `Date` (year, month, day), `Time` (hour, minute, etc),
`DateTime` (the prior two combined), `Instant` (for a certain moment on the
global timeline), and `Duration`.

1b) `DateTime` should probably be split into two separate things, one of which
is aware of time zones.

2) All the obvious date arithmetic functions - duration between dates,
adding/subtracting durations, etc etc.

~~~
glintik
"moment.js: Mutable. Thank you, next."

Mutable is not bad, buddy. You live in mutable world.

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

~~~
mywittyname
That's totally expected behavior to me.

I would expect to use something like Moment.addDate(date1, 5, 'days') if I
wanted a new instance of a date to be returned.

Even in javascript-land, methods like that will have side-effects, yet still
return this often just for the sake of method chaining. E.g. date.add(5,
'days).format("%Y-%m-%d") would mutate date, but return the same instance as a
convenience.

------
codegladiator
I wish more software/libraries would mark themselves as "Done" instead of
sending one update every week and a ui refresh every 6 months. Software
engineering is the only field where we keep building a single thing forever
until it becomes a hot mess.

~~~
lazharichir
It really isn't "done" if you tell people they probably should look at
alternatives instead. Sounds more like a soft deprecation to me.

But regardless of semantics, they're being transparent on the project's
status.

~~~
codegladiator
It "done" really, and I can use it today knowing its pros and cons. It would
be "dead" if it had a glaring flaw which couldn't be fixed (which I don't
think mutability is)

Every project has cons and they should embrace it and call it out like this
project did instead of forever targeting a perfect library but nothing is
perfect. It serves its purpose.

I am not sure if they are telling people not use it just because chrome now
says to exclude it or they came up with it independently.

~~~
jayflux
> I am not sure if they are telling people not use it just because chrome now
> says to exclude it or they came up with it independently.

Independent. The maintainers have been recommending other alternatives (like
Luxon) long before Chrome started to advise users on it. Moment has been in
maintenance mode for a while now, this is just an updated confirmation of the
fact, I'm guessing because users kept asking.

~~~
mj1586
We (the Moment maintainers) have been saying it anecdotally for quite some
time. In our respective podcasts, talks, Stack Overflow comments, etc. The
Chrome thing simply encouraged us to make it an official position.

------
ztratar
I am very emotionally confused, as I feel this is a huge step forward for open
source.

More code should be done. More developers just need to know _how_ to quit the
project when the time is right.

This is weird to say, but this is strong leadership.

~~~
oaiey
This is exactly that: Strong, humble, responsible, positive and encouraging
leadership and guidance.

------
CraigJPerry
There can be a surprisingly looooooooooong tail for retired open source stuff.

I retired [https://pypi.org/project/setuptools-
pep8/](https://pypi.org/project/setuptools-pep8/) in 2013 but I still
periodically check in on it since even today it gets 1.5k downloads per month
[https://pypistats.org/packages/setuptools-
pep8](https://pypistats.org/packages/setuptools-pep8)

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

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

------
SenHeng
> _We now generally consider Moment to be a legacy project in maintenance
> mode. It is not dead, but it is indeed done._

~~~
vasachi
Honestly, I wish more js libraries would be that way. I’ve used date-fns in a
small part of an app, so of course when I return to it in several months,
date-fns released a fully incompatible new major version.

~~~
vorticalbox
sure, annoying but they did bump to v2, nothing is stopping you from
continuing to use the older version if it works for you.

------
vasachi
This should be a reason to use moment.js more, not less. It’s done, so it will
not change under you, and you won’t have to rewrite your app.

~~~
jackdh
Could you not just say the same about using LTS versions?

~~~
vasachi
LTS in js-world is usually something like "we support it for about three
months, maybe six".

And if within that period they release an incompatible version, your upgrade
path is worse, beacause your version is too old.

------
rudolph9
I worked extensively with Luxon (a sibling project leveraging modern js
constructs) and found it to be really great! I’m really happy with their
approach of creating an entirely new project to embody the API and new
features you might expect in newer release of moment. It allowed Luxon to
mature for several years without the weight of supporting the legacy api and
avoided confusion within the community. The direction for moment seems
completely reasonable.

[https://moment.github.io/luxon/](https://moment.github.io/luxon/)

~~~
mekster
Dropped using Luxon when I couldn't easily chain like moment.js.

moment.js's API is intuitive and I have been using Dayjs and it has been doing
great.

~~~
rudolph9
When you say chain, do you mean mutate the object as you call methods?

~~~
mekster
Yes.

~~~
rudolph9
For me that was one of the really desirable features.

------
lmiller1990
Been a happy user for years, will continue to be. It works, it's battle
tested, and powers many of my apps just fine.

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

~~~
superfrank
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?

~~~
balls187
Yes, `somedate` is mutable.

------
preet1986
Request came to my mind after reading this. They also became de-facto standard
and then technology improvements made them less relevant.

Main technological advancements that are breaking old monolithic libraries
are, 1\. async/await along with promises 2\. Need for smaller footprint.
Compile to what is needed not this is what I all got. I think, lodash done
that to underscore.js at one time. 3\. Typing support with libraries for
runtime type safety. It's not breaking existing but new typescript, flow, etc
projects opt for newer libraries with typing support.

------
tannhaeuser
Shouldn't software strive to perfection when done (like, say, LaTeX) rather
than being obsolete when not anymore maintained?

~~~
spyckie2
Some software exists to "bridge the gap" for deficiencies in other areas of
the software ecosystem. Javascript date api really sucked from 2002-at least
2016 (arguably still does? haven't really followed) and so these libraries
come in to close the gap. Similar to JQuery.

Moment can be thought of as an instance (or build) of the iterative
development of a strong usable, robust and bug free javascript api for dates.
It's just that moment is the major release version that is still extremely
popular but is a dead end in terms of design. Eventually the end goal is a
solid, community agreed upon standard lib and in between versions (moment in
this case) should be obsoleted while also not breaking existing code bases.

But read the attached article, it does a much better job of explaining than I
do.

------
rayshan
I've been a happy date-fns user for a long time. Recently I started a project
that heavily uses time zone conversions and date-fns-tz falls short. It does
work 99% of the time. It's not maintained by the core devs. The APIs aren't
very intuitive. If I'm starting a new project I'd like to give Luxon a try.

------
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](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...](https://github.com/conradfr/ProgRadio/commit/d52d9aed219281fb6bfc9ba6709372c9de85a8fb)

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

edit2: Needed a new polyfill for timezones on IE11

------
nabaraz
I wish more projects chose stability over features. Every single week, I see
10s of updates (which I don't care about) when installing node packages.

------
jackconsidine
Pretty sad- I've used moment in 50+ projects. That said, it's a very
respectable and thoughtful resolution. Thanks to the moment team.

I'm a big fan of Luxon and have been using it lately.

------
theobeers
I thought there would be more discussion here surrounding the recent update to
Lighthouse, whereby it warns you if you're using Moment.js and suggests
alternatives.

There was some back-and-forth about this on Twitter the other day:

[https://twitter.com/addyosmani/status/1304676118822174721](https://twitter.com/addyosmani/status/1304676118822174721)

~~~
Macha
Got a "This is not available to you", which confused me since I don't even
have a twitter account. Turns out this just the new form of Twitter's "Links
with referrers stop working the first time"

------
the__alchemist
Moment's API makes it a source for subtle bugs. In particular, the conflation
of dates, times, and datetimes as a single structure. This damage goes beyond
the lib, into ones it's influenced, like Arrow in Python.

I'd love to see something like Rust's Chrono ported to JS via WASM. In a TS
project I did a few years ago, I had to roll my own DT lib.

------
davidtranjs
It is not easy to replace moment.js since many libraries like react-dates rely
on momentjs. Hope they have plan to replace it.

~~~
rvanmil
These kind of dependencies is one of the reasons I prefer to avoid react-*
libraries.

It would be nice to see more flexible dependencies in such libs for example
like material-ui pickers [0] which let’s you bring your own date/time lib.

[0] [https://material-ui-pickers.dev/getting-
started/installation](https://material-ui-pickers.dev/getting-
started/installation)

~~~
hajile
All the date libraries have different APIs. The only one that is currently
standard (the Date object) is full of footguns and hard to use.

You either ship without any date support at all or you pick a library and go.
Very little comes close to Moment for i18n and timezone support, so lots of
libraries go with that.

The Temporal proposal to replace Date can't happen fast enough.

------
mumblerino
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?

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

------
gridlockd
I've got the opposite complaint: Don't force your immutability on me.
Immutability is not a virtue, it is a _tradeoff_. I can deal with mutability
far better than the tons of allocations you're doing behind my back.

------
mcv
Someone recently added moment to our project to parse some dates. More
recently, I decided to use it to parse and format some dates somewhere else,
and I immediately got flak for it.

This is, all I need moment for, is simple date.formatAs('DD-MM-YYYY') and
date.parse(date, 'YYYY-MM-DD') stuff. moment is overkill for that, but js Date
somehow doesn't do it. It would probably be quicker to write one myself than
to find a library that does just that.

~~~
bufferoverflow
That's what Intl.DateTimeFormat is for.

    
    
        var options = { year: 'numeric', month: '2-digit', day: '2-digit'};
        console.log(new Intl.DateTimeFormat('te-IN', options).format(new Date()));
        // outputs 16-09-2020

~~~
mcv
Not as far as I can tell. It just formats it according to a locale, not
according to a format string. SimpleDateFormat for javascript[0] looks more
like what I need. Locales are exactly the thing I don't need.

[0]
[https://github.com/noahcooper/SimpleDateFormatJS](https://github.com/noahcooper/SimpleDateFormatJS)

~~~
bufferoverflow
Why use a whole freaking library instead of just writing a one-line function?

~~~
mcv
Because I'd have to write a lot of variations of that one-line function to
handle different date format variations from various systems.

------
azernik
I'll consider this my yearly reminder to check my user share on iOS Safari;
once I have no version 10 users, off to Luxon it is.

So long, moment, and thanks for all the fish!

------
danellis
Protocol dictates they now delete it from NPM without warning.

~~~
Cthulhu_
I know NPM and/or Yarn now shows warnings on install, some libraries flag up
as being obsolete or unmaintained (in the form of a message from the
developer); I hope Moment sets that up as well, and makes sure they add big
warnings on the website as well.

I too stuck with Moment for longer than I should have because of inertia and
familiarity.

------
gandutraveler
I see that immutability is major concern for backward incompatibility, however
over years I've become so much used to moment js that I wish I can still use
their API's. Can someone explain why is it so hard to release a completely new
version that isn't backward compatible? We could as well use different naming
so that it doesn't conflict with last versions. moment3().now()

~~~
bettem
That’s effective what day.js is. Its effectively an identical api and is
incredibly lightweight in comparison with opt-in extensions.

------
balls187
Time and Dates are incredibly hard, so thank you Moment.js team for the
painkillers you have provided to JS community.

I found myself always starting with native Date library, then eventually
adding Moment.js when we needed to robustly support timezones and timezone
conversions.

Nothing like receiving a text at 5am pacific, because the system is calibrated
to Eastern Timezone work hours.

------
fendy3002
I've used moment in many of my projects. Though they're able to be migrated
into new libraries, I haven't found alternative that use moment.js's date
format notation. Are there any alternative that use it?

Many UI libraries use that format so using different libraries with different
notation will be harder to manage for me.

~~~
mj1586
Moment made up its tokens as it went along. Some match other languages,
several do not.

The only real "standard" in this area is LDML tokens, which are part of CLDR.
Luxon follows those.

------
jmull3n
It's been common knowledge in the front end development community for quite a
while now to avoid Moment.js due to it's file size. Glad to see the
maintainers agree. I'm thankful for the work they did in progressing date/time
management libraries as a whole, but just like jQuery there's now better
alternatives.

------
radicalriddler
End of an era for JS developers. It's been an incredibly useful library. The
amount of projects I've used Moment.JS on... And I'll be somewhat glad to
never use it again. Javascript really needs a better native Date/Time API.

------
abalashov
Another JS dependency I didn't quite get around to using before its status
changed in a way that greatly alters the calculus of choosing whether to use
it.

... and folks kept telling me I was wasting time writing my own time and date
stuff in JS.

------
Justsignedup
Been using date-fns. It's good. I am happy moment recognized that their time
is better spent on other frameworks.

It did the job well and now time to move on. Why save something when another
thing already does it and so well.

------
Reubend
Although I understand the reasoning in their post, I'm quite sad to see the
end of Moment.js.

In my experience, it works reliably and easily. I've never had issues with it,
and it does a fantastic job for a pretty big range of requirements.

------
olso
Maybe react-dates from Airbnb will move away finally

[https://github.com/airbnb/react-
dates/pull/1947](https://github.com/airbnb/react-dates/pull/1947)

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

~~~
perlgeek
OK, let me try.

Most software has "reference types", like a customer. A customer is mutable;
for example their name can change for a variety of reasons, their shipping
address can change etc.

And then there are "value types", like integers or strings. The integer 42 can
never change to be any other value.

If your customer lives in Rando Street no 42, and moves to Rando Street 41,
you don't change the integer (value type) 42 to 41, you set
`custtomer.address.house_number` to the new integer 41. If any other code
referenced the number 42, it still has number 42 stored.

Now, many people argue that a moment in time (like timestamp/datetime) is
usually better modeled as a value type. If you have two references to one
moment, you can rely on the fact that nobody else can modify that moment after
the fact.

This is usually safer, since it makes the case of accidentally over-shared
objects a non-problem, though possibly a little bit less performant (since all
"modifications" must create new copies).

------
thomasfromcdnjs
I've used Moment a million times ago.

Love the work your team has done, best of wishes!

------
codeisawesome
Ah, the nostalgia. Thank you for saving me so many times from dealing with
DateTime APIs and making my projects that much the faster, Moment.js! It's
great to see it in _done_ state!

------
kohlerm
It is done, but not dead? to me that sounds like a contradiction given that
there is always a need for security patches and also given the limitations
mentioned such as improving bundle size.

~~~
untog
As per the post:

"We will address critical security concerns as they arise."

Perhaps a better term than "done" is "feature complete".

------
dandigangi
Super excited about this. It's going to be a slow transition moving off but
our bundle sizes are going to drop dramatically. Definitely love the idea of
making our I18N work easier.

------
telaelit
Thank you to the Moment.js project and all the developers who worked on it.
I’ve used it in many projects and it’s always been great to use. Thanks for
all the work you all put in :)

------
fergie
It is the fate of a truly great library is that its benefits are so undeniable
that they will eventually be absorbed into the standard thus making the
library itself obsolete.

------
Fifer82
Thank you momentjs developers, as well as the time others have taken over the
years answering my boring questions about time. All the best.

------
ChrisMarshallNY
I plan for “done.” I remember taking a project management course, where the
instructor kept using the phrase “What does ‘done’ look like?” I also worked
with a manager that declared "The #1 feature of a project is 'Ship.'”

Every project that I do; even experimental and “unending” projects are done as
“ship-quality.” This is because I often revisit previous work, looking for
snippets. If they are already at “ship” quality, then that’s one less problem.

I’m also a grizzled veteran of “the prototype becomes the product.” That’s
something that many of us have experienced. It sucks, but it’s real. If the
prototype is already “ship-quality,” then that’s one less problem.

I tend to tag ongoing projects, so the head may be dynamic, but cloning a tag
will generate a stable release, or branch point. That’s a fairly typical Git
workflow. I’m not a fan of too many branches. I used the Mainline Model (a
Perforce pattern) for years, but I like no more than two branches, these days
(dev and master, and sometimes, dev can be in a private repo, squashing to
master). Often, I only have one branch. If I create a branch (like a
retrospective fix to a release tag), I merge that branch back into master, or
apply the same fix to master (not my preferred pattern). I will, occasionally,
create experimental or exploratory branches, which are short-lived, and
designed to be reintegrated with master. Again, not a unique workflow. This
will be familiar to many folks.

So, lots of “done,” as mileposts on a continuum. In some cases (like when I am
preparing course materials), I may do a lot of work in a dev branch, and
squash over to master, in order to reduce the “noise” in master, but the “done
bits” are always tags in master. I always reintegrate back to dev, so the
branches remain in sync, and the tags propagate to dev.

One exception to the “continuum model,” is that fix tags may be in small,
short-lived branches. If possible, I try to add the tag to master, at the
reintegration point, but that isn’t always practical or safe, especially if I
can’t actually reintegrate, but have to introduce the fix as new code, down
the road.

Since I have started using the Swift Package Manager, this has been a good
fit. I believe that many package managers rely on that pattern, so I don’t
think the way that I work is especially creative or standout. Pretty much
garden-variety configuration management.

Speaking of package managers, I often extract subprojects from my work in the
master branch, as I progress, spinning them off as standalone package
projects, with their own project lifecycle, and reintroduce them as
dependencies. This gives me little pockets of “done,” that have encapsulated
state and identity (and their own repo), along with focused testing. Each
project I spin off, is one less thing to worry about, and another tool on the
pegboard, for future projects.

So, in my case, “done” is really just a signpost along the road, but there can
be many signposts.

------
ajarmst
[https://xkcd.com/2347/](https://xkcd.com/2347/)

------
ehayes
Just want to plug Luxon, it's pretty great.

------
398796
yes

------
anonytrary
TLDR; Moment sucks now. Use our new library, Luxon, instead.

------
tus88
Moment(null) == now

Why

------
alexbanks
In this thread: "It's not done because I want it to be different."

------
dominotw
> used in millions of projects

Are there really millions of not-toy javascript projects out there?

~~~
schwartzworld
Like it or not, 90% of the web relies on JS for it's UI to function properly.

------
tus88
Sorry, it's dead. Software is never done. Pity they lack the courage to just
admit it.

