
You Don't Need MomentJS - tomcam
https://github.com/you-dont-need/You-Dont-Need-Momentjs/blob/master/lib/rules/methods.json
======
ic4l
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/raw/master/screenshot.png) [https://github.com/you-dont-need/You-
Dont-Need-Momentjs](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.

------
rlv-dan
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...

~~~
cameronbrown
> 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.

~~~
vemv
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.

~~~
cameronbrown
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.

------
Macha
No consideration of timezones.

Looks like I still need MomentJS

~~~
zcdziura
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.

~~~
networkimprov
+1 for Luxon.

------
ericlewis
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.

~~~
sixbrx
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!

------
mabbo
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.

------
vemv
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.

~~~
ericwood
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.

------
keanzu
Didn't we already do this 10 months ago:
[https://news.ycombinator.com/item?id=17990859](https://news.ycombinator.com/item?id=17990859)

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

------
ucarion
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.

------
fimdomeio
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.

