181–190 of 266 posts
Many UI libraries use that format so using different libraries with different notation will be harder to manage for me.
Please pardon this drive-by assessment of JS calendar libraries by a casual user. moment.js: Mutable. Thank you, next. Luxon: Takes the effort to implement `Interval`, which would be `Range ` in any proper language, but somehow avoids providing separate `Date` and `Time` objects. Day.js: When you kinda like moment.js, but your bundler says it's too fat. date-fns: The finest of pure, curry-able functions over the mine…
could someone take the time and explain to a moron like me why the mutability of moment is bad? i just don't get it. moment has always been my goto library for dealing with dates in javascript.
Most software has "reference types", like a customer. A customer is mutable; for example their name can change for a variety of reasons, their shipping address can change etc.
And then there are "value types", like integers or strings. The integer 42 can never change to be any other value.
If your customer lives in Rando Street no 42, and moves to Rando Street 41, you don't change the integer (value type) 42 to 41, you set `custtomer.address.house_number` to the new integer 41. If any other code referenced the number 42, it still has number 42 stored.
Now, many people argue that a moment in time (like timestamp/datetime) is usually better modeled as a value type. If you have two references to one moment, you can rely on the fact that nobody else can modify that moment after the fact.
This is usually safer, since it makes the case of accidentally over-shared objects a non-problem, though possibly a little bit less performant (since all "modifications" must create new copies).
Earlier quoted context omitted.
...but there's nothing to "fix", it works as intended. You might want to do things differently nowadays, is all - that's not on Moment. Re: "obsolete"... jQuery is somewhere laughing, having gone through this already.
> ...but there's nothing to "fix", it works as intended If there were nothing to fix, they wouldn't be telling people not to start new projects with Moment. They actually do mention a few significant issues that they can't / won't fix in Moment such as bundle size and mutability. I will concede that perhaps Moment was "done" at some point before, some years back. When it was quite complete, yet was still the best way…
I'm not going to stop using moment in new or existing projects for petty reasons like the ones presented. I'm tired of having the rug pulled out from under me every time I'm comfortable with something.
Earlier quoted context omitted.
It "done" really, and I can use it today knowing its pros and cons. It would be "dead" if it had a glaring flaw which couldn't be fixed (which I don't think mutability is) Every project has cons and they should embrace it and call it out like this project did instead of forever targeting a perfect library but nothing is perfect. It serves its purpose. I am not sure if they are telling people not use it just because c…
> I am not sure if they are telling people not use it just because chrome now says to exclude it or they came up with it independently. Independent. The maintainers have been recommending other alternatives (like Luxon) long before Chrome started to advise users on it. Moment has been in maintenance mode for a while now, this is just an updated confirmation of the fact, I'm guessing because users kept asking.
I've used moment in many of my projects. Though they're able to be migrated into new libraries, I haven't found alternative that use moment.js's date format notation. Are there any alternative that use it? Many UI libraries use that format so using different libraries with different notation will be harder to manage for me.
The only real "standard" in this area is LDML tokens, which are part of CLDR. Luxon follows those.
Earlier quoted context omitted.
This isn’t me disagreeing with the design decision, this was their own explanation for why you shouldn’t use Moment.js in the future. My point was that the reason we’re transitioning away from it is because of technical reason, not because it’s not being updated.
I'd been complaining about these issues for years. I kinda hate being vindicated years later, the time in between as an outsider kinda frustrates me. I wish we had a more thoughtful, less packrat culture in programming. Fighting off the pushback is exhausting. It's not even worth bringing things up most of the time. And as a disclaimer to those feeling tempted, I've got zero interest in debating this reality, water i…
Earlier quoted context omitted.
If an OSS library does what you need, is it not done in any meaningful sense anyway? It makes little difference if the author had hoped to add the kitchen sink, but gave up on it, if you don't need the kitchen sink.
If it does what I need but has a dozen security flaws because the maintainer just doesn't care anymore it makes a difference. You have to dig around to figure this out. On github it's relatively easy to check the issue tracker but still. One case in point is (was) atftp. Since it's packaged with most distros you might be tempted to assume it's safe to use. But then I encountered a crash on Debian. Tracked down the of…
Does it? The alternative might be to write your own code, which will carry your own flavour of security issues. No matter what code you adopt, be it your own or someone else's, will require some level of commitment in maintaining it.
Earlier quoted context omitted.
> Until very recently it was impossible to make objects immutable in JS. Even now its really only done using third party libraries. There's a big difference between "literally impossible to mutate" (only important in the most security-critical contexts) and "designed around immutability as the default" (which is what is desired in most of the real world.) The former not being possible is not a reason to exclude the l…
With JS, until recently, it was nearly impossible to design immutable API's. Everything takes JSON based objects which have no field accessors. All the objects underneath are just hashmaps with string keys. When all your objects are hashmaps you can't really make fields immutable. Even if you wrote getters, someone can just reassign the function reference. Even if you check your fields in incoming object parameters,…