17 ms·

We now consider Moment.js to be a legacy project in maintenance mode

1129 points by maple3142 6y ago

SenHeng 6y ago
> We now generally consider Moment to be a legacy project in maintenance mode. It is not dead, but it is indeed done.
- vasachi 6y ago
  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 6y ago
    sure, annoying but they did bump to v2, nothing is stopping you from continuing to use the older version if it works for you.
- ilaksh 6y ago
  Makes sense. Similar thing with 'request' awhile back. I mean, you can see that even in the high-tech realm, it takes years for obsolescence to be acknowledged. But at least it does eventually happen. I actually think that a lot of the problems that our society has in general is because we take too many decades to move on from obsolete ways of doing things. What we need is for other core assumptions or technologies in our society to be able to upgraded. For examples: roads, cars, cities, government, money. I truly believe that all of those fundamental structures are often stuck in outdated forms that are holding us back.
ashtonkem 6y ago
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.
Reubend 6y ago
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.
jasonkester 6y ago
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.
- trevyn 6y ago
  I have no problem with a project being considered "complete", but the post also says "we would like to discourage Moment from being used in new projects going forward", which sounds more like "dead & done". :)
  - jimbob45 6y ago
    I think parent poster’s point was that dead should be considered done in this case instead of adding on more and more features and insisting on backwards compatibility until it ends up looking like modern C++. Dead isn’t necessarily bad.
- judofyr 6y ago
  > 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” In this case, the reason why Moment.js is "dead" and not "done" is because it has fundamental flaws in its design: Mutable objects + huge bundle size which doesn't work well with tree-shaking.
  - wvenable 6y ago
    If you fundamentally and incompatibly change it's design then it's an entirely new product. Calling that "Moment Version 3" doesn't mean anything.
    - 6y ago
vasachi 6y ago
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 6y ago
  Could you not just say the same about using LTS versions?
  - vasachi 6y ago
    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.
jackconsidine 6y ago
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.
jmull3n 6y ago
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.
lmiller1990 6y ago
Been a happy user for years, will continue to be. It works, it's battle tested, and powers many of my apps just fine.
jtchang 6y ago
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 6y ago
  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.
preet1986 6y ago
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.
nabaraz 6y ago
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.
codegladiator 6y ago
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 6y ago
  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 6y ago
    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 6y ago
      > 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 6y ago
        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 6y ago
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 6y ago
  This is exactly that: Strong, humble, responsible, positive and encouraging leadership and guidance.
- mekster 6y ago
  I remember request.js being "done" as of late.
alexbanks 6y ago
In this thread: "It's not done because I want it to be different."
mumblerino 6y ago
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?
davidtranjs 6y ago
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 6y ago
  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 6y ago
    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.
divbzero 6y ago
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/Reference/Global_Objects/Intl/DateTimeFormat https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... "MDN: Intl.DateTimeFormat" [2]: https://caniuse.com/mdn-javascript_builtins_intl_datetimeformat_format https://caniuse.com/mdn-javascript_builtins_intl_datetimefor... "Can I Use: Intl.DateTimeFormat"
- Semaphor 6y ago
  The whole Intl namespace is a godsend.
  - Ambroos 6y ago
    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=1045791 https://bugs.chromium.org/p/chromium/issues/detail?id=104579...
    - sebazzz 6y ago
      It isn't the pure javascript feeling without a few cross-browser quirks.
- ehsankia 6y ago
  Not sure if this is a stupid suggestion, but could there be a drop-in replacement for moment which uses Intl and other modern browser APIs, otherwise fetches the full moment.js? Or does MomentJS already do that?
  - deleted 6y ago
    [deleted]
telaelit 6y ago
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 :)
thomasfromcdnjs 6y ago
I've used Moment a million times ago. Love the work your team has done, best of wishes!
tannhaeuser 6y ago
Shouldn't software strive to perfection when done (like, say, LaTeX) rather than being obsolete when not anymore maintained?
- d--b 6y ago
  As the author says, the library caters to a language that is no longer in use - aka. javascript 2010 - and keeping up with the evolution of javascript would be making breaking changes, which have been accomplished by other projects by now. What would be the point?
- spyckie2 6y ago
  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.
dmit 6y ago
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 6y ago
  "moment.js: Mutable. Thank you, next." Mutable is not bad, buddy. You live in mutable world.
  - theon144 6y ago
    Mutable is not bad when necessary, but otherwise I'd say that immutable is generally quite good.
  - japgolly 6y ago
    False comparison. We're not creating a copy of the mutable world, we're writing software. Pretty different. Good luck programming in DNA or whatever and knowing that your code does what you want it to do.
  - deleted 6y ago
    [deleted]
  - TheCoelacanth 6y ago
