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.
The licensing issue with PyQt is very simple: it's the main source of revenue for Riverbank, a small UK company founded by PyQt's author, Phil Thompson. He can't give it away for free because it's literally his livelihood. He does a great job of evolving and updating the wrappers -- just ask how "easy" that is to the PySide authors, which are supposed to do the same job and have been struggling (technically and financially) ever since their project lost "free money" when Nokia died.
The licensing for Qt itself is very simple: if you redistribute and don't go GPL, you have to pay. It's one of the fairest arrangements out there. PyQt has similar terms.
The situation for Qt has changed several times in the last few years through the various acquisitions, so yeah, I might be a bit out of date because it doesn't really matter for PyQt itself -- that's just GPL or commercial.
Exactly. The LGPL (which Qt is licensed under) permits this. It also permits subclassing. What toyg wrote would be true if Qt were licensed under the GPL.
Qt is under the LGPL, but PyQt isn't. So if you want to develop Qt applications with python and PyQt you have to abide by the GPL, not just the LGPL, or buy a commercial license.
And, PyQt works great! I've been playing around with the QOpenGLWidget lately, which not only integrates beautifully with the rest of Qt, but also makes it really easy to write and use a shader program. It's a shame, although not at all surprising, that the few decent online tutorials for modern OpenGL go the C++ / GLEW route. The barrier to entry with PyQt is so much lower!
Not at all. I used adobe's toolset for flash. Even if flash was open source completely, I'm sure the authoring tool would have been still nearly required.
Keeping the underlying language open simply means that it would have been more usable and extensible.
Ok. I don't know anything about PyQt so if you tell me that the dual license arrangement prevents you from using and extending it, despite your willingness to pay, I'll take your word for it.
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.
> HTML is actually one of the most powerful layout engines out there
But it's terribly verbose and isn't extensible. XML was extensible, but even more verbose.
Also, I wouldn't say that HTML is a layout engine; CSS is the layout engine while HTML denotes the structure to be laid out.
> Javascript is as versatile and powerful a language as you might want to ask for in 90% of the cases
Erm, no. It's a terrible little language with some horrible misfeatures (==/===, {} &c.) which has one virtue: near-universal deployment.
> DOM is just a very easy to understand albeit crude way to handle objects
I've never really thought the DOM was all that easy to understand. Attributes vs. nodes, text nodes in unexpected places — it's a mess compared to a nice tree of strings and trees would be.
> It's a conceptual framework thats closest to what we as humans understand.
No, it's the conceptual framework we ended up with, so we all have taught ourselves and been taught to understand it.
> 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.
sudo apt-get install python
python
Python 2.7.9 (default, Mar 1 2015, 12:57:24)
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> "hello world"
'hello world'
>>>
I kind of agree with both of your points regarding python. It is easy to set up for technologically literate people. But just using a web browser is orders of magnitude simpler for the majority. But really they're two different beasts and I don't think it's fair to compare python with a web browser in terms of "ease of set up".
Simpler for which majority? Aren't we talking about developers here, not the technically illiterate?
Learning 1 single (and relatively simple) language vs HTML/CSS for presentation (and all its headaches) and JS for logic/interaction? The browser is a stack, not a single piece of tech.
I'm not classifying people who use web stack as illiterates. Where did that idea come from? The discussion is about developers and the tools they use. We aren't talking about those who are technically illiterate. Nor are we talking about certain technologies being responsible for a project's success. And there are very few instances where one could convincingly point to a language as the reason for success. Making such assertions are usually immature at best.
We are talking about choosing a language like Python normally considered a serious language vs. HTML/CSS/JS/DOM (PHP?) which is often considered less serious development frameworks.
If you go back and see what I originally responded to, perhaps the context becomes a little clearer.
Except that's not the context for this thread at all. What you originally responded to was a comment about the webification of everything, and the lack of MIT-licensed GUI libraries. Several people other than me all responded to your contentions about web-stack being great, easy, conceptually sound, etc.
There was nothing in the OP this thread devolved from about Python itself, other than it having a great QT library. And as far as context is concerned, this particular comment trail was a response to the ease of using Python, not anything at all related to it being "serious" compared to web-stack.
How are we so far apart regarding what is actually being discussed in context? We can both read the comment thread we each keep replying to. Your context (and points) keeps changing.
That is exactly the context of this thread. It might not be your context but it is mine and since I started it seems like you are the one who is changing the context.
You focus on the wrong things. None of your distinctions or interpretations of what I say are wrong per-se, they are just not important distinctions.
The fact is that people can quickly build a webpage with all the bells and whistles in an environment they undertand without having to install anything or rely on dependencies to get started.
They can fiddle around, experiment with it in real time etc. they can play around with it so to speak.
It doesn't take itself too serious. It doesn't have a "guardians of the right way" saying how it can and can't be used.
You can still go to town and go crazy in making perfectly optimized code but it's not demanding that from you.
These are the important bricks in creating something that is powerful. It's ability to function as a toy for the very novice people. To easily provide them with visual feedback with assets they can relate to (cat pictures, video they saw somewhere) etc.
This is what VB had this is what HTML/CSS/JS/DOM/(PHP) has in spades. The non-judgement of the experts.
A lot of unbelievable crap was produced by novices hacking away at Basic in an earlier era as well. The difference was you could move on to better things - Pascal, C/C++, Lisp, etc.
We're stuck with this cobbled together mess of mostly broken shit in browser-land, and there is no bigger-and-better thing we can graduate to.
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.
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.
Browser are for whatever browsers can be made to be for.
There are things it's optimal for but luckily we don't live in a world were people only do what things were originally meant for.
I am using gmail in the browser. I am discussing this with you. I am transferring money between accounts, playing games, filling out surveys, controlling projects, looking up routes on map, enjoying streaming music, video etc.
That's a ridiculous comparison. No one is developing desktop style applications using sed just because it is turing complete, and there ain't billions of people using this software running on sed.
If the web was such a terrible application platform then it would not have been able to stomp the traditional desktop as much as it already has so far.
The reason why it's about native apps on phones is because they don't have access to many of the hardware improvements that are being added all the time.
But quite a big part of those apps uses webview to render information in.
If sed was supported by every platform in the world, including mobile phones, instantly deployable, upgradable, and had a more-or-less functional UI library attached, you can bet your Macbook a hell of a lot of sed would be being written.
We are now in the year 2016, not 1996. Browsers moved past the "networked document viewer" stage well over a decade ago and have been deliberately evolving into full application platforms ever since.
Yes it is. Because most people don't know what to use it for and so the mental barrier becomes the first hurdle for them to solve. Even the Terminal in itself is a mental barrier to most people.
Even after that is solved it's still hard for people to understand exactly why they should choose Python vs. HTML/CSS/JS/DOM.
In fact I don't think you can give one example of why they in 90% of the cases should use Python unless they are doing fairly complex stuff.
We are talking about developers building applications here, not "most people".
Most people don't know anything about HTML, CSS, JS, the DOM, how we got here, how it works, etc. They are neither the target audience of the article nor of the discussion happening here.
Writing an iOS app in Objective-C was the first time I remember thinking, "Goddamn, this is beautiful" since I was 12 and found Basic.
One fucking language.
Looked the same on every device.
And it wasn't hard to get a project going. We are making a fucking computer application, not boiling water for tea.
Now everyone thinks it's progress and noteworthy and oh-my-fucking-gods-amazing to do this shit with fucking HTML, CSS, and JavaScript. What. The. Fuck.
Can't Silicon Valley startups afford developers who can...you know...learn technology and write some code? Is SV only able to disrupt the world by leveraging a browser every damn step of the way?
We are fucking modern-day wizards of techromancy who bend electrons to our will. We are the closest we've ever been to magic (since 1969). We come up with ideas. We make them something fleshy bags of water can poke at with their greasy, grubby, sausage-like fingers while they chortle and snort and spit their Cheetos on their screens. All by just futzing about with some incantations we spill out via keypresses. We can make just about anything that doesn't violate the laws of physics, and we keep defending HTML/CSS/JS as anything other than a horrible fucking wreck that steals our babies in the night, and thus our joy.
Nothing about the browser stack is a conceptual framework that is closest to what we humans understand. That CSS has made slower progress in not being a shitshow than Python 3is fucking abominable. That everyone is clamoring for JS to get all these proven-to-be-holy-rocket-ship-to-the-heavens features other languages have had for-fucking-ever, and had better, is just sad.
What we seem to be creating is an entire decade of developers who can't seem to work without the browser stack. And that's a problem. Because we are going to be reaping the rewards of this for a long while. Browsers need to move beyond, developers need to move beyond. HTML is great when all you want is a motherfucking website.[1] CSS is fine if you're looking for a better/best motherfucking website.[2] JS was cool ... once upon a time.
All three being the primary path taken for building every new thing just feels sad.
[3]: While it's always good to use the best tool for the job, that shouldn't mean we stop creating better tools. Right now, the browser stack just seems content to keep adding more tools into the toolbox, instead of inventing the fucking cotton gin and automated harvester.
You want everyone to be wizards but they are not. You want everyone to find value in only the most advanced forms of science but hey newsflash they are not.
Most people are finding value in very very simple even simplistic things.
Instead of being offended by that instead find solace in the fact that you can create things most other cannot.
I do not want everyone to be wizards. I want those who practice technology magecraft to stop rushing toward the bottom. I want to see less rationalization of lowest-common-denominator development as the best there is—or, at its most charitable, an improvement on good things that already exist, because this is often borne of an inherent laziness to learn, use, and improve great tools. I've seen way too much frank discussion among frontend web developers who are doing things with HTML/CSS/JS because it's all they know, and now they can do other things with it, not because using HTML/CSS/JS is technologically superior, easier, faster, more performant, better suited to the job, etc. It's because they can use what they know, and don't have to pick up a new skill. I find this to be worrisome, analogous to manual laborers being unwilling to learn new skills to remain competitive and employable.
I am also not offended that people find value in simple things.
To place myself in my own line of fire:
There are languages I like, and others I don't. There are languages I use daily that I love and hate. I'd love to have a solid, cross-platform GUI toolkit in my language of choice. I want to be able to write applications by my own subjective measure of what I think is good for the job, how much I like the language, etc. I find it pretty sad that I can't just do that—say, write a truly native desktop app with Elixir, or Go, or Python, or what-have-you. But then I realize there are languages and tools that are already built for doing this. I just don't want to use/learn them. Or don't feel like I have the time. So, I'm just as guilty of wanting to use my pet technology of choice on all my problems. However, I recognize this, and I don't try to rationalize it as wanting to use a better paradigm or conceptual model. I just want to use the tools I want to use. Sadly, they don't always fit.
I can't help but wonder what cool tools we'd have to practice our magecraft if all the time invested in bringing JS everywhere had been put elsewhere.
Objective-C, to reuse that example, has plenty of warts. But it really outshines using the web stack to build native apps for desktop/mobile. Swift is even more pleasant in many ways. You use one language that's built for the job. You always think in that language. You don't have to create style sheets, use a DOM, or use JS bridges to things already made to do the job and do it well. Someone else already said in the thread that using a document model for applications is simply not the write paradigm. But we've grown so accustomed to shoehorning our ideas into a document model, we struggle to recognize this is flawed.
Cross-platform and sans-browser development would be so much easier if there was a single GUI toolkit used on all OSes. Electron has grown so popular because people want to build desktop apps, and they want them to run on as many platforms as possible, while looking and functioning identically. But it brings problems, overhead, and other pains because you're building an application for desktops using the browser stack.
Maybe one day we'll see this situation improve. Or maybe I'll give in like everyone else. Despite my ire, I am frequently impressed when someone creates yet another do-thing-in-JS tool ... and depressed.
Lastly, I think you meant find solace, not solitude.
I never said anyone should care. You asserted in your prior comment a number of things "I want", assumptions you made about my state of mind and what I think. I replied with an explanation of what I actually think.
You keep jumping all over the place in each of your comments here, throwing out one assertion after the other, making up what you think applies 90% of the time, then constantly rebutting with whatever you've chosen to be "the point" in a given comment. It makes for very tiresome and fruitless conversation.
> 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.
The rest of your comment is quite intelligent, but I find these lines to be quite the opposite.
PyQt is available under both the GPL & a commercial license (https://wiki.python.org/moin/PyQt/PyQtLicensing). What you & the article author seem to want is for other people to write software that you can use and modify for free while you charge your own users to use and modify the software you write.
That's, in a word, hypocrisy. If you want to distribute a commercial PyQt app, then buy a license; otherwise release under the GPL (or a compatible license).
I was once asked to leave my comfort zone and write a Windows GUI app. Delphi saved me from the horrors of Petzold, the MFC and VB. Can confirm: it was a pleasure to layout and code in.
it actually was pretty nice in my book, I wrote my thesis in Motif and I got it to run on several different unix platforms without a lot of issues. There were also some really nice commercial widget sets available, as well as things like XDesigner (iirc) for putting GUIs together.
Not saying it was super easy to use (took me a while to get drag & drop working the way I wanted, I even ended up subclassing XmText to get rectangular highlighting) but it sure was nice, I wonder what would've happened if it had not been commercial but had been available on an open licence to start with.
I'm not totally sold on having landed on a bad toolset. Recently I've been looking at email and tools like it - messy, sometimes ugly tools that have withstood the test of time. People try to "fix" and "disrupt" it all the time, but it's pretty good as it is, and its resiliency is a testament to that.
I don't have a fully-formed hypothesis, and I like native apps better than WebKit/electron based apps just like the next guy, but there has to be something to it, no?
The defining characteristic of e-mail and "tools like it" is that they come from pre-Web era, and don't touch the modern web with a ten foot pole (the HTML was grafted on-top of perfectly good e-mail protocol, but is in no way a part of it).
The licensing problem is real, however. I've thought for a while about building a lib for this sort of thing. Funding the time necessary is the hard part. Requiring paid licensing for commercial usage seems fair. Using my awesome project for free fun? Cool. Using it to build something that makes you some money? I'd really appreciate you helping support the continued development and support of the thing helping you make money.
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.
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... ) and maybe it will lead to trading too much developer pleasure for user pleasure.
> 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.
> 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).
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.
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.
I tend to stay away from command line tools if they're written in Python or Ruby and have to be invoked frequently. The delay isn't big but it starts to grate. You can avoid the startup penalty with a server solution like chg does for Mercurial, but it's yet another complication.
It's not the same in GUIs where the startup time doesn't usually dominate, but it's easier to keep the main loop spinning at 60 Hz to avoid dropping frames with a language implementation that is faster and not encumbered with a GIL.
A common pattern here is to use multiprocessing to split off the GUI threads, then the GUI has it's own GIL. A nice side effect of this pattern is forcing one to have a clean set of interfaces between the presentation layer and the business logic.
On a tangential note -- As far as display system update rates are concerned, it is possible to detect differences in EEG data down to around 10ms per frame. (i.e. 100Hz refresh rate) -- even though the difference isn't readily apparent at the conscious level.
But DNF is mostly not written in Python at all. libsolv is C, Hawkey is C, librepo is C, libcomps is C. I also hear they're looking to rewrite even more of it in C.
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?
There's no reason that generating html and css necessarily implies 'coupling' in the bad sense. It does however mean an extra (and potentially complex) layer of abstraction.
However that's a deal I'd consider taking if it means I could write more Python more of the time.
I think the argument is that with "single page applications" you duplicate a lot of your business logic in fat clients. This thinking is essentially a return to circa 2004 but with today's APIs like websockets.
I think you will see applications that are quite generic (look and feel) and very chatty, but quick to develop.
But you can still separate them in the same language. He does not like the html/css/js combi and neither do I. I would like to develop all in 1 language (whatever that language may be); that has nothing to do with decoupling presentation from business logic.
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".
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...).
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.
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 ).
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.
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.
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..
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.
> Python's runtime is completely and utterly incapable of threading. Threading being almost essential to any decent user interface, this whole idea falls flat.
This is just plain wrong and the fact that many GUI programs are written in Python (dropbox, NetworkManager, Zim desktop wiki, etc) should be evidence of that. In fact, most people don't even realize these are written in Python. Yes, Python has the GIL. No, that does not mean it can't do multithreading. It merely means it can't do parallel processing on multiple cores with just threading. But that is by no means a requirement for multithreading, especially regarding GUIs.
> 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
This simply isn't true. Python has the GIL, but that doesn't stop it from making use of threads for IO or CPU bound tasks that release the GIL (using extension modules). There are lots of libraries for multi-threaded IO in Python (e.g., gevent, Twisted, Tornado, asyncio), and, not surprisingly, they are very widely used for web programming.
> 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.
While you're AFAIK correct about running Python on mobile devices, and I think anyone will admit that Python's performance has never been great, one can have a great UI without threads: use coroutines and channels instead.
Fortunately, Python does have coroutines, and a channel library can be built in the fashion of Lua's channel library (https://github.com/majek/lua-channels). I don't know if anyone has done it yet, I'll grant, but a cursory look suggests that it's possible.
The basic idea is that one would spawn a coroutine to handle each UI element, and the coroutines would send messages to one another on channels. I've no idea how fast it would be (at a guess: terrible), but it should work.
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? :)
1. Using the work done by the Kivy guys fixes that need; you can easily run on mobile. With a native webview on both you can use OP his new and shiny GUI browser framework from Kivy without much issue.
Glossing over the threading misinformation, Python's requirements are not particularly different from the likes of C#, but unlike C# there is nobody with the commercial incentive and necessary scale to do the hard work.
The only platform where Python could flourish without effort was Maemo, and for the very brief time that project lived, it did exactly that.
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.