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…
You Don't Need Moment.js
31–40 of 91 posts
Re: You Don't Need Moment.js
#32I 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.
Re: You Don't Need Moment.js
#33If 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.
Re: You Don't Need Moment.js
#34Earlier 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).
Re: You Don't Need Moment.js
#35Earlier 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.
Re: You Don't Need Moment.js
#36If 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...
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
#37I 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…
Re: You Don't Need Moment.js
#38Re: You Don't Need Moment.js
#39Re: You Don't Need Moment.js
#40Earlier 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