I occasionally give a conference talk. I’m not a professional DevRel person, and the whole community doesn’t know who I am – so at the beginning of these talks, I usually put a “Who I Am” slide. This is the content of the slide from my library design patterns talk:

Who am I?

• Engineering Manager in Azure SRE
• A maintainer (not the author) of Moment.js
• JS Foundation Representative to TC39
• Champion of Date rework in JavaScript (tell me your thoughts!)

I suppose that to some this slide sounds ‘impressive’ or whatnot – the big tech company, well-known open source project, and standards committee. But I feel as though I should delete everything there, and just put this:

Enterprise Software Developer

I put things like ‘Engineering Manager in Azure SRE’ on my slides because the community responds to those words, finds them interesting, gives them respect. Maybe they think I work on ‘cool high scale distributed systems’ – and I do. Understand though, at the end of the day, my team makes line of business software to help quickly mitigate incidents in the cloud. We’re enterprise software developers, and we keep your application running.

Now, ‘Enterprise Software Developer’ is a term that is met with disdain by some people. People hesitate to use it in job descriptions due to fear it will drive away candidates. Writing ‘enterprise software’ is just plain ‘uncool’. People want to work on ‘high scale distributed systems’ or ‘languages and frameworks’ or at ‘startups’. We venerate people who work in these spaces, and follow them by the thousands on Twitter. Enterprise software is seen by many as what people do when they aren’t very good or interesting. They say it’s ‘not a hard technical problem’.

And yet, I love it. I love understanding business requirements and translating them into code. I love the people I get to interact with and the complexities I get to unwind. I find it challenging. I can see that it’s a skill that I am specialized in – not the work of a lowest common denominator developer.

What about the whole thing with the standards committee? Isn’t that languages and frameworks?

Sometimes I joke and say that I’m the ‘local idiot’ at TC39. There’s a grain of truth to that one – I’m surrounded by people with a much stronger understanding of the languages problem space than me. People who are much deeper in the tools. People with academic backgrounds I can’t even begin to compete with, and IQs that are… staggering. I’ve never written a lexer, parser, or compiler in my life, and have only a fuzzy understanding of how do to it at all – so I stand out a bit in this crowd.

Yet, even among language geniuses, the skills of an enterprise software developer are needed.

It turns out that most people on TC39 have not sat down and written line of business software in years, if ever. And yet TC39’s target user is usually enterprise software developers. So I get asked a lot of questions – about user expectations, how young developers learn, and what the practical cases for a feature would be. A lot of proposals have example cases from the HR software I used to write.

Oh, and dates. I have the expertise to champion the rework of Date in JavaScript because I spent many years writing “enterprise” time and attendance software.

Do I add as much value as others on the committee with more domain expertise? Certainly not. But I add my own unique value – as an enterprise software developer.

I am an enterprise software developer.

I translate business requirements to code.

I’m damn proud of it.

It adds value to the community.

It keeps the cloud running.

It is what most developers actually do.

So, if you’re an enterprise software developer out there who feels ‘uncool’ or ‘non-technical’ – as I have many times in my life. Nah. You’re awesome. Your software runs the world. The world knows it.

And if you’re a developer who puts down that ‘enterprise software’ stuff – consider how hard it is, and how much value it adds. It’s keeping your product up and running on the cloud – right now.

Hi All!

I was very lucky to have TC39 conveniently hosted at my home-campus – Microsoft in Redmond Washington – this July. It made for a very easy commute, and an enjoyable time.

Starting off on a non-code note, TC39 has elected a new chair – Rex Jaeschke. Rex will serve in this capacity for the September and November meetings as a trial period. At that time, the committee will vote on whether to move forward with him permanently. In addition, the committee elected Leo Balter and Dan Ehrenberg as vice-chairs who will help Rex as he learns the ropes of TC39.

Rex brings an exceptional resume to TC39. He authored the PHP and Hack specifications, and is also currently serving as the editor of the standard for the C# programming language. I very much look forward to what Rex can bring to the table as we continue to grow as a committee, and focus on improving diversity.

July had an unusually packed schedule, and I couldn’t possibly write a blog post that covers everything, but here are some proposal highlights from the meeting:

Optional Catch Binding

