If your project deals with complex date and time then you probably have been use to of moment.js. Be aware, Moment.js has become a legacy project. ...
For further actions, you may consider blocking this person and/or reporting abuse
TC39 is working on a new API called Temporal that looks very promising. It’s in Stage 3 so it’s worth having a look!
Just in the last couple of weeks a major roadblock to browsers shipping
Temporalimplementations has been resolved — namely github.com/tc39/proposal-temporal/... (which was opened back in Mar 2021). There still aren't any fully compliant implementations that are ready to ship, though.Interesting, it kind of makes sense to have a global namespace for managing datetime
This is what I don't like about software development. I am not talking about Moment.js. It's about the developers who think that a software is dead because no update is made. And since how much time? It depends on some random developers who think so!
There are objectives for developing a software. And when they are achieved, the software is declared dead!? There are many software which developers stop using for no logical reason, even when the developers haven't declared them dead, unmaintained, obsolete. But the wheel is reinvented, completely opposite of the reason behind making the software - that is, developers don't have to write the same code from scratch for every project they work on!
If a software has achieved its objectives then it is perfect for use. It is tried and tested. A lot of documentation, questions and answeres, solutions are available. Developers know its APIs. There are readymade code samples to copy-paste. Jumping to another software may require to create new code, new documentation, advertisement; and most importantly - a lot of time is wasted in developing, testing, debugging, learning, giving answers to questions.
I am seeing that new features are added in many software just because developers don't consider them dead. After a point, the newly added features are so odd that not even 0.00...001% developers use those features. Only their size increase. They become bloatware.
Many times it looks like the developers of the new software just want attention; it may be to be popular, add an achievement to their job profile, have money-making ideas, or any other reason.
This is partially true, but not for moment.js
moment.js was developed into a wrong direction, like it has not immutability and also not good support for diverse calendar systems
It has also some other bugs
Luxon was a fresh start and addressed some of the design flaws that moment.js did
Also moment.js became to big and also stale in terms of modern js support
If you have a project that is meant to be only existing for the next 5 years and already runs since 2+ years, stay with moment.js
If you have a project that will be released in the next time, go with something else then moment.js
On one of the projects I touched recently, Moment.js was the single biggest contributor to the JS bundle bloat. That's because moment.js rolls its own localisation instead of using the Intl API. For this reason alone, it's not a good library to use on the frontend.
I would suggest you to treeshake the languages you don't need.
After doing so it is much smaller
There is a Plugin
I would consider dayjs if it was mutable and would work well with timezones. Setting a default timezone is so inconvenient that it almost always will lead to errors sooner or later in larger projects with multiple developers.
Unfortunately I'm not able to find a date library as good as moment. I really hope there will be one in the future with a smaller size.
I've been working with dayjs where I'm able to convert the timezone whenever needed without the need to globally set it. Secondly, immutable part actually saves bugs, not sure what issue it causes you there
I have the need to globally set it but dayjs is unable to do so via normal daysjs constructor. Unlike moment you need to create the object in a different way. I would always tend to forget it when I have several different projects where only one needs to have a specific timezone. After hopping back to this one project a few months later I would just use the default constructor and forget about the timezone.
github.com/iamkun/dayjs/issues/1227
I never had any bugs in my last 16 years that were caused by mutable objects. However: I had issues with immutable objects since you can't just change them. It's more like they differ from the default behaviour in nearly every single language and every object and I tend to forget that you just can't do
dayjsObject.add(1, 'day') to add a day to an existing object.
In case you don't know this special library is immutable it can be very frustrating.
Ah, I understood your point now.
I worked on a project where we had to set the timezones for users specifically, not globally for entire project.
I think the confusing part comes when we have to work on multiple projects in which some projects have dayjs, and some have any other like momentjs.
BTW, I tried to prepare a short guide to choose whether you should go for dayjs or not (for your project): dev.to/shameel/guide-to-learn-dayj...
It's more about the default behavior of logical OOP languages vs the immutable trend in my opinion.
Objects per definition are always mutable and in my opinion it's very inconvenient if they are not and if a function that does sound like it changes an object in fact doesn't do what it is supposed to do. In my experience this will lead to errors.
Legacy has a certain meaning in our line of work and yes it changes a lot of things :-)
@shameel Can you elaborate?
I sincerely never liked those dates frameworks. Use native Date object. Why everyone complains!?
A few months ago in the project I'm currently in we simply deleted 3 huge files with momentjs helpers and replaced with 5 helper functions using native Date. (granted... not the very best codebase, but still... if you know what to expect from Date, you should be fine!)
Github: You Don't Need MomentJS
Add any other cool alternatives if you know of any. =)
I agree, I still use moment cause honestly it works, nowadays if something is not updated every couple months then it's "legacy"
Use Luxon while waiting for Temporal. Or write your own wrapper for Intl, is you need performance (trust me, manually written wrapper on Intl can be 20 times faster than string formats in any of these libraries)
I use
date-fnsfor most of our date rendering, but I've been opting for more of JavaScript's built-in options lately. For example, Date.toLocaleDateString() and some of parts of the Intl API.We're currently working with date-fns and it works like a charm. I recommed it
We replaced it with dayjs. The API is similar enough. If ended up not being that much work
I use date-fns as a replacement, and it does the job.
The documentation is sometimes a bit tight on certain use cases.
I don't know why browsers don't provide date conversion as native api support.