Managing long-term, part-time migrations
Back in July, I noted that GitHub had completed a long-running initiative to remove jQuery as a dependency from the github.com code base, and switch to vanilla JS.
I’d hoped that the team involved would write this up in more detail, and they haven’t disappointed. Last week they published an article about the changes on the GitHub Engineering blog.
The motivation for the changes weren’t so much about removing a 30KB dependency from production JavaScript bundles, but modernising their approach to progressive enhancement by making more use of updated browser capabilities.
They point out that:
sometimes technical debt grows around dependencies that once provided value, but whose value dropped over time
Aside from the technical changes themselves, the team also did some interesting things to keep up project momentum. Nobody was working on this initiative full-time, and it wasn’t run as a big-bang change. It was implemented gradually over a period of years alongside other commitments, and in the context of continuous change across the site.
Initiatives run in this way on a big codebase with lots of contributors in multiple teams can easily lose momentum and fizzle out, themselves becoming dated before they’ve really begun, leaving yet another dead-end legacy approach to maintain.
So, to keep things moving (albeit slowly), they:
- Tracked usage of jQuery across the codebase over time as a way to monitor progress
- Used a custom eslint plugin to prevent inclusion of jQuery in new code
- Clearly mark linting violations in older code
- Notified the team via a pull request bot when new eslint disabling comments were added
- Replaced internal behaviour of rails specific Ajax request APIs
- Maintained a custom modular jQuery build so individual modules could be phased out over time
The team were also able to remove some low some low-value JavaScript enhancements altogether, rather than rewrite them in vanilla JS. This highlights an often under-appreciated benefit of progressive enhancement.
They succeeded in completing the work (eventually), because:
- They had a clear goal
- Progress towards that goal was measured and made visible
- Used automation to prevent or highlight regressions against the goal
It’s not clear from the article how they made the case for the changes, which internal stakeholders needed to be persuaded, or what the inevitable hurdles were along the way. But it’s always good to see real-world case studies like this published for the benefit of others.
All the best,
– Jim