In the ‘common sense prevails’ category, I’m happy to report that Optional Catch Binding advanced from stage 0 to stage 3. This is a simple but very necessary change. In the past, it was required to pass a variable to a catch block, like this:

try {
} catch(e) {
}

With this proposal, the following is sufficient:

try {
} catch {
}

This is a simple change, but one I very much appreciate. Why type what you don’t need?

Fields and Private Methods

The class fields proposal advanced to stage 3.

The start of this proposal may seem un-intuitive to developers at first glance, but it actually enables some wonderful things. The first thing this proposal does is allow someone to define fields on a class:

export class Cat {
  Name;
  Age = 4;
}

If you want to, you can also define static fields on the class, which are attached to the prototype object instead of the instance:

export class Cat {
  Name;
  Age = 4;
  static Noise = 'Meow';
}

So why would we want to do this? Well, first of all, it provides serious perf gains to the runtime by allowing the runtime to know what fields will be on the class up-front. It does this by ensuring that, behind the scenes, all fields are declared in the class constructor.

But perhaps most awesome for library authors in the world (and everyone else too), is that the ability to declare a field enables us to make a field private! For instance, if I want the noise a cat makes to be internal:

export class Cat {
  Name;
  Age = 4;
  static #Noise = 'Meow';
  makeNoise() { return Cat.#Noise; }
}

Now, I don’t know about everyone else, but for me that right there is a game-changer. I don’t know how many times I’ve had to repeat myself on Moment’s GitHub: “The fields marked with an _ are private, don’t use them!”

My problems are solved! Actual private fields! Just add #.

But it gets even better than that.

Private Methods

Private methods advanced to stage 2. Private methods piggyback on the work in the class fields proposal that advanced to stage 3.

export class Cat {
  Name;
  Age = 4;
  #rightFrontLeg = 0;
  #leftFrontLeg = 0;
  static #Noise = 'Meow';
  makeNoise() { return #Noise; }
  #moveRightFrontLeg() { this.rightFrontLeg++; }
  #moveLeftFrontLeg() { this.leftFrontLeg++; }
  batPaws () { this.#moveRightFrontLeg();
    this.#moveLeftFrontLeg();
  }
}

Having highlighted all concepts of private fields previously, I think that the code probably speaks for itself. The individual methods for moving the cat’s legs are inaccessible outside the class, because the methods have been marked private.

Promise.prototype.finally

The proposal for Promise.prototype.finally brings a feature that is immensely popular in the libraries Q and bluebird. This feature allows the user to ‘clean up’ after a promise is completed, regardless of whether it was a success or failure. The following code illustrates a typical use case for finally, where an HTTP request is being timed for debugging purposes. Regardless of success or failure, upon return of the promise, the time should log.

function getThing(uri) {
  const time = performance.now();
  fetch(uri).then(result => {
    return result;
  }).catch(err => {
    //log error somewhere
  }).finally(()=>{
    console.log(performance.now() - time);
  })
}

In Closing

It is with both happiness and regret that I mention that longtime JS Foundation representative to TC39, Leo Balter, has changed his delegate status to being a representative of his employer, Boucoup. I am happy because Leo has gotten the support of his employer to make TC39 a ‘day job’ kind of thing. This is definitely best for him. I also say this with regret because Leo has always been a passionate advocate on the committee of some things that JS Foundation holds most dear, including being the driving force behind the new code of conduct, and a continual champion of diversity and inclusion. I look forward to continuing to work with Leo on many great things.

I remain the JS Foundation’s representative to TC39. In this capacity, I wish to bring the voice of the community to all TC39 activities. If you wish to contribute ideas to the standard, feel free to get in contact with me. DMs are always open on twitter.
There are some amazing proposals headed toward us in ECMAScript, and I’m incredibly excited for what is coming!

Amazingly awesome crowd at JSConf EU today! Can’t believe how many people where here. Check it out:

Packed house for @maggiepint on library design patterns. #jsconfeu pic.twitter.com/3m0MAAJeKQ

— Tom Dale (@tomdale) May 7, 2017

//platform.twitter.com/widgets.js

Thanks everyone for listening to me the whole time.

A PDF version of the slides is here:

JS Library Design

This didn’t render well – so check back for fixes in the future.

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 hope to talk to some people tomorrow at 10:30 in the open spaces area about moving JavaScript libraries forward.

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!

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!