[HN Gopher] You don't (may not) need Moment.js
___________________________________________________________________
You don't (may not) need Moment.js
Author : thunderbong
Score : 43 points
Date : 2021-09-18 18:57 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| throw_m239339 wrote:
| You don't need all those small libs but apparently React is
| mandated in every shop now... the JS community is a joke.
|
| Where is the "you don't need React" website/repo again?
| honie wrote:
| I was wondering if you would mind being a bit more specific
| about your criticism towards React and the JS community?
|
| If you know React well, it seems like there are things that
| everyone can learn from or think about. Would you use vanilla
| JS or other frameworks and why?
| imbnwa wrote:
| People don't use React because the magnitude of managing the
| view update code is so large and/or complicated that diffing a
| reified DOM tree in toto is superior (I've seen it used for an
| app that consisted of a few screens with some text and a button
| each), its become standard so everyone learns one interface and
| development is normalized across shops. This has the benefit of
| a flourishing component ecosystem.
| throw_m239339 wrote:
| > its become standard so everyone learns one interface and
| development is normalized across shops
|
| An industry using the exact same framework (for a time, it
| never lasts) doesn't make that framework a "standard". jQuery
| was also "a standard" by the same logic.
| 8note wrote:
| A standard choice, rather than run by a standards committee
| imbnwa wrote:
| Yes, thank you
| sam_goody wrote:
| JS has been moving forward with a new Date/Time API called
| Temporal[1].
|
| I haven't had a chance to use it myself, but a friend dropped
| Moment.js for it (I think to keep the browser from adjusting the
| date to the local time).
|
| New APIs (and hence, Temporal) are the type of things that if you
| don't know about, you can easily miss and go straight to a
| library for.
|
| [1]: https://2ality.com/2021/06/temporal-api.html
| wruza wrote:
| Oh wow, someone finally took it serious. Everyone: visit the
| link if you didn't yet. Abstract dates, durations, easy dmy
| math, mostly everyday developer-friendly. Dates are one of
| these computer topics that seem familiar (just like numbers in
| a floating point form) but are hard to operate on. And if the
| language's core date/time library is poor man's one, it's
| better to not have it at all.
| smichel17 wrote:
| How do they compare to Luxon?
| merb wrote:
| they might get built-in https://caniuse.com/temporal?
| (https://tc39.es/proposal-temporal/docs/)
| (https://github.com/tc39/proposal-temporal)
|
| > NOTE: Although this proposal's API is not expected to
| change, implementers of this proposal MUST NOT ship unflagged
| Temporal implementations until IETF standardizes
| timezone/calendar string serialization formats. See #1450 for
| updates.
|
| it's basically already accepted. Stage 3 means it's basically
| ready for a preview implementation and stage 4 means passed
| for "official" ecmascript inclusion
| guptaneil wrote:
| Shameless plug: if you're looking for natural language date
| parsing, check out Sherlock.js -
| https://github.com/neilgupta/Sherlock
|
| Otherwise, definitely try native APIs first for straightforward
| date manipulation.
| AdrianB1 wrote:
| I love the approach. I would love to see a good quality "You
| don't need jQuery" out there; people talk about that, but I never
| found something to tell what to use instead and why, just generic
| "use JavaScript for DOM manipulation" (fair) and "use one of the
| alternatives for AJAX" (which one?).
|
| Is there anything like this planned for "You don't need"?
| steve_adams_86 wrote:
| The Ajax alternative is fetch, the native browser API which has
| excellent polyfills for the server which enable JavaScript to
| be isomorphic and dynamic to users and search engines.
| Basically your code will run as expected on the client or
| server, so fully rendered pages can be served - even if it
| needs to call an API to populate content.
|
| https://youmightnotneedjquery.com/ Is this the kind of thing
| you were mentioning? Maybe it's been a while, but if you Google
| "you don't need jquery" you'll find plenty like this and it
| seems to explain well enough.
| ptx wrote:
| The post-jQuery native browser APIs that were added to support
| those use-cases are _querySelector_ for querying the DOM and
| _fetch_ for AJAX (assuming you don 't need the X part).
| buster wrote:
| I'd be interested, in what constitutes a performance sensitive
| web application... is it a full fledged 3D game renderung
| thousands of time strings per second? Or .... ?
| mimsee wrote:
| These days facebook.com could be considered as one.
| dSebastien wrote:
| Established projects using Moment.js a lot might have a hard time
| migrating to something else. Quite unfortunate because there are
| now much nicer / better optimized libraries/APIs out there today
| like date-fns, the new Temporal API, Luxon, etc.
|
| For those still stuck with Moment, it's worth exploring means to
| reduce the impact on bundle sizes. I wrote about that a while
| ago: https://dsebastien.net/blog/2020-07-12-removing-moment-js-
| lo...
| Alex3917 wrote:
| Day.js is basically a drop in replacement, and is 97% smaller.
| You still need to regression test, but imho it's one of the
| highest impact ways to spend a few hours if you care at all
| about performance.
| binarymax wrote:
| Considering moment.js says[0] you should actively consider
| alternatives instead of it, I can't disagree. But I do like the
| breakdown of what to use when instead!
|
| [0] https://momentjs.com/docs/#/-project-status/
| amarshall wrote:
| In fact, Moment's post links to the OP here.
| armchairhacker wrote:
| What's the state of cached ES module imports?
|
| The ultimate goal is, your <script>s are modules, and import
| their dependencies from a common CDN like unpkg. The browser will
| cache the import, so that large common imports are rarely
| actually fetched. Dependencies would have their own cached
| dependencies as well (although this would sharply decrease
| efficiency without extra coordination between client / server for
| bulk fetching).
|
| This would significantly reduce MB-large JavaScript files because
| most of that code is shared general libraries. Even if you use a
| huge library like core.js with no tree shaking, it's no longer an
| issue, as long as many others are also using core.js.
|
| I do know that module scripts can import from remote sites, and
| unpkg with the experimental '?module' resolves imports in unpkg
| modules to other unpkg modules. I also know that browsers are
| very good at caching modules. I doubt browsers are smart enough
| to bulk fetch multiple unpkg dependencies in one request.
|
| Does anyone have more experience with, in general, trying to
| cache large JavaScript imports?
| doliveira wrote:
| Even before the current rules partitioning cache by domain, has
| the promise of those cached scripts ever paid off? Even when
| every website would use just jQuery, everyone had a different
| version, getting it from a different CDN, etc...
| realityking wrote:
| > The browser will cache the import, so that large common
| imports are rarely actually fetched.
|
| Cross site caching is dead. Safari hasn't supported it in years
| and Chrome recently dropped it as well. It's better to hold all
| assets on your domain to avoid TCP and TLS overhead.
|
| Here's a blog post with more details about Chrome's change:
| https://www.stefanjudis.com/notes/say-goodbye-to-resource-ca...
| extra88 wrote:
| Looks like Firefox also made it the default in January with
| version 85.
|
| https://developer.mozilla.org/en-
| US/docs/Web/Privacy/State_P...
| qvq wrote:
| > I doubt browsers are smart enough to bulk fetch multiple
| unpkg dependencies in one request.
|
| https://github.com/WICG/import-maps/issues/209
| dexwiz wrote:
| I implemented a date time library for JS a few years ago and took
| heavy inspiration from java.time. My conclusion is that the time
| zones are the hardest part of the whole thing. Time zones are
| defined by political entities that doesn't give two cents about
| implementing them. Also there is a huge variance in their details
| so just because you understand time zones in X country, don't
| assume that knowledge is universal. Some of my favorites are
| timezone changes at midnight, so 1159>1am, meaning some days lack
| a midnight. Also some Muslim countries switch back to normal time
| for Ramadan, which means up to 4 changes in a single year.
|
| Also anyone trying to sell "Midnight GMT" as a date only format
| is in for a world of trouble down the line.
___________________________________________________________________
(page generated 2021-09-18 23:00 UTC)