Is 74Kb really a cause for concern on modern internet connections? I realize death by 1,000 cuts, etc...but for such a core set of functionality that seems pretty reasonable.
DayJs is 2 (two) Kb. Perfectly reasonable for any app with minimal date handling needs.
(BTW I'm 100% in support of a native temporal API also, although have some gripes with the Dev Exp of what's shown in this post)
That depends on how you define what a modern Internet connection is. If you mean a fast, low latency, unmetered connection then 74kb is obviously fine.
If you mean a 4G connection on a train, or a metered rural satellite connection, or a typically-low-income-user pay-for-data connection, or even a fast cheap Internet connection but with a low-end device that will waste a lot of battery power parsing and running all that JS code, then it's a lot less obvious.
Most of the time you don't know who the user is, so it's best to assume the worst case. If your site works well when things aren't ideal then it'll be awesome when they are good too. Only thinking about the happy path of users with M1 Macbooks with unlimited gigabit ethernet will mean everyone else has a sucky time on your site.
Also, if someone posts your site on HN, most of the comments will be about how bad the code is and you'll miss out on feedback that's actually useful. If you're deploying a 74kb date library, think of your karma.
I think people assume Starlink will bring high-speed internet to every corner of the globe, but that being the case, there’s more situations where groups of people will share a single downlink, and still every kilobyte counts.
You can have LTE+ or even 5G in cities, but traveling by train means that in some areas only a select few extra-lightweight pages like Hacker News are able to load before a timeout or connection loss occurs.
So yes, in some situations even that amount of payload could have a meaningful impact.
“Modern” connections are irrelevant if we are talking about regions, which are not viable for a high-speed infrastructure. And such places are almost everywhere. Mountainous parts of Japan, many American regions, or sparsely populated Polish regions.
Of course, how much it is important varies greatly.
Not too long ago, Google tried to push AMP on all of us because devs were getting way too careless with their bundle sizes. We're still not to a decent place just yet. Internet speeds in The United States, Europe and populated Asia may be growing but there's an entire world that are still at "slow-3G" speeds.
If there is solution that removes the necessity of a 74kb package then I think we should embrace it.
I’m still fairly new to TypeScript but it’s quickly replacing Python as my daily driver for most things that aren’t back-end APIs, and Date is certainly one of those things I would love to see changed.
I’d say that time-related API being core functionality makes it more of a reason why this should be baked into the standard JS API. Why make users download something that most sites and web apps use?
If there is solution that removes the necessity of a 74kb package then I think we should embrace it.
I’m still fairly new to TypeScript but it’s quickly replacing Python as my daily driver for most things that aren’t back-end APIs.
A considerable fraction of all the data ever sent on the internet is JS libraries that could have been bundled into browsers instead of every web page using slightly different versions.