But react-dates has moment as dependency, so…
Welcome to the wonderful world of code re-use. Hey, at least we're not re-inventing the wheel.
We're reimporting the wheel (which, by the way, also has moment.js as a dependency)
You Don't Need Moment.js
41–50 of 91 posts
Re: You Don't Need Moment.js
#42I 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?
Because every web browser and server understands gzip. The gzipped size reflects the transfer size for the file without doing anything at all exotic.
Re: You Don't Need Moment.js
#43If 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 > […
The problem is that if you use a zeroed time component, but at some point it's assumed 00:00:00 (midnight), shifting timezones might mean that it shifts to the previous day. Even if you then truncate the hour portion before display, the date is wrong.
For example, you use a datepicker at some point, and it stores 2000-01-01 00:00:00 in the US/Eastern time zone (because that's where you and the computer you're on are when you do it). If you happen to store that as UTC, you might find some interesting outputs for people on the West coast if you convert back to a local (US/Pacific) timestamp. Specifically, you'll get 1999-12-31 21:00:00, and if you do this blindly and throw away the hour portion, you still get the wrong date.
When you want dates, you often really want to store just the date potion. Any time you want a date and time, you probably also want a timezone along with it, or at a minimum, you want to know what type of output your use case requires and handle it appropriately. Dates and times are one of those things that seems simple until you've had to deal with the details and encountered the problems enough that you always treat it with a bit of respect.
Re: You Don't Need Moment.js
#44Earlier 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
We can only hope moment or at least its API gets similar treatment.
Re: You Don't Need Moment.js
#45The 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.
No, but it does add quite a bit of complexity, and if it's done correctly usually requires not just a database of timezones, but also when and how they've changed over the years.
Not supporting timezones is a valid design choice, but is so important and integral it should be the first item both mentioned by a library and used as criteria to decide whether it's a valid choice for those surveying libraries.
It's sort of like choosing a storage solution. Do you need persistent storage that can survive a reboot, or is something ephemeral that works only while powered good enough? Both have their places, but choosing the wrong one for your specific use case is usually very problematic.
Re: You Don't Need Moment.js
#46Earlier 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).
> A huge amount of JavaScript applications aren't used internationally, aren't used on mobile, or simply aren't websites.
This is the exception, not the rule. I find it hard to believe at 99/100 JavaScript programmers are not working mobile or web applications, where 300KB matters, even if you do some sort of content hashing.
Re: You Don't Need Moment.js
#47A good lightweight alternative is js-joda. I recently switched from moment.js and I've been very happy with it. https://js-joda.github.io/js-joda/
At 43kb gzipped, it's hardly lightweight - that's 70% of moment.js' size, 4x larger than date-fns
js-joda offers a lot more than lightweight native Date type wrappers like date-fns. It offers separate time and date implementations which allows you to more precisely model your problem. The native Date object always consists of a time, date, and timezone.
For example, a js-joda LocalDate is just a date without a time or timezone. This allows you to cleanly represent things like birthdays, anniversaries or holidays in an unambiguous way.
js-joda is also immutable which in my experience is more predictable and less error prone. With js-joda, "d.plusDays(366);" leaves d unchanged.
js-joda also has very good duration support.
Because it does not use the native Date implementation it is potentially more consistent across platforms. It is also has lots of tests.
If all you are doing is formatting a few dates, date-fns is probably sufficient and it is certainly smaller, but for more intensive manipulations of dates and times I think js-joda is well worth the size.
Re: You Don't Need Moment.js
#48A good lightweight alternative is js-joda. I recently switched from moment.js and I've been very happy with it. https://js-joda.github.io/js-joda/
Just like the OG Joda, I'm assuming it doesn't support nanosecond time resolution?
Re: You Don't Need Moment.js
#49Earlier quoted context omitted.
300kb is half a second to load for someone with a 5mb connection (which is still quite common in a lot of the world...and even in parts of the US). It's also a LOT of crap to parse on a lower end computer. Repeat with a few libraries, and you're going to need a Flash-style progress part as your app loads. That's not exactly a great user experience. Doesn't really matter if you're building an MVP or if you have bigger…
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.
Cat pictures don't interfere with my ability to interact with the web page.
The 2MB+ of bloated, unoptimised JS that you ship with your page that I need to parse and render before I'm allowed to see the 20kb of actual content _does_ interfere with my ability to use the page.