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

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

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.

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.

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

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.

Spent several hours debugging that one a couple of years 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.

I like to say that mutable state is to software as moving parts are to hardware (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.

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?

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.

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.