We started the Forge-based version of Dasher in 2016, and (much to my shame) some of the components had stayed at more-or-less the version available at that time, largely due to the migration effort needed to deal with breaking changes. Biting the bullet to upgrade them was painful but necessary, and right now I (and Dasher) feel nicely refreshed.
Last time I mentioned there were two big outstanding dependencies that still required attention: Bootstrap and Rollup. Bootstrap is a UI framework that allows you to design responsive websites, and was a choice that made sense for us when we started Dasher (React was still maturing and we wanted something where we could move quickly). There was quite a bit of work needed to upgrade Bootstrap from 3.x to 4.x, and then from 4.x to 5.x (going from 3.x to 5.x would have been beyond painful). But now it’s done, and we’ve a) been able to maintain the look and feel as much as we want to and b) been able to adopt some enhanced UI widgets where it makes sense. We’re now completely up-to-date with Bootstrap and I intend to keep it that way for some time, at least.
The migration effort for Rollup itself was fairly modest – there were a number of breaking changes, especially around new plugin versions, etc. – but one thing we added along the way was a bundle visualization step: there’s an awesome plugin that builds a webpage showing the make-up of your various bundles, which really helps understand what’s going on. (There are equivalent tools for other bundlers – such as this one for Webpack – in case you’re not using Rollup.)
Here’s a great example of where this has value: much of Bootstrap’s infrastructure to help support user interaction – such as event handlers for button clicks, etc. – works on the principle of toggling state. Which is great if you have one instance of Bootstrap loaded by your page, but if you happen to have two then the additional event handler toggles the state back to what it was, and so certain events are essentially cancelled out. This is a highly obscure problem to track down, but digging into the packages that have been included in your various bundles can help identify any that might be included inadvertently – or twice – and give you some clues of how to fix the problem. Rollup performs a process called tree-shaking – which strips out unused code – so it’s also helpful to understand when libraries (or pieces of them) have been included and when they’ve been stripped away.
This kind of visualizer also highlights areas that could be improved. In the above package you can see that a whopping 12.5% is taken up by a package called video.js. (It’s actually worse than that, as there are some dependent packages only used by video.js that would also be removed if we dropped it.) We only use video.js in certain rare scenarios, such as comparing video footage with extracted skeletons to validate the functioning of our computer vision pipeline.
But very few of the people who have access to Dasher will ever use it (and none of the people loading the demo from the public site), so having it part of the standard bundle just doesn’t make sense. It’s also one of the few remaining “outdated” modules in the Dasher codebase, so I’m all the more keen to drop it or move it to a separate “as needed” bundle.
Anyway, I just thought I’d share some of what I found out during this sometimes-arduous-but-ultimately-worthwhile process over the last few weeks. I hope it’s of interest – or even useful – to someone out there.