I was privileged to represent the JS Foundation at TC39 in January of 2017. Check out this report on the JS foundation blog.
It was awesome to see everybody at That Conference today. I was amazed at how much enthusiasm I got for the open spaces discussion along with the talk. These are the slides from today:
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
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.
Yesterday I wrote a post about how Moment.js isn’t immutable, and how it really isn’t in the cards for development right now.
I think as a team, we are sometimes not great about communicating things to our community that we are doing, and that are moving the library forward. As such, I wanted to write a short post about stuff we do have going on.
Next Major Release
The next major release of Moment.js and Moment TimeZone will have a complete rework of how the system handles time zones internally. This pull request is the completed work on the moment side. Tim has yet to get to the Moment TimeZone side, but it’s coming.
From a functionality standpoint for the library, this doesn’t really add much, though we might get in some syntactic niceties we didn’t have before. Internally though, we see a drastic improvement in our code base. This will allow us a lot more flexibility with new features down the road.
We also hope to have all of Moment changed over to Babel and Rollup by next major release. Again, this doesn’t add much for functionality, but it set us up to start using more ES2015 features. As a team, we have to decide what features we want to bring into the code and when. This is still in discussion.
There is no date for this, but all of this code is well in progress.
Other Stuff on the Table
- Modularized features
- I personally am very attached to getting this one done
- In particular, I would like to see a stand-alone parser that didn’t require the rest of the library
- Duration Formatting
- Non-Gregorian calendars
If any of these are particularly important to you, let me know!
Slides are here:
Slides about date and time!
Big thanks to everyone who showed up and asked awesome questions.
I’m at CodeMash today doing precompiler sessions, and I have to say that it has so far been a great time.
Today I spent most of my session in an “Improving Software Craftsmaship” session where we pair programmed several Katas. In the course of doing this, I found myself paired with a couple of people who were a bit faster to the punch than me on what needed to be done next.
Now, I’m used to this. My coworker Erik can always do basically everything faster than me, and believe me when I say that this doesn’t upset me. Erik is a friend, and I always appreciate his help. This was DIFFERENT though.
See, here at CodeMash, I’m walking around with one of the blue lanyards – I’m a speaker. So, when someone bests me at Katas, I feel like I haven’t lived up to some unsaid expectation. This caused me a bit of a panic attack. I found myself having to walk down the hallway and remind myself of these things:
- I am here to learn as well as talk
- I can practice and get better
- I have my own strengths
This post is admittedly trite, but I wanted to put it out there anyways as a reminder to everyone that, well, we all feel insecure sometimes.