3 ms·

Considering moment.js says[0] you should actively consider alternatives instead of it, I can't disagree. But I do like the breakdown of what to use when instea

Considering moment.js says[0] you should actively consider alternatives instead of it, I can't disagree. But I do like the breakdown of what to use when instead! [0] https://momentjs.com/docs/#/-project-status/ https://momentjs.com/docs/#/-project-status/

amarshall 5y ago
In fact, Moment’s post links to the OP here.
jimmaswell 5y ago
There's nothing wrong with mutable objects, in fact I've always preferred them. I hope making everything immutable is a fad that passes.
- echelon 5y ago
  Mutability introduces an entire class of bugs and is slower to execute. If don't mutate something, it's almost always frictionless and better to make it immutable. There is tooling around immutability and a whole host of compiler optimizations. The resultant code is far less error prone. Do you feel the same way about static typing?
  - jraph 5y ago
    Immutability may enable compiler optimizations, but it also requires copying things around or applying clever tricks so performance isn't too bad. There are times for immutability, and times for mutability. You have to be careful for different things.
    - beebeepka 5y ago
      No. Proper theology demands that you must go with the latest react trend and discard everything else until they change their mind again and generate a ton of blog posts teaching you what was rejected a couple of years ago.
  - orf 5y ago
    It’s not so straightforward as “it’s slower to execute”. Often excessive copying of immutable objects instead of mutating them means code is slower, especially in JavaScript.
- sa46 5y ago
  I'm pretty comfortable declaring that creating a mutable-by-default date, string, or number library is a mistake. I'm not on the make-all-the-things-immutable train but making dates mutable is a painful mistake that Java painfully worked through with JSR-310, the new date and time library. Part of the problem is that moment would both mutate the underlying object and return the object. const a = moment() const b = a.add(1, 'second') Both b and a are now the same object. I've lost a few hours to the design choice.
  - NegativeLatency 5y ago
    Spent several hours debugging that one a couple of years ago
    - moogly 5y ago
      I think the Dev Tools in Chrome might have changed since (I don't use Chrome anymore), but we had issues maybe 5 years ago when hovering over momentjs watch statements in the debugger kept on mutating the underlying data. That was fun.
  - fastball 5y ago
    I think the problem there is more one of library design than specifically a mutable object problem. If `a` is mutated by the `.add()` method, then it should probably return void rather than returning a copy of the object. Is the immutable DX still better in this specific example? Probably. But the above at least would help developers avoid the major footgun with mutability.
  - deleted 5y ago
    [deleted]
  - 01acheru 5y ago
    It’s just a matter of RTFM I guess, the a.add() method returns “a” so that you can chain methods on the same object without creating a new object on every method call. Else: a.add(1, ‘second’).add(1, ‘day’).subtract(2, ‘minute’) would create 3 more objects that are not needed. Creating a new moment object is expensive, it happened to me to work with a lib that grew exponentially slow when using above N dates because they where constantly recreating moments instead of using them wisely so creating a new one on every operation would be quite bad. That’s why the method .clone() exists, so you can declare that explicitly: const a = moment() const b = a.clone().add(1, ‘second’) PS: don’t take RTFM as an offense, I just happen to like it a lot and we use it frequently at work, I don’t mean to be disrespectful towards you :)
