I’m super excited to highlight this awesome RFC from Lucas proposing to bring his Frozen Moment immutability plugin into the Moment.js core package as an optional add-on.
This RFC proposes a new Moment namespace, moment.frozen that wrappers all Moment functions with code that will automatically clone the Moment before performing mutations, creating an immutable API.
Moving forward, it is our desire to make the Frozen Moment immutable API the preferred way of interacting with Moment.js, effectively causing the library to become immutable. By making a second API, we allow legacy products to continue to function as before.
This all started when I wrote a blog post about why Moment isn’t immutable yet about a month ago. With the amount of enthusiasm we saw from the community, we decided to move forward with making Lucas’ plugin official.
As of right now, I am reworking our build process to allow us to better package this plugin.
In the meantime, we need community feedback on a few things:
- Should this be packaged as a separate plugin, or just live in the core library as a second API?
- What should this API be named? Frozen is a working name that probably will not be adopted. We have discussed “m“ and “mom“ as possible options.
- Should the immutable API be a second global instead of being attached to the Moment global?
- Should we simply make the “moment“ namespace immutable, and have a “momentLegacy“ namespace that users can use to overwrite the definition of moment for back-comparability if desired?
- How should plugins and other libraries that depend on Moment interact with this API?
- If we do overwrite the “moment“ namespace with an immutable one, should we release a compatibility build under a 2.0 version number? This build would have the same underlying code, but a mutable moment namespace.
Moving forward, we will be looking for contributors in a few key areas:
- Documentation rework (needs to handle multiple APIs)
- Package management
- Build
In particular, someone with a UX background who wanted to help us improve the design of the docs page to support multiple APIs would be greatly appreciated.
Happy commenting!
Maggie's Blog 
My biggest concern with these changes is that they respond to a disproportionately vocal and expressive part of the community – avoiding the quiet bulwark of ordinary developers who aren’t even aware this discussion is taking place.
GitHub’s threads are not a microcosm of the wider development community. It suffers the same participation bias as many forums on the web, and is biased towards a certain kind of developer: intellectually engaged with the theory; interested in ideas rather than applications; dare I say socially inclined to rallying around popular trends for the sake of their reputations. These developers are naturally attracted to philosophical cause célèbres like immutability and functional programming, and have closer access to you than any other group. They will be the loudest voice in the room, and they will clamour for this change – but what of the wider world?
The wider world wants Stuff That Works. It wants to know that the library it currently uses will continue receiving updates – bugfixes at least, but ideally small incremental improvements that make their lives better.
If you are intent on this change, you will need to make a very clear case to these people why this change will make their lives better; why they should upgrade; why they needn’t worry their legacy projects won’t receive indirect bugfixes; what things they will now be able to do that they could not presently. Because the wider world really does not care at all about immutability for its own sake – it cares about applications, not ideas.
I think you should also be very careful to validate the importance of this change in real terms. I would release this change as a plugin or wrapper, and monitor its uptake carefully over several months before I merged it into trunk. If immutability has been over-represented as a niche concern, you will have found a way to satisfy these vocal users without changing the course of the library as a whole.
LikeLike
@Jimmy Breck-McKye Brilliant point. Beyond the cool-to-some idea of immutability, what is the practical, real-world business advantage of this change?
LikeLike