Designing a Modern Desktop Automation App with Python Backend and Intuitive UX
I am planning to build a desktop application that leverages a Python backend to automate tasks—similar to what tools like Manus AI offer. The core functionality will be built in Python to take advantage of its powerful automation and scripting capabilities.
The frontend should deliver a modern, intuitive user experience that feels native and sleek. My challenge is to decide how to architect the application:
Architecture Decision:
Option 1: Build the Python backend as a local service or hosted API, then use a frontend (like ElectronJS) to connect to it via URL.
Option 2: Bundle the backend and frontend together in a single desktop app, using tools that support local execution and UI (e.g., ElectronJS + Python, or Python GUI libraries like Tkinter, PyQt, etc.).
Technology Stack Decision:
Frontend UX: I want it to be modern, responsive, and interactive—closer to a web-style UX.
ElectronJS vs. Python GUI libraries:
ElectronJS: More flexibility and modern UI using HTML/CSS/JS but might increase bundle size.
Tkinter/PyQt: Simpler to integrate directly with Python but can look outdated or clunky for modern UIs.
What I Need Help With:
Which architectural pattern is better: Hosted API vs. bundled local backend?
Which frontend approach to use: ElectronJS or a Python-native GUI library?
Any recommendations for combining Python automation power with a modern UI in a scalable and user-friendly way.
1 Reply
Electron is not a front-end. It's a wrapper around Chrome (that is the front-end) and Node.js (the back-end).
The core functionality will be built in Python to take advantage of its powerful automation and scripting capabilities.You could replace
Python with JavaScript or Lua or any number of other scripting languages and the sentence would be the same. They all have automation and "scripting" capabilities (whatever that even means).
The frontend should deliver a modern, intuitive user experience that feels native and sleek.Sounds like you want a webview. Or a PWA that the user installs…but maybe not if you want more backend functionality.
Option 1: Build the Python backend as a local service or hosted API, then use a frontend (like ElectronJS) to connect to it via URLYou mean "then use a frontend (like a web browser)…"
Option 2: Bundle the backend and frontend together in a single desktop app, using tools that support local execution and UI (e.g., ElectronJS + Python, or Python GUI libraries like Tkinter, PyQt, etc.).If you're talking about Electron, you should be using JS, not Python. Yes, there are Python bindings for Node.js…but that introduces a lot of overhead as the JS runtime isn't built for Python. If you want Electron then you should be using JS. If you really want Python I'd try to find a Python version of Electron…or if you know C/++ you could write your own :p
Frontend UX: I want it to be modern, responsive, and interactive—closer to a web-style UX.Then use a webview. That's literally what it does: gives you a web browser window to display your HTML/CSS/JS and connect to a locally running server.
ElectronJS: More flexibility and modern UI using HTML/CSS/JS but might increase bundle size.It's Chrome and Nodejs—so yeah, that's a massive file size
Which architectural pattern is better: Hosted API vs. bundled local backend?Depends on your usecase! If the user needs it to be local then you'll need to have a local bundle. But if it's assumed they'll have an internet connection why not just make a webapp?
Which frontend approach to use: ElectronJS or a Python-native GUI library?Electron isn't a front-end, so you're either gonna be using a Python GUI, a webview, make a webapp, use Electron as your backend that also contains Google Chrome (the frontend) to display the data, or somethine else entirely. You talk a lot about tech stack but don't actually say what you're trying to do. Why do you think that Python is best? is this some ML that has a bunch of existing Python libs you want to use? Or were you told it ha "powerful automation and scripting capabilities" and that sounds good to you? So much in tech depends on the actual use case and desired output and you jumped straight to step 11: bulid the damn thing. But you missed out on all the earlier steps detailing what you're trying to do. If we know the what we can better help with the how.