Add project status info and link from home page (#675)

* Regenerate lockfile to fix compile issues

* Adding project status page and link text from home page

* Revisions to project status

* Addition changes to address feedback

* fix typo

Author: mattjohnsonpint

assets/css/_header.scss

@@ -90,6 +90,13 @@
 	font-family: "Montserrat", sans-serif;
 }
 
+.right-of-hero {
+	float: right;
+	color: $white;
+	padding: 20px;
+	font-family: "Montserrat", sans-serif;
+}
+
 .hero-oneline,
 .hero-title {
 	text-align: center;

docs/moment/-project-status/00-intro.md

@@ -0,0 +1,70 @@
+---
+title: Project Status
+---
+
+Moment.js has been successfully used in millions of projects, and we are happy to have contributed to making date and time better on the web.
+As of September 2020, Moment gets over 12 million downloads per week!  However, Moment was built for the previous era of the JavaScript ecosystem.
+The modern web looks much different these days.  Moment has evolved somewhat over the years, but it has essentially the same design as it did when it was created in 2011.
+Given how many projects depend on it, *we choose to prioritize stability over new features*.
+
+As an example, consider that Moment objects are *mutable*.  This is a common source of complaints about Moment.
+We address it [in our usage guidance](/guides/#/lib-concepts/mutability/) but it still comes as a surprise to most new users.
+Changing Moment to be immutable would be a breaking change for every one of the projects that use it.
+Creating a "Moment v3" that was immutable would be a tremendous undertaking and would make Moment a different library entirely.
+Since this has already been accomplished in other libraries, we feel that it is more important to retain the mutable API.
+
+Another common argument against using Moment in modern applications is its size.  Moment doesn't work well with modern "tree shaking" algorithms, so it tends to increase the size of web application bundles.
+If one needs internationalization or time zone support, Moment can get quite large.  Modern web browsers (and Node.js) expose internationalization and time zone support via the [`Intl`](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Intl) object, codified as [ECMA-402](https://ecma-international.org/ecma-402/). Libraries like [Luxon](https://moment.github.io/luxon/) (and others) take advantage of this, reducing or removing the need to ship your own data files.
+
+Recently, Chrome Dev Tools [started showing recommendations for replacing Moment](https://twitter.com/addyosmani/status/1304676118822174721) for the size alone.  We generally support this move.
+
+You may also want to read:
+
+- [*You Probably Don't Need Moment.js Anymore*](https://dockyard.com/blog/2020/02/14/you-probably-don-t-need-moment-js-anymore)
+- [*You don't (may not) need Moment.js*](https://github.com/you-dont-need/You-Dont-Need-Momentjs/blob/master/README.md)
+- [*Why you shouldn't use Moment.js...*](https://inventi.studio/en/blog/why-you-shouldnt-use-moment-js)
+- [*4 alternatives to moment.js for internationalizing dates*](https://blog.logrocket.com/4-alternatives-to-moment-js-for-internationalizing-dates/)
+
+The Moment team has discussed these issues at length.  We recognize that many existing projects may continue to use Moment, but we would like to discourage Moment from being used in new projects going forward.
+
+**We now generally consider Moment to be a legacy project in maintenance mode.  It is not *dead*, but it is indeed *done*.**
+
+In practice, this means:
+
+- We will not be adding new features or capabilities.
+- We will not be changing Moment's API to be immutable.
+- We will not be addressing tree shaking or bundle size issues.
+- We will not be making *any* major changes (no version 3).
+- We may choose to not fix bugs or behavioral quirks, especially if they are long-standing known issues.
+
+With specific regard to Moment's internationalization locale files:
+
+- We may choose to not accept corrections to locale strings or localized date formats, especially if they have been argued successfully for their present form.
+- You must make a new compelling argument for locale changes with significant, non-anecdotal evidence to support your position.
+- If the string or format you are asking to change is reflected in the [CLDR](http://cldr.unicode.org/), then you must submit a change there *first* and have it accepted.
+
+However, since we understand that Moment is well established in millions of existing projects:
+
+- We *will* address critical security concerns as they arise.
+- We *will* release data updates for Moment-Timezone following [IANA time zone database](https://www.iana.org/time-zones) releases.
+
+### Reasons to keep using Moment
+
+In most cases, you should not choose Moment for new projects.  However there are some possible reasons you might want to keep using it.
+
+#### Browser support
+
+Moment works well on Internet Explorer 8 and higher.  By contrast, Luxon only works on IE 10 and higher and requires a polyfill to do so.  [You can read more in Luxon's documentation.](https://moment.github.io/luxon/docs/manual/matrix.html)
+
+Other libraries have also had issues with Safari, especially on mobile devices.  If you have a strong requirement to support older browsers, then you might want to stick with Moment for a bit longer.
+
+However, [Day.js reports compatibility with IE8 and higher](https://day.js.org/docs/en/installation/installation) so you still may wish to consider that alternative.
+
+#### Dependency by other libraries
+
+Several other libraries, especially date pickers and graphing libraries, take Moment as a dependency.  If you are using such a component and cannot find an alternative, then you are already including Moment in your project.
+Thus, it might make sense to continue using Moment throughout your project rather than including yet another date and time library.
+
+#### Familiarity
+
+If you are a long-time user of Moment, you may already understand its API and limitations well.  If so, and the aforementioned issues are not a concern for you, then you certainly can continue to use it.

docs/moment/-project-status/01-recommendations.md

@@ -0,0 +1,71 @@
+---
+title: Recommendations
+---
+
+There are several great options to consider using instead of Moment.
+
+When choosing, consider that:
+
+- Some libraries are split into modules, plugins, or companion libraries.
+- Some libraries use the ECMAScript [`Intl`](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Intl) API for locales, time zones, or both.
+- Some libraries still provide their own locale and time zone files like Moment and Moment-Timezone do.
+
+**Here are the alternatives we recommend:**
+
+### [Luxon](https://moment.github.io/luxon/)
+
+Luxon can be thought of as the evolution of Moment.  It is authored by [Isaac Cambron](https://github.com/icambron), a long-time contributor to Moment.
+Please read [*Why does Luxon exist?*](https://moment.github.io/luxon/docs/manual/why.html) and the [*For Moment users*](https://moment.github.io/luxon/docs/manual/moment.html) pages in the Luxon documentation.
+
+- Locales: `Intl` provided
+- Time Zones: `Intl` provided
+
+### [Day.js](https://day.js.org/)
+
+Day.js is designed to be a minimalist replacement for Moment.js, using a similar API.
+It is not a drop-in replacement, but if you are used to using Moment's API and want to get moving quickly, consider using Day.js.
+
+- Locales: Custom data files that can be individually imported
+- Time Zones: `Intl` provided, via a plugin
+
+### [date-fns](https://date-fns.org/)
+
+Date-fns offers a series of functions for manipulating JavaScript [`Date`](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Date) objects.  For more details, scroll to "Why date-fns?" on the date-fns home page.
+
+- Locales: Custom data files that can be individually imported
+- Time Zones: `Intl` provided, via a separate companion library
+
+### [js-Joda](https://js-joda.github.io/js-joda/)
+
+js-Joda is a JavaScript port of Java's [Three-Ten Backport](https://www.threeten.org/threetenbp/), which is the base for JSR-310 implementation of the Java SE 8 `java.time` package.
+If you are familiar with [`java.time`](https://docs.oracle.com/javase/8/docs/api/java/time/package-summary.html), [Joda-Time](https://www.joda.org/joda-time/), or [Noda Time](https://nodatime.org/), you will find js-Joda comparable.
+
+- Locales: Custom data files via add-on module
+- Time Zones: Custom data files via add-on module
+
+### No Library
+
+JavaScript has always had a [`Date`](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Date) object, defined ECMAScript (ECMA-262) specification [here](https://www.ecma-international.org/ecma-262/11.0/index.html#sec-date-objects).
+
+When using `Date` objects, be aware of the following:
+
+- The `Date` object internally represents a Unix timestamp with millisecond precision.  It offers functions that will convert to and from the system's local time zone, but it is *always* UTC internally.
+  Unlike a `Moment` object, it *can not* be set to use another time zone; It has no concept of "mode".
+
+- Using [`Date.parse`](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Date/parse), or [`new Date(<string>)`](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Date/Date#Timestamp_string)
+  has been problematic and implemented inconsistently in the past.  The [current specification](https://www.ecma-international.org/ecma-262/11.0/index.html#sec-date-time-string-format) defines parsing a variation of ISO 8601 strings,
+  where date-only forms (like `"2020-09-14"`) are parsed as UTC, instead of local time as they would be by ISO 8601.  Even then, not all modern implementations have implemented this specification correctly (e.g., Safari).
+  Other types of strings *may* work, but parsing them is *implementation specific* and can vary significantly - especially with older browsers.  Depending on the implementation, and the components provided in the string, you may be surprised with the result.
+  For these reasons, we agree with [MDN's statement](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Date/Date#Timestamp_string) that **parsing strings with the `Date` object is strongly discouraged**.
+
+Modern JavaScript environments will also implement the by [ECMA-402](https://www.ecma-international.org/ecma-402) specification, which provides the [`Intl`](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Intl) object,
+and defines behavioral options of the `Date` object's `toLocaleString`, `toLocaleDateString`, and `toLocaleTimeString` functions.
+
+When using the `Intl` object, be aware of the following:
+
+- Not every environment will implement the full specification.  In particular, Node.js environments require internationalization support provided by ICU.  See [the Node.js documentation](https://nodejs.org/docs/latest-v12.x/api/intl.html) for further details.
+- The [ECMAScript Intl compatibility table (by kangax)](http://kangax.github.io/compat-table/esintl/) can be useful in determining which features are supported and which are not.
+- Most newer environments provide IANA time zone support via the `timeZone` option in the `Intl.DateTimeFormat` constructor (and in `Date.toLocaleString`, `Date.toLocaleDateString`, and `Date.toLocaleTimeString`).
+  This option can be used to take the internal UTC-based timestamp of a `Date` object and get a *string* that has been converted to a named time zone.  However, it *can not* be used to convert a `Date` object to a different time zone.
+
+If the `Date` and `Intl` objects meet your needs and you fully understand their limitations, then you might consider using them directly.

docs/moment/-project-status/02-future.md

@@ -0,0 +1,12 @@
+---
+title: The Future
+---
+
+One day soon, we hope there won't be a strong need for date and time libraries in JavaScript at all.  Instead, we will be able to use capabilities of the JavaScript language itself.
+Though some capabilities are here today with [`Date`](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Date) and [`Intl`](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Intl), we know from experience and data that there is significant room for improvement.
+
+The effort to make better date and time APIs in the JavaScript language is being done via [The ECMA TC39 Temporal Proposal](https://tc39.es/proposal-temporal/docs/index.html).
+
+You can try out Temporal today, via [an experimental polyfill](https://github.com/tc39/proposal-temporal/tree/main/polyfill).  Please give it a try, but don't use it in production (yet)!
+
+Please also consider contributing to this effort, especially if you have experience using Moment or other date and time libraries.

docs/moment/00-use-it/00-intro.md

@@ -1,5 +1,5 @@
 ---
-title: Where to use it
+title: Using Moment
 ---