18 ms·

Show HN: Cross-platform desktop applications with PyQT

315 points by mherrmann 9y ago

deleted 9y ago
[deleted]
wiremine 9y ago
Not directly related to the initiative itself, but comparing and contrasting the Electron website vs. PyQT is striking: https://riverbankcomputing.com/software/pyqt/intro https://riverbankcomputing.com/software/pyqt/intro https://electronjs.org/ https://electronjs.org/ I've been a (proud) Pythonist for years now, and I've always been a bit chagrined by the quality of the "marketing" of Python projects. It doesn't at all reflect the quality of the community and the projects.
- monkmartinez 9y ago
  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.
- snerbles 9y ago
  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.
  - throwawayfinal 9y ago
    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.
    - camgunz 9y ago
      I get what you're saying, but "writes good web front end code" isn't on my list when I'm looking for a good Desktop development framework. I think stuff like this is pretty tribal, which is OK, but we should confuse it with decisions made on technical or experience merits.
      - throwawayfinal 9y ago
        When the "good Desktop development framework" is primarily in javascript, it's a good signal.
        camgunz 9y ago
        There are a lot of counter-examples: - 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".
        deleted 9y ago
        [deleted]
        throwawayfinal 9y ago
        I would expect that apache and lighttpd are hosted in their respective projects; linux is used to run linux.com servers, etc.
        camgunz 9y ago
        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.
  - darpa_escapee 9y ago
    As a developer consuming the PyQT API, explanations of internals have come in handy.
- ThePhysicist 9y ago
  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: https://www.qt.io/ https://www.qt.io/ 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).
  - Klonoar 9y ago
    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.
    - TomMarius 9y ago
      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.
- djsumdog 9y ago
  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?
  - snerbles 9y ago
    We want that, but we are the minority. 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.
    - flukus 9y ago
      > It is, however, a terrible page for attracting new developers and selling decision makers on the idea of using it. Would that be attracting people that are worth attracting though? Just like in business, not all customers are worth having.
      - wiremine 9y ago
        Man, I'd hope so. Good engineers in this space tend to have a sense of style, IMHO.
      - solarkraft 9y ago
        This is a personal decision I'm fine with - but that's not how your project gets adopted.
    - wiremine 9y ago
      > a terrible page for attracting new developers 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.
- tclancy 9y ago
  Aw, but it appears to be run by Trac and that always gives me flashbacks to the good old days.
- mixmastamyk 9y ago
  Its 15 years older.
  - oblio 9y ago
    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.
    - mixmastamyk 9y ago
      A lot of the wind went to the web resulting in a lot of churn there. Think of this as the LTS. Or, in other words, if it ain’t broke, don’t fix it.
- gkya 9y ago
  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.
  - solarkraft 9y ago
    I like a polished website, but technical info ultimately drives decisions.
_em6m 9y ago
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...
- mi100hael 9y ago
  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.
  - toyg 9y ago
    > 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.
  - WorldMaker 9y ago
    Some of the same applications are also cross-targeting mobile with Cordova, and/or are already or are working to become PWAs.
- mherrmann 9y ago
  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.
  - alexandernst 9y ago
    Please read in between lines... I could easy write any other example. Don't make me compare HTML/CSS's flexibility with Qt's...
marclave 9y ago
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! [1] https://github.com/qt-labs/photoshop-qmlexporter https://github.com/qt-labs/photoshop-qmlexporter [2] https://drive.google.com/open?id=1D733SdbUvGsGvct8jdGqJ3R9iJxeMyvW https://drive.google.com/open?id=1D733SdbUvGsGvct8jdGqJ3R9iJ... [3] https://github.com/UVicFH/infotainment https://github.com/UVicFH/infotainment
- oneweekwonder 9y ago
  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”. [0]: https://ariya.io/2009/01/qt-not-qt https://ariya.io/2009/01/qt-not-qt
  - stagger87 9y ago
    That's funny, I've never heard anyone pronounce it 'cute'. (anecdotal, maybe ~20 developers so far)
    - oneweekwonder 9y ago
      True, and I was pedantic to reply. Last week someone else on hn did the same; and I kept quite. Unfortunately this time I could not stop the graybeard in me.
andrewstuart 9y ago
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.
- xfer 9y ago
  I would still prefer to have native apps, instead of spending 400MB per application.
- pjmlp 9y ago
  That is what Microsoft is doing with PWAs packaged as UWP apps.
