Would it be possible to resolve Electron's performance issues by "precompiling"/prerendering the HTML and CSS (+ maybe scripts) ? As long as the app UI stays the same, it should be cached in an optimized form. (sorry if that already exists in Electron)
Show HN: Cross-platform desktop applications with PyQT
21–30 of 293 posts
Re: Show HN: Cross-platform desktop applications with PyQT
#22Except 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.
Re: Show HN: Cross-platform desktop applications with PyQT
#23Earlier quoted context omitted.
Please read in between lines... I could easy write any other example. Don't make me compare HTML/CSS's flexibility with Qt's...
If you really need the full flexibility of HTML/CSS, you can just use QtWebKit and embed a webview in your UI.
Re: Show HN: Cross-platform desktop applications with PyQT
#24Not directly related to the initiative itself, but comparing and contrasting the Electron website vs. PyQT is striking: https://riverbankcomputing.com/software/pyqt/intro https://electronjs.org/ 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.
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.
Re: Show HN: Cross-platform desktop applications with PyQT
#25Earlier quoted context omitted.
Please read in between lines... I could easy write any other example. Don't make me compare HTML/CSS's flexibility with Qt's...
If you really need the full flexibility of HTML/CSS, you can just use QtWebKit and embed a webview in your UI.
Re: Show HN: Cross-platform desktop applications with PyQT
#26The main problem with "other toolkits" vs Electron apps is that they are not as simple to use in order to create a very good looking UIs. Compare how easy it is to use HTML and CSS in order to create a very complex UIs with all sort of effects vs how utterly complicated is to override, let's say, Qt's ::paint() method in order to achieve rich text inside a label. Let me repeat it. Rich text inside a label. Such a sim…
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.
Re: Show HN: Cross-platform desktop applications with PyQT
#27Would it be possible to resolve Electron's performance issues by "precompiling"/prerendering the HTML and CSS (+ maybe scripts) ? As long as the app UI stays the same, it should be cached in an optimized form. (sorry if that already exists in Electron)
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.
Re: Show HN: Cross-platform desktop applications with PyQT
#28Not directly related to the initiative itself, but comparing and contrasting the Electron website vs. PyQT is striking: https://riverbankcomputing.com/software/pyqt/intro https://electronjs.org/ 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).
Re: Show HN: Cross-platform desktop applications with PyQT
#29The main problem with "other toolkits" vs Electron apps is that they are not as simple to use in order to create a very good looking UIs. Compare how easy it is to use HTML and CSS in order to create a very complex UIs with all sort of effects vs how utterly complicated is to override, let's say, Qt's ::paint() method in order to achieve rich text inside a label. Let me repeat it. Rich text inside a label. Such a sim…
> create a very good looking UIs 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.
Re: Show HN: Cross-platform desktop applications with PyQT
#30The main problem with "other toolkits" vs Electron apps is that they are not as simple to use in order to create a very good looking UIs. Compare how easy it is to use HTML and CSS in order to create a very complex UIs with all sort of effects vs how utterly complicated is to override, let's say, Qt's ::paint() method in order to achieve rich text inside a label. Let me repeat it. Rich text inside a label. Such a sim…
How is this an issue? Before Electron and other HTML/CSS-based "native" apps became all the rage (which is fairly recently), native apps were built using Qt, GTK, Cocoa, WPF, WinForms, MFC, etc., and they did just fine. Perhaps we just really don't need these "effects" and just need consistent, simple UIs of the sort that toolkits that paint native widgets can give you. Whenever I install an app that's built using so…