I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
Unless I really need high performance, probably as a locally hosted site, most likely using whatever the standard native web server is for the backend environment, or H2O if it's C/C++. Taking this approach eliminates a significant percentage of the work you would have to do to get the RPC interface working for whatever native environment you might choose to use, and as much as I dislike JS, it's really good for event-based programming, which is really how you should be doing your UI logic.
Barring that, most likely Qt, after taking the time to learn it.
The problem with the split code-base approach is that it makes it harder to keep track of feature-parity among your different UI's, especially since one person can't as easily implement feature XYZ for all platforms as they can with the other two approaches.
Dev manager at Jungle Disk. I love fixing things, whether I’m refactoring or digging into bugs, I just find it satisfying to make things better than they were before.
Totally agree with your logic on the local site approach. I had not considered how JS would add the benefit of being well suited for event-based UI logic! I had mostly been considering broader advantages that using a “web” stack could offer: ease of development, tooling, code/component re-use and consistency in branding/experience with related sites. The biggest resistance I have to this approach is that it just feels weird to control a local application through a browser. I suppose it really depends on the purpose of the app.
Your point about the split codebase approach is right-on, but for some reason I keep getting stuck with the perception that, while it adds the feature parity problem, the user experience of a “more native” GUI could be a benefit. Maybe I’m taking a “grass is greener” point of view.
short rant:
I think Electron is great, BUT it comes at the cost of eating up more resources... for an app like VS Code, I think the argument can be made that they’ve done a great job optimizing, and what it’s doing with those resources is usually useful (from what I can tell). But for a simple-ish GUI to present some controls/log displays/“visibility” into the “backend” app... it just feels greedy to use.
Anyway, I appreciate the reply and thoughtfulness. Many of us use desktop apps every day and I would love to see (and contribute to) more content around the topic.
Also, I had not seen H20 before... looks like it could be super useful for some of my current use-cases. Thanks for adding that. I’ll be digging into that more for sure!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Unless I really need high performance, probably as a locally hosted site, most likely using whatever the standard native web server is for the backend environment, or H2O if it's C/C++. Taking this approach eliminates a significant percentage of the work you would have to do to get the RPC interface working for whatever native environment you might choose to use, and as much as I dislike JS, it's really good for event-based programming, which is really how you should be doing your UI logic.
Barring that, most likely Qt, after taking the time to learn it.
The problem with the split code-base approach is that it makes it harder to keep track of feature-parity among your different UI's, especially since one person can't as easily implement feature XYZ for all platforms as they can with the other two approaches.
Totally agree with your logic on the local site approach. I had not considered how JS would add the benefit of being well suited for event-based UI logic! I had mostly been considering broader advantages that using a “web” stack could offer: ease of development, tooling, code/component re-use and consistency in branding/experience with related sites. The biggest resistance I have to this approach is that it just feels weird to control a local application through a browser. I suppose it really depends on the purpose of the app.
Your point about the split codebase approach is right-on, but for some reason I keep getting stuck with the perception that, while it adds the feature parity problem, the user experience of a “more native” GUI could be a benefit. Maybe I’m taking a “grass is greener” point of view.
short rant:
I think Electron is great, BUT it comes at the cost of eating up more resources... for an app like VS Code, I think the argument can be made that they’ve done a great job optimizing, and what it’s doing with those resources is usually useful (from what I can tell). But for a simple-ish GUI to present some controls/log displays/“visibility” into the “backend” app... it just feels greedy to use.
Anyway, I appreciate the reply and thoughtfulness. Many of us use desktop apps every day and I would love to see (and contribute to) more content around the topic.
Also, I had not seen H20 before... looks like it could be super useful for some of my current use-cases. Thanks for adding that. I’ll be digging into that more for sure!