411–416 of 416 posts
Earlier quoted context omitted.
The big bundle size is a reason.
Is it bigger than the equivalent Luxon or whatever? Or maybe I'm just fortunate to work in sectors where no one ever really cares about bundle size.
Does this mean we can finally stop downloading and running a third of a MB of js on every website? moment.js, luxon, date-fns, are all obsolete? https://bundlephobia.com/package/moment@2.30.1
In reality, it probably means adding yet another polyfill to the list.
Does this mean we can finally stop downloading and running a third of a MB of js on every website? moment.js, luxon, date-fns, are all obsolete? https://bundlephobia.com/package/moment@2.30.1
> Does this mean we can finally stop downloading and running a third of a MB of js on every website? moment.js, luxon, date-fns, are all obsolete? https://bundlephobia.com/package/moment@2.30.1 In reality, it probably means adding yet another polyfill to the list.
Tangentially... Why did you quote the entire parent post? Quoting a small subset of a large post to respond is one thing, but copying the entire post into a reply adds unnecessary repetition and visual noise to the thread for no benefit. (Is it just me or is this becoming more common?)
Earlier quoted context omitted.
Smolcorp here, we just went from 12-20 across several large projects, it was gnarly. And now, 20 is already set to sunset soon. at some point it just feels like you should give up trying, but I'm hoping 20 to >20 isn't as bad as 12 -> 20
I know it doesn't always work out, but it definitely helps to keep current, rather than performing a massive update every X years. Most of the time the changes are minimal, but they add up over several major revisions. Of course, every now and then something like eslint will completely break every project in existence by changing the configuration format, then you have to wait for all of the plugins to be updated (if…
I really like the temporal proposal, except for one thing: they rely on reference equality in comparisons. On other words: Temporal.Instant.from('2020-01-01') != Temporal.Instant.from('2020-01-01') This isnt inherently bad, but it effectively removes the ability to use these objects as Map keys or collecting them in a Set. I know why that decision was made, I'm just sad that this wont be possible. Maybe there will be…
It looks like `.epochMilliseconds` should work as a Map/Set key/member in some situations, though you'll need to preserve the instant in the value in the Map case if you want to preserve the zonedata / do further operations on the Instant. For the Set case you could use a Map{v.epochMilliseconds:v} and preserve the Instant. Not great, but I think we all blame JS for this rather than Temporal. This could be made to wo…
I had to resort to numbers (Unix time) to not have to add memoization everywhere. Seems like this will continue with Temporal. Or React-Compiler will solve this.
I really like the temporal proposal, except for one thing: they rely on reference equality in comparisons. On other words: Temporal.Instant.from('2020-01-01') != Temporal.Instant.from('2020-01-01') This isnt inherently bad, but it effectively removes the ability to use these objects as Map keys or collecting them in a Set. I know why that decision was made, I'm just sad that this wont be possible. Maybe there will be…
Because it is impossible in JS? Except some crazy hacks, similar to how Java's constant string pool works, where every used object is a reference to a value in a pool of all objects.