anonytrary 6y ago
TLDR; Moment sucks now. Use our new library, Luxon, instead.
danellis 6y ago
Protocol dictates they now delete it from NPM without warning.
- Cthulhu_ 6y ago
  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.
tus88 6y ago
Moment(null) == now Why
tus88 6y ago
Sorry, it's dead. Software is never done. Pity they lack the courage to just admit it.
olso 6y ago
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
qwertox 6y ago
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 6y ago
  > 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/time https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ti...
- metafunctor 6y ago
  HTML5 does have a <time>-tag, but browsers don't render times in local time, you need JavaScript for that.
- kevmo 6y ago
  No other library has filled a huge gap in JavaScript like Moment.js did for so many years. I might say jQuery... which is mighty fine company to be included with!
fergie 6y ago
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.
theobeers 6y ago
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 6y ago
  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"
gandutraveler 6y ago
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()
- sparsely 6y ago
  I think the suggestion is just use Luxon - the apis are a bit different but there isn't really need for another library
- bettem 6y ago
  That’s effective what day.js is. Its effectively an identical api and is incredibly lightweight in comparison with opt-in extensions.
codeisawesome 6y ago
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!
ChrisMarshallNY 6y ago
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.
kohlerm 6y ago
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 6y ago
  As per the post: "We will address critical security concerns as they arise." Perhaps a better term than "done" is "feature complete".
CraigJPerry 6y ago
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
UnbugMe 6y ago
Find out how to lockdown iPads for business uses or corporate use.iPads have revolutionized not only the consumer's lives in the public environment but businesses as well. https://blog.scalefusion.com/lockdown-of-ipads-for-business-use/ https://blog.scalefusion.com/lockdown-of-ipads-for-business-...
dominotw 6y ago
> used in millions of projects Are there really millions of not-toy javascript projects out there?
- kube-system 6y ago
  Without a doubt. Remember there are lots of not-toy software projects that aren't publicly published.
- schwartzworld 6y ago
  Like it or not, 90% of the web relies on JS for it's UI to function properly.
ajarmst 6y ago
https://xkcd.com/2347/ https://xkcd.com/2347/
gridlockd 6y ago
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.
ehayes 6y ago
Just want to plug Luxon, it's pretty great.
398796 6y ago
yes
cjkarr 6y ago
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 6y ago
  Yes, and you're welcome.
  - Roboprog 6y ago
    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.
thrownaway954 6y ago
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.
- fendy3002 6y ago
  Disclaimer: I too use moment in my daily project Example snippet (CMIIW, it's as I remembered): let date1 = moment("2020-01-01"); let date2 = date1.add(2, "days"); console.log(date1.format("YYYY-MM-DD")); // 2020-01-03 date2.add(2, "days"); console.log(date1.format("YYYY-MM-DD")); // 2020-01-05 Usually the date1.add operation won't change the date1 value, and any operation to date2 won't change date1, but it isn't. It's made worse because people like to return moment object outside function scope, so operation outside can modify the object inside and weird bugs happen. It's actually a manageable problem IF you know the behavior, and only using moment object reference inside scope, and using immutable objects as parameter / return, such as milliseconds timestamp and js date.
- perlgeek 6y ago
  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).
rspeele 6y ago
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.
conradfr 6y ago
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/d52d9aed219281fb6bfc9ba6709372c9de85a8fb https://github.com/conradfr/ProgRadio/commit/d52d9aed219281f... edit: halved my app.js' size (before gzip). edit2: Needed a new polyfill for timezones on IE11
dandigangi 6y ago
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.
fendy3002 6y ago
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 6y ago
  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.
rayshan 6y ago
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.
Fifer82 6y ago
Thank you momentjs developers, as well as the time others have taken over the years answering my boring questions about time. All the best.
firebaze 6y ago
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.
- NanoWar 6y ago
  Gotta love immutables after that...
- superfrank 6y ago
  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 6y ago
    Yes, `somedate` is mutable.
- edgarvaldes 6y ago
  Yes, it bit me once
the__alchemist 6y ago
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.
azernik 6y ago
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!
balls187 6y ago
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.
rudolph9 6y ago
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/
- rudolph9 6y ago
  > Ideas in Luxon > Luxon is built around a few core ideas: > * Keep the basic chainable date wrapper idea from Moment. Make all the types immutable. Make the API explicit; different methods do different things and have well-defined options. > * Use the Intl API to provide internationalization, including token parsing. Fall back to English if the browser doesn't support those APIs. > * Abuse the Intl API horribly to provide time zone support. Only possible for modern browsers. > * Provide more comprehensive duration support. > * Directly provide interval support. > * Write inline docs for everything. https://moment.github.io/luxon/docs/manual/why.html#ideas-in-luxon https://moment.github.io/luxon/docs/manual/why.html#ideas-in...
- mekster 6y ago
  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 6y ago
    When you say chain, do you mean mutate the object as you call methods?
    - mekster 6y ago
      Yes.
      - 6y ago
