Ask HN: Framework for Quick Python or Java and Web UIs?

solardev · 2024-12-02T20:37:42 1733171862

I hope I'm understanding this right: You're trying to build a web UI that can let you overlay and position a QR code on top of another image?

If so, I think rather than trying to build your own CLI to do this and refresh the image every time, you can do it entirely clientside with something like https://konvajs.org/docs/react/Intro.html or https://fabricjs.com/, storing the QR overlay position and alpha in state. Then once it looks good on the client, you can send that state as an API request to the server for rendering to the final image. (You can probably also just render the finished output on the client directly, but since you already have that part of the rendering in the server, might as well re-use it).

i.e. let the user handle the image positioning clientside as state, then send the final params to the server for rendering, e.g. /overlay?x=500&y=300&w=30&h=30&opacity=50.

Websockets is overkill and will cause unnecessary complexity. You don't need to sync every intermediate state., just whenever you click "save". Autosave every minute if you must. But why, for something so simple? Positioning the QR code would probably only take a few seconds.

PS And if this is for your own use (as opposed to building a service for other users), I should point out you can also easily do this with existing free web-based image editors like photopea.com

And as a service, this is pretty similar to what Imgix does already, just without the drag-and-drop overlay GUI. Example here with another QR code in the upper right: https://sandbox.imgix.com/view?hasAgreedToUploadTerms=1&url=...

PaulHoule · 2024-12-02T20:57:06 1733173026

It is likely to turn out like you say. The back end is PIL, I don't know if it's fast enough that I'd want to redraw the image while you drag and drop the QR code but I'm sure it can redraw the thing fast enough to keep up with the arrow keys and if I did want D+D I could have an outlined box stand in for the QR code.

I am not so much thinking about this one but the long game that I might want to make 20 things like this in the next year. I might want to pound out 3 in the next month and then I won't think about it for 6 months and then pound out another 7 over the weekend. I don't want to spend another 2 weeks figuring out how to do it again.

At work I am used to the "we use so many widget sets that there are seven ways that something might be styled that you need to know about it so management thinks it is pixel perfect" (although it isn't) and that's just one of the traps you can get into to replace fast development with slow development.

I'm looking for some plan to eliminate everything slow in developing a bunch of little random apps similar in scope to that QR app.

(A similar application I have in mind is a "builder" that can run git and mvn and npm to automatically sync up and build a collection of Java and Javascript projects that comprise a web application. It works great but the output is just as hard to read as the output of "mvn install" and I'd like to be able to simultaneously see THE PROJECT BUILT SUCCESSFULLY despite THESE HARMLESS MESSAGES THAT LOOK LIKE THE SYSTEM LOG FOR A NUCLEAR MELTDOWN. So some kind of UI that lets you from detailed log to various levels of synopsis would be great...)

solardev · 2024-12-02T20:59:56 1733173196

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=.... 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 · 2024-12-02T23:36:15 1733182575

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 · 2024-12-03T00:53:56 1733187236

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.

zahlman · 2024-12-03T20:18:56 1733257136

>A similar application I have in mind is a "builder" that can run git and mvn and npm to automatically sync up and build a collection of Java and Javascript projects that comprise a web application. It works great but the output is just as hard to read as the output of "mvn install" and I'd like to be able to simultaneously see THE PROJECT BUILT SUCCESSFULLY despite THESE HARMLESS MESSAGES THAT LOOK LIKE THE SYSTEM LOG FOR A NUCLEAR MELTDOWN. So some kind of UI that lets you from detailed log to various levels of synopsis would be great...

If you happen to be working in Python for this and are only concerned with your own output, the standard library `logging` module is designed for this kind of tagging and filtering of log messages by importance. The API is rather old fashioned (it uses %-style formatting and to my understanding the design is based on Log4J), but it does the trick and many people swear by it. However, AFAIK it isn't built for picking through the log messages after the fact - it just helps you implement a command-line option for verbosity level, really.

genezeta · 2024-12-04T20:41:58 1733344918

I'm not sure I understand what you want, but... If want you want is a generic way to interface with a bunch of small tools that take some parameters and output some file, read on. If not, sorry.

One thing you might do is abstract over something like dat.GUI [0]

(Note: I like dat.GUI but understand it hasn't seen development lately and you might be concerned about that. In that case, substitute dat.GUI for Tweakpane [1] and the idea is still the same)

dat.GUI creates a sort of control panel with various types of inputs based on whatever you want to manipulate. Something like this [2].

The code to produce it can be abstracted quite nicely. So you could simply create a small generic script to create a panel from just a JS object with the properties you want to manipulate. You'd link this to a simple submit against your server-side binary.

Now, the only thing that remains is presenting the output. I'm guessing that today you're generating an image but in some other case your output may be a text file or something else. For a lot of things you can just relay on the browser if you output to an <iframe> and let the browser sort it. In most cases it will display it and when not, it could offer to download & save with the correct headers.

[0] https://github.com/dataarts/dat.gui

[1] https://tweakpane.github.io/docs/

[2] https://imgur.com/a/em4qKl7

PaulHoule · 2024-12-02T19:42:50 1733168570

(An example card I print is https://bsky.app/profile/up-8.bsky.social/post/3lbqfh7pesc2x)