In this article, I'll summarize Day.js & date-fns comparison, that concludes this series.
Introduction
Based on what I've learned in the first round of articles, Day.js & date-fns look the most interesting.
date-fns
In the first test, where I used only one method, the application was at 1.6 KiB in both webpack & esbuild. That was the best result from all tested libraries, but the functional API of date-fns is built for tree-shaking. As this way of testing emphasizes gains of three-shaking, the size advantage of date-fns can diminish if we use more methods.
The second test, with using more methods started above 22 KiB. That's because format is huge. I found a smaller one that can achieve the same result by shopping around among many date formating methods. Then the final results were:
- webpack - 3.63 KiB
- esbuild - 3.6 KiB
Day.js
The main advantage of Day.js is that is has the same API as Moment.js. This makes it especially easy if we have Moment used all over the place in our project, and we want to replace is it with something smaller or newer. In my first test, the application was 6.64 KiB when bundled with webpack, and 7.0KiB with esbuild.
To keep the comparison fair, I recreated the second test app. I found a gotcha - Day.js pretend to provide complete API, but some method doesn't work as expected until you add a plugin with a correct implementation. With the plugin in place, the results are:
- webpack - 7.39 KiB
- esbuild - 8KiB
Verdict
I would go with date-fns for projects where I'm very build-size-conscious, and I can manage without a fully flexible format function. Day.js is for sure a good migration option for projects that are using Moment.js. The only downside is that we have to pay attention to all the plugins we need to import to ensure all works as expected. The 4KiB difference may not be enough to justify the effort of rewriting all the date manipulation logic.
Summary
This article concludes the series. Please let me know if there is some other library I should take a look at.
Top comments (0)