If you're not convinced vimming is the best way to interact with your editor, you probably haven't seen a really proficient vimmer.
I've always wondered the best way to write tests for "This event should happen x% of the time."
Obviously we could re-run the test 100 times and see if it happened close to x%, but not only is that inefficient, how close is "close"? You'll get a bell curve (or similar), and most of the time you'll be close to x but sometimes you'll be legitimately far away from x and your test will fail.
You could start from a known seed, but then are you really testing the percentages, or just checking that the RNG gives you the same output for the same seed, which you already know?
You have plenty of time before the product is released to register and verify everyone. You completely avoid traffic issues. Accounting is easy - you'll sell out when you run the lottery. You'll build a reputation for releasing inventory fairly and without causing undue stress on your customers, and avoid the suspicion that you're in cahoots with the scalpers (looking at you, Ticketmaster).
I'm accustomed to stressing out over concert tickets and struggling to get gaming consoles, and have a deep hatred of scalpers and the platforms that enable them, but I had no idea that scalpers were ruining the educational/hobby markets too. That seems really low.
It’s not. It doesn’t do hot reloading, and it’s one of the features the author rejected I think.
Also, in case of working on an Electron project: How well does it handle main/render/preload compile targets and handling of native modules and linking?
Electron-forge is, for instance, the recommended toolchain for building Electron apps and the Webpack stuff is a particular pain in the ass.