This post is from the Moment website.

No nonsense, do not want to see official documents, directly put the summary:

Moment.js was built last time to complete the JavaScript ecosystem, and now the JavaScript ecosystem is robust enough that there are many excellent libraries that can replace moment.js. So the team focused on stability and, unless there were major issues to be addressed, minor bugs would be ignored and major iterations of innovation would not be released. It is not recommended to use moment.js as a time processing package for your new project. Alternatives are Luxon, day. js, date-fns, js-joda.

Take a look at the official website:

Moment.js has been used successfully on millions of projects, and we’re happy to have contributed to improving dates and times on the Web. As of September 2020, Moment was downloaded over 12 million times per week! But Moment was built for a previous era of the JavaScript ecosystem. Today, the modern web looks very different. Moment has evolved over the years, but its design is essentially the same as when it was founded in 2011. Given how many projects depend on this, we chose to prioritize stability over new features.

For example, consider that the Moment object is mutable. This is a common source of complaints about Moment. We’ve addressed this issue in the user guide, but it’s still a problem for most new users. For every project that uses this project, changing Moment to immutable would be a major breakthrough. Creating immutable “Moment V3” would be a daunting task, and would make Moment a completely different library. Since this has been done in other libraries, we felt it was more important to keep the mutable API.

Another common argument against using Moment in modern applications is its size. Moment doesn’t work with modern “Tree Shaking” algorithms, so tends to increase the size of Web application bundles. If internationalization or time zone support is required, Moment can be large. Modern Web browsers (and Node.js) expose internationalization and time zone support through Intl objects (encoded as ECMA-402). Libraries like Luxon (and others) take advantage of this, reducing or eliminating the need to transport your own data files.

Recently, Chrome development tools have started showing suggestions for resizing Moment only. We generally support this move.

The Moment team has discussed these issues in detail. We recognize that many existing projects may continue to use Moment, but we want to prevent Moment from being used in future new projects. Instead, we want to recommend great options for use in modern applications today. We also want to promote the additional functionality of the Temporal JavaScript language, which is looking for feedback and contributors.

Now, we often think of Moment as a legacy project in maintenance mode. It’s not dead yet, but it’s really over (I mean, it still works, but that’s it, no longer optimized).

In practice, this means:

  • We won’t be adding new features.
  • We don’t change the Moment API to be immutable.
  • We will not solve the problem of tree shaking or bundle size.
  • We won’t be making any major changes (no version 3).
  • We may choose not to fix errors or behavioral quirks, especially if they are long-standing known problems.

About Moment’s internationalization locale file:

  • We may choose not to accept corrections to locale strings or localized date formats, especially if corrections have been successfully proposed for their current format.
  • You must use significant, non-anecdotal evidence to make new, compelling arguments for district change to support your position.
  • If the string or format you want to change is reflected in the CLDR, you must first commit the change here and accept it.

However, as we know Moment is established in millions of existing projects:

  • When there are serious security issues, we will address them.
  • We will release a moment-timezone data update when the IANA Timezone database is released.

Reasons to continue using Moment:

In most cases, you should not choose a Moment for a new project. However, there are some possible reasons you might want to keep using it.

1. Browser support

Moment works fine on Internet Explorer 8 and later. In contrast, Luxon only runs on IE 10 and higher and requires polyfill to operate. You can read more in Luxon’s documentation.

Other libraries also have Safari issues, especially on mobile devices. If you urge support for older browsers, you might want to stick with Moment for a little longer.

However, day.js reports compatibility with IE8 and later, so you may still want to consider using this alternative.

2. Dependencies of other libraries

Several other libraries, notably the date picker and the graphics library, treat Moment as a dependency. If you are using such a component and cannot find a replacement, you have included a Moment in your project. Therefore, it may be necessary to continue using Moment throughout the project rather than include another library of dates and times.

3. Familiarity with it

If you’re a longtime user of Moment, you’re probably already familiar with its API and limitations. If so, and you don’t have to worry about the above, you can certainly continue to use it.

advice

There are plenty of good options to consider using instead of Moment.

When choosing, please consider:

  • Some libraries are divided into modules, plug-ins, or companion libraries.
  • Some libraries use ECMAScript IntlAPI for locale, time zone, or both.
  • Some libraries still provide their own locale and Timezone files like Moment and moment-timezone.

Moment’s recommended alternative:

  • Luxon

  • Day.js

  • date-fns

  • js-Joda