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.

Library

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.

Code

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

Benchmark

And the results are as follow:

Webpack

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.

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.

Links

The benchmark repository.

Summary

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