8 ms·

You Don't Need Moment.js

241 points by ggregoire 8y ago

nicoburns 8y ago
There's also Luxon from (one of?) the maintainers of Moment: https://moment.github.io/luxon/ https://moment.github.io/luxon/. It abuses the i18n api (by parsing the date out of a formatted string) to provide timezone support without shipping timezone data, which is pretty clever.
- owenversteeg 8y ago
  Oh, that's a beautiful hack, I love it.
rublev 8y ago
The entire reason I need moment is so I don't have to do everything they're doing in that repo.
danielvinson 8y ago
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 address any of that.
- Sujan 8y ago
  Why and how are the suggested alternatives worse regarding the aspects you mentioned?
- phaedryx 8y ago
  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?
  - k__ 8y ago
    Guess you have to measure yourself then :)
  - owenversteeg 8y ago
    Because it's a simple, universal metric. Accurately stating the the performance impact of something like Moment is extremely involved and entirely dependent on how your project works and your users.
  - hinkley 8y ago
    Because every web browser and server understands gzip. The gzipped size reflects the transfer size for the file without doing anything at all exotic.
- big_elephant 8y ago
  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 user experience. for circumstances like that, a developer might look at what are the biggest libraries in their vendor bundle and look for ways to reduce them via tree-shaking or find alternatives, that is if they are even aware of how slow their current bundle might be for mobile users. i think this is for that kind of use case, not only to offer alternatives to those who might need it, but also to raise awareness for those who develop on their desktop and don't engage with their app like most of their users do
  - appleiigs 8y ago
    I think mobile phones have browser cache too.
    - big_elephant 8y ago
      sorry, i shouldn't have mentioned caching. the emphasis should have only been on connection speed
- shados 8y ago
  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 fish to fry, but eventually it certainly matters. There's a reason the modern web is so freagin slow, and only half of it is because of slow backend APIs.
  - angersock 8y ago
    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.
    - this_user 8y ago
      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 8y ago
        [deleted]
    - FridgeSeal 8y ago
      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.
      - angersock 8y ago
        The library in question is nowhere near 2MB. You're tilting at windmmills.
- deleted 8y ago
  [deleted]
- anonytrary 8y ago
  > 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.
  - deleted 8y ago
    [deleted]
  - danielvinson 8y ago
    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).
    - s17n 8y ago
      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.
    - anonytrary 8y ago
      > 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.
- robocat 8y ago
  I'm assuming you don't have anything to do with mobile web design. Our complex single page app is approximately 180kb gzipped (JavaScript files and a single html main page) - no html from the server except for reports. Size is very important for first visit (lower delay loading files over cellular), and important for subsequent cached visits (mobile devices are slow to parse JavaScript).
- ricardobeat 8y ago
  300KB is more than enough for a fully functional website including _all code assets_. This is the sort of thinking that got us here.
- h1d 8y ago
  I wonder how many seconds it takes to load your site on mobile when you think 300KB is irrelevant in your product. From users point of view, it's irrelevant what you use inside but how snappy things are.
- fouc 8y ago
  https://infrequently.org/2017/10/can-you-afford-it-real-world-web-performance-budgets/ https://infrequently.org/2017/10/can-you-afford-it-real-worl... https://infrequently.org/2018/09/the-developer-experience-bait-and-switch/ https://infrequently.org/2018/09/the-developer-experience-ba... https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4 https://medium.com/@addyosmani/the-cost-of-javascript-in-201...
