Do you make updates to your old games? or let them sit to look at every couple years and replay with a new perspective?
I recently ported some older harlowe games to sugarcube and chapbook based on their complexity, as a means of procrastinating from completing my game for the spring thing. I set myself this rule to not edit the plot or writing but just fix the css so that they remain playable on all devices. And that brings me to my sub question: Why do pages break on older browsers, even if they are not using any modern css or es6 features?
Because browser writers are more interested in one-upmanship in the quest for marketshare and control (and increasingly: data collection) than they are in whether or not your stuff works. The W3C is part of the problem, having sold out long ago, indeed if they ever even were in a state of not being sold out.
Web browsers are actually one of the most stable and reliable platforms there is, perhaps only Win32 is more reliable. If things break it’s likely because it was doing something subtle that was technically invalid in the past and has been tightened up since.
But that’s forwards compatibility. It’s more likely that it won’t work as well on old browsers, because old browsers are full of bugs!
One cause of old games breaking that I’ve seen occasionally (e.g., when spelunking through the IF Archive) is stricter cross-origin checking by modern browsers. (Can’t remember if I’ve seen that specifically for a Twine work, and I don’t have examples to hand.)
Posix might be fine, but in practice it isn’t always easy getting things to run on older/newer versions of Linux because glibc version mismatches are difficult. On Linux now apps are frequently packaged in containers with all their libraries included, or just statically linked in the first place. The developer experience on Windows is often easier.
Because (older) web standards only describe the common behaviour of a thing, and it was left up to the web-browser developers to decide:
if they would implement a specific thing at all.
how much of a specific thing’s specification they would follow when they did implement it.
if they would add any additional behaviour to a specific thing, that wasn’t covered by its specification.
what “our web-browser only” things they would add, that weren’t covered by a specification at all.
Much of a web page / app developer’s time was spent working out how to get something to appear consistent & “work” on multiple web-browsers. And when CSS or JavaScript was involved, the effort required to do both of these things just increased.
Windows peaked at Windows 7, I have used all the later ones and it’s not trivial to run old stuff, or even new stuff sometimes (you have the required graphics card but software says you dont, you have more than needed RAM still things aren’t smooth, etc).
Yeah, I’ve tried my hand at Android dev a few times and I always step away feeling icky.
I’m pretty committed to the idea that closed source software is a problem to be overcome, especially on mobile devices that hold so much power over people’s daily lives. But in the Android communities supposedly devoted to freeing and unlocking devices there’s way too much BS like “I did this, so now trust my binary posted to this random forum thread so I can bask in everyone’s adulation” instead of organized attempts to create a free ecosystem by, you know, posting source to dedicated repos. Maybe it’s changed since last time I looked, but I doubt it.
This was the scenario in 2015, and is pretty much the same in 2025 too, with the addition that most useful stuff get deprecated by the team themselves. (I have not used Jetpack Compose and can’t speak about its ecosystem though).