1. 7
  1.  

  2. 4

    I don’t think the required work to add this compatibility for new moment replacements is worth it. Most people won’t change their code anyway. And new systems will gradually adopt libraries when they exist. It’s nice that people think about that, but I don’t think anyone wants to maintain this additionally.

    I’ve got a webpage based on bootstrap 3, jquery and moment.js + 3 graph libs to display the required data in the way I need. This will probably never get upgraded to anything newer because of too many dependencies that I’ll have to sort out and find good replacements or hacks to get these new graph libs to do what I want. The code 3 years old and will probably work for another 3, so why bother. Ironically the backend is newer because I find it easier to update these parts over big JS libraries.

    1. 2

      You might be right, but this is a very slow “gradually”.

      If I’ve had a 3yo code like yours, I’d also not refactor it just to use a newer technology. I would do that if it was a larger, active project where moving away from moment could save me developer time and significantly shrink the bundle size.

      I could also migrate an existing project/package gradually and with more ease with such a skeleton, while gaining some of the advantages of the replacement library (some space saving, performance etc.) right away.

      I believe that a small subset of moment’s API will be enough for the large majority of projects. Since moment is in maintenance mode, there will be no API changes from the source to handle in the skeleton. Thus, no major rewrites will be needed for anything but bugfixes and major version releases of the replacement.

      I believe that such a skeleton would make the choice of using a new date-time library an easier one, as well as enjoying the advantages of a migration in cases where they’re required.

    2. 2

      That’s a neat solution! I do wonder if it pans out in practice, and how large the boilerplate to cover Moment.js’s API ends up being. I’m not sure about the tree-shakeability of the resulting setup, since a large portion of Moment’s API is implemented as instance properties on an Moment object. It would be useful, I think, to prototype a proof-of-concept to decide if it can be obtained before embarking on such a tedious task.

      1. 1

        The boilerplace question is a major one here. It might be big, but as long as it’s not larger than moment.js it could still provide the other advantages. Mainly, a smoother transition. I’d also add that such a boilerplate could not be a FULL replacement. I bet that by implementing a relatively small part of moment’s API, you’d cover the large majority of dependencies.

        About tree-shakeability - that might be true. Maybe there are ways to handle that? Depending on the project, some sacrifice in compatibility could allow us to search for a solution using a Proxy object, for example.

        Of course, a POC is a must, first. Could be a nice hackathon project :)