You Don't Need Moment.js
github.com
You Don't Need Moment.js
1–10 of 91 posts
Re: You Don't Need Moment.js
#2There's also Luxon from (one of?) the maintainers of Moment: https://moment.github.io/luxon/.
It abuses the i18n api (by parsing the date out of a formatted string) to provide timezone support without shipping timezone data, which is pretty clever.
Re: You Don't Need Moment.js
#3The entire reason I need moment is so I don't have to do everything they're doing in that repo.
Re: You Don't Need Moment.js
#4I really don't understand this... while yes, I might at some point be interested in reducing my bundle size, for 99% of developers out there, a difference in 300kb is just completely irrelevant.
I choose my JS libraries because they are actively maintained, have well designed APIs (easy to use), are common enough to where newly hired developers already know them, and just generally make my life easier. This doesn't address any of that.
Re: You Don't Need Moment.js
#5[deleted]
Re: You Don't Need Moment.js
#6I really don't understand this... while yes, I might at some point be interested in reducing my bundle size, for 99% of developers out there, a difference in 300kb is just completely irrelevant. I choose my JS libraries because they are actively maintained, have well designed APIs (easy to use), are common enough to where newly hired developers already know them, and just generally make my life easier. This doesn't a…
Why and how are the suggested alternatives worse regarding the aspects you mentioned?
Re: You Don't Need Moment.js
#7The lack of timezone support in the two suggested alternatives (date-fns, dayjs) means they're not real alternatives for any use-case as soon as you're operating in a country with any DST, https://en.wikipedia.org/wiki/Daylight_saving_time_by_countr....
Re: You Don't Need Moment.js
#8I really don't understand this... while yes, I might at some point be interested in reducing my bundle size, for 99% of developers out there, a difference in 300kb is just completely irrelevant. I choose my JS libraries because they are actively maintained, have well designed APIs (easy to use), are common enough to where newly hired developers already know them, and just generally make my life easier. This doesn't a…
Yeah, I don't understand why comparisons are always made for gzipped code sizes. I mean, I could write something really small that is difficult to parse and abuses memory vs. something big but is all comments.
Why is this the first metric that is always trotted out?
Re: You Don't Need Moment.js
#9I really don't understand this... while yes, I might at some point be interested in reducing my bundle size, for 99% of developers out there, a difference in 300kb is just completely irrelevant. I choose my JS libraries because they are actively maintained, have well designed APIs (easy to use), are common enough to where newly hired developers already know them, and just generally make my life easier. This doesn't a…
Yeah, I don't understand why comparisons are always made for gzipped code sizes. I mean, I could write something really small that is difficult to parse and abuses memory vs. something big but is all comments. Why is this the first metric that is always trotted out?
Guess you have to measure yourself then :)
Re: You Don't Need Moment.js
#10The lack of timezone support in the two suggested alternatives (date-fns, dayjs) means they're not real alternatives for any use-case as soon as you're operating in a country with any DST, https://en.wikipedia.org/wiki/Daylight_saving_time_by_countr... .
Seriously... It's not like timezone support is some esoteric interest in a Date/Time library.