Don’t Blindly Use Libraries
Last week we introduced Routine Sorting on My Morning Routine. In a nutshell, we added informative data labels on every routine card, as well as the ability to sort routines based on these data points.
Sorting is a common use case and can be achieved in many ways. The most convenient solution is to use a library, because often, these days, someone else has probably already implemented what you need. While I find this okay for quick prototypes and trivial projects, I believe you shouldn’t add third-party code to most projects without a broader evaluation. It’s not only about dependencies and security (you can switch), it’s also about performance, and by that I mean the overall performance of your website/app and not the third-party code per se. Heck, I’m sure that someone else has implemented a better sorting algorithm, but for My Morning Routine mine suits best—and that’s what it is about (plus, it’s probably easier for the author=you to maintain and scale). Open source libraries, frameworks, etc. are great, but they often come with much more than you actually need for a given project.
For example, I considered using TinySort, because the core is already very compact, but I still didn’t need many of its features and would have had to implement others (bedtime after midnight) myself.
Below is a footprint comparison that shares more insights.
Note: Filesize is of course not alone an indicator of performance, you should profile the whole thing. In my case the actual sorting algorithm is very basic, so I used the saved time to write this post instead.
Sorting only
The minified version of MMR’s sorting code is almost six times smaller, and the compressed version five times. Plus it already covers the bedtime is after midnight case, which I’d still have to develop and add to TinySort.
MMR Sorting | TinySort |
---|---|
619 bytes minified | 3.645 bytes minified |
376 bytes compressed | 1.755 bytes compressed |
The complete code
This includes among others the dropdown, states, no-data-marker, and also our featured filter. The compressed MMR’s solution is more than two times smaller, and the footprint of TinySort doesn’t include the bedtime is after midnight case.
MMR Sorting | TinySort |
---|---|
2.970 bytes minified | 5.996+ bytes minified |
1.007 bytes compressed | 2.481+ bytes compressed |
You might think that I’m nuts discussing such a small footprint, but considering that this is only a little feature and you might have dozens of them, it adds up very quickly. And don’t get me wrong, TinySort is great, it just wasn’t ideal for our use case. So the next time you’re about to add another library or really any third-party code, take a few minutes and evaluate how much of its features (and edge case handlers) you’ll actually use and need.