Live data from Hacker News

You Don't Need Moment.js

github.com

31–40 of 91 posts

Re: You Don't Need Moment.js

#31

I 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…

300KB is more than enough for a fully functional website including _all code assets_. This is the sort of thinking that got us here.

Re: You Don't Need Moment.js

#32

I 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…

> for 99% of developers out there, a difference in 300kb is just completely irrelevant. If this is true, which I hope it's not, then I feel very sorry for anyone who doesn't live in a major first-world c̶o̶u̶n̶t̶r̶y̶ city and wants to enjoy the internet.

I feel like this is just a very short-sighted view of the JavaScript ecosystem. A huge amount of JavaScript applications aren't used internationally, aren't used on mobile, or simply aren't websites. I've worked on multiple projects that are served locally from a pre-downloaded package (for example a Kiosk UI).

Re: You Don't Need Moment.js

#33

If you are dealing with timestamps from the past (e.g. birthdays via a datepicker that constructs Date objects), then you should watch out for different browsers' inconsistent handling of Daylight Savings Time. Moment is really indispensable here, since it includes a database of past years' DST transition dates. I wrote a blog post about it here: https://illuminatedcomputing.com/posts/2017/11/javascript-ti...

I agree, it's similar to Joda for Java. Sure, Joda does some things that exist in the standard library, but you can be sure that by using Joda that you're getting it right in all kinds of twisted scenarios you never considered.

actually joda is built into java8+ called java.time

Re: You Don't Need Moment.js

#34

Earlier quoted context omitted.

> for 99% of developers out there, a difference in 300kb is just completely irrelevant. If this is true, which I hope it's not, then I feel very sorry for anyone who doesn't live in a major first-world c̶o̶u̶n̶t̶r̶y̶ city and wants to enjoy the internet.

I feel like this is just a very short-sighted view of the JavaScript ecosystem. A huge amount of JavaScript applications aren't used internationally, aren't used on mobile, or simply aren't websites. I've worked on multiple projects that are served locally from a pre-downloaded package (for example a Kiosk UI).

True, but in your OP you said 99%. Far more than 1% of javascript developers are working on websites and all of those people should be thinking twice before adding 300kb to their bundle size.

Re: You Don't Need Moment.js

#35

Earlier quoted context omitted.

After gzipping none of the variants are that large, and let's be real: the 3rd party ads and analytics and cat pictures are gonna strictly dominate the load time.

Just because there is even more bloat being loaded from other sources doesn't mean that adding more bloat doesn't matter. This kind of mindset has brought us to exactly this point where modern web sites are loading more slowly than one from 20 years ago would have while using dial-up.

[deleted]

Re: You Don't Need Moment.js

#36

If you are dealing with timestamps from the past (e.g. birthdays via a datepicker that constructs Date objects), then you should watch out for different browsers' inconsistent handling of Daylight Savings Time. Moment is really indispensable here, since it includes a database of past years' DST transition dates. I wrote a blog post about it here: https://illuminatedcomputing.com/posts/2017/11/javascript-ti...

Past time zones should only be a fairly specialist need: our front end code (SPA that is especially in the time domain) doesn't need to deal with past time zones. Then again, although our SPA is 100% JSON, we do all date and time processing at the server.

Putting UTC times into our front end would require the front end to know too many business rules.

> e.g. birthdays via a datepicker that constructs Date objects

> [From your comment in link]: The birthday will be wrong from the very start, because datepickers din't care about people can be born in some TZ and fill forms different TZs. Normally if you're only interested in date only, it doesn't matter if time part is off by hour or more hours. But if you live in Africa, then it could be whole day difference (because of how date will parsed).

I have trouble understanding your example - I am guessing you are sending UTC date including time of birth? Seems a little contrived. Maybe pick a better example (calendars or alerts and timezones?)

That said, I agree that trusting the browser implementation is mad. We still have clients accessing using IE8 (we just dropped support), Safari 7 (iPhone 4), and a fair number use Chrome 30/33 because that is the version the WebView is stuck on for Android 4.4.

Some of our users have the date on their computer set a week out (or more)!

Edit: just saw comment at end of your article "If your users enter birthdays with some kind of date picker, you probably suffer from this bug!". I think you just have a problem with your code: you would not use UTC date/time from a date picker, and you should either zero the time component or don't use Date internally when you just need a date - e.g. an input type=date naturally returns "yyyy-mm-dd".

Re: You Don't Need Moment.js

#37

I 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…

it depends on who will be downloading the bundle. if it's a group of consistent users primarily using desktop browsers, it may not be worth worrying about since they'll probably download it once at a fast speed and reuse from the cache repeatedly afterwards. if you have lots of new users on mobile using slow cellular connections, big libraries like moment.js add up and can really hurt load times and make for a poor u…

I think mobile phones have browser cache too.

Re: You Don't Need Moment.js

#38
The problem is that moment didn’t include locales as a default at one point, and then suddenly it did. And it’s the kind of thing you don’t want to do module splitting on, date functions can be used in all sorts of places so it’s really a core lib

Re: You Don't Need Moment.js

#40
post #33

Earlier quoted context omitted.

I agree, it's similar to Joda for Java. Sure, Joda does some things that exist in the standard library, but you can be sure that by using Joda that you're getting it right in all kinds of twisted scenarios you never considered.

actually joda is built into java8+ called java.time

Thanks for the tip, I had no idea and was still including the dependency.
Post reply on HN