Live data from Hacker News

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

day.js.org

31–40 of 141 posts

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

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

I've always found moment to just present the same problems you would otherwise have with a few new ones tacked on stated in a different and more complicated way but with a pitch site and artwork.

The js date is a bit primitive and moment looks easier but in practice it's actually a convoluted clunky type system that hides important nuance behind impressively bad defaults.

I approach all of these "better than what the language offers" solutions the same way: it would be truly remarkable if some kid had a more nuanced and correct take then people with years of experience and PhDs in language design who made the language but more likely, I think the kid who wrote the library is just better at drawing cartoon characters, hype posting on social media and making something popular.

I used to get immediate hostility and belittling insults when I stated this about 10 years ago. I think people have finally come around. Let's see how the replies go.

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

#32
post #29
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…

I only see this being an issue storing times as strings. Why not store them as integers (like a Unix timestamp) or at least some standardized string format? The only reasonable use case I can think of where you absolutely need all this complexity is if you're rendering a calendar or something similar.

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

#33
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

> I'd wager that an average webpage size is probably closer to 1MB.

And the average American is heavier than they should be. Doesn't make it ideal. Always endeavour to trim the fat.

This is HN, and despite the likely predominance of US big-city devs here, I'd wager that most of them like money from rural dwellers just as well as they do the money of their fellow city-slickers.

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

#34
post #29
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…

This was the reply I was trying to prevent by saying "minimal code example".

I'm not interested in long theoretical articles. But I would look at a few lines of code.

Here is an example of some code I recently wrote:

    logEvent {
        'date': new Date().toISOString(),
        'event': 'image_updated',
        'value': image['id'],
    }
This logs that an image with a given id was updated.

Why would I trade in my single date line for 423 files with 53004 lines of code?

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

#36
post #32
post #29

Earlier quoted context omitted.

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…

I only see this being an issue storing times as strings. Why not store them as integers (like a Unix timestamp) or at least some standardized string format? The only reasonable use case I can think of where you absolutely need all this complexity is if you're rendering a calendar or something similar.

There are countless, profitable business use cases for accurate time tracking.

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

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

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

#38
post #37
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.

First you have to define what you mean by "one month ago". Is it 30 days ago? Or last month? Or a certain number of milliseconds ago?

No library can help you with that. You have to define what you actually want to calculate.

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

#39

Earlier quoted context omitted.

Luxon is my preferred library

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.

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

#40
post #34
post #29

Earlier quoted context omitted.

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…

This was the reply I was trying to prevent by saying "minimal code example". I'm not interested in long theoretical articles. But I would look at a few lines of code. Here is an example of some code I recently wrote: logEvent { 'date': new Date().toISOString(), 'event': 'image_updated', 'value': image['id'], } This logs that an image with a given id was updated. Why would I trade in my single date line for 423 files…

You wouldn't. It's not a trade anyone is asking.
Post reply on HN