- kristiandupont 5y ago
  I like to say that mutable state is to software as moving parts are to hardware (https://kristiandupont.medium.com/mutable-state-is-to-software-as-moving-parts-are-to-hardware-dd53303a97cd https://kristiandupont.medium.com/mutable-state-is-to-softwa...). It's not always the best (or even an) option, but it does spare you some concerns.
sydd 5y ago
the breakdown is not complete, for example I needed to pull in a new library to get the localized first day of the week with Luxon (this differs based on locale) Also I really don't recommend dayJS, its documentation is crap (for example this is the documentation of its timezone plugin: https://day.js.org/docs/en/plugin/timezone https://day.js.org/docs/en/plugin/timezone ) and is full of serious bugs that its developer does not respond to: https://github.com/iamkun/dayjs/issues https://github.com/iamkun/dayjs/issues Also the code style is really concerning too: https://github.com/iamkun/dayjs/issues/1598 https://github.com/iamkun/dayjs/issues/1598
- moogly 5y ago
  I worked on an app that was centered around scheduling a recurring future event in, if you needed to, an arbitrary (not necessarily the user's) timezone, about a little over a year ago and we had to ditch Dayjs due to timezone bugs. Luxon was our choice and it did the job.

amarshall 5y ago

In fact, Moment’s post links to the OP here.

jimmaswell 5y ago

There's nothing wrong with mutable objects, in fact I've always preferred them. I hope making everything immutable is a fad that passes.

echelon 5y ago
Mutability introduces an entire class of bugs and is slower to execute. If don't mutate something, it's almost always frictionless and better to make it immutable. There is tooling around immutability and a whole host of compiler optimizations. The resultant code is far less error prone. Do you feel the same way about static typing?
- jraph 5y ago
  Immutability may enable compiler optimizations, but it also requires copying things around or applying clever tricks so performance isn't too bad. There are times for immutability, and times for mutability. You have to be careful for different things.
  - beebeepka 5y ago
    No. Proper theology demands that you must go with the latest react trend and discard everything else until they change their mind again and generate a ton of blog posts teaching you what was rejected a couple of years ago.
- orf 5y ago
  It’s not so straightforward as “it’s slower to execute”. Often excessive copying of immutable objects instead of mutating them means code is slower, especially in JavaScript.
sa46 5y ago
I'm pretty comfortable declaring that creating a mutable-by-default date, string, or number library is a mistake. I'm not on the make-all-the-things-immutable train but making dates mutable is a painful mistake that Java painfully worked through with JSR-310, the new date and time library. Part of the problem is that moment would both mutate the underlying object and return the object. const a = moment() const b = a.add(1, 'second') Both b and a are now the same object. I've lost a few hours to the design choice.
- NegativeLatency 5y ago
  Spent several hours debugging that one a couple of years ago
  - moogly 5y ago
    I think the Dev Tools in Chrome might have changed since (I don't use Chrome anymore), but we had issues maybe 5 years ago when hovering over momentjs watch statements in the debugger kept on mutating the underlying data. That was fun.
- fastball 5y ago
  I think the problem there is more one of library design than specifically a mutable object problem. If `a` is mutated by the `.add()` method, then it should probably return void rather than returning a copy of the object. Is the immutable DX still better in this specific example? Probably. But the above at least would help developers avoid the major footgun with mutability.
- deleted 5y ago
  [deleted]
- 01acheru 5y ago
  It’s just a matter of RTFM I guess, the a.add() method returns “a” so that you can chain methods on the same object without creating a new object on every method call. Else: a.add(1, ‘second’).add(1, ‘day’).subtract(2, ‘minute’) would create 3 more objects that are not needed. Creating a new moment object is expensive, it happened to me to work with a lib that grew exponentially slow when using above N dates because they where constantly recreating moments instead of using them wisely so creating a new one on every operation would be quite bad. That’s why the method .clone() exists, so you can declare that explicitly: const a = moment() const b = a.clone().add(1, ‘second’) PS: don’t take RTFM as an offense, I just happen to like it a lot and we use it frequently at work, I don’t mean to be disrespectful towards you :)
kristiandupont 5y ago
I like to say that mutable state is to software as moving parts are to hardware (https://kristiandupont.medium.com/mutable-state-is-to-software-as-moving-parts-are-to-hardware-dd53303a97cd https://kristiandupont.medium.com/mutable-state-is-to-softwa...). It's not always the best (or even an) option, but it does spare you some concerns.

sydd 5y ago

the breakdown is not complete, for example I needed to pull in a new library to get the localized first day of the week with Luxon (this differs based on locale) Also I really don't recommend dayJS, its documentation is crap (for example this is the documentation of its timezone plugin: https://day.js.org/docs/en/plugin/timezone https://day.js.org/docs/en/plugin/timezone ) and is full of serious bugs that its developer does not respond to: https://github.com/iamkun/dayjs/issues https://github.com/iamkun/dayjs/issues Also the code style is really concerning too: https://github.com/iamkun/dayjs/issues/1598 https://github.com/iamkun/dayjs/issues/1598

moogly 5y ago
I worked on an app that was centered around scheduling a recurring future event in, if you needed to, an arbitrary (not necessarily the user's) timezone, about a little over a year ago and we had to ditch Dayjs due to timezone bugs. Luxon was our choice and it did the job.