May 31, 2021 Article blog
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:
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:
About Moment's international language environment file:
However, due to the large number of Moment users, we deal with the following issues in a timely manner when:
In most cases, do not select Moment for new
Moment
However, you may still need to use it in some special scenarios.
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.
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.
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.
There are many good libraries to replace Moment.
When making a choice, consider the following:
Intl
API for the locale, time zone, or both.
Here are our recommended alternatives:
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.
Intl
implementation
Intl
implementation
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.
Intl
is implemented through plug-ins
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.
Intl
is implemented through a separate library
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.
JavaScript has always had a
Date
object that follows the ECMAScript (ECMA-262) specification.
When using
Date
object, keep the following in mind:
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".
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:
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.
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.