Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You Don't Need Moment.js

github.com

Post reply on HN
Print view View original

71–80 of 91 posts

Re: You Don't Need Moment.js

#71

Post by robocat »

kbenson wrote: post #43
robocat wrote: post #36

Earlier quoted context omitted.

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…

Exactly: it isn't difficult to safely use Date() to hold and compare dates, but you need enough experience to avoid the gotchas (which are not unique to JavaScript).

You can roll your own solution using Number for date, since Number can safely hold a 52 bit integer (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...) and if you avoid using 32 bit Unix epoch dates as you get a falsy value on 1/1/1970.

Re: You Don't Need Moment.js

#72

Post by ivanhoe »

sidstling wrote: post #57
anonytrary wrote: post #28

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…

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

One unique thing to js that the backend usually doesn't have to deal with is a lot of edge-cases with different browsers. That's (at least for me) the main motivation to use 3rd party libs when ever possible, hoping that they know more than me, and have invested more time in testing and thinking about all the possibilities... and usually it's true

Re: You Don't Need Moment.js

#73

Post by Freak_NL »

rhacker wrote: post #50
anothergoogler wrote: post #40

Earlier quoted context omitted.

Thanks for the tip, I had no idea and was still including the dependency.

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.

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

Re: You Don't Need Moment.js

#74

Post by mattmanser »

baliex wrote: post #7

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

And as date-fns doesn't support all locales, and moment.js without locale support is roughly the same size as date-fns, what was the point of this?

It's not like the author can't have known this, moment.js without locales is listed right at the top on the moment.js home page (but left out of this list).

At a previous client, we only imported the locales they actually support, you don't need to import the whole lot of locales if you don't want to. When you don't need the whole lot, they're actually tiny.

Side-note, Chrome recently changed how it parsed dates breaking existing code (if you left the "z" off a ISO date), yes, that meant different browsers native date parsing wasn't consistent until recently. I forget exactly when it happened but I think it's was about a year or two ago. I think we ran into it because we were using .Net MVC which by default the serializers would spit out DateTime's without the Z and DateTimeOffsets with them. They changed it for newer versions.

Personally, working with future dates in the restaurant trade, the recent dogmatic approach to treating everything with ISO is frustrating. When humans say "meet at a restaurant on 27th Sept at 7pm" they don't, at all, mean it by timezone. A person in France doesn't want to see the booking show 27th Sept at 8pm. And storing it ISO is dangerous as timezones actually change.

Re: You Don't Need Moment.js

#76

Post by mratzloff »

mattmanser wrote: post #74
baliex wrote: post #7

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

And as date-fns doesn't support all locales, and moment.js without locale support is roughly the same size as date-fns, what was the point of this? It's not like the author can't have known this, moment.js without locales is listed right at the top on the moment.js home page (but left out of this list). At a previous client, we only imported the locales they actually support, you don't need to import the whole lot of…

Date-fns supports 46 locales currently, so it's not nothing.

Regarding local times, if it's always local, why worry about it? Just store it in "UTC" without conversion, with the understanding that it will never be converted. That's what the Postgres "timestamp without time zone" type essentially is.

Re: You Don't Need Moment.js

#77

Post by pythonaut_16 »

guitarbill wrote: post #65
noonespecial wrote: post #60

Earlier quoted context omitted.

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?

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…

Let's be honest though, if someone's copy-pasting from Stack Exchange, they're probably not reading or understanding the whole thing they're copying either.

My rule in code reviews is if you're basing/copying something from the internet, you better be able to explain everything it's doing, and if you're pulling a dependency you better be able to explain why we need it and why you think it's trustworthy enough to put in our application.

Re: You Don't Need Moment.js

#78

Post by FlorianRappl »

sidstling wrote: post #57
anonytrary wrote: post #28

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…

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

Coming from .NET you should know Noda Time (https://nodatime.org) and the problem it solves. Consider moment the JS alternative, however, with JS native Date being more limited / broken than .NET's DateTime.

TL;DR: Goes way beyond standard formatting.

Re: You Don't Need Moment.js

#79

Post by dcposch »

caseymarquis wrote: post #21

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

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

Re: You Don't Need Moment.js

#80

Post by Sacho »

FlorianRappl wrote: post #78
sidstling wrote: post #57

Earlier quoted context omitted.

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

Coming from .NET you should know Noda Time ( https://nodatime.org ) and the problem it solves. Consider moment the JS alternative, however, with JS native Date being more limited / broken than .NET's DateTime. TL;DR: Goes way beyond standard formatting.

The C# DateTime has more useful methods than JS Date, but DateTimeKind and the way it counts ticks makes it an absolute trap for anyone to use, so I wouldn't say it's less broken.
Post reply on HN