You Don't Need MomentJS | Hacker News Reader

You Don't Need MomentJS

github.com

25 pointstomcam23 comments

This is lacking context, the main reason for this repo is to provide alternatives due to the actual size of moment.js.

https://github.com/you-dont-need/You-Dont-Need-Momentjs/raw/... https://github.com/you-dont-need/You-Dont-Need-Momentjs

There are still many situations where these alternative solutions will not work. For example timezones.

But in general pulling moment.js in for one method call is pretty ridiculous if it can be replaced and needs to be ran on the clientside.

The truth is that MomentJS (and jQuery and other libraries/technologies that people love to hate) solve problems and are easy to work with. Not everyone need or care about bundle size, mutability, etc. They are fine with older, mature libraries that they are comfortable with using, because they are focused on solving real problems for clients, not optimizing they technology stack all the time. I'm tired of developers who value other developers based on if they use the latest hippest framework or not. I don't give a fuck if functional programming if so much better in theory, if OOP solves the problem! Sorry for the rant...

> Not everyone need or care about bundle size

This is the reason the web is fat, nay, morbidly obese. They solve problems for clients but they make the user experience suck, death by 1000 cuts/megs.

Rarely the actual case (which can be demonstrated from the fact that "the web" is mostly web pages, not webapps).

Bloat tends to originate from using way too many widgets/analytics coming from third-party domains.

Last time I checked analytics/widgets are still part of the web ecosystem and are part of the same culture of "just use X library". Classic tragedy of the commons where users suffer.

Everybody should be shaking their trees...

Thank you for this - and yes.

> I'm tired of developers who value other developers based on if they use the latest hippest framework or not

The thing is most developers are actually pretty terrible at shipping product and so they judge each other purely on technical decisions, not business ones.

Libraries, especially MomentJS, take a TON of guesswork out of something that's incredibly complex: date/time. I use Moment for anything dealing with time on the front-end because it's almost universal at this point (other devs can support), it's a VERY mature/supported product, and I can just _trust it_ at this point.

People talking about bloat in regards to jQuery/Moment (or insert any JS library that's over 3 years) usually fail to mention things like CDNs, gzip, HTTP2, etc etc. Truth is, if you practice good hosting methods you can get the entirety of jQuery 3.4.x WAY beneath 100kb, to the tune of approx 35kb (last I checked).

No consideration of timezones.

Looks like I still need MomentJS

Yep, timezone support is the primary reason I use MomentJS

If you do find the size of MomentJS to be troublesome for your particular usecase, and are in need of handling timezones, Luxon is a great alternative. It's from the authors of Moment, and I believe it uses the built-in i18n APIs found within modern browsers to handle timezones.

+1 for Luxon.

date-fns v2 supports timezones with the date-fns-timezone package https://www.npmjs.com/package/date-fns-timezone. Works well for me so far.

This is great news! Thanks for sharing. We've been pulling in moment-tz where needed but using date-fns in projects where timezones weren't needed.

What I take away from this is we need better first class date support in JS. Ideally, we don't include things like this. But in swift / iOS dev you get foundation + all of its awesome date handling. Dates are core to many apps. It should be first class.

The JS stdlib is abysmal, which is ridiculous given the cost of netwotk.

No uuid, no hashing, no zipping, no threading, limited random generation, super basic data structures...

So I have no hope for better date handling.

If you mean dates as just dates (no time part) then I agree 100%! So many environments think that if a date is good, then a date+time must be even better so just have the latter (and perversely call them "dates"). We'll just set the time part to 0, what could go wrong?

Then we get off by one dates when truncating the timestamp back down to just a date, when it happens in a different context than where the original timestamp ("date") was created and so falls on the wrong side of midnight, usually having gone through UTC in some intermediate system (if it didn't start there) with original context lost along the way. Had we really just wanted instants and not dates there would be no problem with that conversion, but a date is not an instant!

If the concern is around library size, sure, I'm on board with not needing MomentJS in many contexts. But my bigger worry is around people doing time based math/logic themselves. Don't do that. Use a library.

Timezones (there are way more than you think); daylight savings time (it's far more complex than you think); leap seconds; Logic around "is X plus 30 minutes after Y?" (you haven't considered every edge case).

Libraries in these contexts will save you from outages, bugs, etc. They've considered these edge cases. I primarily work in a Java world these days, and the java.time additions in Java 8 are (imho) more important than the Lambda additions. (And yes, there was Joda-time before, but the Joda author has explicitly said you should use java.time.)

So sure, if you're just getting the date in a specific format you can forgo MomentJS. But as soon as you start to want to do more things, maybe weigh in whether it's worth the size or not. That library is large because it contains a lot of important knowledge.

Why hand-holding developers into making specific library choices?

"You might not need jQuery" was reasonably useful, but that should have been it.

No need to turn everything into a meme.

Moment is somewhat the defacto standard for date manipulation in JS; it's to the point where most engineers I know will reach for it the minute they have to do any date/time work. This isn't too far off from a lot of people's usage of jQuery, and so the parallels in the name aren't unwarranted at all.

I found it really useful, as I'm already very familiar with Moment, but am hesitant to use it on future projects where I only need a small fraction of its capabilities and don't want to inflate my bundle size.

Didn't we already do this 10 months ago: https://news.ycombinator.com/item?id=17990859

Ah, this explains why in this post they linked to an actual file in the repo instead of the repos homepage.

Last I checked, the proposed alternative (date-fns) doesn't expose a straightforward way to parse an RFC3339 timestamp, without any further bells and whistles. That's the reason I last used Moment.js, but otherwise I'd be happy to remove that dependency.

Did you know new Date(someDateString) will get you different dates depending on browser unless you do some very precise date string. I learned this the hard way in my last task when I decided that using moment.js was overkill.

Reply on news.ycombinator.com