11 ms·
Day.js – Fast 2kB alternative to Moment.js with the same modern API
- tmpfile 4y agoPet peeve: would be nice if they offered a Chapter View or Single Page View or PDF of their documentation.
- tobase 4y agoLuxon has been my go to lib for date and time but will try this out.
- viddi 4y agoThere's an error in the documentation. What's the standard procedure to submit a pull request or bug report here? The docs subdirectory just links to the website and I couldn't find them in the gh-pages branch, either.
- 9wzYQbTYsAIc 4y agoProbably a good question to ask here: https://gitter.im/iamkun/dayjs https://gitter.im/iamkun/dayjs
- noduerme 4y agoI'm a fan of Moment... it's served me well for most of a decade, including in some really heavy scheduling/timetable applications. The size of importing Moment is really fairly negligible for a full-scale single page app. The one drawback I find with it is the overhead for creating new Moment objects. You never want to, for instance, run through a for/next loop of SQL dates and convert each into a Moment for sorting. If you must have them as Moments, you really need to cache once and compare later. Usually in my code I even avoid writing `new Moment()` within a control structure that only needs the current day or hour, and I set up an interval to run permanently in a utility class to just cache a recent Moment every 10 seconds or so, for comparison wherever else it's needed in the code. That's the only real issue for me with Moment and I'm not sure this lib would change that... especially if I need to extend it for various uses every time it's called, which for me would be a rather large drawback that would end up polluting lots of modules with extra lines of code for specific date comparison purposes.
- Hendrikto 4y ago> The size of importing Moment is really fairly negligible. This attitude is why large parts of the Internet suck these days. I recently visited a friend in Kallithea, Athens, Greece. With his Internet connection, that would add about half a second. It‘s a typical speed for residential connections in Athens.
- noduerme 4y agoAgain, my context here is a large (1-2Mb) single page application. I wouldn't use a library like that in a static/informational webpage, and it's hard to think of a context where it would be necessary.
- nabaraz 4y agoWhat is the obsession with xKB? With tracking, analytics, monitoring and gazillion other scripts, I'd wager that an average webpage size is probably closer to 1MB. Checked some of the popular sites (caching enabled)- Amazon.com - 4.8MB Google.com - 2.5MB
- szundi 4y agoWhen you can, you save, you’ll be faster. Also you are more willing to include more libs if they are all small, and more easily include new big ones when necessary without the soon need to rewrite your code as it became too big. Hosting is cheaper.
- markdown 4y ago> I'd wager that an average webpage size is probably closer to 1MB. And the average American is heavier than they should be. Doesn't make it ideal. Always endeavour to trim the fat. This is HN, and despite the likely predominance of US big-city devs here, I'd wager that most of them like money from rural dwellers just as well as they do the money of their fellow city-slickers.
- swyx 4y agoalso people are gonna load Amazon and Google no matter the size. if your shitty startup or ecommerce site takes >1s to load... not so much.
- laundermaf 4y agoWhy do you reckon the average webpage size is closer to 1MB? Could it be perhaps because people do not obsess with xKB? It’s just 140kb extra, don’t worry about it. Repeat 5 times.
- Hendrikto 4y ago> What is the obsession with xKB? […] I'd wager that an average webpage size is probably closer to 1MB. This is the mindset that got us into this mess…
- maxloh 4y ago
- TekMol 4y agoI never use any date library and I never had a problem with it. I just use what the native Date() object offers. Other devs always say "Just wait, one day it will fall on your feet". But this has been going on for many years, in which my software has served millions of users and nothing ever fell on my feet. I think the complexity of a library like this (423 files, 1433 commits, 53004 lines of code) would have created more problems during this time. So not using one is a net positive. Any minimal code example of what is prone to break without a date library and how this date library is supposed to prevent it?
- epgui 4y agoExamples of essential complexity you have to worry about if you want your code to be correct, and even if you want to test/detect all issues that can/do come up: - https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time https://infiniteundo.com/post/25326999628/falsehoods-program... - https://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-about-time https://infiniteundo.com/post/25509354022/more-falsehoods-pr... In my experience engineers will often brush these sorts of things off as “edge cases”, but really all of these complexities are just how dates and time work in the real life (I’d argue that they’re just “normal cases” to test for)… So any anomaly in software will cause real problems of varying importance for users.
- extheat 4y agoI only see this being an issue storing times as strings. Why not store them as integers (like a Unix timestamp) or at least some standardized string format? The only reasonable use case I can think of where you absolutely need all this complexity is if you're rendering a calendar or something similar.
- 9wzYQbTYsAIc 4y agoThere are countless, profitable business use cases for accurate time tracking.
- ohbtvz 4y ago
- johnny_reilly 4y agoInteresting to see the support for luxon. When moment was announced as a done project they recommend a number of alternatives; one of those was luxon. Date-fns was also in there, and given I was already using it I carried on my merry way! I'm curious what the difference between luxon and date-fns is. Npm trends are interesting https://npmtrends.com/date-fns-vs-dayjs-vs-luxon-vs-moment https://npmtrends.com/date-fns-vs-dayjs-vs-luxon-vs-moment
- mgkimsal 4y agoIIRC, moment's website listed luxon as their recommended replacement via a top-site banner. The banner seems gone now, but luxon is still the first listed on the recommendations page.
- robertwt7 4y agoI love dayjs! I’ve been using it for the past 4 years in most projects and I have no issue at all. Current company used moment, but recently they also changed to dayjs as well. Love to see the author being very active in github as well :)
- taspeotis 4y ago> Moment.js with the same modern API Moment.js objects are mutable [0], and this library's objects are ... immutable. [0] https://momentjs.com/guides/#/lib-concepts/mutability/ https://momentjs.com/guides/#/lib-concepts/mutability/
- moogly 4y agoThe mutability in Moment.js is not really a feature though, just a massive inconvenience/source of bugs (unless you use `.clone()` all over the place). But yeah, very important difference.
- miohtama 4y agoMutability cannot be enabled thru plugin: https://day.js.org/docs/en/plugin/bad-mutable https://day.js.org/docs/en/plugin/bad-mutable However it is discouraged as mutable dates often lead to less maintainable, harder to debug, code.
- brundolf 4y agoIt's not quite exactly the same API - you'll need to do some testing afterward - but if you're using Moment idiomatically, nearly everything should just-work
- rs_rs_rs_rs_rs 4y ago>Fast Where are the benchmarks?
- FrontAid 4y agoIf you are considering switching to a (different) date library, I would suggest to hold off. ECMAScript is about to introduce a native date and time API that is much better than the current Date functionality. It may also make the need for a third-party date library obsolete (as long as you do not need to parse custom date formats). - https://github.com/tc39/proposal-temporal https://github.com/tc39/proposal-temporal - https://github.com/tc39/proposal-temporal#polyfills https://github.com/tc39/proposal-temporal#polyfills - https://tc39.es/proposal-temporal/ https://tc39.es/proposal-temporal/ - https://tc39.es/proposal-temporal/docs/index.html https://tc39.es/proposal-temporal/docs/index.html - https://github.com/tc39/proposal-temporal/issues/1450 https://github.com/tc39/proposal-temporal/issues/1450 - https://tc39.es/proposal-temporal/docs/parse-draft.html https://tc39.es/proposal-temporal/docs/parse-draft.html As far as I know, issue #1450 is the last remaining blocker for the standardization. I'd assume that this will be resolved in the next months. So Temporal will likely be officially released with ECMAScript 2023, but browser vendors and other implementors will start shipping it before the offical release.
- iainmerrick 4y agoInstead of using something that works right now, you’re saying people should hold off for a few months, then start using a prerelease API?
- badlucklottery 4y agoThey mentioned "switching" which implies an already working solution. Within that context, yeah, maybe wait a few months if you can afford to. Also, once the spec is finalized, there may also be a compliant polyfill available. If so, you'll get the functionality early and still have good compatibility down the line.
- dspillett 4y agoIf you have something working, perhaps delay refactoring to a new library. Or as it is coming RealSoonNow(tm) perhaps start looking into polyfills as you are going to need one anyway for a story time at least to support LTS browser versions.
- HatchedLake721 4y agoIf you need timezone support, be careful, there’s a few critical timezones bugs you can find in GitHub issues that made us switch to Luxon.
- danr4 4y agolinks?
- fareesh 4y agoNot sure if this is a gotcha, but how does one make a JS date object (across Safari, FF and Chrome) that refers to the same day of the year regardless of timezone?
- chaitanya 4y agoYou can’t, because JavaScript date objects are just timestamps. Here’s what I wrote on this (along with a small library to handle this problem): https://lisper.in/javascript-date https://lisper.in/javascript-date
- fareesh 4y agoInteresting, thank you for your work, I might use it in a project. Edit: looks like I need a date object specifically, so I will go with the timezone conversion method and convert back to timestamp
- aabbcc1241 4y agoyou can find small alternative with https://bundlephobia.com/ https://bundlephobia.com/
- lloydatkinson 4y agoI highly recommend date-fns instead as that uses the native Date object. It doesn’t use a wrapper.
- tyingq 4y agoMoment.js gets a lot smaller if you apply the same trick Day.js is using here, that is, to just load the locales that you need. See https://medium.com/rise-engineering/how-we-managed-to-shed-300kb-of-moment-js-size-in-angular-d2931d448194 https://medium.com/rise-engineering/how-we-managed-to-shed-3... for an example. Takes Moment.js from 364KB to 59KB. Still much larger than 2KB, but perhaps small enough.
- ramesh31 4y agoMoment has always been absurdly large. There's really no reason for it. The vast majority of usages can be solved with 4 lines of native `Date` object based code.
- 0xHenry 4y agoI'd love to see how different this is from moment.js
- zzzbra 4y agoi’ve definitely enjoyed using this but it would be nice it there was better TS support for some of the extensions
- erikpukinskis 4y agoDay.js seems cool, but when I was evaluating these libraries I noticed the ‘startOf’ function doesn’t take a time zone argument… I guess it just presumes you want the system offset? https://day.js.org/docs/en/manipulate/start-of https://day.js.org/docs/en/manipulate/start-of I can’t trust a date/time library that’s blasé about time zones at the API level. Undefined behavior around time zones causes a steady stream of off-by-one bugs in your codebase if you’re not vigilant.
- layer8 4y agoHopefully there will be Night.js to complement it.
- FractalHQ 4y agoI prefer date-fns https://date-fns.org https://date-fns.org It’s functional and tree shakable! I’ll have to check out Day.js next time though.
- chucklenorris 4y agoBtw most libraries (luxon, dayjs) that use Intl api to do timezone manipulation in chrome and nodejs and are excruciatingly slow. So slow that pods would get restarted because they would fail to respond to health check while doing the timezone manipulation, on moderate traffic (50req/s). I still use moment-timezone because it comes with it's own tzdata and it's 100x faster.
- 9wzYQbTYsAIc 4y agonot bad, a quick skim of the repo shows that the locale file sizes might be 50% or less as compared to Moment.js - approx. 1 kB per locale from day compared to 2+ kB per locale from moment
- linecept 4y agoWhy is this good/better compared to date-fns?
- simon--poole 4y agoHaving used both moment and Luxon in the past, the date-fns API makes no logical sense to me at all.
- motoxpro 4y agoInteresting, I am the exact opposite. Things like isAfter and addDays as functions just seem so simple.
- benknight87 4y agoSmaller bundle size, similarity to moment.js As a dev who’s used all three, is there a massive difference? Not really. Stick with what you like (though moment is no longer maintained so maybe not that)
- RedShift1 4y agoMoment is still being maintained, but will not receive any new features.
- code_runner 4y agoMoment’s own docs tell you to not use moment
- 1123581321 4y agodate-fns doesn't have the best function naming scheme.
- 999900000999 4y agoVery awesome to see Moment JS have a legacy. What a great api
- psydvl 4y agoBut no new features. However, not sure it's required some
- throwaway0x7E6 4y agoyeah, why stop at 200 KiB (or something) it already is
- jokethrowaway 4y agoIt's embarrassing we never evolved the date api which comes with the browser. That said, I tend to err on writing a custom function / importing only a custom function over importing an entire library just to run a 2 lines function.
- cercatrova 4y agoThe new Temporal API in JS is precisely that.
- tobyhinloopen 4y agoLooks a bit like JS-Joda.
- johnnypangs 4y agoYeah, but that’s been just a proposal for a long time. Getting new features in JS takes forever.
- Gare 4y agoConsidering that they tend to stay forever, I'd rather wait for them to be well designed than rushed and half-baked.
- dbbk 4y agoAlmost all of it has already been implemented in Safari and Chrome, it's behind a feature flag until the spec is finalised
- eyelidlessness 4y ago> just a proposal It’s literally final pending commitments from/to another standards body. If they hadn’t made that commitment there’d be people chastising them for something else. I swear to fuck, we can’t have nice things because no one will ever accept having nice things.
- Nican 4y agoI have not used moment.js or other date libraries in a long while. But how does this compare to Luxon? (https://moment.github.io/luxon/#/why https://moment.github.io/luxon/#/why)
- zebracanevra 4y agoDayjs is 2kb. That library is 70kb+. Dayjs has the familiar momentjs API. Both libraries have the greatest differentiating feature from moment: immutable objects. Being able to compose dayjs objects together without fear of modifying them afterwards makes everything a breeze.
- _fat_santa 4y agoFull disclosure I haven't used Luxon nearly as much as I've used DayJS, but I would say IMO DayJS is way simpler and more intuitive, this is a very small thing but for example, why would they format Months, by "L" instead of by "M"? The other reason I like DayJS over Luxon is the sheer number of plugins you can pull in to do various things. Like for example I was building an application where I had to build a weekly calendar form for a timesheet, the requirement was weeks start on Saturday and end of Friday. In DayJS I was able to do this pretty easily by doing: dayjs().startOf('week').subtract(1, 'day') to get the start and then took the result and did res.add(6, 'days') to get the end. I'm not sure if Luxon has this type of functionality. Lastly I like the plugin architecture rather than giving you everything up front. By default DayJS does not include any of those cool transformations like I talked about above, you have to pull them in as plugins from DayJS, this results in a bit more setup but smaller bundle sizes at the end of the day.
- icambron 4y agoIn Luxon that is dt.startOf(“week”).plus({ days : 6 })
- Mogzol 4y ago> why would they format Months, by "L" instead of by "M" "M" is used for months in Luxon, and is usually what you should use. "L" is only for standalone months, i.e. not within a date string, usually not what you want. In English these are the same thing, but in some languages they are different. https://github.com/moment/luxon/blob/master/docs/formatting.md#standalone-vs-format-tokens https://github.com/moment/luxon/blob/master/docs/formatting....
- deleted 4y ago[deleted]