> Cursed knowledge we have learned as a result of building Immich that we wish we never knew
> Cursed knowledge we have learned as a result of building Immich that we wish we never knew
50 extra packages are cursed
There is a user in the JavaScript community who goes around adding "backwards compatibility" to projects. They do this by adding 50 extra package dependencies to your project, which are maintained by them.
which bring to this user: Jordan Harband https://github.com/sponsors/ljharb
Does anyone know what they actually mean with that cursed knowledge point? And what's the "backwards compatibility" that Jordan also boasts in his GH profile?I love reading about opensource drama, especially if it's some technology I don't use directly, it's like watching a soap opera.
https://github.com/A11yance/axobject-query/pull/354#issuecom...
Is he really being paid per download, or is he just being sponsored? It’s not clear if either would imply some form of malicious intent either.
His libraries tend to build up on older runtime implementations and freeze every used functionality during runtime, so they provide "second-run safety" and "backwards compatibility". Developers disagree with some of its effects, such as a grown dependency tree and impacts in performance of multiple magnitudes (as measured in micro-benchmarks). ljharb seems to follow a rather strong ideology, but is a member of the TC39 group and a highly trusted person.
https://github.com/A11yance/axobject-query/pull/354#issuecom...
The problem is that he's forcing his ways on others. If we're identifying an aggressor here, it's him. The project maintainers are the victims.
Honestly, I can't understand the intent behind such a defensive rebuttal to the criticism of his actions.
I still think the conclusion on "setTimeout is cursed"[0] is faulty:
> The setTimeout method in JavaScript is cursed when used with small values because the implementation may or may not actually wait the specified time.
The issue to me seems that performance.now()[1] returns the timestamp in milliseconds and will therefor round up/down. So 1ms errors are just within its tolerance.
[0]: https://github.com/immich-app/immich/pull/20655
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Performance...
setTimeout() does not actually guarantee to run after the elapsed time. It merely gets queued for the next async execution window after that timer elapsed. Hence it can also be off by infinity and never get called - because JS is single threaded (unless you use a worker - which comes with its own challenges) and async windows only open if the main thread is "idle".
Usually, this is very close to the time you set via setTimeout, but it's very frequently slightly off, too.
Is there even such a thing? You're at the mercy of the platform you're running on. And Windows, Linux, Mac, Android, and iOS are not realtime to begin with.
I guess if you're running on a realtime platform but in a VM like JS does, you can then take that property away, downgrading the "language" from being realtime. I wouldn't call that a language property still though, maybe my VM implementation doesn't make that downgrade after all.
Then there are also gotchas like these[0][1]:
> As specified in the HTML standard, browsers will enforce a minimum timeout of 4 milliseconds once a nested call to setTimeout has been scheduled 5 times.
Still, the issue is rather how to measure the elapsed time reliably, for unit-tests among other things.
[0]: https://developer.mozilla.org/en-US/docs/Web/API/Window/setT...
[1]: https://html.spec.whatwg.org/multipage/timers-and-user-promp... (first Note)
See: https://developer.mozilla.org/en-US/docs/Web/API/Window/setT...
i wish there was an unused lambda parameter warning..
Sometime I want to build a DB front-end that you send up some type of iceberg/parquet or similar, and return a similar file format over a quic protocol. Like quic, persistent connections could be virtualized, and bulk insert could be sane and normalized: eg insert these rows into a table or temp table, then execute this script referencing it. While I'm at it, I'll normalize PL/SQL so even brain-dead back-ends (sqlite) could use procedural statements and in-database logic.