I agree—I loathe frontend development, but React made it tolerable to do for limited periods—but it's still a hack on a teetering Jenga tower of hacks.
The really funny thing is that the OS runs a simple event + render loop, then the browser implements a wildly complex stateful/declarative structure on top of that (the DOM), then React apps create a simple event + render loop again, this time with special diffing logic to update the underlying DOM as little as possible
This is a great insight. I'd never noticed this about browser stuff, but it's definitely a major issue in video game development.
Like, most game dev frameworks (especially for mobile) leave you with device-level looping, under language-level looping, under framework-level looping, under code-level looping. This, obviously, is hell.
The result is that something as simple as "play this sound file, looping when finished" ranges from awkward to literally impossible. Memory access, garbage collection, and framework timing all collide and leave you with mysterious multi-second gaps while everything tries to sync up. And so everyone building something serious has to dive down past LibGDX into awful, ground-level things like Hammer or un-frameworked C++/Java/etc.
I'm not sure what the cure is - unlike a AAA game, there's room for a tiny bit of inefficiency in a webpage. 0.1-0.5 second loads are reasonable, instead of 0.01 second frame renders. But right now the endless layers are spitting out far too many 10 second load times, and no one even seems to notice the redundancy.
Yes, we write web browsers in JS, simply because our browsers let us write nested browsers in JS. I'm only waiting for an OS written in JS so we can use its editor to write an OS in JS.
loathe? I loathe public speaking and flossing, but these things are good for me, and I'm sure you wouldn't be doing frontend dev if there wasn't a big upside that it made possible.
> teetering Jenga tower of hacks?
How is any programming language not capable of being brittle?
