(brought to you by boringcactus)

the browser is a terrible place for art (31 Dec 2023)

condensation on the shower door is a more stable platform to develop for than the web.

i’ve grumbled repeatedly before about how the web’s lack of actual versioning is a nightmare hellscape from satan, but i may as well rehash that even though it’s not the thing i’m mad about now. Java 9, for example, adds some features that were not present in Java 8, and you can decide whether to develop for Java 9 and be able to use the new features or develop for Java 8 and be compatible with older runtimes. on the web, meanwhile, we have terms like “ES2023” that are purely decorative and carry basically no meaning. all the standards are living documents, new features go in one at a time whenever it’s convenient, and they get implemented one at a time at whatever pace happens, except when a browser can’t figure out how to put a good UI on a new feature so they decide that feature is actually evil¹. the standard way to manage this is to compile your new-feature-using code into older-feature-using code based on guessing which browsers people still use and checking massive tables of which browsers support which features as of which versions, but this sucks, and no amount of vehicular manslaughter² will let you do the same thing in CSS, where you just can’t use anything invented after like 2016 because some dipshit vendor still can’t be bothered to implement it. they actually kinda had “CSS3” (along with “HTML5” and “ES6” to some extent), but the CSS people actually noticed that named standards versions are fake and split CSS up into shit like CSS Media Queries Level 3 and CSS Color Level 4. unfortunately, that hasn’t actually solved any of this, because then Firefox 101 implements like 80% of CSS Values and Units Level 4 and there’s no way to reason about which 80% without just listing off each individual feature by name.

the thing i’m mad about today is that even when you somehow manage to beat the odds and make something that actually works, browsers will break it before long anyway because they don’t give a shit. an art game i made less than two years ago just completely fails to do anything now, despite having worked at the time. the game uses the localStorage API to do literally anything at all, and apparently using localStorage in a game that gets embedded in an iframe sets off a dozen warning sirens at Mozilla HQ and throws an exception that just breaks the game. this game has more CSS than JS (by lines, if not by characters), so it blew my mind when i went to check how i had built it and it just didn’t work at all. i have no idea if i have turned on an inadvisable Firefox setting to break everything all of the time, or if this issue exists the same way in Chrome, or if it's somehow itch.io’s fault for confusing CSP reasons and i’m too eager to assume it’s the browsers’ fault, but like. browsers already all did this on purpose with moving audio playback behind less than obvious thresholds of user interaction over the objections of a ton of people whose browser-based art would just detonate if they did that; they have not earned the benefit of the doubt here.

it’s not just my dubious art games, either; you can’t play the equally sophisticated but much more fun Room of 1000 Snakes anymore, because steve jobs killed the unity web player when he killed flash and java³.

browsers don’t give a shit about backwards compatibility⁴. operating systems do⁵. make actual executables that can be downloaded and then played. my next game will be distributed solely via retail CD⁶. good fucking luck.

  1. Mozilla on Web NFC. this is uncharitable but i do not think it is inaccurate
  2. core-js. this is irrelevant but based on the way the guy talks about it this is my own personal the onion john lennon
  3. obviously we don’t get to check in on the universe where safari on ios supports plugins to see how flash and java are doing in there, and it’s possible that goddamn adobe and motherfucking oracle would ruin everything even if apple didn’t move first. but i’m right
  4. unless they’re doing API design and it’s contains/includes time. goddamn mootools or prototypejs or whichever. if it’s an opportunity to make things worse, they will absolutely care about backwards compatibility. don’t get me started on css if/when
  5. except when they don’t, like if they’re mobile operating systems run by bored corporations, or if apple hasn’t made enough unforced errors yet this year, or if maintaining a 32-bit userland is getting annoying. so basically it’s just windows and the kinds of linux distribution that solve backwards compatibility by never moving forwards in the first place
  6. no it won’t
  7. ⁸ one of my other browser-based games is also broken but because it uses a primary server for multiplayer and that primary server was on the heroku free tier and i hardcoded the url because the previous url was getting caught up in ad blocking because apparently third-party websockets connections to the goofy donuts ass tlds like .fun are inherently suspicious. it could be fixed if i cared, but. there’s the rub
  8. this footnote does in fact not actually come from anywhere, i just wanted to also mention it because it’s tangentially related