radicalriddler 6y ago
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.
deleted 6y ago
[deleted]
abalashov 6y ago
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.
mcv 6y ago
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 6y ago
  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 6y ago
    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 6y ago
      Why use a whole freaking library instead of just writing a one-line function?
      - mcv 6y ago
        Because I'd have to write a lot of variations of that one-line function to handle different date format variations from various systems.
Justsignedup 6y ago
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.

1129 points by maple3142 6y ago

SenHeng 6y ago

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

vasachi 6y ago
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 6y ago
  sure, annoying but they did bump to v2, nothing is stopping you from continuing to use the older version if it works for you.
ilaksh 6y ago
Makes sense. Similar thing with 'request' awhile back. I mean, you can see that even in the high-tech realm, it takes years for obsolescence to be acknowledged. But at least it does eventually happen. I actually think that a lot of the problems that our society has in general is because we take too many decades to move on from obsolete ways of doing things. What we need is for other core assumptions or technologies in our society to be able to upgraded. For examples: roads, cars, cities, government, money. I truly believe that all of those fundamental structures are often stuck in outdated forms that are holding us back.

ashtonkem 6y ago

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.

Reubend 6y ago

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.

jasonkester 6y ago

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.

trevyn 6y ago
I have no problem with a project being considered "complete", but the post also says "we would like to discourage Moment from being used in new projects going forward", which sounds more like "dead & done". :)
- jimbob45 6y ago
  I think parent poster’s point was that dead should be considered done in this case instead of adding on more and more features and insisting on backwards compatibility until it ends up looking like modern C++. Dead isn’t necessarily bad.
judofyr 6y ago
> 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” In this case, the reason why Moment.js is "dead" and not "done" is because it has fundamental flaws in its design: Mutable objects + huge bundle size which doesn't work well with tree-shaking.
- wvenable 6y ago
  If you fundamentally and incompatibly change it's design then it's an entirely new product. Calling that "Moment Version 3" doesn't mean anything.
  - 6y ago

vasachi 6y ago

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 6y ago
Could you not just say the same about using LTS versions?
- vasachi 6y ago
  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.

jackconsidine 6y ago

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.

jmull3n 6y ago

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.

lmiller1990 6y ago

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

jtchang 6y ago

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 6y ago
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.

preet1986 6y ago

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.

nabaraz 6y ago

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.

codegladiator 6y ago

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 6y ago
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 6y ago
  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 6y ago
    > 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 6y ago
      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 6y ago

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 6y ago
This is exactly that: Strong, humble, responsible, positive and encouraging leadership and guidance.
mekster 6y ago
I remember request.js being "done" as of late.

alexbanks 6y ago

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

mumblerino 6y ago

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?

davidtranjs 6y ago

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 6y ago
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 6y ago
  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.

divbzero 6y ago

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/Reference/Global_Objects/Intl/DateTimeFormat https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... "MDN: Intl.DateTimeFormat" [2]: https://caniuse.com/mdn-javascript_builtins_intl_datetimeformat_format https://caniuse.com/mdn-javascript_builtins_intl_datetimefor... "Can I Use: Intl.DateTimeFormat"

Semaphor 6y ago
The whole Intl namespace is a godsend.
- Ambroos 6y ago
  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=1045791 https://bugs.chromium.org/p/chromium/issues/detail?id=104579...
  - sebazzz 6y ago
    It isn't the pure javascript feeling without a few cross-browser quirks.
ehsankia 6y ago
Not sure if this is a stupid suggestion, but could there be a drop-in replacement for moment which uses Intl and other modern browser APIs, otherwise fetches the full moment.js? Or does MomentJS already do that?
- deleted 6y ago
  [deleted]

telaelit 6y ago

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 :)

thomasfromcdnjs 6y ago

I've used Moment a million times ago. Love the work your team has done, best of wishes!

tannhaeuser 6y ago

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

d--b 6y ago
As the author says, the library caters to a language that is no longer in use - aka. javascript 2010 - and keeping up with the evolution of javascript would be making breaking changes, which have been accomplished by other projects by now. What would be the point?
spyckie2 6y ago
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.

dmit 6y ago

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 6y ago
"moment.js: Mutable. Thank you, next." Mutable is not bad, buddy. You live in mutable world.
- theon144 6y ago
  Mutable is not bad when necessary, but otherwise I'd say that immutable is generally quite good.
- japgolly 6y ago
  False comparison. We're not creating a copy of the mutable world, we're writing software. Pretty different. Good luck programming in DNA or whatever and knowing that your code does what you want it to do.
- deleted 6y ago
  [deleted]
- TheCoelacanth 6y ago

anonytrary 6y ago

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

danellis 6y ago

Protocol dictates they now delete it from NPM without warning.

Cthulhu_ 6y ago
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.

