With this approach, I have the best of both worlds for my small shop where development time is constrained. The really good part is that I can reuse for the desktop application work done for the website both the front-end and the backend which is written in Python for all the scientific code.
All this makes Qt a first citizen in the Rich user interface world where the players have names like Vue, React and Angular today.
Btw, don't forget we had desktop toolkits with rich user interfaces already in the 2000s. In that time, Java was the big player. Swing was already superseded by Eclipse's SWT and HTML panels were already ubiquitous.
One of the things that Mac file dialogs do is implicitly expand the sandbox for the process that opens the file dialog. Is the other side of the bridge still able to access the selected path?
Qt will just open a native macOS dialog that will link files into the sandbox. From there you can pass the path returned by the dialog to sandboxing-oblivious C++ code.
As a side note: Flatpaks in Linux use a similar mechanism for sandboxed applications (in Flatpak these are called ‘portals’).
But in any case fbs doesn't mention some useful bits. Does freezing work reliably with all packages (is it different to the canonical packages for freezing Python binaries)? In my experience some libraries just wouldn't freeze - matplotlib was a pain. How big are the output binaries? The Qt libraries are large enough without chucking in Python as well (even a minimal install is quite big).
I've been a (proud) Pythonist for years now, and I've always been a bit chagrined by the quality of the "marketing" of Python projects. It doesn't at all reflect the quality of the community and the projects.
Also, having developed apps in both frameworks I would say that it's easier to get started with Electron if you come from a HTML/CSS/JS background, but apps written in QT look more native and like "real" desktop apps to me. Also, QT as well as PyQT are incredibly well designed libraries and it's a lot of fun programming with them (I'm not saying that it's not as much fun programming in JS).
PyQT's page is clearly written by a developer, with an emphasis on explaining the internals of the library. The author clearly saw no need to make it attractive. There is no long-term vision beyond the library itself.
While PyQT is navel-gazing, Electron's page is all about grabbing mindshare and establishing clout. It seeks to conquer the world and your desktop, and you're going to like it.
I think stuff like this is pretty tribal, which is OK, but we should confuse it with decisions made on technical or experience merits.
We're still savanna primates, and silly little things like technical merits aren't going to get in the way of sexy shiny. Projects that understand this fact will attract developers and flourish, and those that don't will languish in forgotten obscurity.
- any imaging library (libpng, libjpeg)
- any compression library (zlib, xz, bzip2)
I do agree that PyQt has a respectable documentation page. It is, however, a terrible page for attracting new developers and selling decision makers on the idea of using it.
This is a better way of identifying my frustration: open source projects don't just need good docs, they need to attract and inspire... especially visual frameworks like a GUI.
Would that be attracting people that are worth attracting though? Just like in business, not all customers are worth having.
Why would you not want a toolkit that makes rich application experiences across multiple platforms easy and standard?
I get that performance is a problem with the tooling in its current form (arguably...) but that's not a reason to ignore the problem electron is solving: creating complex UIs using things like WinForms, QT, GTK, Cocoa, etc SUCKS.
It requires learning vendor specific toolchains, different builds for different platforms, and an incredible amount of wasted time that could be spent developing your business logic instead.
I get that Electron brings benefits: it's dirt-easy to build something that'll run on Windows, MacOS, and Linux, without having to know a bunch of platform-specific details, and if you already have a webapp, you can leverage a lot of that work, but in the end it just feels to me like people cutting corners. You get a sub-standard app, but you don't have to pay developers to build for each platform plus the web. Which I think is a perfectly reasonable business trade off to make; I'm just not happy with the result as a user.
Animations are an important tool for showing transitions between states.
Pasquale D'Silva has a bunch of good blog posts explaining how they can help an interface:
Apart from being resource hogs Electron apps are usually delightful. And usability (for non programmers!) is what for a large part decides the value of your app. You want users to use your program, right? What they see is the UI. Making it easy to develop good UIs is important for a GUI tool (obviously!).
It annoys me when people say something sucks without taking the time to understand it.
That is only true in the sense that your Python 2.x experience didn't translate into your Python 3.x experience. That is, I think the overlap is similar on a language level. The difference lies in the libs/frameworks.
Even jQuery is still helpful if you think of how it's accessing the DOM rather than just a set of magic functions to make things happen.
For the purpose of this discussion — carrying learned knowledge forward — it was minor.
Obsolete does not mean you cannot use your knowledge anymore. It means that community are shifting interested into new thing, maybe for better or for worse.
In this case, I do not think stick with JQuery or old framework for 5 years is productive for programming. If that happen to any community I would say that is a downside, not an upside.
Except for that fact that community and newly graduated junior developer are ahead of me in something. I can live with that
Because way more often than not the "rich" stuff are all fluff with no meat, end up taking wasting system resources and work badly with the rest of the system.
Accessibility is another big one.
† The flip side is if you use the same app on different operating systems often. There are some apps that fall into that category for me personally, but I think your average user probably only uses two operating systems regularly: one on their mobile device(s) and another on their "real" computer(s).
Ignoring the snark, "Modern" is better should not be the default, either. Performance is a valid reason to ignore Electron.
The Slack desktop app is the prime example for how bad Electron apps are. Its literally notorious for it.
Seriously, open the desktop app, then open the web app. They're identical. Precisely because they chose to use a toolkit that let them easily handle cross platform issues with UI in a sane and repeatable manner.
Yes. So why would I run essentially a second web browser instance to run the same code in a different place?
Beyond that, I had with weird screen refresh issues with the desktop app, where scrolling or even just typing in the text box would cause parts of the main HTML view to just disappear to the point where it'd be unusable. Often images wouldn't load, or would load, but then have the same disappearing issue. Restarting or refreshing the UI wouldn't help. I'd have to restart the app every couple days anyway due to ballooning memory usage. Hell, even the font rendering was weird and didn't match what I'd see by opening a regular Chrome window. I reported the issues to Slack, but never heard back, and after waiting through several releases for a fix, over a period of months, I gave up.
> ... let them use a toolkit that let them easily handle cross platform issues with UI in a sane and repeatable manner.
That's not what I want. I want apps that fit in with my desktop, not apps that look the same across OSes, ignoring platform idioms and style/placement standards.
I installed the Netflix chrome app on my Windows PC. It's basically the Netflix webpage on a separate application window that doesn't have tabs or a search bar.
A single Gitter tab uses 20MB RAM. I'm sure it would use at least 250MB for the same functionality if I used the electron version.
This is such an obvious problem. Why haven't they fixed it already by trimming down the web browser?
Now that Desktop apps compete with web apps those toolkit’s are falling short. They are falling short in ease of development, cross compatibility, lack of trained developers (relative to web), and lack of good looking UIs and UI patterns.
I have developed some larger Qt applications and in each case there are at most a couple dozen of lines with platform-specific code. Qt abstracts away most of the platform differences.
For me ‘good looking UIs and UI patterns’ means: well integrated in the platform and accessible. Electron apps fail miserably in both departments.
Delphi/Qt Designer look way worse than any HTML/CSS/JS GUI builder, too - along with having interfaces equivalent to what GIMP's is to Photoshop.
Plus, with HTML/CSS, you can work manually on your project, without any special tool besides your browser,
Why would I develop in such an arcane manner if I already have great development tools for more than two decades?
Again, I recommend anyone who only has HTML/CSS experience to look beyond their bubble. We had RAD tools with Delphi 1.0 in 1995, where you could build a user interface using drag and drop and associate code with event by simply double clicking a widget in the interface builder. I built GUI applications in Delphi as a 13-year old because it was trivial, even without an internet connection, StackOverflow, etc.
Not only did it take something like two orders of magnitude more man-hours to develop, but it takes users twice as long to get anything done, too.
I have a fair bit, albeit less than the average user of said programs, of experience with Qt Designer and, admittedly to a lesser extent, Delphi. They're infinitely more complicated than, say, Adobe Muse. Muse has plenty of widgets, too; even if it's not 1:1 on pure quantity. BlueGriffon is quite nice, too.
Modern web browsers* have more or less functional IDEs within their devtools.
*Except Firefox, of which has devtools half a mile behind most other browsers, at least in my opinion.
Of course, I'm speaking from the point of view of someone who's a much worse programmer than designer.
I can understand the cross-platform angle, but not ease of development (unless you are limiting yourself to the very, well, limiting subset of interactions and controls that are easy to do in HTML). Nor, for that matter, the quality of the end-product.
Don't get me wrong, I love native applications—but saying that they're easier to develop than something in HTML/CSS is, generally speaking, not true.
Granted, I'm far worse of a programmer than a designer, so I might be missing out on what's good about Delphi because of it.
For a designer, yes, I can see your point -- it's easy to use markup to make something that looks good (or at least this month's fashion for web pages good) quickly. It's when you want to add any kind of sophisticated behavior and non-standard UI (i.e. exactly why you would want to have a desktop app instead of just using a browser in the first place) where even old Delphi would be far superior. And the result would actually look like a native app, too.
Discord's a highly admirable, semi-complicated web application, that extremely benefits by not looking native, in my opinion. The interface of it is miles ahead of any native desktop VOIP/Text client I know of, and I don't think it'd have been done without Electron.
Of course, I'll agree that generally nothing more complicated than that should be anything but native.
Discord seems to be a nice app (never used it, though) but it has the exact same generic look of, say, Microsoft Teams (another Electron app). Nice, but I would not say that it has any better interface than even classic Skype. Much better than the new monstrosity that is Skype 8, but then Skype 87 also drops proper native interface.
Of course you can get native application to look like nothing else quite easily, but by default they at least agree with the host OS conventions, which is a good thing IMHO.
Also, the Discord interface looks entirely different than Microsoft Teams.
Microsoft Teams: https://www.windowscentral.com/sites/wpcentral.com/files/sty...
Discord also allows advanced users to theme it with ease, which is another good thing about it.
Now, just double-checked a few apps (Firefox, mIRC, Visual Studio) between Windows 7 and latest insider buld of Windows 10. They look exactly the same. Office? Looks the same, too. Can you reference some app that does look different between them?
Still not seeing any sinificanmt difference between Teams and Discord either. From left to right:
- Narrow column with icons
- Wider column with list of somethings
- Even wider colunm with another list
- Less wide column with more icons and text.
Seriously, if you swap icons between the two, would you be even able to tell the difference? Sure, some content in some of those colunms is different -- these are different apps, after all, but saying that one interface looks entrirely different seems to me to be an exaggeration. From a designers' POV maybe, colors re different, and icons are in slightly different locations. From a users view, they are basically identical. For that matter, Slack seems to look exactly the same, too. At least based on what they show on their site. Except, of course, that being an Electron app and not following even what little Windows has for UI standards, they have to start the description form saying that to find settings you need to go a Workspace menu. Which, of course, doesn't look like a menu to begin with.
Honestly, I do not see how this is an improvement. Cheaper for the manufacturer, sure.
Can you please provide an example of such tool?
Doing UI development since Windows 3.x days, and I am yet to find such a tool for HTML/CSS/JS development.
Oh and in the process it would be nice to know about a least one comparable component library for such tool.
from PyQt5.QtWidgets import QApplication, QWidget
if __name__ == '__main__':
app = QApplication(sys.argv)
w = QWidget()
With PyQt, he needs to download and install PyQt. When ready to ship, he needs to figure out how to build it into an app that can be delivered to clients.
With web technologies, he knows how to get deliver code in ways it can be loaded in a web browser, and how he can deliver code to end users.
Though to use that web code with Electron, he needs to download and install electron and figure out how to build it into an app that can be delivered to clients.
The web has a lot of great advantages for sure, but native applications have advantages and can do things that are unwieldy and inefficient via the web.
i'm just trying to act as if people do when i suggest them learn new programming languages :) or any things which they aren't used to for that matter.
Even when you screw up the HTML it will still load, which won't happen if you get your underscores wrong in your example.
Edit: removed erroneous formatting
And this is why we have the wasteland of browser incompatibility that we're (still!) in. If something is wrong, it shoudn't work. Why are our standards so low that mistyping "head" as "herd" is considered something that heuristics should fix, rather than causing an error?
I mean, really, though, any decent IDE should flag that error for you in-line, anyway.
> Edit: removed erroneous formatting
This is beautiful!
You don't need to override ::paint because the authors of the class already included support for rich text.
To be fair, these are different problems from what the grandparent was discussing.
Licensing is a problem a business really shouldn't have: Qt is LGPL and PyQt licenses are cheap even for ramen-eating startups.
Lack of mobile support is a Python problem, I agree there. I can assure you everyone in the Python world is sorely aware of it. Unfortunately, nothing will change until someone does what Google did for Java with Android. But it's a problem that electron apps have too, because "html apps" are still pretty bad on mobile (and terrible on desktop).
Similarly, packaging a PyQt app is not much more of a problem than packaging any app that is not among the "blessed" mobile languages (Java/Kotlin and Objective-C/Swift).
Furthermore, most people do not care about this, and the value of marketing with a sleek design vastly outweighs any benefit of conforming to system components UI.
If literally every Electron app fixed memory issues and correctly placed OK/Cancel dialog buttons, I'd be fine with it for the rest of my life - and I write native code for a living. ;P
No, they aren't.
"MacOS UI consistency is a mess."
Not really. Most small developer programs I use follow these. It makes it really easy to know what to do to accomplish something.
"Furthermore, most people do not care about this"
[Citation Needed]. I think most people would prefer to not have to learn a new UI from scratch everytime they want to use a different app.
"and the value of marketing with a sleek design vastly outweighs any benefit of conforming to system components UI."
What is this "value"? How does that help me accomplish my tasks?
"If literally every Electron app fixed memory issues and correctly placed OK/Cancel dialog buttons, I'd be fine with it for the rest of my life"
You mean, if every Electron app stopped being Electron?
I'm not going to bother listing out the litany of odd UI issues present in macOS, because you can Google it and find this within a few seconds. It comes up every. single. macOS. release.
Nobody cares about learning a new UI because most of the tools they use are webapps nowadays anyway, which require this.
The value isn't yours, if that wasn't apparent. For the vast majority of people who use apps with easier to implement design/UI/UX features, it's easier for them to get things done. These apps wouldn't have caught on without that.
And lastly, you've opted to be incredibly pedantic in an attempt to be snarky (I'm guessing, otherwise I've no clue why you'd do this). Electron is more than memory issues and this isn't even a debate.
I don't want a good looking UI, I want to have a fast and _usable_ UI!
This fad in the UI and JS world that absolutely everything has to be "beautiful" needs to go away.
Good looking UI is a major part of user experience.
Your eye will probably be more attracted by the good design of the electron website.
I'm not saying an app should be only good looking, but it's clearly a major part.
It drives engineers batty, because it's often irrational.
Just because something is irrational doesn't mean it doesn't have a huge impact on something like adoption.
If we didn't care how things looked, we might all be wearing google glass.
Edit: the snark... removed.
There are ways around that. For example, DOtherSide is a C library to bind to QML, and binary releases for Windows and Linux are made available on the GitHub page, so in principal you could try out QML without needing to directly use a C/C++ compiler:
There are also a few other languages with QML bindings, such as Rust (the Rust binding is based on DOtherSide):
You'll need to dip into clang or whatnot for really hardcore perf either way
I still develop 100% in QWidgets, which probably makes me a dinosaur but at least I know what I'm getting out of it.
Meanwhile, there have never been anything but Single Page Applications in the native world.
And sure, Qt is now more than 20 years old, it's from a time strongly rooted in "widget" based UI systems that have somewhat fallen out of favor. That is what QML is for, which similarly to WPF that started this trend, allows for GPU accelerated vector composition of anything you could ever want, with sane provided defaults so not every project is reinventing grids.
What Electron apps are good examples of ones that look very good? Slack and VS Code both look fairly bland, and Spotify is a bit of an over-energetic mess, at the moment.
It's ironic that people bang the drum about REST and decoupling... and then at the first hint of actual serious frontend/backend decoupling, everyone runs for the hills.
The official pronunciation of Qt is “cute”. It is not pronounced as “cue tea”.
Last week someone else on hn did the same; and I kept quite.
Unfortunately this time I could not stop the graybeard in me.
Except this sucks if, you know, you want to make some money on your app... Kicking the tires for a potentially commercial app is a FULL stop for me right there.
JS and so many newer language(s)/bindings that compile to JS make the option to good to ignore.
I love Python, but it has stagnated hard in the last few years. The 2 to 3 transition really hurt the Python ecosystem in ways I am just starting to recognize. There are only "ok" to "terrible" options for GUI creation in the python ecosystem. Furthermore, packaging for different platforms is still a problem in 2018.
Why is that a problem? You get a commercial license for PyQt and are good to go(?)
> I love Python, but it has stagnated hard in the last few years. The 2 to 3 transition really hurt the Python ecosystem [...]
I disagree. I think the ecosystem is more vibrant than ever.
> Furthermore, packaging for different platforms is still a problem in 2018.
That is exactly what this project is trying to help with.
Beside the ML/AI sub-community, I am having a hard time finding GUI innovation in the Python ecosystem. Perhaps, you could show me an option that doesn't suck? I've tried Kivy, PyQt, PySide, Eel, gooey, etc... I am not a JS dev and had an electron/react app up and running that I easily ported to my Android phone in under an hour.
On one hand you have the complex licensing thing (PyQt) where you are limited to desktop of Mac, Win, Linux. On the other you have a skill (JS dev) that is good for literally any screen, on any platform with almost zero complications for commercial apps. It is a no brainer.
If it isn't obvious, I have begun the transition to embrace JS for what it is... I am learning it and it hasn't been too bad. Python will be relegated to ML/AI and glue...
Regarding licensing, you can simply buy the commercial license only when you go public / begin making money. It's not that difficult I think.
But as I said, you are correct in that Electron is easier to use for many people. I'm also the last person to say you should always use PyQt. Just today I recommended someone to use Electron over PyQt. It really depends on the project.
As much as I love Python, I don't want its GUI ecosystem to become the next Delphi.
I don't know of any other cross-platform native GUI library that even matches Qt in quality or features. I don't think WxWidgets is a contender, unless someone here proves me wrong.
EDIT: I see, all it needs is the PyQT license for $500 and the Qt is covered under LGPL, for any commercial release.
It even happened in Python, too. I personally attribute a whole generation of failure for the Linux Desktop to the "Python for Desktop" frenzy of the Gnome 2/KDE 4 times. I remember I had a dual-boot Pentium 4 box, and while Windows apps were always slick and responsive, Linux always felt sluggish and unresponsive, until I found C/C++ alternatives to all the apps I used.
(If someone has a high-quality way to use asyncio or Twisted with the Qt event loop, I'd probably bump Python a bit higher.)
I'm primarly a Python developer too, and on that respect I like Python's approach to C extensions. It's easy enough to rewrite your application logic into C when performance is important, and in general I think experienced Python programmers will do just that. The problem with Electron is both the lack of support for doing this, and the lack of experienced developers willing to do it.
I am reasonably excited about WebAssembly as a solution for this for web apps. (Although web apps also have a natural front-end/back-end separation, and people consider JS as just one of many potential options for a back-end language, which helps a lot here.) It does surprise me that there isn't good support for doing this with actual native code on Electron.
Priority #1: Runtime, your code will (hopefully) be run a lot more than it does anything else.
Priority #2: Debug, your code will be debugged more than it is read
Priority #3: Reading, you will probably read your code a significant amount more than you write code.
Priority #4: Writing. A software should spend the least amount of time on a CPU being written.
I'm not saying that you should only focus on making fast/slick runtimes that are easily debuggable above literally everything else; but you should absolutely have slanted priorities towards this goal.
And in that respect, why wouldn't you learn the right tool for the job?
Given that, what makes sense to optimize for? The slowest, most error-prone processor in the mix is, the wetware in your head.
So, almost all of the time, put #1 at the bottom of the list. Put #3 next, because once it works, the slowest process is relearning why it works, necessary to debug or extend it.
#2 and #4 are simultaneous.
So, for most coding most of the time on most projects, write dead-obvious code using normal design patterns and simplest abstractions. Because time is money, and your wetware time is millions of times more expensive than cpu time.
Just because your code isn't in a tight loop doesn't mean you shouldn't think about performance. If you waste CPU resources then the rest of the system that is in a tight loop will have more switches to do. If you waste memory then the code in the tight loop will have memory evicted from it's precious memory cache. Just because your process is not CPU bound does not mean you aren't having an impact on overall system performance.
If you're running your own servers do whatever you want, but if you're making consumer software then don't pretend you're software is the only thing running.
We should write code that's idiomatic and clear if we want easy debugging.
Your other point about "wetware is more expensive" is a statement about how much you're scaling. Another 100ms on facebooks home page load is an aggregate of at least a dozen hours a day taken from users, so if it costs a developer a dozen hours to remove that performance hit then it's absolutely worth it.
Performance should be the default, not the edge case.
My argument is about runtime, not about developer comfort - if you have race conditions between threads, or deadlocks, or blocking I/O on the UI thread, that's a runtime problem, not a developer comfort problem.
(I do also disagree with your priorities, in part because if you get #4 right you avoid a lot of #2, but I wanted to be clear about what my argument is.)
I've experimented around with Quamash a bit with Asyncio and it seems to work nicely! Looking at CI it seems to have some rough edges (at least on Windows) though.
It looks like this is done by subclassing QAbstractEventDispatcher and filling out virtual functions registerSocketNotifier(), registerTimer(), etc. I suppose you could do this for asyncio/Twisted, but I'd prefer to import something where someone has done this for me and is accepting bug reports from the community, because this is the sort of thing that's made of edge cases that are hard to notice in testing.
If anything, python bindings allowed a generation of new distros like Mint to emerge, as “sysadmin types” could develop simple GUIs much faster and cheaper than if they had been forced to learn C/C++. The failure of established companies to capitalise on this is entirely their fault; for example Maemo/Meego refused to let Python apps on the Nokia store, and never even tried to push PyQt as their mobile story (which would have predated the Swift/Kotlin moves by almost a decade, giving them a fighting chance to get some developer mindshare).
Web developers hate the idea of using C++ to write desktop apps because the language is brittle, outdated, and overly complex.
Its fairly fast, easy to link out to C if you need to. There are versions of the VM that are blisteringly fast, like Luajit, and others that are tiny like eLua.
Its syntax is incredibly easy, as is most of the language to understand.
It can be event and callback oriented.
And though dynamic, most gotchas about JS don't apply, as it isn't overly eager to typecast everything.
The best situation I can think right now, and the one I would adopt myself, is indeed PyQt. Mostly because Python makes it easy to drop the compute-heavy application code into C extensions, not because of the GUI toolkit itself.
I want to like it. The problem is that the one character symbolic syntax notation remain nonsensical and seem arbitrary to me.
> (eg &'a T)
Basically, unless you've been working in C/C++, you've never really used funky symbols to denote "modifiers".
Say what you will, but
> public static void main
is easier to Google and even to parse for most people.
Keep in mind that the vaaaaaast majority of devs today have never worked professionally in C/C++. I'd imagine some of them have never even touched it, even as a hobby.
I guess with something like React there's even more overlap in UI and application flow, but you still have to learn interacting with the filesystem, dialogs, preferences, menus, menu icons and window settings, state between launches, and any other fiddly things that your app brushes up against. There's also building and packaging, bundling for the app store (if you're using one), and updating the app.
If you write your program in C/C++ we're good, though now you're using a clunkly language.
If you're using Java you have some decent GUI options, but it's a bit ugly. Still alright.
In almost any other languages you're in deep trouble. The prototypical example: building out interfaces in Python.
You have some GUI bindings to the cross platform libs, but many have really old and outdated docs. Or licensing issues. Or installation issues. It's super hard to ship a GUI for your Python app compared to anything else with the language
Ultimately almost all other languages are used for server software. Packaging and GUIs are super low on the list of priorities.
As a side note: I see the Arch Linux package is 16M, unlike Ubuntu's 39M. Perhaps the app needs a relatively recent Qt or PyQt release that is available from Arch's repos but not on the oldest supported Ubuntu and thus needs to be shipped.
The Arch package is smaller because it declares PyQt as a dependency, rather than shipping it itself. The reason for this is that it was difficult otherwise to make the shipped version of PyQt libraries and dependencies compatible with the ones already on the system.
For comparison of installed size:
- Code.exe is 77MB (version 1.20.0)
- directory "C:\Program Files\Microsoft VS Code" is 225 MB
I haven't used it personally but they appear to have a few notable clients.
Seems they also have popular language bindings (Go, Python, Rust etc...).
It's not opensource though so that could be a deal-breaker for some but licensing/pricing isn't prohibitive.
Has anybody here on HN used this before? Care to share your experience with it?
That's not really what being licensed under the GPL means.
PC-BSD thought that they had to license their own stuff under the GPL because they were using Qt, but all you need is GPL compatibility. After that realisation, PC-BSD relicensed their code to 3-clause BSD.
Here are my bindings to python for the nuklear framework. https://github.com/billsix/pyNuklear
Lisp is interesting in that unevaluated code is a data structure of the language. In immediate mode GUIs, the sequence of function calls is your data structure.
Electron needs to be competed with in two areas, though: Developer experience and end user experience. Solving just one of them means you don't really compete with Electron.
For a good user experience I'd have recommended a Qt Quick [QML] based interface.
Developer experience requires some good tooling, which unfortunately Qt creator doesn't really provide for me.
Electron is backed up by Github , we are talking about a billion dollar unicorn , and a lot of commits made are coming from outside github ( microsoft engineers for instance)
For this ? I doubt it would go beyond 1 year of surviving .
Also I've been using VS Code for years ,it's incredibly well optimized and doesn't have a problem in terms of memory or CPU .I personally found electron very reliable , it has surprised me on this point.
That is super welcoming for people that want to run more than CLI in 2018! /s
I don't have an answer to your questions, but it's at least somewhere to start looking.
E: Most of the links are broken. This one is a bit better, but it's Windows-specific: https://wiki.tcl.tk/8646
HTML Forms suck until you have to write form classes/UI in native languages, and then realize how annoying it is when you need to customize something or want a unique input that might make said form easier to deal with.
e.g, NSTextField in Cocoa _still uses cells_ behind the scenes.
But well, Qt presentation is not nearly as sexy as HTML/CSS, that's for sure.
I recently wanted to dabble with a tiny Android app, after hours wasted trying to get Kivy to work I bought a book on Kotlin and downloaded Android Studio, lots to learn but with the advantage that it works.
Personally, I tend to use QtDesigner to layout apps and Qt for implementation (this applies for PyQt/PySide or C++). It tends to reduce the code necessary to get something up and going and helps keep things more MVC.
Tkinter is the standard UI library for Python, but I haven't used Tk in close to 15 years. Tk worked well enough for smaller Perl or Tcl apps, but when I first moved to Python professionally (around 2005) I bounced between WxWidgets, PyGTK, and PyQt. Qt was always ahead of the rest, but had licensing concerns at the time. I feel like there's a bit of roughness conceptually between Qt and Python that are just fundamental, but I think that's more on Python and asynchronous needs of UIs.
I was trying to figure out when this decision was made. I see references of tkinter dating back to 1999 (tk is from 1991), but it looks like it was officially included along with Python starting in 2008. If true, I would think it would be obvious it wouldn't be the best general choice going forward by that time. But I can see the reasoning behind choosing it due to licensing, size, volatility of api.
In all of the comparisons I found on different frameworks the criticisms of Tk all seem to be about the looks (in that it didn't take on native styles), but that seems to have been resolved. It doesn't affect my in house use case either. The other thing mentioned is that Qt has more widgets. I don;t need those right now. Therefore it would seem that for simple in house software Tkinter was a pretty fair choice.
> I feel like there's a bit of roughness conceptually between Qt and Python that are just fundamental, but I think that's more on Python and asynchronous needs of UIs.
I can't get over this. I am not a good enough scientist to explain what the problem is but there is something that just doesn't feel right with Python GUI programming.
Most of the guis Ive needed just use basic widgets. I've poked at the browser and opengl widget, but never really used them. I have had to add custom behaviors to widgets to match other apps and it seemed pretty well suited. Funny enough, the Qt organization has stopped development on Widgets over 5 years ago (which is all I've ever really used). They consider Widgets feature complete and are focusing on QML.
> there is something that just doesn't feel right with Python GUI programming.
It's unclear what the other advantages over PyInstaller are. Does @cached_property provide a performance benefit?
AFAIK the main performance issues come from chromium's vast size - browsers are complex machines and it's easy to hurt performance by doing something that looks reasonable at first, but blocks the UI. Being single-threaded doesn't help. But reality is, most of the time Electron apps perform really well, it's just that they have slower startup times, consume massive amounts of memory, more CPU than average, and are 100MB each.