How to dev

How to dev

What is the size impact of importing Day.js

In this article, I'll take a look at how much the build size increases when you add Day.js library for date object manipulation.


Day.js is an interesting library that implements a similar API as moment.js but with a smaller overhead. Because it's implementing the same fluent interface, tree-shaking is not possible with it, but the library looks promising size-wise anyway.


The code I use in the benchmark is:

import dayjs from "dayjs";

console.log("Yesterday was", dayjs().subtract(1, "day").toDate());

It's the same logic I have in the luxon & date-fns example.

Build scripts

The build scripts I use are:

$ webpack --mode=production
$ esbuild src/index.js --outfile=dist/main.js --bundle --minify


And the results are as follow:


npm run webpack  

> day-js-bundle-size@1.0.0 webpack
> webpack --mode=production

asset main.js 6.64 KiB [emitted] [minimized] (name: main)
runtime modules 663 bytes 3 modules
cacheable modules 6.43 KiB
  ./src/index.js 95 bytes [built] [code generated]
  ./node_modules/dayjs/dayjs.min.js 6.34 KiB [built] [code generated]

$ stat dist/main.js
  File: dist/main.js
  Size: 6802     ...

The build output is 6.64 KiB. The webpack build is still pretty quick, contrary to the luxon benchmark, which was noticeably slower than esbuild.


$ npm run esbuild   

> day-js-bundle-size@1.0.0 esbuild
> esbuild src/index.js --outfile=dist/main.js --bundle --minify

  dist/main.js  7.0kb

⚡ Done in 4ms

$ stat dist/main.js 
  File: dist/main.js
  Size: 7191    ...

The esbuild output is 7.0KiB, which is about 5% bigger than the webpack one.


The benchmark repository.


In this article, I have shown the size impact of day.js on the build size.

Interested in reading more such articles from Marcin Wosinek?

Support the author by donating an amount of your choice.

Share this
Proudly part of