Haitischmock 9y ago
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)
- WorldMaker 9y ago
  Some Electron apps do use things like caches of Chromium/v8 binary memory states to speed startup.
- ricardobeat 9y ago
  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.
jordigh 9y ago
> 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.
- pacifika 9y ago
  Do you have a source for the PC-BSD assertion?
monkmartinez 9y ago
> "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.
- mherrmann 9y ago
  > Except this sucks if, you know, you want to make some money on your app... Why is that a problem? You get a commercial license for PyQt and are good to go(?) > I love Python, but it has stagnated hard in the last few years. The 2 to 3 transition really hurt the Python ecosystem [...] I disagree. I think the ecosystem is more vibrant than ever. > Furthermore, packaging for different platforms is still a problem in 2018. That is exactly what this project is trying to help with.
  - monkmartinez 9y ago
    $500 dollars... is "not expensive"? 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.
    - mherrmann 9y ago
      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. [1]: https://fman.io https://fman.io
monkmartinez 9y ago
It costs $500 for a commercial license for PyQT!!!!!!! That is super welcoming for people that want to run more than CLI in 2018! /s
- ThePhysicist 9y ago
  You can develop commercial apps with PyQT, your code just needs to be compatible with the GPL3 license (https://www.riverbankcomputing.com/commercial/pyqt https://www.riverbankcomputing.com/commercial/pyqt). PyQT is not different from any other dual-licensed open-source project in that sense.
  - mherrmann 9y ago
    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. [1]: https://fman.io https://fman.io
wiz21c 9y ago
HTML/CSS is nice to display information. Now if you have to input data, then HTML/FORMS/etc. are not that good...
- Klonoar 9y ago
  This is... very far from the truth. 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.
  - wiz21c 9y ago
    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.
Loic 9y ago
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. [0]: https://www.ceondo.com/ecte/2016/04/chemeo-studio-explore/ https://www.ceondo.com/ecte/2016/04/chemeo-studio-explore/
- makecheck 9y ago
  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?
  - danieldk 9y ago
    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’).
  - Loic 9y ago
    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.
- 9y ago
deleted 9y ago
[deleted]
s73ver_ 9y ago
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.
- mherrmann 9y ago
  It doesn't have to be an either-or. Some projects will be better built with Electron. Others with PyQt. They can coexist perfectly well.
- ikurei 9y ago
  This trope makes me quite sad... 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.
  - s73ver_ 9y ago
    "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.
dvfjsdhgfv 9y ago
There is another option, far easier to use: Lazarus.
- systems 9y ago
  and another option use Tcl/Tk, or just Tk with your language of choice: http://www.tkdocs.com http://www.tkdocs.com
  - Buttons840 9y ago
    How is the themeability of Tk? Can I make it look good? What's the best looking Tk app you're aware of?
    - sli 9y ago
      I was curious as well and found this: https://wiki.tcl.tk/9485 https://wiki.tcl.tk/9485 I don't have an answer to your questions, but it's at least somewhere to start looking. E: Most of the links are broken. This one is a bit better, but it's Windows-specific: https://wiki.tcl.tk/8646 https://wiki.tcl.tk/8646
- peatmoss 9y ago
  Racket has a cross-platform GUI framework that wraps the appropriate native UI elements. https://docs.racket-lang.org/framework/index.html https://docs.racket-lang.org/framework/index.html
scotty79 9y ago
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).
butz 9y ago
With PWAs coming to desktop, "Electron problem" will be solved this year.
KirinDave 9y ago
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...
- mherrmann 9y ago
  In my case, it was Electron's startup performance that made me go for PyQt [1]. [1]: https://fman.io/blog/picking-technologies-for-a-desktop-app-in-2016/ https://fman.io/blog/picking-technologies-for-a-desktop-app-...
  - KirinDave 9y ago
    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 Let's just contrast and compare: The ENTIRE story for Qt accessibility is tree navigation, with trust that readers exist: http://doc.qt.io/qt-5/accessible-qwidget.html http://doc.qt.io/qt-5/accessible-qwidget.html Meanwhile Electron has an auditing tool for a wide range of accessibility requirements which also explains how you can fix the problems: https://github.com/electron/spectron#accessibility-testing https://github.com/electron/spectron#accessibility-testing 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."