- boubiyeah 8y ago
  Devs like you is the main reason why the web is much, much slower than it could be. Perhaps it's time to start reading about UX , browser JS parsing speed, how JS executes, etc. Making your dev life easier is nice, but don't forget the end goal... (Note: I'm not talking about those internal apps that have 10 users :p)
deleted 8y ago
[deleted]
baliex 8y ago
The 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_country https://en.wikipedia.org/wiki/Daylight_saving_time_by_countr....
- sushid 8y ago
  Seriously... It's not like timezone support is some esoteric interest in a Date/Time library.
  - kbenson 8y ago
    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.
- benmccann 8y ago
  I've sent a PR to date-fns to add time zone support, but the maintainer doesn't seem to have much bandwidth to review it. In the meantime, I'm going with Luxon
- dcposch 8y ago
  I wrote a tiny library, tzjs, for exactly this reason. Modern browsers have built-in timezone support via window.Intl. It's actually pretty nice! One glaring omission in the spec: given (UTC instant, tzname), there is no clean way to get that offset for that timezone at that moment. tzjs works around this omission. This saves a lot of bundle space. moment-timezone includes the whole tzdata dataset: https://bundlephobia.com/result?p=moment-timezone@0.5.21 https://bundlephobia.com/result?p=moment-timezone@0.5.21 https://github.com/dynasty-com/tzjs https://github.com/dynasty-com/tzjs
jmhain 8y ago
A 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/ https://js-joda.github.io/js-joda/
- ricardobeat 8y ago
  At 43kb gzipped, it's hardly lightweight - that's 70% of moment.js' size, 4x larger than date-fns
  - dmm 8y ago
    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.
- Rapzid 8y ago
  Just like the OG Joda, I'm assuming it doesn't support nanosecond time resolution?
ggregoire 8y ago
But react-dates has moment as dependency, so…
- BigJono 8y ago
  Welcome to the wonderful world of code re-use. Hey, at least we're not re-inventing the wheel.
  - nkozyra 8y ago
    We're reimporting the wheel (which, by the way, also has moment.js as a dependency)
- pnevares 8y ago
  https://github.com/airbnb/react-dates/blob/master/package.json#L95 https://github.com/airbnb/react-dates/blob/master/package.js... A devDependency is not the same as a dependency.
  - scottlecrab 8y ago
    It's a dev dependency because they use it in unit tests but it's also a peer dependency, meaning that if you want to use the library you need to include moment.
    - pnevares 8y ago
      That's my error, thanks for the correction.
pjungwir 8y ago
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-timezones/ https://illuminatedcomputing.com/posts/2017/11/javascript-ti...
- anothergoogler 8y ago
  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.
  - merb 8y ago
    actually joda is built into java8+ called java.time
    - anothergoogler 8y ago
      Thanks for the tip, I had no idea and was still including the dependency.
      - rhacker 8y ago
        It's not API compatible, so if you use Joda and you're thinking of using java.time, it's going to be a lot of refactoring.
        Freak_NL 8y ago
        It's pretty straight forward to migrate from Joda to Java 8's builtin classes though. Just remove the dependency on Joda Time and let the compiler tell you which files to fix. This blog post lists which Java 8 classes replace their Joda Time counterparts: https://blog.joda.org/2014/11/converting-from-joda-time-to-javatime.html https://blog.joda.org/2014/11/converting-from-joda-time-to-j...
caseymarquis 8y ago
Most of moment's size is in the localizations. You can reduce it from 300kb to 100kb by removing them or only including the ones you care about: https://stackoverflow.com/questions/25384360/how-to-prevent-moment-js-from-loading-locales-with-webpack https://stackoverflow.com/questions/25384360/how-to-prevent-... I think the bigger lesson, if moment's size is news to you (for those of us using webpack), is to install webpack-bundle-analyzer. It's loads of fun, if you like visualizations.
- dcposch 8y ago
  You can further reduce that to 0kb by using window.Intl . You get locale and timezone aware date formatting, built-in on all modern browsers. The API is pretty nice! https://caniuse.com/#feat=internationalization https://caniuse.com/#feat=internationalization
the-pigeon 8y ago
For all the problems with Moment.js this article really sells it as the better solution for many use cases.
anonytrary 8y ago
Whenever a "you might not need this heavy, popular lib" gets posted to HN, the responses are always pretty divided. I always try and write my own functions and import things like lodash, underscore, jQuery, and moment as a last resort. Bundle size may not be that important to the people working on prototypes and side projects, but it certainly is to many other people. If a library is heavy, it is in their interest to organize it instead as a collection of submodules that can be depended on individually (IIRC, lodash does this) otherwise they risk people just not using their stuff.
- sidstling 8y ago
  I’ve picked up node and js more seriously recently, coming from .Net and C# and I’ve been wondering why people in my learning material are relying so much on third party libraries for very basic things. I’m probably a little old fashioned, but I didn’t even know moment existed and I’ve been fooling around quite a bit with JS dates recently. It didn’t take a long time to write the .ToString(dd-MM-yyyy) module, that was the only thing I really needed aside from the standard library, but I guess it would’ve been faster to import moment.js.
  - noonespecial 8y ago
    I've definitely made my peace with it. Think of it this way: how much better is a bunch of imports than the slew of stackexchange copy-pasta you'd find in an old PHP app?
    - guitarbill 8y ago
      Think of it this way: how much safer is the slew of stackexchange copy-pasta, which might have at least been fully read. And it doesn't add another dependency that might steal your credentials or your customer's credentials in the future. (moment.js supports a huge number of localizations, which is impressive and good for i18n. so in this case maybe it isn't directly comparable to copy&paste for anything but trivial use-cases.)
      - 8y ago
ENGNR 8y ago
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
patriot_prayer 8y ago
I need Moment because Date.parse does not do the same thing in Safari as it does in Chrome
h1d 8y ago
When will JS engines ship with timezone data to not let a third party maintain it?
- guitarbill 8y ago
  Ironically, it's possible every browser includes this already internally, but doesn't expose it to Javascript [0]. Packages still have their place, but the lack of a decent standard library will hurt us for decades to come (already is arguably). [0] https://dxr.mozilla.org/mozilla-central/source/intl/icu/source/i18n/unicode/timezone.h#131 https://dxr.mozilla.org/mozilla-central/source/intl/icu/sour...
  - boubiyeah 8y ago
    This. People often have a beef with the very wild npm ecosystem with tons of libs of varying quality, abandonned projects, bloated libs, etc but mostly it comes down to the standard library being anemic.
andy_ppp 8y ago
Yes, I’m using date-fns and bits of this pull request [1]. It works very well and uses the Intl browser API to support time zones. Also worth noting that the mutable nature of moment can make things very confusing where as date fns is immutable and consistent. Remember that unless building a calendaring system, all dates should be stored in UTC and only converted into a specific Timezone for presentation. [1] https://github.com/date-fns/date-fns/pull/707 https://github.com/date-fns/date-fns/pull/707
gpmcadam 8y ago
Another light alternative (~2kB) is [fecha](https://github.com/taylorhakes/fecha https://github.com/taylorhakes/fecha)
koblas 8y ago
While you might not need moment.js and can remove it from your project. The problem is that every other project is using it, so you're already picking up the dependency. Many months ago I went digging into if we could remove it and while I successfully pulled it out, found that three of the packages we install all needed it -- thus having one date library was preferable to extra code size.

241 points by ggregoire 8y ago

There's also Luxon from (one of?) the maintainers of Moment: https://moment.github.io/luxon/ https://moment.github.io/luxon/. It abuses the i18n api (by parsing the date out of a formatted string) to provide timezone support without shipping timezone data, which is pretty clever.

owenversteeg 8y ago
Oh, that's a beautiful hack, I love it.

rublev 8y ago

The entire reason I need moment is so I don't have to do everything they're doing in that repo.

danielvinson 8y ago

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 address any of that.

Sujan 8y ago
Why and how are the suggested alternatives worse regarding the aspects you mentioned?
phaedryx 8y ago
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?
- k__ 8y ago
  Guess you have to measure yourself then :)
- owenversteeg 8y ago
  Because it's a simple, universal metric. Accurately stating the the performance impact of something like Moment is extremely involved and entirely dependent on how your project works and your users.
- hinkley 8y ago
  Because every web browser and server understands gzip. The gzipped size reflects the transfer size for the file without doing anything at all exotic.
big_elephant 8y ago
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 user experience. for circumstances like that, a developer might look at what are the biggest libraries in their vendor bundle and look for ways to reduce them via tree-shaking or find alternatives, that is if they are even aware of how slow their current bundle might be for mobile users. i think this is for that kind of use case, not only to offer alternatives to those who might need it, but also to raise awareness for those who develop on their desktop and don't engage with their app like most of their users do
- appleiigs 8y ago
  I think mobile phones have browser cache too.
  - big_elephant 8y ago
    sorry, i shouldn't have mentioned caching. the emphasis should have only been on connection speed
shados 8y ago
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 fish to fry, but eventually it certainly matters. There's a reason the modern web is so freagin slow, and only half of it is because of slow backend APIs.
- angersock 8y ago
  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.
  - this_user 8y ago
    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 8y ago
      [deleted]
  - FridgeSeal 8y ago
    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.
    - angersock 8y ago
      The library in question is nowhere near 2MB. You're tilting at windmmills.
deleted 8y ago
[deleted]
anonytrary 8y ago
> 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.
- deleted 8y ago
  [deleted]
- danielvinson 8y ago
  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).
  - s17n 8y ago
    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.
  - anonytrary 8y ago
    > 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.
robocat 8y ago
I'm assuming you don't have anything to do with mobile web design. Our complex single page app is approximately 180kb gzipped (JavaScript files and a single html main page) - no html from the server except for reports. Size is very important for first visit (lower delay loading files over cellular), and important for subsequent cached visits (mobile devices are slow to parse JavaScript).
ricardobeat 8y ago
300KB is more than enough for a fully functional website including _all code assets_. This is the sort of thinking that got us here.
h1d 8y ago
I wonder how many seconds it takes to load your site on mobile when you think 300KB is irrelevant in your product. From users point of view, it's irrelevant what you use inside but how snappy things are.
fouc 8y ago
https://infrequently.org/2017/10/can-you-afford-it-real-world-web-performance-budgets/ https://infrequently.org/2017/10/can-you-afford-it-real-worl... https://infrequently.org/2018/09/the-developer-experience-bait-and-switch/ https://infrequently.org/2018/09/the-developer-experience-ba... https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4 https://medium.com/@addyosmani/the-cost-of-javascript-in-201...
boubiyeah 8y ago
Devs like you is the main reason why the web is much, much slower than it could be. Perhaps it's time to start reading about UX , browser JS parsing speed, how JS executes, etc. Making your dev life easier is nice, but don't forget the end goal... (Note: I'm not talking about those internal apps that have 10 users :p)

deleted 8y ago

[deleted]

baliex 8y ago

The 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_country https://en.wikipedia.org/wiki/Daylight_saving_time_by_countr....

sushid 8y ago
Seriously... It's not like timezone support is some esoteric interest in a Date/Time library.
- kbenson 8y ago
  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.
benmccann 8y ago
I've sent a PR to date-fns to add time zone support, but the maintainer doesn't seem to have much bandwidth to review it. In the meantime, I'm going with Luxon
dcposch 8y ago
I wrote a tiny library, tzjs, for exactly this reason. Modern browsers have built-in timezone support via window.Intl. It's actually pretty nice! One glaring omission in the spec: given (UTC instant, tzname), there is no clean way to get that offset for that timezone at that moment. tzjs works around this omission. This saves a lot of bundle space. moment-timezone includes the whole tzdata dataset: https://bundlephobia.com/result?p=moment-timezone@0.5.21 https://bundlephobia.com/result?p=moment-timezone@0.5.21 https://github.com/dynasty-com/tzjs https://github.com/dynasty-com/tzjs

jmhain 8y ago

A 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/ https://js-joda.github.io/js-joda/

ricardobeat 8y ago
At 43kb gzipped, it's hardly lightweight - that's 70% of moment.js' size, 4x larger than date-fns
- dmm 8y ago
  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.
Rapzid 8y ago
Just like the OG Joda, I'm assuming it doesn't support nanosecond time resolution?

ggregoire 8y ago

But react-dates has moment as dependency, so…

BigJono 8y ago
Welcome to the wonderful world of code re-use. Hey, at least we're not re-inventing the wheel.
- nkozyra 8y ago
  We're reimporting the wheel (which, by the way, also has moment.js as a dependency)
pnevares 8y ago
https://github.com/airbnb/react-dates/blob/master/package.json#L95 https://github.com/airbnb/react-dates/blob/master/package.js... A devDependency is not the same as a dependency.
- scottlecrab 8y ago
  It's a dev dependency because they use it in unit tests but it's also a peer dependency, meaning that if you want to use the library you need to include moment.
  - pnevares 8y ago
    That's my error, thanks for the correction.

pjungwir 8y ago

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-timezones/ https://illuminatedcomputing.com/posts/2017/11/javascript-ti...

anothergoogler 8y ago
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.
- merb 8y ago
  actually joda is built into java8+ called java.time
  - anothergoogler 8y ago
    Thanks for the tip, I had no idea and was still including the dependency.
    - rhacker 8y ago
      It's not API compatible, so if you use Joda and you're thinking of using java.time, it's going to be a lot of refactoring.
      - Freak_NL 8y ago
        It's pretty straight forward to migrate from Joda to Java 8's builtin classes though. Just remove the dependency on Joda Time and let the compiler tell you which files to fix. This blog post lists which Java 8 classes replace their Joda Time counterparts: https://blog.joda.org/2014/11/converting-from-joda-time-to-javatime.html https://blog.joda.org/2014/11/converting-from-joda-time-to-j...

caseymarquis 8y ago

Most of moment's size is in the localizations. You can reduce it from 300kb to 100kb by removing them or only including the ones you care about: https://stackoverflow.com/questions/25384360/how-to-prevent-moment-js-from-loading-locales-with-webpack https://stackoverflow.com/questions/25384360/how-to-prevent-... I think the bigger lesson, if moment's size is news to you (for those of us using webpack), is to install webpack-bundle-analyzer. It's loads of fun, if you like visualizations.

dcposch 8y ago
You can further reduce that to 0kb by using window.Intl . You get locale and timezone aware date formatting, built-in on all modern browsers. The API is pretty nice! https://caniuse.com/#feat=internationalization https://caniuse.com/#feat=internationalization

the-pigeon 8y ago

For all the problems with Moment.js this article really sells it as the better solution for many use cases.

anonytrary 8y ago

Whenever a "you might not need this heavy, popular lib" gets posted to HN, the responses are always pretty divided. I always try and write my own functions and import things like lodash, underscore, jQuery, and moment as a last resort. Bundle size may not be that important to the people working on prototypes and side projects, but it certainly is to many other people. If a library is heavy, it is in their interest to organize it instead as a collection of submodules that can be depended on individually (IIRC, lodash does this) otherwise they risk people just not using their stuff.

sidstling 8y ago
I’ve picked up node and js more seriously recently, coming from .Net and C# and I’ve been wondering why people in my learning material are relying so much on third party libraries for very basic things. I’m probably a little old fashioned, but I didn’t even know moment existed and I’ve been fooling around quite a bit with JS dates recently. It didn’t take a long time to write the .ToString(dd-MM-yyyy) module, that was the only thing I really needed aside from the standard library, but I guess it would’ve been faster to import moment.js.
- noonespecial 8y ago
  I've definitely made my peace with it. Think of it this way: how much better is a bunch of imports than the slew of stackexchange copy-pasta you'd find in an old PHP app?
  - guitarbill 8y ago
    Think of it this way: how much safer is the slew of stackexchange copy-pasta, which might have at least been fully read. And it doesn't add another dependency that might steal your credentials or your customer's credentials in the future. (moment.js supports a huge number of localizations, which is impressive and good for i18n. so in this case maybe it isn't directly comparable to copy&paste for anything but trivial use-cases.)
    - 8y ago

ENGNR 8y ago

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

patriot_prayer 8y ago

I need Moment because Date.parse does not do the same thing in Safari as it does in Chrome

h1d 8y ago

When will JS engines ship with timezone data to not let a third party maintain it?

guitarbill 8y ago
Ironically, it's possible every browser includes this already internally, but doesn't expose it to Javascript [0]. Packages still have their place, but the lack of a decent standard library will hurt us for decades to come (already is arguably). [0] https://dxr.mozilla.org/mozilla-central/source/intl/icu/source/i18n/unicode/timezone.h#131 https://dxr.mozilla.org/mozilla-central/source/intl/icu/sour...
- boubiyeah 8y ago
  This. People often have a beef with the very wild npm ecosystem with tons of libs of varying quality, abandonned projects, bloated libs, etc but mostly it comes down to the standard library being anemic.

andy_ppp 8y ago

Yes, I’m using date-fns and bits of this pull request [1]. It works very well and uses the Intl browser API to support time zones. Also worth noting that the mutable nature of moment can make things very confusing where as date fns is immutable and consistent. Remember that unless building a calendaring system, all dates should be stored in UTC and only converted into a specific Timezone for presentation. [1] https://github.com/date-fns/date-fns/pull/707 https://github.com/date-fns/date-fns/pull/707

gpmcadam 8y ago

Another light alternative (~2kB) is [fecha](https://github.com/taylorhakes/fecha https://github.com/taylorhakes/fecha)

koblas 8y ago

While you might not need moment.js and can remove it from your project. The problem is that every other project is using it, so you're already picking up the dependency. Many months ago I went digging into if we could remove it and while I successfully pulled it out, found that three of the packages we install all needed it -- thus having one date library was preferable to extra code size.