
Show HN: Cross-platform desktop applications with PyQT - mherrmann
https://github.com/mherrmann/fbs
======
Loic
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
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?

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

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

~~~
snerbles
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
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
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
When the "good Desktop development framework" is primarily in javascript, it's
a good signal.

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

~~~
throwawayfinal
I would expect that apache and lighttpd are hosted in their respective
projects; linux is used to run linux.com servers, etc.

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

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

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

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

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

~~~
jakelazaroff
_> Pretty animations? I don't need those; in fact they're distracting and
annoying._

Animations are an important tool for showing transitions between states.

Pasquale D'Silva has a bunch of good blog posts explaining how they can help
an interface:

\- [https://medium.com/@pasql/transitional-
interfaces-926eb80d64...](https://medium.com/@pasql/transitional-
interfaces-926eb80d64e3)

\- [https://medium.com/elepath-exports/spatial-
interfaces-886bcc...](https://medium.com/elepath-exports/spatial-
interfaces-886bccc5d1e9)

------
marclave
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=1D733SdbUvGsGvct8jdGqJ3R9iJ...](https://drive.google.com/open?id=1D733SdbUvGsGvct8jdGqJ3R9iJxeMyvW)
[3]
[https://github.com/UVicFH/infotainment](https://github.com/UVicFH/infotainment)

~~~
oneweekwonder
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
That's funny, I've never heard anyone pronounce it 'cute'. (anecdotal, maybe
~20 developers so far)

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

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

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

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

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

~~~
dijit
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?

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

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

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

~~~
mherrmann
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/)

------
wilsonfiifi
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/

------
jordigh
> 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
Do you have a source for the PC-BSD assertion?

------
billsix
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
Could you elaborate, or have a link handy?

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

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

------
andrewstuart
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
I would still prefer to have native apps, instead of spending 400MB per
application.

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

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

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

~~~
systems
and another option use Tcl/Tk, or just Tk with your language of choice:
[http://www.tkdocs.com](http://www.tkdocs.com)

~~~
Buttons840
How is the themeability of Tk? Can I make it look good? What's the best
looking Tk app you're aware of?

~~~
sli
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)

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

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

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

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

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

------
_raoulcousins
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
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/cb0d57e59c9fecf24fb281...](https://github.com/mherrmann/fbs/blob/cb0d57e59c9fecf24fb28104ea52f4837f49c892/fbs/freeze/windows.py#L32)

------
jubjubbird
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
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/cb0d57e59c9fecf24fb281...](https://github.com/mherrmann/fbs/blob/cb0d57e59c9fecf24fb28104ea52f4837f49c892/fbs/freeze/windows.py#L32)

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

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

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

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

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

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

~~~
nabla9
Here is an example of modern UI build with Qt:

[https://www.youtube.com/watch?v=f7en65HkjeQ&t=39](https://www.youtube.com/watch?v=f7en65HkjeQ&t=39)

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

~~~
jcelerier
> 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...](https://github.com/jcelerier/TodoMVC-
QML/blob/master/Main.qml) ; as you can see, it's far from bloated (mostly due
to the language being based on reactive semantics).

For instance a consequent part of KDE has been rewritten in QML and more is
underway with Kirigami : [https://dot.kde.org/2017/01/12/kde-releases-
kirigami-ui-20](https://dot.kde.org/2017/01/12/kde-releases-kirigami-ui-20)

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

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

These certainly were troubled times, but KDE5 is honestly really nice. See the
latest release
[https://www.kde.org/announcements/plasma-5.12.0.php](https://www.kde.org/announcements/plasma-5.12.0.php)

> 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

www.reddit.com/r/unixporn

------
eivarv
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?

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

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

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

~~~
ikurei
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_
"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.

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

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

------
KirinDave
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
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-...](https://fman.io/blog/picking-technologies-for-a-desktop-app-in-2016/)

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

~~~
mwcampbell
Thank you for caring about accessibility. However, I don't think the pros and
cons between Qt and Electron are as straightforward as you may think.

First, Qt accessibility on Windows is improving:

[https://blind.guru/qtwin.html](https://blind.guru/qtwin.html)

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 don't know what the situation is on Mac.

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