wilsonfiifi 9y ago
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? [0] https://sciter.com/ [1] https://sciter.com/developers/sciter-sdk-bindings/ [2] https://sciter.com/prices/
eivarv 9y ago
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?
- Kalium 9y ago
  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!
  - zamber 9y ago
    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. I guess there's a method in this madness.
- digi_owl 9y ago
  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.
darreld 9y ago
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.
Klonoar 9y ago
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.
digi_owl 9y ago
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.
ihnorton 9y ago
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.
- pritambaral 9y ago
  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.
  - ihnorton 9y ago
    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).
  - mherrmann 9y ago
    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. [1]: https://fman.io/blog/google-omaha-tutorial/ https://fman.io/blog/google-omaha-tutorial/
_raoulcousins 9y ago
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?
- mherrmann 9y ago
  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]. [1]: https://github.com/mherrmann/fbs/blob/cb0d57e59c9fecf24fb28104ea52f4837f49c892/fbs/freeze/windows.py#L32 https://github.com/mherrmann/fbs/blob/cb0d57e59c9fecf24fb281...
guhcampos 9y ago
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.
- loftyal 9y ago
  Could you give me some examples of "Computer Science has had "had tools for the right jobs"". Thanks
  - mattgreenrocks 9y ago
    SQL comes to mind here.
    - guhcampos 9y ago
      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.
- geofft 9y ago
  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.)
jubjubbird 9y ago
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?
- mherrmann 9y ago
  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. [1]: https://github.com/mherrmann/fbs/blob/cb0d57e59c9fecf24fb28104ea52f4837f49c892/fbs/freeze/windows.py#L32 https://github.com/mherrmann/fbs/blob/cb0d57e59c9fecf24fb281...
mhd 9y ago
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.
deleted 9y ago
[deleted]
jimnotgym 9y ago
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.
- pfranz 9y ago
  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.
  - jimnotgym 9y ago
    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.
billsix 9y ago
Immediate mode graphical user interfaces have changed the way I look at GUI programming for the better. Here are my bindings to python for the nuklear framework. https://github.com/billsix/pyNuklear https://github.com/billsix/pyNuklear
- mixmastamyk 9y ago
  Could you elaborate, or have a link handy?
  - billsix 9y ago
    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.
dilap 9y ago
I made a few apps with PyQT. I certainly wouldn't do it again.
solarkraft 9y ago
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.
wnsire 9y ago
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.

315 points by mherrmann 9y ago

deleted 9y ago

[deleted]

Not directly related to the initiative itself, but comparing and contrasting the Electron website vs. PyQT is striking: https://riverbankcomputing.com/software/pyqt/intro https://riverbankcomputing.com/software/pyqt/intro https://electronjs.org/ https://electronjs.org/ I've been a (proud) Pythonist for years now, and I've always been a bit chagrined by the quality of the "marketing" of Python projects. It doesn't at all reflect the quality of the community and the projects.

monkmartinez 9y ago
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.
snerbles 9y ago
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.
- throwawayfinal 9y ago
  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.
  - camgunz 9y ago
    I get what you're saying, but "writes good web front end code" isn't on my list when I'm looking for a good Desktop development framework. I think stuff like this is pretty tribal, which is OK, but we should confuse it with decisions made on technical or experience merits.
    - throwawayfinal 9y ago
      When the "good Desktop development framework" is primarily in javascript, it's a good signal.
      - camgunz 9y ago
        There are a lot of counter-examples: - 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".
        deleted 9y ago
        [deleted]
        throwawayfinal 9y ago
        I would expect that apache and lighttpd are hosted in their respective projects; linux is used to run linux.com servers, etc.
        camgunz 9y ago
        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.
- darpa_escapee 9y ago
  As a developer consuming the PyQT API, explanations of internals have come in handy.
ThePhysicist 9y ago
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: https://www.qt.io/ https://www.qt.io/ 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).
- Klonoar 9y ago
  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.
  - TomMarius 9y ago
    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.
djsumdog 9y ago
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?
- snerbles 9y ago
  We want that, but we are the minority. 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.
  - flukus 9y ago
    > It is, however, a terrible page for attracting new developers and selling decision makers on the idea of using it. Would that be attracting people that are worth attracting though? Just like in business, not all customers are worth having.
    - wiremine 9y ago
      Man, I'd hope so. Good engineers in this space tend to have a sense of style, IMHO.
    - solarkraft 9y ago
      This is a personal decision I'm fine with - but that's not how your project gets adopted.
  - wiremine 9y ago
    > a terrible page for attracting new developers 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.
