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

81–90 of 91 posts

Re: You Don't Need Moment.js

#81

Post by boubiyeah »

guitarbill wrote: post #67
h1d wrote: post #52

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

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

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.

Re: You Don't Need Moment.js

#82

Post by koblas »

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.

Re: You Don't Need Moment.js

#83

Post by boubiyeah »

danielvinson wrote: post #4

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…

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)

Re: You Don't Need Moment.js

#84

Post by village-idiot »

Freak_NL wrote: post #73
rhacker wrote: post #50

Earlier quoted context omitted.

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

The worst is when you’re stuck on older libraries that still use Joda transitively, so you gotta transition to and from joda at the barriers.

Re: You Don't Need Moment.js

#85

Post by TheCoelacanth »

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…

This is why Javascript needs an equivalent to Java 8's LocalDate and LocalDateTime. It copied Java's terrible, fundamentally broken class for dealing with dates, if it could finally get around to copying the good date library that Java added later, that would be great.

Re: You Don't Need Moment.js

#86

Post by reitanqild »

robocat wrote: post #36
pjungwir wrote: post #18

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

Just this summer I saw the Angular Material team struggle with misunderstandings around this.

Some German (I suppose, based on the GitHub profile) had to write a UTC aware implementation and then others had to push them to realize the issue.

Seems time and other regional issues are really hard even for the geniuses at Google. (Yep, I honestly believe they're smarter than me, which makes this really confusing.)

Re: You Don't Need Moment.js

#87

Post by true_religion »

shados wrote: post #14
danielvinson wrote: post #4

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

That is totally fair, but for me, I make internal company apps. They happen to use Javascript, but realistically we could ask someone to download 100mb of a binary, and it would still be an ok situation.

For other devs? I bet they say that people on slow connections are not the target market. After all, a slow line will choke on all the ads used to pay for the site.

Re: You Don't Need Moment.js

#88

Post by marcus_holmes »

kbenson wrote: post #63
marcus_holmes wrote: post #62

Earlier quoted context omitted.

Even just using dates can be a mess. At midday UTC everyone experiences the same date. The other 23 hours of the day, a varying proportion of people are experiencing a different date. "using dates" therefore works out to "not caring about the time of day" and that reduces to "not caring about the time of day in the same timezone" since the same time of day in two timezones have a ~50% chance of being in different dat…

Sure, but I was referring more to the times you actually do just want a date. It's perfect for a birthday, or "this day in history", or any number of other things. Nobody really cares that while it was Tuesday where you were born, it was Wednesday for them. In some instances, if you really only care about the day something happened, adding a time is just extra details to screw up. But if you do need need a a time, yo…

well, yes, 99% of the time you're right... but... an astrology application (for example) will care about your timezone for your birthday.

It comes down to the use case, not the data.

Re: You Don't Need Moment.js

#89

Post by mattmanser »

mratzloff wrote: post #76
mattmanser wrote: post #74

Earlier quoted context omitted.

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.

Because if you send it up to the client it's very easy to accidentally get it converted unless you constantly guard against it.

Re: You Don't Need Moment.js

#90

Post by shados »

true_religion wrote: post #87
shados wrote: post #14

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

That is totally fair, but for me, I make internal company apps. They happen to use Javascript, but realistically we could ask someone to download 100mb of a binary, and it would still be an ok situation. For other devs? I bet they say that people on slow connections are not the target market. After all, a slow line will choke on all the ads used to pay for the site.

Yeah, we definitely care about this more for our external apps than internal ones, but as we grow and our internal users expect more and more sophistication from our internal tool, it's becoming a bigger priority. It really does matter. Think the customer support agent or the sales rep who's on the phone and has to make the customer wait just a few more seconds can have an impact... but it's definitely harder to justify.

> I bet they say that people on slow connections are not the target market

That however... there's a LOT of data showing how every seconds count for things like ecommerce or news websites. And for actual B2B type apps, they likely don't have adds after you are logged in. We're gathering a lot of data on this internally, and customers care a -lot- about perf of things like CMSs, CRMs and other enterprisey apps.

Post reply on HN