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!
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 ) and is full of serious bugs that its developer does not respond to: https://github.com/iamkun/dayjs/issues
Also the code style is really concerning too: https://github.com/iamkun/dayjs/issues/1598
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?
There are times for immutability, and times for mutability. You have to be careful for different things.
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')
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.
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’)
It's not always the best (or even an) option, but it does spare you some concerns.