V-calendar: Moment.js implementation

[stephan-v]

Is there a reason this is not using moment.js as a dependency? I was expecting to find it in the package.json file.

I see there is a lot of code in the project that calculates things like leapyear, days in the week, first day of the month, etc. Logic like this could all be removed from the project with an implementation of moment.js.

Besides that, moment.js is already heavily used so there is a big chance a large project already relies on that library. I have been working on my own calendar implementation but I see a lot of potential in this project.

Thoughts on implementing moment.js?

[nathanreyes]

It was definitely considered. When I first started this project I wanted to keep it as lightweight as possible.

Currently, if I'm not mistaken, the minified g-zipped size the latest version of moment is approximately 1.5 times the size of v-calendar itself. I understand there are definitely benefits to moment.js, but the latest feature I am currently working on (recurring dates for attributes) really depends on efficiency and I'm not sure how it would perform using moment's API.

I will definitely revisit this in the future especially as the project stabilizes, especially if I have difficulty in the date logic itself or until I have time to experiment with it on another feature branch.

Sorry for the long response, but you do ask a good question and just want others to understand the reasoning here. I'm not closed to it for future discussions though.

[stephan-v]

Moment.js is 50.1kb gzipped and minified:

https://cdnjs.cloudflare.com/ajax/libs/moment.js/2.19.2/moment.min.js

Your package is currently 129b gzipped and minified:

https://unpkg.com/[email protected]/lib/v-calendar.min.js

Correct me if I am mistaken here though. Of course that is without the neccesary locales for moment.js but users should load what they need anyways, and they are not that large. It gets rid of many cross-browser inconsistencies that are going on with javascript dates.

An abstraction layer will not only get rid of code duplication for a standalone project, but it will also get rid of the import entirely if for any reason moment.js has already been imported. Besides that I can see that it would save quite some lines of code in this project.

Just food for thought here.

[nathanreyes]

I hear you. Maybe the numbers I last looked at (screenshot below) included lots of different locales.

Honestly, I'm not that up to speed with moment but I will probably start a separate branch here soon after I deliver the features I want before v1.0. Thanks for the input.

[shrpne]

@nathanreyes I'm definitely against moment, it is the monolithic and huge library. Obviously, not all of its features will be used in v-calendar and even in a large project.
In replacement, I suggest using any popular modular library, like date-fns. So v-calendar size remains minimal, and date-fns dependency could be reused.

[stephan-v]

@shrpne Actually the bundle sizes for moment.js and date-fns are similar with date-fns being somewhat larger actually, so please don't start shouting stuff of the rooftops when you haven't done your research.

[shrpne]

@stephan-v You don't have to include the whole date-fns, like you do with moment. You should import only those functions that you need, it will make overall size much smaller.

import {format} from 'date-fns/esm'
format(new Date(), 'MM/DD/YYYY')

[Jogai]

Since https://github.com/nathanreyes/v-calendar/issues/479 and https://github.com/you-dont-need/You-Dont-Need-Momentjs

I think this could improve the component, and seems better for maintenance too.