The Madness of Modern Javascript

I came across this code recently while researching Magento 2’s UI Component system

initComponent: function (node) {
    if (!node.component) {
        return this;
    }

    loadDeps(node)
        .then(loadSource)
        .done(initComponent);

    return this;
}

That block in the middle might confuse a junior programmer, but I’m no spring chicken. That looks like a javascript promise and confusion around the .done(initComponent) being a different method than the initComponent whose scope we’re in at the moment, this should be straight forward code to follow.

Except – whose promises library is it? What are the nuances of how then and done handle calling loadSource and initComponent (how this is bound, how arguments, if any, are handled, etc.)? If we jump to loadDeps

function loadDeps(node) {
    var loaded = $.Deferred();

    registry.get(node.deps, function (deps) {
        node.provider = node.extendProvider ? deps && deps.name : node.provider;
        loaded.resolve(node);
    });

    return loaded.promise();
}

we see the promise comes from $.Deferred() – but it $ jQuery? Or some other library that’s decided to yoink the $ global? Or is $ scoped to something else locally? If it is jQuery is Deferred() a built in jQuery promise library, or something third party?

I love developing software for the web – but one of the reasons I love it is the code’s relatively straight forward to follow, changes in your code show up relatively directly in your browser, and the tools are simple enough that there is a general, world wide consensus on how things should work. Or maybe that should be “”was“ easy to follow, or "there was” a consensus.

Modern javascript, by and large, doesn’t seem to represent or respect any of those values. Each code base builds its own version of the world from the ground up, and getting involved in projects means investing heavily in trying to intuit what the rules of each strange new world are. That’s a maddening way to run a career.