4 ms·

I love moment, but it's age is starting to show. The way it's designed makes code splitting and tree shaking extremely difficult, and the difficulty removing l

I love moment, but it's age is starting to show. The way it's designed makes code splitting and tree shaking extremely difficult, and the difficulty removing large chunks of the library (i'm looking at you locales) is annoying at best. It's also a pretty heavy library on it's own anyway, as it needs to implement quite a lot of code for legacy browsers that isn't really needed if you are only targeting evergreen browsers (and possibly IE 10-11). As an alternative, I always recommend "date-fns"[0]. it got a mention in the article, but not nearly enough of one! https://github.com/date-fns/date-fns https://github.com/date-fns/date-fns

apaprocki 8y ago
Please review and contribute your views on the TC39 Temporal proposal. There’s a polyfill to play with now... https://github.com/tc39/proposal-temporal https://github.com/tc39/proposal-temporal
- Klathmon 8y ago
  This is fantastic, however it doesn't really completely replace the reasons for using something like date-fns. Stuff like a "time-range" (both a "computer" value, and a "humanized" one like "10 minutes ago"), and other nice to haves. There's no reason this can't be a good base going forward though! And for what it does cover, I really like the API.
  - oldmanhorton 8y ago
    There is an Intl.RelativeTimeFormat proposal as well: https://github.com/tc39/proposal-intl-relative-time/blob/master/README.md https://github.com/tc39/proposal-intl-relative-time/blob/mas...
- univerio 8y ago
  This looks like a step in the right direction. I can't seem to find a polyfill though -- do you have a link to that?
  - Klathmon 8y ago
    The one open PR is a self described "first go" at a polyfill. https://github.com/tc39/proposal-temporal/pull/57 https://github.com/tc39/proposal-temporal/pull/57
eropple 8y ago
I stumbled across Luxon, also under the Moment umbrella, not too long ago and I think it's pretty slick. It feels a lot more natural to use.
- Klathmon 8y ago
  I saw that for the first time today elsewhere in this thread, and I really like it!
_ZeD_ 8y ago
>>> I love moment, but it's age is starting to show. according to https://github.com/moment/moment/blob/develop/CHANGELOG.md#030 https://github.com/moment/moment/blob/develop/CHANGELOG.md#0... the 0.3.0 release was from 2011. it's barely 7 years ago. And I'm non counting the fact that the current version is 2.22.2 (so there are at least 2 major ones). How... how can you tell it's aging?!
- nawgszy 8y ago
  Hopefully I can explain your downvotes a bit. The JavaScript ecosystem is in an entirely different place now. ES6 has made it feasible to write cleaner, more concise code, and Webpack has allowed library consumers to "naively" import a whole library but the algorithm known as 'tree-shaking' will remove any unused code, which can be especially valuable when a library has a few purposes which are somewhat orthogonal, and each requires has its own large codebase, aka Moment.
- Klathmon 8y ago
  Because not all things "age" at the same rate. (1 month old milk is old, a 1 month old can of tomato paste is far from old) Lodash (#1 in this article) is just as old or older than Moment, however I wouldn't call lodash "aging" simply because it has adapted to the new paradigms in the javascript ecosystem and works very VERY well with them (to the point that I'd argue lodash is a pretty good example of how to work with these tools). Moment still does a great job at what it does, and it's in no way getting "worse" over time (quite the opposite!), however because of some choices made during it's development, it can't easily take advantage of newer developments in the javascript ecosystem. JS has changed significantly, and is still changing. I'd argue that JS became a "real" programming language over the last 10 years, and because of that a lot of things created in that time aged much quicker than they should have. Like I (briefly) pointed out in my comment, things like tree shaking, module bundling, code splitting, minification, and the tooling and ecosystem around them have changed drastically in the last 5 years. Now moment will still work great with those things, but it doesn't take advantage of them. And that means that alternatives end up getting a leg up because they do take advantage of them. Something like `date-fns` is designed with tree-shaking in mind, so if I only want to use the part of it that "humanizes" a time range, i'll only get that code. If I want to provide multiple locales for multiple users, but only have each user download their own locale at runtime, I can do that easily. Not to mention that browser support has changed in the last few years, so most people no longer need to support IE 7, 8, 9, etc... And that means that the code that moment has built up to support those browsers isn't needed on newer ones, but again it's difficult or impossible to build it without that to save size. To continue the analogy I used at the start of my comment, I'd say moment is week old milk. It's not bad yet, but I wouldn't buy it from the store like that in most cases. Moment is great, I do use it in 2 projects at work because it was the best tool for the job for a long time, and it still works fantastically. However if I'm starting a new project now, i'm most likely going to reach for something else. Not because it's "newer" or because it's the hot thing right now, but because in all honesty the API of a date management library isn't all that complicated, and switching isn't a large cost. And when those other libraries can provide benefits that moment can't, i don't have much of a reason to stay with these "older" libraries.
spraak 8y ago
It is also sneakily mutable at times. Some methods will mutate the original object - the cause of a few bugs I've investigated recently
- hinkley 8y ago
  Why do [time] libraries all seem to make this mistake? I think I fixed the same concurrency bug due to misuse of Java’s date parser at four different companies (one of them I didn’t even work for). Use one object to hold configuration and another to hold state.
z3t4 8y ago
I usually copy/paste the functions I need :P

apaprocki 8y ago

Please review and contribute your views on the TC39 Temporal proposal. There’s a polyfill to play with now... https://github.com/tc39/proposal-temporal https://github.com/tc39/proposal-temporal

Klathmon 8y ago
This is fantastic, however it doesn't really completely replace the reasons for using something like date-fns. Stuff like a "time-range" (both a "computer" value, and a "humanized" one like "10 minutes ago"), and other nice to haves. There's no reason this can't be a good base going forward though! And for what it does cover, I really like the API.
- oldmanhorton 8y ago
  There is an Intl.RelativeTimeFormat proposal as well: https://github.com/tc39/proposal-intl-relative-time/blob/master/README.md https://github.com/tc39/proposal-intl-relative-time/blob/mas...
univerio 8y ago
This looks like a step in the right direction. I can't seem to find a polyfill though -- do you have a link to that?
- Klathmon 8y ago
  The one open PR is a self described "first go" at a polyfill. https://github.com/tc39/proposal-temporal/pull/57 https://github.com/tc39/proposal-temporal/pull/57

eropple 8y ago

I stumbled across Luxon, also under the Moment umbrella, not too long ago and I think it's pretty slick. It feels a lot more natural to use.

Klathmon 8y ago
I saw that for the first time today elsewhere in this thread, and I really like it!

_ZeD_ 8y ago

>>> I love moment, but it's age is starting to show. according to https://github.com/moment/moment/blob/develop/CHANGELOG.md#030 https://github.com/moment/moment/blob/develop/CHANGELOG.md#0... the 0.3.0 release was from 2011. it's barely 7 years ago. And I'm non counting the fact that the current version is 2.22.2 (so there are at least 2 major ones). How... how can you tell it's aging?!

nawgszy 8y ago
Hopefully I can explain your downvotes a bit. The JavaScript ecosystem is in an entirely different place now. ES6 has made it feasible to write cleaner, more concise code, and Webpack has allowed library consumers to "naively" import a whole library but the algorithm known as 'tree-shaking' will remove any unused code, which can be especially valuable when a library has a few purposes which are somewhat orthogonal, and each requires has its own large codebase, aka Moment.
Klathmon 8y ago
Because not all things "age" at the same rate. (1 month old milk is old, a 1 month old can of tomato paste is far from old) Lodash (#1 in this article) is just as old or older than Moment, however I wouldn't call lodash "aging" simply because it has adapted to the new paradigms in the javascript ecosystem and works very VERY well with them (to the point that I'd argue lodash is a pretty good example of how to work with these tools). Moment still does a great job at what it does, and it's in no way getting "worse" over time (quite the opposite!), however because of some choices made during it's development, it can't easily take advantage of newer developments in the javascript ecosystem. JS has changed significantly, and is still changing. I'd argue that JS became a "real" programming language over the last 10 years, and because of that a lot of things created in that time aged much quicker than they should have. Like I (briefly) pointed out in my comment, things like tree shaking, module bundling, code splitting, minification, and the tooling and ecosystem around them have changed drastically in the last 5 years. Now moment will still work great with those things, but it doesn't take advantage of them. And that means that alternatives end up getting a leg up because they do take advantage of them. Something like `date-fns` is designed with tree-shaking in mind, so if I only want to use the part of it that "humanizes" a time range, i'll only get that code. If I want to provide multiple locales for multiple users, but only have each user download their own locale at runtime, I can do that easily. Not to mention that browser support has changed in the last few years, so most people no longer need to support IE 7, 8, 9, etc... And that means that the code that moment has built up to support those browsers isn't needed on newer ones, but again it's difficult or impossible to build it without that to save size. To continue the analogy I used at the start of my comment, I'd say moment is week old milk. It's not bad yet, but I wouldn't buy it from the store like that in most cases. Moment is great, I do use it in 2 projects at work because it was the best tool for the job for a long time, and it still works fantastically. However if I'm starting a new project now, i'm most likely going to reach for something else. Not because it's "newer" or because it's the hot thing right now, but because in all honesty the API of a date management library isn't all that complicated, and switching isn't a large cost. And when those other libraries can provide benefits that moment can't, i don't have much of a reason to stay with these "older" libraries.

spraak 8y ago

It is also sneakily mutable at times. Some methods will mutate the original object - the cause of a few bugs I've investigated recently

hinkley 8y ago
Why do [time] libraries all seem to make this mistake? I think I fixed the same concurrency bug due to misuse of Java’s date parser at four different companies (one of them I didn’t even work for). Use one object to hold configuration and another to hold state.

z3t4 8y ago

I usually copy/paste the functions I need :P