Thanks for the explanation. Honestly, your explanation is better than the entire video. - I watched it in full and got really confused. I completely missed the part where he said the light is pulsing at 30kHZ and was really puzzled at how he is able to move the mirror so fast to cover the entire scene.
Huh. I watched a lot, but not all, of the video, and I thought he made it clear early on that he was stitching together 1px videos & repeating the event for each pixel (about a million times for that 720p result)
Where do you even get the $3,000 standing desk? I am don't even compare prices and I got mine from Amazon for $200-$300. Sure the quality might not be the best but I just can't see there are people buying $3000 standing desks.
Early in the pandemic I bought a decent motorized standing desk for $520. It's nice, but I could very easily imagine a desk that costs 6x that. I would never buy that desk, but some people go for that sort of thing.
> And as someone who's into spy stories, I know that a big part of tradecraft is of formulating your questions in a way that divulges the least about your actual intentions and current information.
Not necessarily disagreeing with you, but if everyone started doing this, we will be in XY problem city.
Yeah, the commonjs to esm transition has been the python 2 to python 3 transition of JavaScript, except the benefits are limited (at least compared to the hassle created).
There are many libraries that have switched to esm only (meaning they don't support commonjs), but even today, the best way to find the last commonjs version of those libraries is to go to the "versions" tab on npm, and find the most downloaded version in the last month, and chances are, that will be the last commonjs version.
Yes, in a vacuum, esm is objectively a better than commonjs, but how tc39 almost intentionally made it incompatible with commonjs (via top-level awaits) is just bizarre to me.
It had to be incompatible with CommonJS regardless of top level await. There is no imaginable scenario where browsers would ship a module system with synchronous request and resolution semantics. A module graph can be arbitrarily deep, meaning that synchronous modules would block page load for arbitrarily deep network waterfalls. That’s a complete non-starter.
Given that, top-level await is a sensible affordance, which you’d have to go out of your way to block because async modules already have the same semantics.
Recently, Node has compromised by allowing ESM to be loaded synchronously absent TLA, but that’s only feasible because Node is loading those models from the file system, rather than any network-accessible location (and because it already has those semantics for CJS). That compromise makes sense locally, too. But it still doesn’t make sense in a browser.
Bundler engineer here. ESM is great when it comes to build-time optimisations. When a bundler runs into CJS code it literally deopts the output to accommodate - so from that side it's amazing.
But also, there's a special place in hell for the people that decided to add default exports, "export * from" and top level await.
Commonjs is also very weird as a "module" instance can be reassigned to a reference of another module
module.exports = require('./foo')
and there's no way to do this in ESM (for good reason, but also no one warned us). In fact major projects like React use CJS exports and the entire project cannot be optimized by bundlers. So, rather than porting to ESM, they created a compiler LOL
If I may, the evil is not in the top level await but in the use of a top level await in a module that exports. That is evil. But a top level await in a programs main script seems ok to me.
Hm, I'm sorry you feel that way. It's not meant to be mean. On the contrary; Instead of encouraging someone who I feel is going down a wrong path, to me it's kinder to express my view that they aren't. I have personally wasted years of my life on technical projects, and would have been better off if someone had told me that it was a bad idea.
I'm of the opinion that these passion projects are incredibly important.
Your passions projects were problably also far more important to your growth than you give them credit for.
Scratching an itch is how we, as programmers/engineers/whatever, grow. It is also how we stumble into solving real problems and make our mark on the world.
Who knows, this could become the next big player in the browsersphere, or maybe it'll pivot into something else, or perhaps it will spark someones imagination. At the very least it has (probably) already been a source of creative bliss and pride for the ones involved, which in my opinion makes it worthwhile.
This explanation is extremely misleading. For many of my projects, vast majority of the operations do not use the database . And the few that does, contains long running huge joins/aggregates. Using the sync API is just straight up terrible because the task will block literally everything else that does not use the db in js, meaning generating a report in the background can literally prevent you from handling any requests. (I did end up using better sqlite 3 because they are personal projects and getting stuck for 2 seconds when the scheduled report generation happens is ok ish for the a few people using it. But I will not consider using better sqlite 3 for any future projects)
