I get what you're saying, but I think that's just a tradeoff you'll have to make for now, at least until future WASM versions allows the DOM to be manipulated b

I get what you're saying, but I think that's just a tradeoff you'll have to make for now, at least until future WASM versions allows the DOM to be manipulated by backend languages :( Until then, it's a choice between keeping all the logic serverside and creating user-facing jank, or moving some of it client-side and worsening your own developer experience with the inevitable frontend decay and planned obsolescence. Yes, it sucks either way. The web was never meant to be this interactive, and it's just decades of hacks on top of hacks, and it's probably only going to get worse... =/ If you don't want a full frontend and want to keep as much serverside as possible, maybe a compromise is to create tiny modular frontend apps in vanilla, with each page being its own script? They can be in their own folder in your current repo and served as string literals from your backend. Hopefully that will minimize decay and dep hell a few years from now... at the cost of being a lot slower to implement upfront without any libs or React. Otherwise, yes, what you're saying would totally work... capture minimal inputs from the user (arrow keys and cli commands) and redraw and resend the updated picture on every input. You still don't need websockets for that (but you can use them if you really want to), but IMHO that's terrible UX. Even DOS image editors on a 386 were never that slow, since they didn't require a network call for every moved pixel... this is like BBS-game-over-a-9600-baud-modem level of slow, lol. For what it's worth, services like GeForce Now can stream entire 4K video games in near-real-time using hardware compression on the server side. But those codecs are a lot more efficient, sending inter-frame diffs instead of the whole JPEG/PNG over and over again with minor changes. Maybe you can do something like that if you want it to be smoother? But all of the above seems like so much work compared to a simple frontend that would probably take a couple hours to write. Even if you have to rewrite the whole thing 3 years from now, it's still less work than hacking that sort of interactivity into not just the server but over HTTP/websockets... I probably sound biased (and that's ok), but IMO this is a situation that might actually call for an interactive frontend (or at least an interactive page). Yeah, React and JS are often misused when simple things could be server rendered. But when it comes to real-time feedback & image editing, I don't see how you could avoid JS altogether. That's how Photopea, Figma, GDocs, GSlides, Adobe online stuff, MS Office, etc. all work. Like it or not, JS for now IS the language of the interactive web :( Doesn't have to be React, though. If you take the time to write it in vanilla without deps, it would probably last a few more years.