tus88 6y ago

Moment(null) == now Why

tus88 6y ago

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

olso 6y ago

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

qwertox 6y ago

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 6y ago
> 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/time https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ti...
metafunctor 6y ago
HTML5 does have a <time>-tag, but browsers don't render times in local time, you need JavaScript for that.
kevmo 6y ago
No other library has filled a huge gap in JavaScript like Moment.js did for so many years. I might say jQuery... which is mighty fine company to be included with!

fergie 6y ago

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.

theobeers 6y ago

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 6y ago
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"

gandutraveler 6y ago

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()

sparsely 6y ago
I think the suggestion is just use Luxon - the apis are a bit different but there isn't really need for another library
bettem 6y ago
That’s effective what day.js is. Its effectively an identical api and is incredibly lightweight in comparison with opt-in extensions.

codeisawesome 6y ago

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!

ChrisMarshallNY 6y ago

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.

kohlerm 6y ago

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 6y ago
As per the post: "We will address critical security concerns as they arise." Perhaps a better term than "done" is "feature complete".

CraigJPerry 6y ago

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

UnbugMe 6y ago

Find out how to lockdown iPads for business uses or corporate use.iPads have revolutionized not only the consumer's lives in the public environment but businesses as well. https://blog.scalefusion.com/lockdown-of-ipads-for-business-use/ https://blog.scalefusion.com/lockdown-of-ipads-for-business-...

dominotw 6y ago

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

kube-system 6y ago
Without a doubt. Remember there are lots of not-toy software projects that aren't publicly published.
schwartzworld 6y ago
Like it or not, 90% of the web relies on JS for it's UI to function properly.

ajarmst 6y ago

https://xkcd.com/2347/ https://xkcd.com/2347/

gridlockd 6y ago

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.

ehayes 6y ago

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

398796 6y ago

yes

cjkarr 6y ago

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 6y ago
Yes, and you're welcome.
- Roboprog 6y ago
  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.

thrownaway954 6y ago

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.

fendy3002 6y ago
Disclaimer: I too use moment in my daily project Example snippet (CMIIW, it's as I remembered): let date1 = moment("2020-01-01"); let date2 = date1.add(2, "days"); console.log(date1.format("YYYY-MM-DD")); // 2020-01-03 date2.add(2, "days"); console.log(date1.format("YYYY-MM-DD")); // 2020-01-05 Usually the date1.add operation won't change the date1 value, and any operation to date2 won't change date1, but it isn't. It's made worse because people like to return moment object outside function scope, so operation outside can modify the object inside and weird bugs happen. It's actually a manageable problem IF you know the behavior, and only using moment object reference inside scope, and using immutable objects as parameter / return, such as milliseconds timestamp and js date.
perlgeek 6y ago
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).

rspeele 6y ago

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.

conradfr 6y ago

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/d52d9aed219281fb6bfc9ba6709372c9de85a8fb https://github.com/conradfr/ProgRadio/commit/d52d9aed219281f... edit: halved my app.js' size (before gzip). edit2: Needed a new polyfill for timezones on IE11

dandigangi 6y ago

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.

fendy3002 6y ago

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 6y ago
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.

rayshan 6y ago

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.

Fifer82 6y ago

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

firebaze 6y ago

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.

NanoWar 6y ago
Gotta love immutables after that...
superfrank 6y ago
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 6y ago
  Yes, `somedate` is mutable.
edgarvaldes 6y ago
Yes, it bit me once

the__alchemist 6y ago

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.

azernik 6y ago

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!

balls187 6y ago

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.

rudolph9 6y ago

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/

rudolph9 6y ago
> Ideas in Luxon > Luxon is built around a few core ideas: > * Keep the basic chainable date wrapper idea from Moment. Make all the types immutable. Make the API explicit; different methods do different things and have well-defined options. > * Use the Intl API to provide internationalization, including token parsing. Fall back to English if the browser doesn't support those APIs. > * Abuse the Intl API horribly to provide time zone support. Only possible for modern browsers. > * Provide more comprehensive duration support. > * Directly provide interval support. > * Write inline docs for everything. https://moment.github.io/luxon/docs/manual/why.html#ideas-in-luxon https://moment.github.io/luxon/docs/manual/why.html#ideas-in...
mekster 6y ago
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 6y ago
  When you say chain, do you mean mutate the object as you call methods?
  - mekster 6y ago
    Yes.
    - 6y ago

radicalriddler 6y ago

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.

deleted 6y ago

[deleted]

abalashov 6y ago

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.

mcv 6y ago

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 6y ago
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 6y ago
  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 6y ago
    Why use a whole freaking library instead of just writing a one-line function?
    - mcv 6y ago
      Because I'd have to write a lot of variations of that one-line function to handle different date format variations from various systems.

Justsignedup 6y ago

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.