i’ve definitely enjoyed using this but it would be nice it there was better TS support for some of the extensions
Day.js – Fast 2kB alternative to Moment.js with the same modern API
111–120 of 141 posts
Re: Day.js – Fast 2kB alternative to Moment.js with the same modern API
#112If 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…
Moment.js was one of our biggest dependencies, and the transition to Day.js was easy. I'm certainly glad we didn't hold off. I'm sure we'll switch to Temporal eventually, but it's misguided to suggest everyone should wait a year or more to improve their sites just to save a little effort in the interim.
Re: Day.js – Fast 2kB alternative to Moment.js with the same modern API
#113> Moment.js with the same modern API Moment.js objects are mutable [0], and this library's objects are ... immutable. [0] https://momentjs.com/guides/#/lib-concepts/mutability/
It's not quite exactly the same API - you'll need to do some testing afterward - but if you're using Moment idiomatically, nearly everything should just-work
Re: Day.js – Fast 2kB alternative to Moment.js with the same modern API
#114I have not used moment.js or other date libraries in a long while. But how does this compare to Luxon? ( https://moment.github.io/luxon/#/why )
Full disclosure I haven't used Luxon nearly as much as I've used DayJS, but I would say IMO DayJS is way simpler and more intuitive, this is a very small thing but for example, why would they format Months, by "L" instead of by "M"? The other reason I like DayJS over Luxon is the sheer number of plugins you can pull in to do various things. Like for example I was building an application where I had to build a weekly…
In Luxon that is dt.startOf(“week”).plus({ days : 6 })
Re: Day.js – Fast 2kB alternative to Moment.js with the same modern API
#115Earlier quoted context omitted.
Who is "some kid"?
Must be a euphemism for “300 contributors on a js.org supported GitHub project”.
Immediate hostility and belittling attacks strike again.
That was a reply to a comment, not to the code posted. You're being sloppy imprecise and presumptive and expressing it as haughty snide arrogance.
Cool attitude
Re: Day.js – Fast 2kB alternative to Moment.js with the same modern API
#116Not sure if this is a gotcha, but how does one make a JS date object (across Safari, FF and Chrome) that refers to the same day of the year regardless of timezone?
You can’t, because JavaScript date objects are just timestamps.
Here’s what I wrote on this (along with a small library to handle this problem): https://lisper.in/javascript-date
Re: Day.js – Fast 2kB alternative to Moment.js with the same modern API
#117Earlier quoted context omitted.
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.
User: set an alarm in eight hours. It's 10PM right now. At what time should the alarm be set? 6AM? Woops, tomorrow is the switch to DST! What now? User: remind me to brush my teeth on November 21st at 8AM. Okay, will do! Wait, you took a plane on November 2nd and are now on the other side of the world? Should I remind you at 8AM or 5PM? User: please note my doctor's appointment in two weeks at 10AM. Sure thing bub! W…
> What now?
I mean, there is no way to write code to “handle” this that isn’t just guessing on the part of the programmer. The correct thing to do is to prompt the user for verification or further information.
> There are requirements that we, as humans, will intuitively find the right interpretation for…
Interpretation is subject to error. (Yes humans have immensely more context to work with than computer programs, but just because we we’re better guessers doesn’t mean we’re not still guessing.)
Re: Day.js – Fast 2kB alternative to Moment.js with the same modern API
#118If 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…
> I would suggest to hold off you don't need to hold off - you just wrap the library in an api of your own, specific for your usage. Then, when/if the ecmascript standard library adds a good one in, you just need to re-implement the wrapper, which would be presumably pretty easy as the api surface area is fairly small.
If I were helping someone start a web project _right now_ I'd probably tell them to just use Moment.js and forget about it. Any live web product I've ever worked on has always had more than enough to work on to keep updating the date-time library at the bottom of the to-do list almost indefinitely.
Re: Day.js – Fast 2kB alternative to Moment.js with the same modern API
#119If 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…
Moment.js was one of our biggest dependencies, and the transition to Day.js was easy. I'm certainly glad we didn't hold off. I'm sure we'll switch to Temporal eventually, but it's misguided to suggest everyone should wait a year or more to improve their sites just to save a little effort in the interim.
One has also got to hope that Temporal offers all the features a well built daytime library does offer. What good is it if Temporal is lacking that one feature you need, so that you end up including another library as well.
By then you can assume that the other library will be a lightweight wrapper around Temporal.
Re: Day.js – Fast 2kB alternative to Moment.js with the same modern API
#120Earlier 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…
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.
I’d argue that we already know how time works, so the proof exists up front and there is no “just in case”.
You could make an argument that there are more important things to fix, but then you’d be deciding consciously that it was okay to ship software known to be incorrect.