Coding With Fun
Home Docker Django Node.js Articles Python pip guide FAQ Policy

Moment .js officially recommends using a different time processing library instead


May 31, 2021 Article blog


Table of contents


The article comes from the public number: Imprint Chinese Translator: Phobal

Recently, Moment .js released the status of the project in an official document, writing that Momentjs is officially under maintenance and will no longer provide large-version updates, and recommends using a different time processing library instead of or using JavaScript for experimental proposal Temporal.

The following is a Chinese translation of the status of this project.

Moment.js has been used in millions of projects and we are honored to be able to help you with dates and times on our website. A s of September 2020, Moment has been downloaded more than 12 million times a week! Moment however, was built for the last era of the JavaScript ecosystem. T he Web has changed dramatically over the years, with Moment following suit, but it's designed to be essentially the same as it was when it was created in 2011. Given that many projects rely on it, we prioritize stability over new features.

Moment objects are mutable objects, which are often criticized by users. A lthough we've written in the Usage Guide on how to fix this problem, there are still a lot of new user errors. T urning Moment into an immutable object can have a devastating effect on projects that already use Moment Getting Moment to support immutable is a daunting task in itself, which will turn Moment into another library, which is already implemented by many similar libraries at this stage, so there's nothing wrong with keeping Moment mutable

Another point that everyone is sick of is the size of the Moment package, and tree shaking is not valid for Moment resulting in a sharp increase in the volume of the package applied. I f you need internationalization and time zones in your app, Moment can be bigger than you think. M odern web browsers (and Node.js) enable internationalization and time zone support through Intl objects, numbered ECMA-402. Libraries like Luxon take advantage of this advantage to reduce the size of library files.

Recently, Chrome development tools have advised users to change Moment We are also in favour of such a move.

The community has published many articles on this issue:

  • You may no longer need Moment .js
  • You (probably) don't need Moment .js
  • Why don't you need to use the Moment .js...
  • 4 libraries that replace the moment .js for date internationalization

Moment team also discussed these issues in detail. W e realized that there might be projects that would continue to use Moment B ut we don't recommend that you use it in a new project, instead, we recommend libraries that work better with modern webs. It is also recommended that you try Temporal a new proposal for JavaScript processing time, which requires your support and contribution.

We officially announced that Moment was in maintenance, but not dead, but fulfilling its mission.

In fact, this means:

  • No new features will be added.
  • The API is not changed to immutable.
  • The problem of tree shaking and package volume will not be resolved.
  • No significant changes will be made (no v3).
  • You may choose not to fix bugs, especially long-standing known bugs.

About Moment's international language environment file:

  • We may choose not to accept corrections to locale strings or localized date formats, especially if their existing formats have been demonstrated.
  • When the language environment changes significantly, you must provide a compelling basis to support your position.
  • If you want to change the string or format, you must submit the change request on the CLDR and accept it before you can change it.

However, due to the large number of Moment users, we deal with the following issues in a timely manner when:

  • When serious security problems arise, we will address them.
  • We will update Moment-Timezone's data after the IANA time zone database publishes the update.

You need to continue using Moment's scene

In most cases, do not select Moment for new Moment However, you may still need to use it in some special scenarios.

Browser support

Moment works perfectly under IE8. Luxon by contrast, can only run on IE 10 and later, and needs to be used with polyfill You can learn more in Luxon documentation.

Other libraries have the same problem on Safari especially on mobile devices. If you have to support legacy browsers, you may want to continue using Moment

However, Day.js supports IE8 and later, and you might consider using it if you have compatibility-related requirements.

The dependency of other libraries

Some libraries, especially date selectors and graphics libraries, use Moment as a dependency, and if you're using a similar component and can't find an alternative, your project is already dependent on Moment You can continue to use Moment in your project without introducing a date time library.

Loyal fans

If you're a big fan of Moment you're well aware of its APIs and limitations. If so, and do not care about the above problem, you can continue to use it.

Some alternative libraries are recommended

There are many good libraries to replace Moment.

When making a choice, consider the following:

  • Some libraries are divided into modules, plug-ins, and companion libraries.
  • Some libraries use ECMAScript's Intl API for the locale, time zone, or both.
  • Some libraries still offer their own language environment and time zone files, just like Moment and Moment-Timezone.

