I have been developing in HTML/Python for a while now. This works wonderfully. You just need to put all your business logic in Python, use PyQt to run all the platform specific code like file dialogs, printing, etc. but keep the main interface with React. You do that by having a webview with a service object being the bridge between Python and the JS view[0]. If you are a bit careful with the amount of information going through the bridge, you get very good performance (the page[0] is linking to some small screencasts/videos).
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.
Indeed, Qt is a great basis for developing a modern application with a HTML frontend. This is because Qt bundles a modern browser engine (was WebKit, nowadays Chrome) and has JavaScript support at various places (https://doc.qt.io/qt-5.10/topics-scripting.html).
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.
But why you would want to use React, Angular etc. while you can just do it in C++ and QtQuick and have many times better performance so better user experience and for example Servo browser engine rendering benchmark animation took me 1/2 loc to reproduce in QtQuick...
Wait, what? You are using python, to use Qt, to open a WebView to run HTML/JS app... Why can't you just use Qt directly? I've done some test on an embedded device powered by i.MX6 and HTML5 animation in WebEngineView gives 8fps, while the same animation purely in QtQuick gives stable 60fps... That's a K.O. I guess...
I’m curious, does that work with sandboxing on the Mac?
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?
I am sorry, I am developing mostly for boring big companies and my experience is only with Linux (because I develop with) and Windows (because my customers pay me to have the stuff available on it). Practically, this is just a PyQt application with a webview, so, it should work with PyInstaller.
I don’t know about this project, but I am using Qt in a C++ application, and this certainly works with macOS sandboxing.
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’).
I'm assuming this is a desktop app, not running off a server. How do you get round the problem of distributing Python with every install? Or do you just accept it? I love Qt in C++ because most of the time the code just recompiles between Mac/Windows/Linux. I've shied away from writing GUIs in Python because deploying - to the point where a non-technical user can run the program - always ends up being hacky.
It's not clear that the poster I replied to is using fbs - I'm assuming not.
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).
Yes, the react front-end is the interactive view so to speak. In my first comment, you have link to some videos where it shows the interface and you do not need to be a genius to see the HTML look of the interface.
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 is just the Python binding for Qt, so don't expect a fully polished website there. If you really want to compare Electron with QT, I suggest looking at the main QT website:
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).
It's not crazy to expect a UI toolkit website (even if it's just the bindings...) to have a better presence/pitch to make the sell. UI toolkits are built on how good they look and what they enable you to do, and the last thing PyQt should be doing is forcing people to check out a very marketing-heavy Qt main page.
That's not true, Qt itself doesn't look like anything. It's the style engine that matters in this case. The framework itself is interesring from the API viewpoint.
It does reflect the priorities of the community, though.
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.
As a developer, Electron's page shows their prowess in writing good front end code, which is really important. As someone who understands the basic concept of Electron, I want a product that demonstrates those competencies.
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.
- apache
- lighttpd
- v8
- PostgreSQL
- Linux
- Go
- ZeroMQ
- any imaging library (libpng, libjpeg)
- any compression library (zlib, xz, bzip2)
- urxvt
- vim
- emacs
- tmux
Basically none of these have good websites. When I'm looking for a CSS framework or like, UI tricks like scriptaculous then I think it's a good signal, but past that I really think there's no link here. Really "has a good website" means "someone who knows how to build good websites built one for this project".
Sure because those are examples of what you can do with the tech. You can't really make a website with Qt, so using... PyQt's website as an example for evaluation doesn't make a ton of sense.
Is it really that good though, or is it just that a lot of design effort (and dollars) have been put into it? Just based on the quality of electron based applications I have used, I feel like this basically amounts to spending a lot of time polishing a turd. Why compliment or be distracted by how shiny it is?
I prefer the pyqt website. No stupid animations. No bullshit. Just clear links to all the information you need, easily available docs, etc. I mean, it's kind a real reflection of the two frameworks. Do you want a framework that requires a 90MB payload with it that's a resource hog and a web browser or do you want something small, light and works?
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.
I agree... and I think there is a similar POV when looking at the results of tkinter and an Electron app. The visuals alone are worth it... let alone the ease of development and packaging.
If I was picking one based on their website, I'd no doubt go for PyQT. "Marketing" is just a eulogy for lying I think. And it further annoys me when FOSS projects imitate IT companies and try to do marketing.
If I'm going to use a GUI toolkit, the last thing I want to hear is "it hasn't been updated/hasn't had a revamp in 15 years". I know it's just the site, but it doesn't inspire confidence.
The 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 simple thing...
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 something like Electron (which is immediately obvious once the app launches), I know I'm in for a sub-par experience.
"Bah humbug, the old stuff is good enough for me!" is a shitty answer.
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'd argue the old stuff is better, not simply "good enough" vs. Electron etc. What have we gotten in exchange for the crap performance and extra RAM usage? Pretty animations? I don't need those; in fact they're distracting and annoying. You absolutely can make "pretty", complex UIs in native/cross-platform toolkits, and personally I find them much nicer to work with than the horror show that is HTML/JS/CSS.
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.
We can totally accept old-fashioned UI as developers. Hell, we even work in our terminals all day or use i3wm instead of any desktop environment. However, most apps target normal end users, not developers. Show your cousin whether she likes a flashy "modern" UI more or a succinct UI more, the answer is a no-brainer. And then try to explain to her what RAM usage actually means... The same as asking her whether she prefers using i3 or Windows, Vim or Word etc.
I'm glad you understand one part of Electron adoption, but the other part is user experience.
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!).
creating complex UIs using things like WinForms, QT, GTK, Cocoa, etc SUCKS
I think that this depends on your background. Personally, I would rather do a UI in QT than Javascript. I like that Qt supports high level components such as trees:
With Qt I can also use a lot of the experience that I gained 5 years ago on a UI today. Any Javascript UI experience that I picked up 5 years ago is obsolete.
It annoys me when people say something sucks without taking the time to understand it.
"Any Javascript UI experience that I picked up 5 years ago is obsolete."
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.
No its nothing like a minor language change. This actually happened to me and my Javascript UI experience (Jquery) is obsolete in the world of React and Angular or whatever the flavour of the month is.
If you learned Javascript and not jQuery then your experience is just as relevant today, with the main difference being that Javascript has had a lot of improvements since then (e.g. myArray.includes vs myArray.indexOf(x) != -1).
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.
If you know Javascript you can learn Angular or React or Vue fairly quickly.
Python's transition from 2 to 3 was anything but "minor"... further, jquery was designed and developed for a completely different reason than React or Angular at a different time in the evolution of the web. Your jquery knowledge still works I promise... the thing is there are better options.
What does obsolte mean actually? Today you still can build web app by jQuery.
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
This has nothing to do with Javascript. It's much easier to do complicated UI using a web browser's layout engine than it is using one of the above frameworks. For really simple stuff, yes it's about the same, maybe even easier with native UI, but if you ever need to do something outside of buttons and lists, things will get ugly fast. On a browser on the other hand, you can very quickly implement any component you can think of using well-documented CSS rules.
> Why would you not want a toolkit that makes rich application experiences across multiple platforms easy and standard?
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.
Also because it often violates the standard UI conventions for the given OS, so I have to learn how to use every application from scratch.†
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).
Developers have already been working around the standard styles with all those technologies. It only took more time and effort. I look at the native apps I've installed and the standard layout is the rare exception. I mean no offense, but arguing that a standard set of controls would be enough for most of the applications would be faulty judgement at best, if not being delusional.
The platform widget set is a language: when you look at a well-behaving application that uses such language, you immediately know what's a button, what's a menu, what's a tooltip, what's a label etc., and you can configure how ALL the applications look via applying a theme system-wide. Especially important if one needs certain color schemes or font sizes globally. Modern apps each have their own distinct language, and that puts the user at discomfort (and also danger, from time to time) as he through trial and error seeks how to use the thing to get what he wanted to do done. It's a feature when all the apps look like each other for the most part.
Wow. You realize they share most of the same code, and are essentially feature identical?
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.
> You realize they share most of the same code, and are essentially feature identical?
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 wish Chrome apps for the desktop were more popular. Use the browser you're using anyways but on a thing that sort of acts like an application.
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.
Yes, that's the problem. Web apps are never going to have the level of system integration that you'd expect with a native desktop app. Why install a 'native app' that offers you the subpar web experience when you could just open it in your browser?
If that's the case, then the desktop app buys you absolutely nothing over just using the webapp. In fact, now you have to have multiple instances of your browser running, instead of just one.
Exactly, it doesn't have any business being a fake desktop app, just because the devs don't want to learn native frameworks nor how to write portable web applications.
if they are identical, why would i choose to open up a bundled web browser when the one i already have opened works just fine and can display the web page just as well?
The Electron and browser Slack apps are not /exactly/ the same on Windows. The Electron version of Slack swaps out the normal titlebar for a black bar and a hamburger menu. The point of a native app is to integrate with the native window manager, but Slack overrides the native styling. (Spotify does the same thing.) The browser version, by virtue of running in the web browser, is consistent with the rest of the system UI.
See, for a website, that's fine. But not for an application. Why would I not want an application that fits in well with my chosen OS, and follows the design guidelines and patterns of that OS?
Linux and Mac weren’t as popular OSes either. And frankly, Windows apps didn’t need to look decent because people on the Windows/Linux side of the world were ok with really bad looking apps.
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.
Have you ever designed an application with Qt Designer or Delphi for that matter? Both are literally drag and drop. You can make a first mock-up of a application in a few minutes.
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.
Neither are as good as 99% of the tools available for development with HTML/CSS. Plus, with HTML/CSS, you can work manually on your project, without any special tool besides your browser, and see the effects you have on the layout in real time.
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.
Neither are as good as 99% of the tools available for development with HTML/CSS. [...] 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.
I have a feeling that you do not have any actual experience with Qt Designer or RAD tools? Designing a user interface quickly is many times easier in Qt, Delphi, etc. than in HTML/CSS. It start with the basic fact that Qt has many useful widgets that are not available in plain HTML, nor many CSS/Javascript frameworks. From there it is just drag and drop, adding a few spacers here and there and you are done.
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.
At one of my jobs, a Delphi application (admittedly quite old) was reimplemented with the latest (at trhe time, anyway, I'm sure it's completely passe now) web frameworks, fancy Javascripts, nd all that.
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 feeling that you do not have any actual experience with Qt Designer or RAD tools? Designing a user interface quickly is many times easier in Qt, Delphi, etc. than in HTML/CSS. It start with the basic fact that Qt has many useful widgets that are not available in plain HTML, nor many CSS/Javascript frameworks. From there it is just drag and drop, adding a few spacers here and there and you are done.
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.
Why would I develop in such an arcane manner if I already have great development tools for more than two decades?
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.
But what exactly do any HTML/CSS do for me that I could not do with a 17 years old copy of Delphi? And the resulting application will be harder to use, bloated, and much slower than a Delphi one (let alone using something more modern).
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.
It can do a bit less, if you're opting to go with pure HTML/CSS; however, without JS, pure HTML/CSS is quite snappy if done well, and infinitely easier to write, from my experience. It's also easier, in my opinion, to make nice looking interfaces with.
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.
Well, it had always taken me far less time and effort to do a nice, interactive app in Delphi than it would in HTML/JS.
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.
Native applications vary too wildly, in my opinion. HTML/CSS/JS make it easy to get a consistent UI, which is incredibly valuable if you're making software for less technically advanced people than your average HN poster.
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.
AH, but how many of those less technical people use more than one platform? Most likely they are using Windows. Possibly MacOS. Very unlikely Linux. So giving them something that looks entirely different from all the other apps they are used to, and what integrates well with the system isn't necessarily the best.
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.
The average Mac OS application varies wildly - from Garageband to Safari, it's not entirely consistent. Windows applications look terrible by default, and the main problem is that there are so many different versions of Windows applications. A Windows 7 application looks entirely different to the same application running on Windows 8 or 10.
Also, the Discord interface looks entirely different than Microsoft Teams.
I'm not tyhat familiar with Mac software, but last time I checked, Apple had some pretty stringent standards for UI design. And well, unless you went to some extreme lengths, your menus, textboxes and buttons would look consistent.
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.
I would disagree with this as I've created many small apps using QT, and getting started is much easier than with Electron (in my opinion). It is as easy as this:
import sys
from PyQt5.QtWidgets import QApplication, QWidget
if __name__ == '__main__':
app = QApplication(sys.argv)
w = QWidget()
w.setWindowTitle('Hello, world!')
w.show()
That's his point. With a web app, his experience tells him he can run the code within an environment that he's used to.
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.
Yes god forbid anyone ever need to learn something new to do something different.
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.
At least in nw.js which is a similar toolkit to Electron:
{
"name": "helloworld",
"main": "index.html"
}
And index.html is just whatever HTML web page you want, like "<html><herd><title>Hello World</title></herd><body>Hello World</body></html>". You could also use a javascript file as your "main" file if you want.
Even when you screw up the HTML it will still load, which won't happen if you get your underscores wrong in your example.
> Even when you screw up the HTML it will still load
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.
Please tell me you're trolling... you actually want your software to run when there're errors and not have it blow up in your face? I don't even... ah screw it.
I agree that HTML/CSS is easier to use, though maybe some of that is just because everybody has been using them for years. However, you certainly don't have to override ::paint() to get rich text inside a label. You can use a simple subset of HTML in your QLabel to get various text effects.
You cited an example that is literally trivial in QT. The implication is that instead of comparing tools on their actual merits, and then forming qualitative conclusions, you already have an opinion you're trying to convince others of and are attempting to support it by making assertions about a tool you don't understand.
Are you seriously being difficult with someone who is suggesting that with HTML/JS, most of your work will already be done for you, even in the most niche cases?
Javascript is "libraries" the language, for better or worse. You're comparing a language which is the de-facto language of front-end design and increasingly popular on the back-end to UI toolkits that have been around forever and still have virtually no mindshare by comparison.
HTML and javascript are the time and energy wise choice for any sort of front end design. It's just that we have shit like electron that is beyond suboptimal at tackling the issue of "native" applications (although I'd argue still a sensible choice!). Ideally we have something like react-native for the desktop, or built in html/js runtimes with platform specific bindings.
> licensing, packaging, and lack of mobile support
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).
No, please do. Explain to users why you need that, and why you feel you are important enough to bypass and ignore all of the existing design guidelines and patterns of whatever OS I'm running on. And why you feel you have to use up all of my CPU and memory to do so.
For the last time, "existing design guidelines and patterns" is a myth. Even Apple only really hits that (and barely) on iOS; MacOS UI consistency is a mess.
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
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 want a good looking UI, I just find that electron doesn't deliver this. A good looking UI is one that blends in with the rest of the system, electron apps look like their being run in an emulator from another OS.
It's a "random" guess. But in my experience, for a website, if it doesn't look good at first sight, a user might just leave instantly. As someone pointed out in the comments, just looking at sites like:
I'm sure that's part of it, but the primary usability studies I'm aware of have all focused on speed/response. Whether this translates to "native" apps or not, I'm not sure, but certainly for the web, response times are king [1]. Curiously, this metric has been a stable predictor of retention for decades (see the sources in the link as it'd be redundant for me to post them here).
To be annoying, and not to disagree with your comment in any real way at all, I’d argue it’s the engineers who are being irrational for choosing to ignore or not make the effort to understand human nature. I’m sure there are plenty of studies in psychology, social psychology, or anthropology explaining the rational basis behind why fashion/marketing has such a strong impact on human behavior. I’d also bet that the advertising industry is well aware of these studies ;).
Then just use tkinter and avoid the licensing issue. The main draw of QT from literally almost everyone in the Python community is the beauty of Qt! Go read /r/python's latest, almost weekly discussion about GUI creation.
Yes. QML is a step in the right direction, but the syntax is kind of awkward, and you still need C++ on the background, which makes it harder to use, more expensive (in terms of man/hours cost) and slower to develop than <the JS framework of the month> + HTML/CSS.
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:
Not that most companies would care, as dev cost seems to be all that matters these days, but the upsides are much faster and leaner applications than what you get from Electron.
Can't talk as to rendering and such, but python isn't going to be a performance win vs JS. V8 is faster than cpython by a decent margin for typical tasks on typical data structures.
You'll need to dip into clang or whatnot for really hardcore perf either way
Performance of Python driving UI components implemented in C beats performance of JavaScript driving UI components implemented in JavaScript on top of the DOM.
It's not the js that's the problem. It's the dom. QML was designed from the ground up for optimal rendering on the gpu and from the ground up for applications rather than documents.
You won't be using Python with QML at all, but rather JS - so you still can enjoy the speedy development vs. a traditional Widget app, and you get a far more efficient runtime, too.
If it is so trivial, what is the big deal with "Single Page Applications"? Seems like plenty of pain there in the HTML and CSS world..
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.
> The 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.
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.
The other issue is that a lot of these sorts of applications like Slack started life as a web app. In that case, your options are use Electron or build a new desktop application from the ground up.
> your options are use Electron or build a new desktop application from the ground up.
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.
QT is amazing, it has been around so long and there even is a photoshop to qml exporter [1] that helped us make this dashboard for my Universitys formula hybrid team in [2] [3]. It really did not take too long and the performance is amazing on the Pi. I highly recommend QT, and there are amazing bindings for languages. I am looking forward to trying this out!
Qt, the application framework from Qt Software is written as Qt (capital Q). It is not written as QT (capital Q, capital T). QT can refer to a lot of other things, e.g. Apple QuickTime.
The official pronunciation of Qt is “cute”. It is not pronounced as “cue tea”.
> "PyQt is dual licensed on all supported platforms under the GNU GPL v3 and the Riverbank Commercial License. Unlike Qt, PyQt is not available under the LGPL. You can purchase the commercial version of PyQt here. More information about licensing can be found in the License FAQ."
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.
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.
I guess it depends on how much time you spend on an app. I've been working on my PyQt app [1] for 2331 hours (I track my time). $500 is nothing in comparison.
Yeah, I wish you all the luck... but look at it from a new programmer perspective, or someone that wants to create an app for money, but doesn't know if it will work.
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...
You raise valid points. Of course, a web developer who has never used Python will be more comfortable with Electron. That may be a very good reason for her to prefer it.
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.
The licensing is a problem for an Electron competitor. I really wanted to use Python / Qt to make a desktop application I'd like to sale, but got confused by the licensing issues. I'll just use Electron. I hate that this is the case, but pretty screenshots and good marketing will be far more important than a fast startup time.
If you don't want to pay for a commercial license, just use PySide. It's LGPL-licensed and has nearly exactly the same API as PyQT. So near that when I switched out PyQT with PySide, all I had to do was change two import statements throughout a ~3000 python gui application.
Yeah, except that it seems like PySide still doesn't support Qt 5.x according to [1]? While there is a page for PySide2 [2], I can't figure out if it's complete or not.
Does PyQT require an additional commercial license for the Qt itself? Qt's website says that its commercial license is $459/developer/month! The subscription fee is pretty hefty. So that means I pay PyQT $500 in addition to $459/month for Qt?
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.
Qt is licensed under the LGPL. This lets you use it as a library. When you use PyQt, that's exactly what you are doing. So, you don't need a separate license for Qt. The PyQt license is usually enough. (caveat: IANAL)
Unfortunatelly PyQt does not solve the problem of Javascript engineers who are not willing to learn a new programming language.
That's the whole reason for the whole Javascript fadigue. Computer Science has had "had tools for the right jobs" for years, but now we have a large developer base that only knows Javascript and think it's some kind of holy grail of computing. Happened before with Java. Happened before with PHP. It will happen again.
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.
Speaking as a developer who primarily writes Python and secondarily C, Rust, C++, bash, and others as necessary, who has in fact worked on a large-scale C++ UI project in Qt on the Linux desktop running alongside PyGTK UIs, and who doesn't actively write JavaScript, I have to say that JavaScript is a really good choice of language, especially for UI, because it has a strong bias towards event-based programming and callbacks instead of blocking code and threads. If you're going to pick the right tool for the job of UI, I'd put JS a bit ahead of Rust (because of immaturity; that is likely to change real soon), which I'd put a lot ahead of C++ (because you're going to screw up threading) a little bit ahead of C and Python (because you're definitely going to screw up threading). If you're interested in rapid prototyping, I'd move Python up several notches - but not past JS, which is what I reach for these days for throwaway prototypes if I think I know enough JS to pull it off.
(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 agree with you. I can't think of a better language for writing GUI then Javascript right now, in particular because it has so many great toolkits and widget libraries.
But what makes those apps resource hungry and sluggish is usually not the UI: it's the whole lot of applicationg logic that's buried into their cores using Javascript code for stuff the language was not designed for.
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.
Yes - and even when I was working on the Qt apps, I really wanted a shared non-Qt and preferably non-C++ library for application logic that was nicely portable between Qt on desktop, Python for the spots where we needed it, and Android (Java) and iOS (Objective-C).
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.
The point is that we unnecessarily focus on developer comfort in writing software, but software needs to be optimised first and foremost for runtime. In fact I'd put the priority as such:
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?
Most code, #1 is irrelevant. Most code isn't in the inner loop of performance-limiting execution.
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.
> Most code, #1 is irrelevant. Most code isn't in the inner loop of performance-limiting execution.
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.
#2 and #4 are not simultaneous. Writing that really clever function that's difficult to read has happened to us all, in fact in ops there is the notion of "write-only scripts", such as intricate one liners or regex's.
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.
> The point is that we unnecessarily focus on developer comfort in writing software, but software needs to be optimised first and foremost for runtime.
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.)
finally someone who understands JS while most other devs trying JS dont know events, have a hard time understanding async and complain about lack of threads - in JS you can spawn worker process's but that wont help if you dont understand events/async. everything in JS is event based eg button.onclick and while it might feel old you can never abstract that away as the cpu uses interups that is basically events. that is how computers and the real word works. for example if a coworker comes into your office thats an interupt. you have a routine/function for it and tells him to fuck off. but at the same time your manager comes in. that is the nature of async. and you might have an edge case you did not think about.
> 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've experimented around with Quamash[1] 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.
Sure, but if you don't have events of your own to process, either you're constantly calling processEvents() and spinning the CPU, or you're in a loop that does so every second, which is both high-latency and inefficient (and bad for battery life). You generally want to process an event when it suits the event, not when it suits you :-)
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.
I've used variations of qt4reactor (https://pypi.python.org/pypi/qt4reactor/1.6) to integrate Twisted with PyQt apps. It usually works pretty well for desktop apps (I used it to create an ssh tunnel using twisted conch for a desktop database visualization too).
Wat? The PyKDE binding were always an afterthought. The big KDE4 language bet was, guess what... javascript bindings, to build widgets. And then Ruby bindings, since Ruby had just exploded. Except web developers never cared for the Linux desktop, they are Mac users.
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).
People like you hate the idea of using JavaScript to write desktop apps because you feel like the end result is too slow and inefficient.
Web developers hate the idea of using C++ to write desktop apps because the language is brittle, outdated, and overly complex.
We need a middle ground: a language with the syntax of a scripting language, like Python or JavaScript, that compiles down to native code, like C++ or Rust.
I am under the impression that Qt is attempting this with QML and JavaScript.
Well, we have Vala. It compiles to C just like Nim and it's used for GUIs, although it's Gtk specific and some would argue it's not a programing language:
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.
Rust might eventually get to that point, and C++ itself with QT is relatively easy if you stick to the basics. But in a way, anything trying to please both higher level and lower level developers is going to have to settle for some kind of middle ground.
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.
What exactly do you mean by "one character symbolic syntax notation"? I can't think of anything in Rust matching that description that doesn't exist in C++ as well.
If you look at the popular web development languages, they don't really have sigils. Javascript/Flow/Typescript/Coffeescript (front end). Java, C#, Python, PHP (ok, I'll grant you $). Ruby is a bit of an oddball and I guess it's part of the reason Python is overtaking it.
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.
Which is unfortunate, because most apps don't have a lot of business logic to them. Most time is spent learning the interface and libraries...it might as well be a different language or something better suited to task at hand. For a crud app I'd generally grab for Qt, for a multimedia app or game I'd grab for SDL.
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.
SQL is a good one. Fortran is another. ASIC's, GPU's. When generic is not good enough, we create specific solutions.
Javascript is itself an example: it solves very well the problem of giving web pages interactivity. It was not designed to be a general purpose language though - it was, and is - being worked around into one.
For GUIs in particular the problem is far from solved in the sense you've mentioned.
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.
The only exception to this is JavaScript! JavaScript is so much about front-end stuff that legitimate effort is put into getting stuff working well and painlessly. Sure React didn't invent FRP, but the communities gone further with the concepts than any other community. Bar none.
So many people refuse to admit it, but the JavaScript community is the state of the art in GUI development. The biggest crutch bring the weak native support of course.
You're of course welcome to your opinions, but I strongly suspect that you need more experience as a developer to understand the answer to your question, if you don't have a sense of what things are demanding in JS and if you think that being able to write C++ is clearing some sort of high bar.
I write code using JavaScript and C++ on a daily basis. I would hire a successful C++ dev over a successful JavaScript dev for cross-platform work. There are too many issues.
I am curious about final package size on various platforms when using this project. The download bundles for the related "fman" project vary considerably -- Win: 1MB; macOS: 23MB; Ubuntu: 39MB. The last number matches my experience with scripted Qt applications, at which point the size is comparable to a typical ~50-70 MB Electron app, at least for compressed downloads. Visual Studio Code is 44 MB on Windows and 65MB on Mac. Scriptable wrappers usually imply that the core Qt shared objects can't be pruned, and the wrappers themselves also add up, so that Windows number is impressive and intriguing!
I would also wonder about performance scaling. Are there good examples of "large" applications where CPython drives the main loop, as opposed to a scripting layer over a C++ core? CPython has a shallower optimization floor than Javascript+V8, and most larger Python GUI applications I've tried had noticeable lags (thinking of several visualization apps, and several Python-centric IDEs). I was similarly skeptical of Javascript-based desktop applications until recently, but Visual Studio Code has been very impressive.
I'd wager the Windows download is not the full app, rather just an installer. There's no way Qt and PyQt would fit in just 1MB on an OS that doesn't include those as shared libraries.
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.
That is correct, the Windows binary is an online installer. The reason for this is that fman uses Google Omaha for its auto-update mechanism [1].
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.
Yeah, I finally got windows version to download (cut out a few times, HN overload?). The win download is an online installer, so the size makes much more sense. I didn’t check the install directory, but it took 2 minutes to retrieve on slowish WiFi, so I would expect the install size is in-line with the others. (Good point about Arch).
You care comparing installer size. Typically an installer is considerably smaller than the installed app size and usually the installer is deleted. So it's not really worth comparing installer sizes.
For comparison of installed size:
- Code.exe is 77MB (version 1.20.0)
- directory "C:\Program Files\Microsoft VS Code" is 225 MB
It seems Sciter[0] is another alternative to Electron for those who aren't too keen on Electron's
resource usage but still want to use HTML, Js and CSS for their UI.
I haven't used it personally but they appear to have a few notable clients.
Seems they also have popular language bindings[1] (Go, Python, Rust etc...).
It's not opensource though so that could be a deal-breaker for some but licensing/pricing[2] isn't prohibitive.
Has anybody here on HN used this before? Care to share your experience with it?
> In simple terms, this means you can use it for free in open source projects that are also licensed under the GPL
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.
No callbacks. No lifecycle diagrams. You don't give up control of the event loop. No memory management. You can add new widgets by copying/ pasting/modifying from demos easily.
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.
An actually good alternative to Electron is badly needed, imo. PyQt seems like a reasonable start for a platform like this.
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.
Browsers should just provide controlled access to the operating system file system which will remove some large percentage of the use cases for Electron. It would be easier and much safer.
While this looks promising on paper for Python user , it will probably just die in the coming years due to a lack of vision and of community.
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.
Ultimately this tech feels a lot like all the 'I hate javascript so here is my alternative' frameworks we had for the past year.
You can develop commercial apps with PyQT, your code just needs to be compatible with the GPL3 license (https://www.riverbankcomputing.com/commercial/pyqt). PyQT is not different from any other dual-licensed open-source project in that sense.
It depends on how much time you will spend developing your app. I've been working on mine [1] for 2331 hours (I track my time). $500 is nothing in comparison.
If this comes to fruition it would be great. I, wanting to start a new commercial desktop app, recently researched using Python/PyQT. The packaging situation was not good so I decided on another technology but I'd love to be able to use Python and reliably create a desktop app installation. The PyQT license cost doesn't bother me if I could use it. Certainly cheaper than Delphi.
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.
Ah... My experience differs :-) For example, many keyboard shortcuts don't work over tables (because they conflict with those from the browser; maybe Electron helps here, don't know); copy/pasting images is not easy; editing complex data structures is not easy, especially when you want to transmit delta-edits to the server; it's also tough to freely draw over controls (for example to give visual hints here and there).
But well, Qt presentation is not nearly as sexy as HTML/CSS, that's for sure.
Coding is only a part of my job. I am currently building an application for our warehouse, connecting our ERP to some external services. Lots of moving parts across several machines. In the middle is a tiny GUI, which has been more trouble than the rest put together. I used Tkinter to minimise dependencies. I am staggered by how much code it takes to get a GUI working (compared to the rest of the project), and this is just a plain industrial app. I'm sure this is part of the reason why JavaScript is taking over the desktop. Visual Studio had me making apps like this in minutes last time I used it (some time ago). Where did we go wrong?
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.
If I had just learnt JavaScript instead I could have done both in one hit.
How would javascript reduce the code necessary for a gui or help you cross platform? UIs are very different between phone / desktop so even if you stayed with javascript you'd be learning different libraries or rewriting everything to conform to the other platform.
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.
PyQt is really difficult for me to use because of the license, I'm afraid.
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.
Yeah, Tk just looks and behaves (as a gui) very crudely, but my preference for other gui libraries was always ease of use, organization, and troubleshooting. Verbosity would go under ease of use and organization. I think Gtk and/or Wx had a gui to layout widgets, but it was so far behind Qt. I still don't have a preferred way to organize Qt code, but it offers almost too many options. The main book on PyQt, Rapid GUI Programming with Python and Qt, doesn't use Designer and all the guis are done programatically. It's a great way to learn the library, but horrible for maintenance.
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.
I think it's because GUIs, by their nature, are event driven and require parallel execution. Python doesn't do this very well so there's awkward syntax, a few competing paradigms, and unexpected behaviors (with memory, code flow, etc). I can see an argument for Javascript in this regard.
I write desktop apps using PyQt and build an installer with pynsist. This is cross-platform, but I only need Windows support. Other than that, is this project just a simplified way to build desktop applications, or would it produce something fundamentally different from what I'm building now?
It would build something similar but encapsulate knowledge gained from distributing to many thousands of machines. For instance, about .dlls that are available 99% of the time but sometimes missing on some users' machines [1].
So this is a wrapper for PyInstaller? I see that it creates an installer .exe on Windows or a dmg on Mac, which is nice (I'm having trouble with PyQt and the latter at the moment).
It's unclear what the other advantages over PyInstaller are. Does @cached_property provide a performance benefit?
It uses PyInstaller, but also does much more. For example, PyInstaller doesn't let you create installers. Also, PyInstaller only gets you 95% there for packaging. There are still some edge cases such as missing DLLs [1]. Finally, fbs provides a very high-level interface. You don't have to learn PyInstaller's configuration options, or how to create an installer on Windows or a .dmg file on Mac. Those are all things that take a significant amount of time to learn, get right and integrate. fbs does it all for you.
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)
Performance-sensitive apps already do that (like VS Code, Atom). Most of the cost is in the javascript, caching bytecode lowers startup time a lot. Pre-rendering is not really practical, and painting is rarely the main bottleneck either way.
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.
And then we just have to put React-ExtJS on our 8 gigs and still swapping displaced full stacks to have something that looks like a proper desktop application again.
I think that to compete with electron it would need to have something like React. It's very hard to go back to gui controls and the way they were done since before the web after you tasted something like React.
Killer innovation is not the markup language but components (extremely flexible and trivially composable at any level).
Every time this argument comes up, I see the same tired comments, and they're typically from people that don't have to build a modern UI. There is an insane amount that you get for free in HTML/CSS/JS, and it's very clear why things like Qt & co don't stack up.
Here's a small list (which could easily be a much bigger list) of things that are much easier in web dev land than their native counterparts.
- Want to chart some data with nice animations? The chart library in Qt is good... until you need to make it look sexy. If you're in HTML/CSS/JS, you can just reach for an unlimited number of alternative libraries to pull from. (No, saying "go without the animations" isn't an answer.)
- Universal stylesheets are a godsend for quickly iterating on UI. Qt's stylesheets do not come close to the abilities that modern CSS provides you (and frameworks beyond Qt often lack something even close to this). Saying "CSS shouldn't be doing this stuff" isn't an answer, because the alternatives are simply less productive. It's absolutely amazing to be able to target an arbitrary node in a nested structure and tell it to behave differently, and have the entire thing render appropriately.
- You want smooth scrolling (that matches the OS behavior...) at 60fps? There is an untold amount of work that each browser vendor has put in to this effort, and the benefit is greatly undersold. Ever looked into wxWidgets? You have to go out of your way to make a scroll view bounce on macOS. That is utterly insane in 2018 - and no, saying "why does Mac need to be different?" isn't a solution. The entire point of cross platform development is that it should handle this.
- Have you ever tried to optimize scrolling on a TableView in Qt/wxWidgets/Cocoa/etc? Give me HTML/CSS/JS any day of the week.
- This point is slightly separate, but... I've written Python for over 10 years now, and I would not want to write a UI in Python. The language is one of my favorite and works well for most things, but UIs are often just kind of hacky - Python isn't a language that's ideal to write hacky code in. I'd sooner do it in Ruby or something.
Want the tl;dr? There is no other frontend community that even comes close* to the wide range of documentation, available libraries, built-in/free benefits, approachability, and general "it'll just work" feeling across platforms.
I write native UI code daily, and the writing is on the walls for it. Tangentially, this is very much why I suspect Apple is looking to merge Cocoa and UIKit more - it's the only way native Mac apps survive (oh, and even Apple renders significant chunks of some of their apps with Webkit... three finger swipe right on your trackpad if you wanna see some ancient Webkit app history).
* - _maybe_ UIKit for iOS comes close, due to Apple's vendor lock in factor and focus on UI, but that's something that a) rarely extends back to macOS apps and b) usually winds up splintered between Objective-C/Swift implementations.
That's a killer UI, and I'm happy to admit it's incredibly good for what I've seen/used of Qt apps over the years... but it's not the norm. I would honestly pay money to see how much effort it took to get it to this.
There's also the point I forgot to mention in my original post, which is that... if your entire app starts as a webapp, there's no sense in maintaining an entire separate Qt codebase when you could just wrap it. Standalone products like this (embedded, etc) might have an easier time justifying it, but I really don't think it hits the ease of use metric (not even touching on the fact that you then need to handle product changes across multiple codebases/teams - money doesn't absolve your, your team or your company of the inherent difficulty here).
Also, hell, the simple act of refactoring native level UI code is often more of a PITA than the HTML/CSS/JS counterpart. Native APIs need to make themselves more accessible and sexy if they want to have a chance here.
Alsoooo to just end this rant of mine, I'll point out that the OP's project shouldn't charge money for this. It's not that they're not allowed to or anything like that, but you're in no way making PyQT a viable Electron alternative if you require licensing. There's little money in building UI frameworks for this reason; the web kind of requires you to compete on free to use. There are people (regardless of your take on the matter) that don't use Qt for licensing reasons and that is a hard blocker.
> That's a killer UI, and I'm happy to admit it's incredibly good for what I've seen/used of Qt apps over the years... but it's not the norm.
It's the norm for Qt apps since 2011 - 2012 when qml was introduced (of course, older apps use the older tech - and honestly, sometimes it makes more sense : at least all the colors, fonts, etc... will respect your desktop theme unlike "modern" toolkits). Here's how some QML code looks: https://github.com/jcelerier/TodoMVC-QML/blob/master/Main.qm... ; as you can see, it's far from bloated (mostly due to the language being based on reactive semantics).
I've used QML before, but I appreciate you linking a sample for anyone who's curious.
Re: the matter at hand, it's cool if you don't consider that bloated. If I was using a C++ Qt codebase as the comparison point, I might think that too. However, if we're comparing it to a typical web codebase, that's an order of magnitude more dense. This also just doesn't matter in 2018, because QML could have the best documentation in the world and you'll still have trouble figuring out any issues as it doesn't have anywhere near the level of literature and/or (discoverable, not buried in some dead Linux project) open source code that the web platform does. Qt has a sexy problem, and every time it's brought up people try to claim it doesn't matter, but it does.
(There's also a slew of apps (e.g, I could go pick a cryptocurrency wallet app at random...) that have been built long after 2012 and still have issues with rendering.)
I'm not interested in debating KDE, since... that project stopped being relevant to me around KDE4. Nothing but wasted potential.
Re: respecting a Desktop theme... I used to love ricing out my desktop too. ;P
The thing is that it's an archaic viewpoint - one that you're welcome to have, but it'll increasingly be pushed down. Product design is always going to trump desktop UI customization capabilities, because one of those has money behind it and the other doesn't.
I also don't know anybody who customizes their desktop chrome anymore because (in addition to companies like Apple making it next to impossible) most people use their machines through a web browser at this point.
Also, let me be clear: I would love for native UI frameworks to be better. I don't particularly enjoy digging around in web codebases, but pretending that anything is else is as close to approachable as them makes it very difficult for any native UI toolkit to improve. People seem to think it's on the Web to catch up to the performance of native, but it's really the reverse - native needs to play the game how the web does or it's going to go extinct.
> However, if we're comparing it to a typical web codebase, that's an order of magnitude more dense
Well, I disagree. All the examples I could find, for instance in Vue.js, React, etc... had quite a bit more LOC necessary to achieve the same behaviour, when counting JS + CSS + HTML. Even with lambdas, associating a behaviour to an object is still not as nice as just doing `height: width/2` and knowning that the constraint will keep being enforced.
> I'm not interested in debating KDE, since... that project stopped being relevant to me around KDE4. Nothing but wasted potential.
> The thing is that it's an archaic viewpoint - one that you're welcome to have, but it'll increasingly be pushed down.
Will it ? in the contrary I find that the ricing community is more active than ever :p
Ricing was a thing with e16 and blackbox when there were less than 100k linux users two decades ago. Now there are more than a hundred million... it's not going to disappear.
Besides, it's sometimes a necessity. Think for instance of all the vision-problem-related enhancements that a coherent desktop theme can provide.
> I also don't know anybody who customizes their desktop chrome anymore
Serious question: Why do so many people think building desktop application GUIs with web-technologies is a good idea?
I'm currently trying to formulate some thoughts on this;
While I understand that HTML/CSS generally seems more flexible and may be more easily accessible to more/newer devs, it carries huge, negative implications in the forms of HCI (not having consistent interface elements on the user platform), performance and energy usage (particularly Electron), OS-integration, and accessibility features.
Can someone please give me some arguments as to why this not only seems like a good idea, but also why it's the best tool for the job?
* Cost. Why hire a separate dev team for each of web, Windows, and MacOS (and in this scenario, you never get a Linux app) when you can hire a single dev team to work on the core of the app with maybe one person to handle platform issues (and you get a Linux app nearly for free, which you wouldn't otherwise bother with)? Hell, you might not even need to hire more people to deal with your desktop apps initially, if you have at least one web developer who is resourceful and can figure out the remaining details.
* Hiring. Web developers are everywhere and easy to hire. Finding someone with expertise in a particular GUI toolkit is harder. Even if you initially don't care about which particular GUI toolkit, after you start building in one, you need to find more people to hire who are familiar with it. (This is also another "cost" item, I guess.)
* Ignorance. My biases are probably showing here, but my impression of most frontend developers is that they don't worry about performance too much, at least not to the level that, say, a C++ or JVM or CLR developer would. They seem to view many performance issues as something to be solved by the Javascript engine or browser renderer. They also likely develop and test their app on a high end machine and don't notice perf issues until users complain.
* Marketing. Visit Electron's website, and then visit PyQt's (or Qt's, though they're a little better) or GTK's. I guess it shouldn't be a surprise that the websites made by people who work on web technologies look better and tend to have better marketing.
* Tooling. Web debugging tools have gotten pretty great during this decade, closing the gap with native-code IDE debuggers, gdb, valgrind, etc. Electron's tooling make it fairly easy to build for each platform. Building a cross-platform app in Qt or GTK requires native compilation for different platforms, which is still, even today, a bear to set up.
What has happened is that "we" have divorced software from hardware by adding an increasing number of abstractions.
There is a increasing number of people that never had to deal with boot sectors or config files to get a computer up and running, they just hit a button and a few seconds later it lights up in massive colors and sounds.
And the only languages they know are web related languages, because that was the thing to know when they got interested in computers. And as the saying goes: When all you have is a hammer, all problems looks like nails.
> it carries huge, negative implications in the forms of HCI (not having consistent interface elements on the user platform)
This is a double-edged sword for multi-platform apps, but isn't a drawback for monoculture environments.
> Can someone please give me some arguments as to why this not only seems like a good idea, but also why it's the best tool for the job?
For a certain class of apps (such as IDEs), its a great idea due to the ease of extensibility as well as making multiplatform releases effortless. I doubt VS Code would have been available for Linux had it used a non-web-tech stack, and it has displaced PyCharm for some of my lighter tasks. PyCharm is written in Java, so it's also not native, but it's the best IDE in the world, IMO.
One codebase catchall. Most apps need some sort of web version and desktop version. So doing it all in web tech makes sense.
Then as you get familiar with web tech doing it in native toolkits requires you to learn new paradigms and quirks which is a barrier to creating new apps so people revert to what they know (web tech).
It's just that web is so popular so people stick to what they know. Same reason people would use say python with c extensions over golang. Even though go is faster out of the box, if they're used to the python ecosystem it makes sense for them to prototype in python and then optimize with c extensions, they can get something that works with less cognitive friction.
Why learn frameworks and UI paradigms for different platforms if you can just build it once? You can have a desktop app in under an hour if you already have a web app.
It appeals to people who regard desktop resources (memory, CPU cycles, etc.) as functionally unlimited. Thus, there's no reason to worry about low-level efficiency, such as with C or C++. So why not use all the technologies you already know and use everywhere else, like JavaScript?
I don't know if I agree that it's the best tool for the job, but I can see the appeal to someone whose world is JS and Python only. Especially if memory management is a foreign and scary world to them - and having done it, it certainly is scary!
I do Python and JS daily. Never had to do hand memory management in my life (maybe once in Objective-C).
Webdev is not the best tool for the job but it's cheaper and substitutes for a sleeve of other specialised tools.
The user experience is secondary if you do a product on a budget and iterate over it all the time. Especially if you are a web-first experience like Slack. Having native stuff there would make it even worse adding cognitive dissonance to the overall design.
Because system resources are cheaper than expert knowledge.
We've got enough RAM & CPU cycles spare that we can run GUIs in a headless browser and CSS & JS have come along far enough to make this easy(ish) to pull off, especially when combined with a framework such as React or Angular.
I can see why it's done, from the cost PoV, but I'm always a little dismayed when I find yet another desktop app which has the 'uncanny valley' of an almost-native look and feel. Same goes for ReactNative vs true native mobile apps.
What's really "enough RAM & CPU cycles"?
I think one can argue that this is really offloading development cost as a a resource cost onto the users - who must run "native", inefficient applications.
This means not only implicitly making a choice about the users' hardware, but it may in some cases exclude certain user segments as well.
I wish them the best of luck, but I don't think it's going to happen, because one of the big reasons Electron is popular is because web-dev people don't want to learn other languages.
I'd love to learn other languages and stacks! It's just that, often, it isn't a worthy use of my time. All that time used into learning C++ and Qt would be better used in making and improving my software.
This is even more impactful when hiring people. I'm building a small team that has to handle Web development, mobile apps, and someday a desktop app. The less different skills I need for all of this, the more cost-effective it will be.
Personally, I'd rather have ultra-fast, spartan-looking, as-efficient-as-possible apps. If I could choose just by heart, I'd code in Lisp, and probably I wouldn't even make GUIs and just make CLI apps. Sadly, programming is not only a hobby and I have to consider my business needs before my technical preferences.
Engineering isn't about picking the best, most perfect technologies, but about handling trade-offs. Many are using web tecnologies because of the fads, and some out of lazyness, but many (i'd guess most) are doing it because it's worth it.
"I'd love to learn other languages and stacks! It's just that, often, it isn't a worthy use of my time. All that time used into learning C++ and Qt would be better used in making and improving my software."
This line of thinking, that it's not worth your time to learn tools that would improve your software, and make it less resource intensive, is a large reason for that trope.
"Many are using web tecnologies because of the fads, and some out of lazyness, but many (i'd guess most) are doing it because it's worth it."
I can't agree with this, mainly because, it's not worth it. It doesn't improve the software in any way; if anything, it makes it worse.
The longer i deal with computers the more brittle the Python ecosystem appears to be.
Yes it may be a wonderful language, but it seems so damned easy to get the interpreter to not find libraries that should by all accounts be right damn there in its search path.
I'm really curious why anyone would want to do this. You'll almost surely arrive at something equally slow and awkward as Electron, but without the cutting edge interpreter, accessibility, or text support...
Chromes rendering engine is objectively better than Qt's for an awful lot of things.
What you may win back is a gig of ram that wasn't really being used anyways...
I am happy you found something that worked for you. But to me, I'm just very frustrated. People consistently suggest Qt is a net good because Electron uses more RAM and just totally abandon accessibility. The proliferation of Electron is one of the single most progressive things to happen on the front of general desktop application accessibility for folks with special visual or motor control needs since OS's started addressing these needs directly
But congrats now we can run 2 tabbed text editor instances at once. Because for some crazy reason we're going to pretend Electron apps aren't competitive on $30 computers but IntelliJ is immune to criticism.
On a more emotional and personal level, in my entire time using linux since 1995, I've never once used a Qt app I liked. I wrote them professionally, and I hated each one and felt ashamed of the outputs.
To me, to then layer Python on top is like taking stale bread and slathering on that curiously pale, overly sweet peanut butter that they use on airlines. It's quite possibly the most Nope thing you could say other than, "Oh and also we embedded an APL interpreter and you'll need to write C++ circa 1995 for memory management."
This blogger specifically mentions the JAWS screen reader, but this should also help users of the Narrator screen reader built into Windows.
Speaking of which, Electron is not very accessible with Narrator. The reason is that Chromium implements IAccessible2, a non-Microsoft extension of the old Microsoft Accessibility API. Since IA2 is not a Microsoft API, Narrator doesn't support it.
Also, one of my blind friends told me a few months ago that Electron apps are inaccessible on Linux. I haven't yet verified this myself. Qt is accessible on Linux, though I don't know how it compares with GTK.
I've seen folks with readers on Chrome on Linux. I don't mean to imply that Electron magically providers full accessibility; just that the underlying engine has much more robust support not only for readers and navigators (to which there is a ceiling folks aspire to), but also for auditing.
It's not really possible for developers to understand the full extend of accessibility needs unless they experience it themselves. As such, Electron and Chrome's accessibility auditing tools that capture these needs are an incredible step forwards.
As for Narrator, I think historically folks have been somewhat inclined to use third party or direct integration tools because it was widely considered to be inferior to the capabilities provided by direct integrations like ChromeVox or Apple's (superior) Voice Over (which from all reports I get and can find casually searching, works as well as Safari if not better).
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.
[0]: https://www.ceondo.com/ecte/2016/04/chemeo-studio-explore/