
Thoughts on the future of Python and graphical interfaces - sebg
https://medium.com/@tryexceptpass/a-python-ate-my-gui-971f2326ce59#.r71wrkqfq
======
throwaway13337
This article only talks about one aspect of the larger problem in UI
Development - the webification of everything.

It's good that we've finally been able to agree on a common set of tools to
make UIs, it's just too bad it had to be this one.

The HTML/JS/CSS/DOM mess is a pretty terrible solution that we seem to be
stuck with.

History is peppered with UI authoring tools that were better but stewarded by
companies that held to tight licensing that stunted their growth. Hypercard,
delphi, adobe flash (and FLEX - which looks a lot like react), even unity has
more intuitive wysiwyg UI tools that could have proved versatile with the
right stewardship.

The difference is vertical integration. These companies made their tools
complete solutions and often went so far as to put virtual machines on
everything to interpret them correctly every time.

The article's author touches on the license problem with python's own pretty
damn good QT lib.

If only someone could find a way to make a good tool without fucking up
licensing.

~~~
ThomPete
I actually believe that the HTML/JS/CCS/DOM mess is a good thing and that it's
a pretty powerful combination that rivals other more powerful languages in 90%
of the cases for the kind of applications one might want to build.

HTML is actually one of the most powerful layout engines out there, Javascript
is as versatile and powerful a language as you might want to ask for in 90% of
the cases, CSS has it's flaws but they are being addressed and is fine for
most styling issues and DOM is just a very easy to understand albeit crude way
to handle objects.

All in all a combination of tools that makes it extremely easy to get started
and se results right away. I believe this is also on of the reasons why PHP is
so popular. It's ability to seamlessly integrate with that "mess" either to
take over the formatting or to fit into the existing formatting.

It's a conceptual framework thats closest to what we as humans understand.

Pythons problem like most other programming languages including Objective-C
and Ruby is that while they are elegant and powerful computationally they are
horrible for most people to get started with because just setting it up in
itself is a big task.

So I don't think we are stuck. In fact I believe that if Python would take the
same laize faire approach to the mess as PHP it would be much more popular
than it is today.

~~~
gaius
You know, if MS had written Outlook in VBA and told people to read their email
as a plugin to Word, they would have been laughed out of the room. But that's
exactly what Google did with GMail and now everyone builds apps that way!
Browsers are for documents, and forcing applications to be interactive
documents is, when you look at it like that, ludicrous.

~~~
91bananas
Luckily turns out it isn't 1995 anymore. Browsers let you do stuff, pretty
cool stuff last time I checked, sometimes it's play video, sometimes it's read
a document, other times it is to create tangible things.

~~~
gaius
You can embed a video in a Word doc too. I don't know anyone who watches
movies like that.

~~~
ThomPete
Not sure what your point is gaius. Care to elaborate?

~~~
PeCaN
I'll bite: Wrong tool for the job, just like using a scriptable remote
document viewer as an application platform.

~~~
ThomPete
That make no sense since the web is successfully used for many other things
than reading document.s

