How GitHub switched from jQuery to, well, nothing

This recent tweet from GitHubber Mislav Marohnić certainly grabbed lots of attention.

We’re finally finished removing jQuery from http://GitHub.com frontend. What did we replace it with? No framework whatsoever:

• querySelectorAll,
• fetch for ajax,
• delegated-events for event handling,
• polyfills for standard DOM stuff,
• CustomElements on the rise.

I feel sorry for Mislav, because this tweet generated a lot of questions, and he clearly spent some time responding.

There is of course plenty of discussion about the technical approach, because it’s still relatively atypical.

As many of the replies expressed, I hope that Mislav or someone else at GitHub will be able to write up a blog post to cover why they settled on this approach and how they executed it, because I think it would make a refreshing change from Why BlingSpurtle Switched From Foo.js To Bar.js.

One question and answer in the thread really stuck out for me:

C. Spencer Beggs asks:

How long did it take?

Mislav replies:

YEARS 😲

Now, it’s not completely clear if he means that it took years to execute their very specific pre-defined plan. It’s far more likely that they spent most of that time developing the necessary conditions in the company for it to happen, and only a short time actually doing the technical work to carry it out.

What do I mean by this? Well, for this work to happen, they would have had to:

• Identify the people (who may identify themselves) to advocate for the benefits of taking this approach.
• Weighed it against all the other options, especially as mainstream JavaScript framework adoption is currently the de facto approach for moving away from jQuery.
• Wait for the the necessary stability in browser capabilities and adoption. They seem to have dropped a lot of IE11 support, for example
• Demonstrated feasibility of the approach to leaders and other stakeholders. This is likely to have been a stop-start, iterative approach in itself, involving experiments and a long trail of failed attempts.
• Prioritised the work against other efforts and waited for an opportunity to push it forward.

I’m really interested to hear about case studies like this, but the worst thing you can do is use it as direct evidence that you should take a similar path, without understanding the full background behind it.

It’s so easy to take a rose-tinted view of other teams’ celebrations on social media, because we don’t get to see the internal politics, failed experiments, blind alleys, de-priorisations and other barriers that got in their way. All we see is the end result.

What improvements you currently trying desperately to get pushed through? And what is getting in your way?

All the best,

– Jim