I mean, I’ve also done that at times, but it just happens so often around here. You basically can’t drive more than a few minutes on a road without having someone tailgating you…
…does actually work wonders. I just had to be forced to do it consistently.
Except I completely missed another factor:
Christmas Eve rolled around, my dad picked me up from the train station. It was just a ten minute drive home, but of course, some asshat had to tailgate us. My dad pretty much just routinely became angry.
Which I get. That shit used to stress me out, too.
But well, used to. I had not experienced that level of stress for multiple months. I felt like some monk, checking in on what the normal people were dealing with.
I do feel like it’s good, though, when libraries optimize. Ideally, they don’t have much else to do than one thing really well anyways.
And with how many libraries modern applications pull in, you do eventually notice whether you’re in the Python ecosystem, where most libraries don’t care, or in the Rust ecosystem, where many libraries definitely overdo it. Because well, they also kind of don’t overdo it, since as a user of the library, you don’t see any of it, except the culmulative performance benefits.
There used to be the genre of collect-'em-ups, where the thinly-veiled end goal was to just collect various items.
For example, to complete a level in Banjo-Kazooie, you had to collect 10 puzzle pieces and 100 musical notes, and you likely gathered lots more bonus collectibles along the way.
These were essentially just numbers going up. But we do all have that gatherer instinct in us, so if you can get past the meaninglessness, it’s just one of the easiest sources of endorphins.
And I feel like modern crafting systems evolved out of that. While you still can’t think too hard about it, they are providing meaning, in that you’re now collecting 100 wood planks, because you want to craft a house.
The unfortunate side effect is that they are now part of the soup which is pretty much mandatory to include in big budget games.
Indies are perfectly capable of fleshing out individual endorphin sources these days, so AAA games need to outdo them by having multiple. And the whole collect+craft loop is an endorphin source that can be added relatively easily to many game concepts, especially if you’re also buying into the mandatory open world.
So, I guess, the moral of the story is: AAA bad, indies good.
But like, for real. AAA won’t stop using the collect+craft loop, unless we have another massive technology jump where their big budget becomes useful again (like with 2D -> 3D, back in the days).
So, if you’re tired of it, you do want to look into smaller budget games or, I guess, some of the few remaining niche AAA titles…
I used to think so, too, but on the one hand, the DOM API is absolutely massive. Going through the standardization, implementation and documentation process another time would take decades.
And on the other hand, a language-agnostic API in WebAssembly would mean specifying it WebAssembly itself. And well, it’s Assembly-like, so what’s currently a single line for calling a JS function would turn into tens of lines of low-level code.
Ultimately, you’d want code from some other high-level language to give you a summary of how you may need to call your language-specific wrapper. In practice, that’s likely even worse than translating it from JS, because the high-level call isn’t standardized.
There’s actually in theory all the pieces in place to use a different scripting language, because in the early days, there really were multiple. But yeah, the massive DOM API is only really standardized+implemented+documented for JS, so you don’t get around it in the end.
As the others said, though, WebAssembly is starting to become a thing and the JS boilerplate for calling the DOM API can be generated for you.
Sure, but you can get frameworks that generate that for you. I’ve written whole webpages in WASM without writing any JS.
You don’t get around reading JS documentation, though. Especially the DOM API is just documented as JS, and you basically hope that your framework makes it obvious enough how to write that in your non-JS language of choice.
The == operator in JS will try to cast the things being compared and do all kinds of ‘smart’ assumptions about what equality means. This is why everyone uses === instead…