Here are our recommended alternatives:

Luxon

Luxon can be thought of as the evolution of Moment, written by Isaac Cambron a longtime writer for Moment. R ead 为什么会存在Luxon? and For Moment For Moment用户 documents in Luxon documents.

  • Language environment: Intl implementation
  • Time zone: Intl implementation

Day.js

Using similar APIs, Day.js is designed as a minimalist alternative to Moment.js It's not a temporary replacement, and if you're used to using Moment's APIs and want to get started quickly, consider using the Day .js.

  • Language environment: Custom data files that can be imported separately
  • Time zone: Intl is implemented through plug-ins

date-fns

Date-fns a range of functions for working with JavaScript Date objects. F or more details, read "Why use date-fns on the date-fns home page. section.

  • Language environment: Custom data files that can be imported separately
  • Time zone: Intl is implemented through a separate library

js-Joda

js-Joda is a JavaScript version of Three-Ten Backport for Java, which is based on the JSR-310 implementation in the Java SE 8 java.time package. If you're familiar with java.time Joda-Time, or Noda Time, you'll find js-Joda comparable.

  • Language environment: Custom data files via add-on modules
  • Time zone: Custom data files through add-on modules

No third-party libraries are used

JavaScript has always had a Date object that follows the ECMAScript (ECMA-262) specification.

When using Date object, keep the following in mind:

  • The Date timestamp inside the Date object with millisecond accuracy. I t provides the ability to convert back and forth between system-local time zones, but the internal UTC is always. U nlike Moment objects, you cannot set them to use other time zones. It does not have the concept of a "pattern".
  • Using Date.parse or new Date() has been a bug in the past and implementations have been inconsistent. T he current specification supports defining strings that resolve ISO 8601, where only the form of the date (such as "2020-09-14" is resolved to UTC, not local time in ISO 8601. E ven so, not all modern browsers follow this standard (e.g. Safari). O ther types of strings can also be used, but parsing them is additional and can be very different, especially for older browsers. D ifferent implementations and incoming strings can produce different results. For these reasons, we agree with MDN's statement that we strongly oppose the use of Date objects to parse strings.

Modern JavaScript environments also implement the ecMA-402 specification, providing Intl objects and defining methods such as toLocaleString toLocaleDateString and toLocaleTimeString on Date objects.

When working with Intl objects, keep the following in mind:

  • Not every environment implements a complete specification. I n particular, node .js environment relies on international support from the ICU. For more details, see node.js documentation.
  • ECMAScript Intl compatibility list (provided by kangax) for easy access to support.
  • Most of the newer environments offer Intl.DateTimeFormat constructors (as well as Date.toLocaleString options that support Date.toLocaleDateString timeZone through the IANA time zone. Date.toLocaleTimeString T his option can be used to get the internal UTC-based timestamp of the object and get the string that has been converted to a named time zone. However, it cannot convert Date object to a different time zone.

If Date and Intl objects meet your needs, and you fully understand their limitations, consider using them directly.

future

Temporal - It's better to use JavaScript to bring your own time and date processing

In the future, we hope to eliminate the need to use JavaScript-related date and time processing libraries. I nstead, use the javaScript language's own characteristics directly. Despite Date and Intl that provide some features, we still have a lot of room for improvement from past experience and data.

As can be seen from the interim proposal for ECMA TC39, organizations are working to write better date and time APIs for the JavaScript language. It is currently in the second phase of the TC39 process.

Temporal will be a new global object that acts as a top-level namespace, such as Math I t exposes many different types of objects, including Temporal.Absolute Temporal.DateTime Temporal.Date Temporal.Time Temporal.TimeZone and more. The Temporal Cookbook contains many cases and provides examples of how to use these objects in different situations.

You can experience it with this experimental polyfill, but don't use it in a production environment.

If you have experience working with libraries using Moment or other date times and are interested in temporal proposal, you are welcome to participate in the discussion and development.

The above is W3Cschool编程狮 about Moment .js official recommendation to use other time processing library instead of the relevant introduction, I hope to help you.