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

Day.js – Fast 2kB alternative to Moment.js with the same modern API

day.js.org

Post reply on HN
Print view View original

61–70 of 141 posts

Re: Day.js – Fast 2kB alternative to Moment.js with the same modern API

#61

Post by iainmerrick »

FrontAid wrote: post #59

If you are considering switching to a (different) date library, I would suggest to hold off. ECMAScript is about to introduce a native date and time API that is much better than the current Date functionality. It may also make the need for a third-party date library obsolete (as long as you do not need to parse custom date formats). - https://github.com/tc39/proposal-temporal - https://github.com/tc39/proposal-tempor…

Instead of using something that works right now, you’re saying people should hold off for a few months, then start using a prerelease API?

Re: Day.js – Fast 2kB alternative to Moment.js with the same modern API

#62

Post by maigret »

epgui wrote: post #29
TekMol wrote: post #27

I never use any date library and I never had a problem with it. I just use what the native Date() object offers. Other devs always say "Just wait, one day it will fall on your feet". But this has been going on for many years, in which my software has served millions of users and nothing ever fell on my feet. I think the complexity of a library like this (423 files, 1433 commits, 53004 lines of code) would have create…

Examples of essential complexity you have to worry about if you want your code to be correct, and even if you want to test/detect all issues that can/do come up: - https://infiniteundo.com/post/25326999628/falsehoods-program... - https://infiniteundo.com/post/25509354022/more-falsehoods-pr... In my experience engineers will often brush these sorts of things off as “edge cases”, but really all of these complexities ar…

You can still add a library once it’s really needed and an area is proved to cause bugs. Most of the times though, developers will add them upfront “just in case”, making the bundles always heavier and thus harming the user experience with a slower UI.

Re: Day.js – Fast 2kB alternative to Moment.js with the same modern API

#63

Post by Hendrikto »

nabaraz wrote: post #26

What is the obsession with xKB? With tracking, analytics, monitoring and gazillion other scripts, I'd wager that an average webpage size is probably closer to 1MB. Checked some of the popular sites (caching enabled)- Amazon.com - 4.8MB Google.com - 2.5MB

> What is the obsession with xKB? […] I'd wager that an average webpage size is probably closer to 1MB.

This is the mindset that got us into this mess…

Re: Day.js – Fast 2kB alternative to Moment.js with the same modern API

#64

Post by throwaway0x7E6 »

forty wrote: post #37
TekMol wrote: post #27

I never use any date library and I never had a problem with it. I just use what the native Date() object offers. Other devs always say "Just wait, one day it will fall on your feet". But this has been going on for many years, in which my software has served millions of users and nothing ever fell on my feet. I think the complexity of a library like this (423 files, 1433 commits, 53004 lines of code) would have create…

Any operation like adding/substracting months from a date is very messy to implement yourself. What is one month ago when you are March, 31st? We have to deal with monthly subscriptions and it's not fun.

>What is one month ago when you are March, 31st?

"one month ago" is between "a few weeks ago" and "a few months ago".

>We have to deal with monthly subscriptions and it's not fun.

it is a lot less unfun if you define a month as N calendar days in your terms of service, like virtually everyone does

Re: Day.js – Fast 2kB alternative to Moment.js with the same modern API

#65

Post by 9wzYQbTYsAIc »

TekMol wrote: post #55
9wzYQbTYsAIc wrote: post #42

Earlier quoted context omitted.

> I'm not interested in long theoretical articles Those articles are more empirical in nature than theoretical. > This logs that an image with a given id was updated As a thought exercise, imagine that your log trail needed to be created in a distributed system, spanning multiple machine time zones, or that you needed to build a report that is read from browsers in multiple time zones that differ from multiple differ…

You are trying to convince me with the popular "This is not going to work for a much more complex system". I heard it very often. I don't buy it. Any system, no matter how complex, can be composed of small, simple systems. I never ran against a "complexity wall" when writing software in a lean way and suddenly thought "Damn, those tens of thousands of lines of library code now would be the better approach".

More power to you if you have the budget to spend time writing code that someone else has already written.

Re: Day.js – Fast 2kB alternative to Moment.js with the same modern API

#67

Post by 867-5309 »

spoils19 wrote: post #39
9wzYQbTYsAIc wrote: post #11

Earlier quoted context omitted.

But how does this compare to Luxon, besides it being the preferred library of blahyawnblah?

I don't think there's any need to be condescending.

it's actually their username

Re: Day.js – Fast 2kB alternative to Moment.js with the same modern API

#68

Post by yilugurlu »

FrontAid wrote: post #59

If you are considering switching to a (different) date library, I would suggest to hold off. ECMAScript is about to introduce a native date and time API that is much better than the current Date functionality. It may also make the need for a third-party date library obsolete (as long as you do not need to parse custom date formats). - https://github.com/tc39/proposal-temporal - https://github.com/tc39/proposal-tempor…

Having read the cookbook [1], and wow that's a complex API out there. I can see that there will be a `Temporal Light` to allow us to do `now().startOf('month')` like calls.

[1] https://tc39.es/proposal-temporal/docs/cookbook.html

Re: Day.js – Fast 2kB alternative to Moment.js with the same modern API

#69

Post by badlucklottery »

iainmerrick wrote: post #61
FrontAid wrote: post #59

If you are considering switching to a (different) date library, I would suggest to hold off. ECMAScript is about to introduce a native date and time API that is much better than the current Date functionality. It may also make the need for a third-party date library obsolete (as long as you do not need to parse custom date formats). - https://github.com/tc39/proposal-temporal - https://github.com/tc39/proposal-tempor…

Instead of using something that works right now, you’re saying people should hold off for a few months, then start using a prerelease API?

They mentioned "switching" which implies an already working solution. Within that context, yeah, maybe wait a few months if you can afford to.

Also, once the spec is finalized, there may also be a compliant polyfill available. If so, you'll get the functionality early and still have good compatibility down the line.

Re: Day.js – Fast 2kB alternative to Moment.js with the same modern API

#70

Post by Hendrikto »

noduerme wrote: post #25

I'm a fan of Moment... it's served me well for most of a decade, including in some really heavy scheduling/timetable applications. The size of importing Moment is really fairly negligible for a full-scale single page app. The one drawback I find with it is the overhead for creating new Moment objects. You never want to, for instance, run through a for/next loop of SQL dates and convert each into a Moment for sorting.…

> The size of importing Moment is really fairly negligible.

This attitude is why large parts of the Internet suck these days.

I recently visited a friend in Kallithea, Athens, Greece. With his Internet connection, that would add about half a second. It‘s a typical speed for residential connections in Athens.

Post reply on HN