221–230 of 266 posts
I found myself always starting with native Date library, then eventually adding Moment.js when we needed to robustly support timezones and timezone conversions.
Nothing like receiving a text at 5am pacific, because the system is calibrated to Eastern Timezone work hours.
I worked extensively with Luxon (a sibling project leveraging modern js constructs) and found it to be really great! I’m really happy with their approach of creating an entirely new project to embody the API and new features you might expect in newer release of moment. It allowed Luxon to mature for several years without the weight of supporting the legacy api and avoided confusion within the community. The direction…
> Luxon is built around a few core ideas:
> * Keep the basic chainable date wrapper idea from Moment. Make all the types immutable. Make the API explicit; different methods do different things and have well-defined options.
> * Use the Intl API to provide internationalization, including token parsing. Fall back to English if the browser doesn't support those APIs.
> * Abuse the Intl API horribly to provide time zone support. Only possible for modern browsers.
> * Provide more comprehensive duration support.
> * Directly provide interval support.
> * Write inline docs for everything.
https://moment.github.io/luxon/docs/manual/why.html#ideas-in...
Earlier quoted context omitted.
> I wish the was a way to fix this attitude. So that project maintainers didn’t need to write two page apologies for finishing their thing. One of the problems is that GitHub is full of OSS libraries where the last commit was three years or more ago and you have no idea (without forensically analysing commits, issues, etc.) whether it's because the project is done or because the maintainer(s) lost interest, had other…
Github having an objective "This isn't being worked on anymore" flag with a few options as to why, and pointers for where to reach a community for support/discussion would be most useful, especially overlaid on the crazy huge dependency graph frontend projects tend to acquire.
Earlier quoted context omitted.
I don't view the mutability of moment as a complete show stopper, though. If you limit the surface area of the mutability by hiding the underlying moment object within an abstraction, then you can at the very least keep the chances of misusing moment to a minimum.
I also think it's not a showstopper for Node.js apps. For bundling in a front-end app it's waaaay too big.
That said, we wouldn't be in this position if more companies used a shared CDN for libraries instead of always bundling them.
It is not easy to replace moment.js since many libraries like react-dates rely on momentjs. Hope they have plan to replace it.
These kind of dependencies is one of the reasons I prefer to avoid react-* libraries. It would be nice to see more flexible dependencies in such libs for example like material-ui pickers [0] which let’s you bring your own date/time lib. [0] https://material-ui-pickers.dev/getting-started/installation
You either ship without any date support at all or you pick a library and go. Very little comes close to Moment for i18n and timezone support, so lots of libraries go with that.
The Temporal proposal to replace Date can't happen fast enough.
Earlier quoted context omitted.
Github having an objective "This isn't being worked on anymore" flag with a few options as to why, and pointers for where to reach a community for support/discussion would be most useful, especially overlaid on the crazy huge dependency graph frontend projects tend to acquire.
What’s the value in that vs a small note in README.md or similar?
Earlier quoted context omitted.
"moment.js: Mutable. Thank you, next." Mutable is not bad, buddy. You live in mutable world.
Mutability, in this case, can be pretty unexpected. Just like you don't expect the expression a + 5 to change the value of a but to return a new number, most people don't expect myDate.add(5, 'days') to change the value of myDate. I know that moment values are mutable, yet I often forget it while writing code and make dangerous mistakes because of how unnatural it is to see an arithmetic expression that is not immuta…
I would expect to use something like Moment.addDate(date1, 5, 'days') if I wanted a new instance of a date to be returned.
Even in javascript-land, methods like that will have side-effects, yet still return this often just for the sake of method chaining. E.g. date.add(5, 'days).format("%Y-%m-%d") would mutate date, but return the same instance as a convenience.
Earlier quoted context omitted.
You might benefit from flipping this around and asking yourself why you're not able to ship software that remains shipped without intervention. And why you can't even imagine a world where that would be possible. If you spend some time and effort removing whatever obstacles you have in place that are keeping you from being able to do that, you'll have a lot more free time to spend building new things. For what it's w…
Wow! What software is this that is complete and doesn’t need maintenance? Based on my experience, it must be either very simple or very uninteresting.