tclancy 9y ago
Aw, but it appears to be run by Trac and that always gives me flashbacks to the good old days.
mixmastamyk 9y ago
Its 15 years older.
- oblio 9y ago
  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.
  - mixmastamyk 9y ago
    A lot of the wind went to the web resulting in a lot of churn there. Think of this as the LTS. Or, in other words, if it ain’t broke, don’t fix it.
gkya 9y ago
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.
- solarkraft 9y ago
  I like a polished website, but technical info ultimately drives decisions.

_em6m 9y ago

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...

mi100hael 9y ago
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.
- toyg 9y ago
  > 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.
- WorldMaker 9y ago
  Some of the same applications are also cross-targeting mobile with Cordova, and/or are already or are working to become PWAs.
mherrmann 9y ago
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.
- alexandernst 9y ago
  Please read in between lines... I could easy write any other example. Don't make me compare HTML/CSS's flexibility with Qt's...

marclave 9y ago

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! [1] https://github.com/qt-labs/photoshop-qmlexporter https://github.com/qt-labs/photoshop-qmlexporter [2] https://drive.google.com/open?id=1D733SdbUvGsGvct8jdGqJ3R9iJxeMyvW https://drive.google.com/open?id=1D733SdbUvGsGvct8jdGqJ3R9iJ... [3] https://github.com/UVicFH/infotainment https://github.com/UVicFH/infotainment

oneweekwonder 9y ago
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”. [0]: https://ariya.io/2009/01/qt-not-qt https://ariya.io/2009/01/qt-not-qt
- stagger87 9y ago
  That's funny, I've never heard anyone pronounce it 'cute'. (anecdotal, maybe ~20 developers so far)
  - oneweekwonder 9y ago
    True, and I was pedantic to reply. Last week someone else on hn did the same; and I kept quite. Unfortunately this time I could not stop the graybeard in me.

andrewstuart 9y ago

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.

xfer 9y ago
I would still prefer to have native apps, instead of spending 400MB per application.
pjmlp 9y ago
That is what Microsoft is doing with PWAs packaged as UWP apps.

Haitischmock 9y ago

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)

WorldMaker 9y ago
Some Electron apps do use things like caches of Chromium/v8 binary memory states to speed startup.
ricardobeat 9y ago
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.

jordigh 9y ago

> 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.

pacifika 9y ago
Do you have a source for the PC-BSD assertion?

monkmartinez 9y ago

> "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.

mherrmann 9y ago
> Except this sucks if, you know, you want to make some money on your app... Why is that a problem? You get a commercial license for PyQt and are good to go(?) > I love Python, but it has stagnated hard in the last few years. The 2 to 3 transition really hurt the Python ecosystem [...] I disagree. I think the ecosystem is more vibrant than ever. > Furthermore, packaging for different platforms is still a problem in 2018. That is exactly what this project is trying to help with.
- monkmartinez 9y ago
  $500 dollars... is "not expensive"? 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.
  - mherrmann 9y ago
    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. [1]: https://fman.io https://fman.io

monkmartinez 9y ago

It costs $500 for a commercial license for PyQT!!!!!!! That is super welcoming for people that want to run more than CLI in 2018! /s

ThePhysicist 9y ago
You can develop commercial apps with PyQT, your code just needs to be compatible with the GPL3 license (https://www.riverbankcomputing.com/commercial/pyqt https://www.riverbankcomputing.com/commercial/pyqt). PyQT is not different from any other dual-licensed open-source project in that sense.
- mherrmann 9y ago
  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. [1]: https://fman.io https://fman.io

wiz21c 9y ago

HTML/CSS is nice to display information. Now if you have to input data, then HTML/FORMS/etc. are not that good...

Klonoar 9y ago
This is... very far from the truth. 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.
- wiz21c 9y ago
  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.

Loic 9y ago

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. [0]: https://www.ceondo.com/ecte/2016/04/chemeo-studio-explore/ https://www.ceondo.com/ecte/2016/04/chemeo-studio-explore/

makecheck 9y ago
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?
- danieldk 9y ago
  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’).
- Loic 9y ago
  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.
9y ago

deleted 9y ago

[deleted]

s73ver_ 9y ago

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.

