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.
OOP and FP use very different strategies to ensure code quality.
If you are not aware of the different strategies, it will surely lead to errors.
But that has nothing to do with my argument. OOP and FP have no impact here and are irrelevant. My point was that
works as you would expect as a developer that knows the principle of "call by reference". On the other hand
won't produce the result most people would expect.
But what did you mean by
Maybe it´s just an implementation detail and it´s just a decision you have to make. In the moment.js documentation we find:
Where day.js states:
Yes that's what this entire discussion is about. Mutable libraries vs immutable libraries.
The default behaviour when you work with objects in any language is: when you change attributes or call functions you usually by default change the state of the class itself. It's a well known principle and people are doing this for decades.
When you have a car and call the
car.drive()function you want the car to drive - you don't want to create a new instance of the car by cloning it.We all know how moment and days js works and what mutable and immutable means.
The discussion here is why it should be better to always have immutable classes as it is the opposite of what we are used to.
You are right that objects usually have a mutable state, but this does not mean, all object methods need to change state.
Think of time string formatting, each time library needs to know the target format to generate a string. A functional library cannot store the format internally, so there are two options:
a) it may ask for a system specific format string each time it needs to generate a string. This way, you are always sure you are in line with the system settings.
b) you need to pass the format string every time you generate a time value string.
In OOP you can decide to store the format string in the object. This allows to build several objects with different format:
But even with that you can still define, that the add-method mutates the object or just the return value. This has not much to do with OOP or FP, it is just a decision.
Well that's why I explained that is has nothing to do with OOP vs FP. You were the one who started to talk about OOP vs FP. However mutability and immutability in this case are about objects and the way they are changed in the case of dayjs.
Yes indeed that was the point of the entire conversation: Mutable vs Immutable is a decision and in the current trend the majority of people consider mutable objects as always BAD in their core while they are not (always). That was the entire point. They are not always entirely strictly bad in their core.
That's the entire topic. Not more, not less.
I'm still not sure if you get the point. It's just Mutable vs Immutable, not about FP, not about OOP, not about where values are stored and how you can access those.
It's just about the fashion trend. stackoverflow.com/a/43318963/5604055
To make it even clearer: The starting point of the discussion was just
"Dayjs is better because it is immutable"
That it and my entire point was, this is not strictly an advantage - just a different design approach. A different choice, not better
Yes of course.
But in this case it ALWAYS clones the object and returns the new one. That's what I am talking about.
ALL methods won't change the object but clone it and say it's better this way due to several reasons. One for example "it's easier to understand"
Maybe it´s a different consideration behind that.
Maybe it's just a concession to the "fashion trend" that is still usable in both worlds.
But the trend is to use only immutable objects, mutable objects are considered as bad. That's what I am talking about.
"Best practice" is to not mutate objects at all.... And I think this is stupid since developers were able to succesfully mutate objects within the last 50 years without any issues.
However mutable objects are doomed by many people today.
Oh, that´s a big word. There have been "some" issues between 1973 and now.
The idea of "Immutability" refers tightly to functional programming, which you may like or not. But outside this world, immutability means nothing.
I think there are good reasons why most of the software is not written in Erlang or Haskell. Erlang was created in 1987, Haskell in 1990, so there was pretty much time to gain popularity. But even chrome is written in C++.
There are enough people out there that tell you, you are stupid, because they know better. But the only thing that is really immutable is their own stupidity...
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"
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.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)
We're currently working with date-fns and it works like a charm. I recommed it
I use date-fns as a replacement, and it does the job.
The documentation is sometimes a bit tight on certain use cases.
We replaced it with dayjs. The API is similar enough. If ended up not being that much work
I don't know why browsers don't provide date conversion as native api support.