3 ms·

Sorry, I'm not quite sure what "PIL" and "D+D" mean. (Edit: oh, a python img lib and drag and drop). The whole point of doing this clientside is that you're no

Sorry, I'm not quite sure what "PIL" and "D+D" mean. (Edit: oh, a python img lib and drag and drop). The whole point of doing this clientside is that you're not redrawing anything on the server or sending anything over the wire (while laying out). An image overlay operation is a trivial thing to do in clientside JS, in Canvas, and then once you have it positioned right you just send back the params in a fetch to the server. It makes no sense to redraw the thing every time on the server; that's going to be super janky compared to an interactive canvas. I think this is a perfect case for separating the server and clientside logic. (Edit: Sorry, I edited my previous reply after you already replied. Basically the client would just let the user set the params, and then you'd send it to the backend similar to how you would to imgix: https://sandbox.imgix.com/view?hasAgreedToUploadTerms=1&url=https%3A%2F%2Fsandbox-uploads.imgix.net%2Fu%2F1733172845-29226cfcfafabef27fdb8eb7c5f91e1f%3Fblend64%3DaHR0cHM6Ly9zYW5kYm94LXVwbG9hZHMuaW1naXgubmV0L3UvMTczMzE3MjkzNy1iOTBiNmM4Yzg4OTcxOGIxNjBlMTc4NGZmZDc4M2UzYz93PTYwMA%26blend-x%3D1100%26blend-y%3D100%26blend-w%3D200%26blend-alpha%3D75 https://sandbox.imgix.com/view?hasAgreedToUploadTerms=1&url=.... It wouldn't matter how you rendered the image in the backend, that's up to you, but it frees the user from having to wait for a network roundtrip after every minor adjustment.) And yes, you can easily make this modular enough, especially with a lib, to easily create similar use cases in the future.

PaulHoule 2y ago
Yeah, the client side for just the QR is almost trivial, I don't even think you need the canvas. I can code it up in React pretty quickly, probably not mess with 3rd party components, just write my own HTML and CSS. What mostly concerns me is that one "little" feature in an existing python project (git repository, etc) involves creating another project, opening up another IDE window, etc. Now maybe that React project becomes a sidecar and I build out several mini-applications in it to amortize the investment in maintaining the project, maybe it even grows into the front end for the whole thing. On the other hand I relish the freedom of starting a new mini-app without the complexity and risk that some dependency I add now is the one that I'll be scratching my head over 3 years from now. On top of that I need one button start for the whole system when I guess that's what's bugging me, that a "mini-app" involves having more than one project to deal with, it just seems from a rapid prototyping perspective to be the wrong way. (e.g. I want 10x tools!)
- solardev 2y ago
  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.

PaulHoule 2y ago

Yeah, the client side for just the QR is almost trivial, I don't even think you need the canvas. I can code it up in React pretty quickly, probably not mess with 3rd party components, just write my own HTML and CSS. What mostly concerns me is that one "little" feature in an existing python project (git repository, etc) involves creating another project, opening up another IDE window, etc. Now maybe that React project becomes a sidecar and I build out several mini-applications in it to amortize the investment in maintaining the project, maybe it even grows into the front end for the whole thing. On the other hand I relish the freedom of starting a new mini-app without the complexity and risk that some dependency I add now is the one that I'll be scratching my head over 3 years from now. On top of that I need one button start for the whole system when I guess that's what's bugging me, that a "mini-app" involves having more than one project to deal with, it just seems from a rapid prototyping perspective to be the wrong way. (e.g. I want 10x tools!)

solardev 2y ago
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.