mherrmann 9y ago
It doesn't have to be an either-or. Some projects will be better built with Electron. Others with PyQt. They can coexist perfectly well.
ikurei 9y ago
This trope makes me quite sad... 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.
- s73ver_ 9y ago
  "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.

dvfjsdhgfv 9y ago

There is another option, far easier to use: Lazarus.

systems 9y ago
and another option use Tcl/Tk, or just Tk with your language of choice: http://www.tkdocs.com http://www.tkdocs.com
- Buttons840 9y ago
  How is the themeability of Tk? Can I make it look good? What's the best looking Tk app you're aware of?
  - sli 9y ago
    I was curious as well and found this: https://wiki.tcl.tk/9485 https://wiki.tcl.tk/9485 I don't have an answer to your questions, but it's at least somewhere to start looking. E: Most of the links are broken. This one is a bit better, but it's Windows-specific: https://wiki.tcl.tk/8646 https://wiki.tcl.tk/8646
peatmoss 9y ago
Racket has a cross-platform GUI framework that wraps the appropriate native UI elements. https://docs.racket-lang.org/framework/index.html https://docs.racket-lang.org/framework/index.html

scotty79 9y ago

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).

butz 9y ago

With PWAs coming to desktop, "Electron problem" will be solved this year.

KirinDave 9y ago

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...

mherrmann 9y ago
In my case, it was Electron's startup performance that made me go for PyQt [1]. [1]: https://fman.io/blog/picking-technologies-for-a-desktop-app-in-2016/ https://fman.io/blog/picking-technologies-for-a-desktop-app-...
- KirinDave 9y ago
  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 Let's just contrast and compare: The ENTIRE story for Qt accessibility is tree navigation, with trust that readers exist: http://doc.qt.io/qt-5/accessible-qwidget.html http://doc.qt.io/qt-5/accessible-qwidget.html Meanwhile Electron has an auditing tool for a wide range of accessibility requirements which also explains how you can fix the problems: https://github.com/electron/spectron#accessibility-testing https://github.com/electron/spectron#accessibility-testing 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."

wilsonfiifi 9y ago

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? [0] https://sciter.com/ [1] https://sciter.com/developers/sciter-sdk-bindings/ [2] https://sciter.com/prices/

eivarv 9y ago

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?

Kalium 9y ago
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!
- zamber 9y ago
  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. I guess there's a method in this madness.
digi_owl 9y ago
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.

darreld 9y ago

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.

Klonoar 9y ago

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.

digi_owl 9y ago

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.

ihnorton 9y ago

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.

pritambaral 9y ago
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.
- ihnorton 9y ago
  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).
- mherrmann 9y ago
  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. [1]: https://fman.io/blog/google-omaha-tutorial/ https://fman.io/blog/google-omaha-tutorial/

_raoulcousins 9y ago

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?

mherrmann 9y ago
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]. [1]: https://github.com/mherrmann/fbs/blob/cb0d57e59c9fecf24fb28104ea52f4837f49c892/fbs/freeze/windows.py#L32 https://github.com/mherrmann/fbs/blob/cb0d57e59c9fecf24fb281...

guhcampos 9y ago

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.

loftyal 9y ago
Could you give me some examples of "Computer Science has had "had tools for the right jobs"". Thanks
- mattgreenrocks 9y ago
  SQL comes to mind here.
  - guhcampos 9y ago
    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.
geofft 9y ago
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.)

jubjubbird 9y ago

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?

mherrmann 9y ago
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. [1]: https://github.com/mherrmann/fbs/blob/cb0d57e59c9fecf24fb28104ea52f4837f49c892/fbs/freeze/windows.py#L32 https://github.com/mherrmann/fbs/blob/cb0d57e59c9fecf24fb281...

mhd 9y ago

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.

deleted 9y ago

[deleted]

jimnotgym 9y ago

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.

pfranz 9y ago
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.
- jimnotgym 9y ago
  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.

billsix 9y ago

Immediate mode graphical user interfaces have changed the way I look at GUI programming for the better. Here are my bindings to python for the nuklear framework. https://github.com/billsix/pyNuklear https://github.com/billsix/pyNuklear

mixmastamyk 9y ago
Could you elaborate, or have a link handy?
- billsix 9y ago
  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.

dilap 9y ago

I made a few apps with PyQT. I certainly wouldn't do it again.

solarkraft 9y ago

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.

wnsire 9y ago

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.