------
nzjrs
I would suggest everyone check out remi, which feels like a desktop UI library
and renders in the browser
[https://github.com/dddomodossola/remi](https://github.com/dddomodossola/remi)

~~~
analog31
I like it.

Any idea what effort it would take to integrate MatPlotLib graphs?

~~~
nzjrs
Check the examples. Integration with js graphing is being worked on (mpl or
plotly, I'm undecided)

~~~
analog31
Indeed, I checked it out today. Way cool.

------
simula67
I would like to see more discussion about the speed of Python for user facing
applications. Users can perceive delays of upto 100ms (
[http://stackoverflow.com/questions/536300/what-is-the-
shorte...](http://stackoverflow.com/questions/536300/what-is-the-shortest-
perceivable-application-response-delay) ).

# time yum

real 0m2.147s

user 0m1.276s

sys 0m0.772s

# time apt-get

0.00s user

0.00s system 91% cpu

0.004 total

~~~
andybak
I'm not sure you can throw the 100ms figure around without context - and
especially not when making the jump to discussing console applications. The
psychology of button clicking is very different to the psychology of command
typing.

~~~
simula67
It is true that console applications would have different constraints. But GUI
applications written in Python, like 'Ubuntu Software Center', were also
perceptibly slow last time I checked. yum vs apt-get was a quick comparison I
could show. I find yum very annoying compared to apt-get/pacman.

The author wants more Pythonic GUI apps because s/he thinks it produces more
readable code. It has been argued that such code can be slower (
[http://lukauskas.co.uk/articles/2014/02/13/why-your-
python-r...](http://lukauskas.co.uk/articles/2014/02/13/why-your-python-runs-
slow-part-1-data-structures/) ) and maybe it will lead to trading too much
developer pleasure for user pleasure.

~~~
andybak
> maybe it will lead to trading too much developer pleasure for user pleasure.

In many cases - developer time or cost is the constraint. Therefore it might
be the difference between something existing and not existing.

It's a similar argument with 'native vs other' on mobile. Currently native
apps are obviously better in terms of speed and overall quality. However -
much non-native software simply wouldn't exist if there wasn't a rapid, low-
barrier to entry development option.

~~~
TeMPOraL
> _much non-native software simply wouldn 't exist if there wasn't a rapid,
> low-barrier to entry development option_

And the world would be much better if that happened.

Seriously, the primary driver for the "developer-time offset" is the race-to-
the-bottom competition between companies on who releases the app first, driven
by the assumption that in this market the winner takes all. Maybe it is the
case (though my impression is that people tend to gravitate to better software
over time), but then there are markets without such a huge competitive
pressure. Like package managers for Linux-based systems. Seriously, there is
no reason for not doing them right (except of course the Unix philosophy being
that not doing things right is the Right Thing).

~~~
andybak
> Seriously, the primary driver for the [...]

So to summarise - no-one would choose Python for building GUI apps if it
wasn't for the obsession modern companies have with being first-to-market?

If I've been unfair or misunderstood then can you please explain a bit more
clearly how we got from a discussion about using Python for GUI applications
to a statement that it's somehow about commercial pressures to release an app.
It certainly doesn't match my own reasons for learning and using Python or
those of anyone I've met.

~~~
TeMPOraL
I was addressing your mobile / web vs. native angle. In those markets, in my
opinion many of the products, having to choose between being done right or not
being done at all would do better if they chose the second option.

I don't have anything against Python per se. Sure, it isn't the fastest
language out there (even considering the high-level features it provides), but
rarely the problem with application performance lies squarely with Python.
It's more often about not putting time to "make it good" and "make it fast"
after "making it work". Especially with - from what I hear, quite good - FFI
capabilities of Python, in the worst case one could always push the most
intensive computations down to C.

~~~
andybak
Ah. I see. I was conflating your reply with the grandfather.

With regard to mobile apps - I was thinking more about non-commercial or
hobbyist apps - the interesting, quirky or niche.

------
viperscape
Take a look at earl grey lang, specifically document building dsl it has:
[http://www.earl-grey.io/#documentbuilding](http://www.earl-
grey.io/#documentbuilding)

------
aavotins
Quote: "I want to write Python code that spits out the HTML and JavaScript
required for these interfaces and I still want to handle all the logic in
Python."

Substitute Python with PHP and it feels like 2004 again. I think we all agreed
a long time ago that decoupling presentation layer from business logic was a
good thing, no?

~~~
gaius
You can do that with Bokeh.

~~~
andybak
Bokeh has a very interesting approach. It has three levels you can jump
between:

1\. Just write Python and get interactive graphs

2\. Write Python and small snippets of embedded js when (1) is too limiting

3\. Write Python to generate the datasets, and proper javascript via bokeh.js
if you need to dig in deep.

And as the project matures - the number of reasons to jump from 1 to 2 to 3
will become less. I'd like to see a similar approach applied to general UI
development. It's a great example of "make the easy things easy, and the hard
things possible".

------
sethish
> in fact I think the very idea of Django and similar frameworks should go
> away. I find templates cumbersome, hard to read and non-pythonic.

This is incredibly dismissive and hardly a well functioning argument. I don't
like to edit html templates, therefor web frameworks shouldn't exist.

~~~
dfox
I think that the point here is that html templates are oriented towards
writing things that are primarily web sites, and not data-heavy and UI-heavy
applications that happen to use web browser as thin client.

I'm somehow trying to solve this problem by using jinja2 macros to the point
of abuse and by having relatively large amount of python code that handles
generating complex HTML (navigation, tables, forms, widgets...).

~~~
VT_Drew
for tables use [https://github.com/bradleyayers/django-
tables2](https://github.com/bradleyayers/django-tables2)

for forms use [https://github.com/gregmuellegger/django-
floppyforms](https://github.com/gregmuellegger/django-floppyforms)

For navigation just use something like
[http://purecss.io/menus/](http://purecss.io/menus/)

------
hatmatrix
There is something to be said about the UI approach of R's Shiny interface. As
a scientist with limited budget for dedicated IT development, I can focus on
creating the content and the UI can easily be built to access it
functionality.

------
phantom_oracle
Is there another option for building native interfaces that are cross-platform
(let's say desktop for now: so just Linux, Win and OSX)?

Instead of the webapp-as-desktop-app does there exist a language/IDE/tool that
has a friendlier license for building native desktop apps?

~~~
spriggan3
Python supports Gtk+3 and anything that run on GObjects. Let me tell you that
it's quite a lot of libraries you can use from Python. Deluge ( torrent client
is written with Python and Gtk+3 ).

------
spo81rty
What about using Iron Python to make a Windows UI app?

------
Chris2048
What about :
[http://nucleic.github.io/enaml/docs/](http://nucleic.github.io/enaml/docs/)

~~~
infinite8s
Enaml hasn't seen any sustained development since 2014.

------
cafard
wxWindows with PythonCard wasn't at all hard to use, and to my eye looked a
lot better than Tk. But wxWindows looked to be dormant last time I checked.

------
mkj
It seems the author didn't look far if they just said "PyQt, licensing too
hard" (fair enough) without noticing PySide.

~~~
dbcurtis
To be fair, the transition to Qt5 has been a slog for pyside, but momentum
recently picked up now that the Qt team has the resources to support the
effort officially.

------
pbreit
Does anyone have definitive information on how all the Slack clients are
built?

------
voyou
"I want to write Python code that spits out the HTML and JavaScript required
for these interfaces and I still want to handle all the logic in Python."

This sounds a lot like PyJS: [http://pyjs.org/](http://pyjs.org/)

~~~
jventura
I used pyjs (pyjamas) for some personal projects and I liked it a lot.
Unfortunately it got stuck in time, and in 2012 the current maintainers did a
bad political move, and left the project in even worse shape than it was.

Nowadays, I wouldn't consider pyjs to build anything relevant..

------
microcolonel
Without a miracle, it seems like a bit of a lost cause.

I see some pretty glaring reasons why Python has not taken off in writing
GUIs, especially on mobile.

1\. The Python runtime is not very easy to embed on iOS and Android, and the
sheer number of bindings needed to make it worth doing is immense.

2\. Python's runtime is completely and utterly incapable of threading.
Threading being almost essential to any decent user interface, this whole idea
falls flat.

3\. If the other two problems weren't enough, Python's single-threaded
performance is really not great either. On resource-constrained systems (think
phones) this hits doubly hard.

~~~
matjazzz
I wouldn't agree on points 2 and 3. I find multiprocessing routines really
easy to implement and they work as they should. However, I have no experience
with threading in other languages so I might be missing out ...

With regards to performance, I found that one can produce very fast routines
through use of specialized libraries for specific tasks, such as numpy etc.
There are also great visualization tools, such as pyqtgraph which are blazing
fast, at least, in my view, compared to any web interface. I have been
skeptical about the html/js interface so far, because I am concerned with how
fast large amounts of data can be surfaced from Python data models to HTML
plots.

That said, I share the Python UI pain :/ As of now, I am stuck with QT and
cx_freeze for desktop app development and the whole thing feels very medieval.
The QT library in itself is great but at the same time it does not feel very
"python". cx_freeze requires constant tinkering and makes debugging very hard
at times.

What do HN users use for building GUIs for Python? :)

~~~
nzjrs
I use gtk via pygobject. I find it feels the most pythonic. Cross platform
remains difficult however.

~~~
infinite8s
While it feels more pythonic, it does not look at all native on most
platforms.

