Is flexx.ui Pythonic enough?

[almarklein]

@JohnLunzer wrote in #302:

I understand that Flexx is in part an attempt to bridge Python and Javascript. I understand also that the GUI elements of Flexx originate from the phosphor JS package. If I could draw an analogy. The PyQt package makes little if any demands on the user to understand C++ (the native language of Qt).

Do you have any goals of providing that same level of abstraction to Flexx in the future? I realize the implications of that could affect the "bridge" aspect of Flexx. With careful design I believe the UI component of Flexx could have an API which made no demands on the user to have knowledge of JS/HTML/CSS. I'm not saying that having knowledge of those languages is a bad thing, but along with the "bridge" component Flexx touts "Apps are written purely in Python". Based on my short experience with Flexx I feel like while that is technically true, a more honest statement would be "Apps are written purely in Python, with some knowledge of Javascript, HTML, and CSS."

[almarklein]

@JohnLunzer thanks for this question. I think that in principle flexx.ui should be usable for people with no experience in web development. At least in basic usage. The fact that you bring this up might suggest that we have some work to do here, so I am eager to learn how we can improve things.

That said, because things run in a web environment, people will want to make use of the situation and e.g. use CSS to style their widgets, so certain web-aspects do "leak through" sometimes. (CSS is not even that bad, I guess, since Qt uses that too). I think this is unavoidable and also ok. The question, I think, is how can we make it such that Python-only users do not get confused by this, and get "gently" introduced to these concepts as they need more advanced features.

I suspect that some of your feelings also come from PyScript not being real Python, which is also hard to avoid completely, but can definitely be improved, #259 addresses this.

@JohnLunzer I'd be happy to hear more about what parts of the API you think suffer from this.

I expect @Korijn also has an opinion on this from a web-dev's point of view.

[JohnLunzer]

That said, because things run in a web environment, people will want to make use of the situation and e.g. use CSS to style their widgets, so certain web-aspects do "leak through" sometimes. (CSS is not even that bad, I guess, since Qt uses that too). I think this is unavoidable and also ok.

I fully agree with this, and I tried to communicate that I do not feel like the "leak through" is a weakness in any respect. The "leak through" is in reality part of the "Python-JS bridge" aspect of Flexx and is an important and wanted feature of Flexx. That said I believe it only represents a single layer of the API.

I suspect that some of your feelings also come from PyScript not being real Python

Actually my feelings were triggered by my original request in #302. The VideoWidget is a good example. The VideoWidget is ultimately a wrapper to the HTML5 video element. The code you gave me in #302 alters the tags for this element. The Flexx documentation does not indicate this. Because implementation details are mostly hidden in Phosphor even the Flexx source code gives only an obtuse indication of what VideoWidget is manipulating. One can put it together from the three lines of code from the def _init_phosphor_and_node(self) of the VideoWidget class:

self.node.controls = 'controls'
self.node.innerHTML = 'Your browser does not support HTML5 video.'
self.src_node.type = 'video/mp4'

But it is more than is necessary to ask from a user to put it together on their own, especially one with no web-dev experience.

I see two "levels" of API being useful and necessary in Flexx.

First, a "leak-through" level which I feel mostly exists as seen currently in Flexx. Using the case above this would assume a minor level of experience with web-dev languages/technology, enough to understand manipulating HTML tags and understanding of how to place an HTML5 video element in a minimal website. At this level it would important for the documentation to state exactly what is being manipulated in the DOM how it is being manipulated.

Second, I see a "Python only" API level which, again using the example above, would make no demands on the user to even know that the VideoWidget wrapped around an HTML5 video element. All of the relevant HTML5 tags (autoplay, controls, height, preload, etc) would be exposed during creation of a VideoWidget object as kwargs (or other Pythonic mechanism). Practically speaking I think this can already be achieved in Flexx. At this level it may be disadvantageous to non web-dev experienced users to mention any lower level implementation details.

The VideoWidget is probably an idealized case, as the HTML5 video element is simple and straight forward.

I believe Flexx can achieve both "levels" of API without much sacrifice. Though, this would be a potentially far reaching design goal worthy of a well thought out approach.

[Korijn]

My initial response to this would mostly be that Web APIs change incredibly frequently and things like the autoplay feature on the video tag were actually quite recently! Wrapping around all this functionality in the Python API would demand a respectable maintenance effort to keep up. It's the web: you are expected to follow developments in the field and read docs (like MDN).

Perhaps Flexx could refer to the video tag's MDN page in the VideoWidget docs as a quick improvement, since all the attributes are exposed, really.

[JohnLunzer]

It's the web: you are expected to follow developments in the field and read docs (like MDN).

Couldn't I just as easily say, "It's Python: you're only ever expected to read docs.python.org." Python is popularly used to hide the implementation details of complex code/libraries.

As stated in the docs:

The primary motivation for Flexx is the undeniable fact that the web (i.e. browser technology) has become an increasingly popular method for delivering applications to users.

Many people would like to deliver their applications on the web but simply can't gain the knowledge of a professional web developer to do so. There are numerous projects designed to unify and simplify the web stack; amongst those is Flexx. I beleive Flexx has already satisfied its primary motivation at some level. The question is how far is a developer willing to go with this? Hence the title of this issue.

@Korijn It is too simple to say, "Too much effort, users expect to know better". A consequence of that approach is a steeper learning curve resulting in less users or confused users looking for support. Both of those effects negatively impact Flexx and its userbase. There is a balance between API friendliness and code complexity.

Here is a practical question, how many users do you think would prefer:

class JS:
    def init(self):
        self.vid1.node.autoplay = 'autoplay'

vs adding autoplay = True to VideoWidget()?

It is clear which is more Pythonic and which has less cognitive load. It is clear which one is more likely to turn away curious inexperience eyes out of utter bewilderment (saying "This doesn't look like the Python I know").

Flexx has an opportunity to reach a lot of people, not just web developers. If Flexx intends to reach non web developer audience it seems unlikely to get there without providing an alternative to the snippet above and applying that same design methodology to all of flexx.ui.

Please note, I am not advocating removal of the current patterns but simply a more Pythonic web-noob friendly alternatives.

[Korijn]

I fully recognize that Flexx needs to appeal to "web-noobs" and should therefore look and feel like regular Python. Don't get me wrong. :)

My point is that I think that (1) the amount of APIs that is available on the web is staggering and really a lot of ground to cover and that (2) it is a moving target with really high velocity. Projects like Qt can count on a certain level of stability of the underlying available system APIs. This is quite different on the web: APIs like the video tag's are subject to change frequently depending on what the W3C and browser vendors prioritize.

As it stands and as I've understood, Almar is the only developer on Flexx, and so I don't think you can reasonably expect him to provide a Pythonic abstraction layer across the full myriad of browser APIs that is available.

Don't get me wrong: if we can think of a way to make such a Pythonic API a feasible goalpost for Flexx, I'm all ears!

Perhaps we could start by identifying the most commonly used elements and put abstractions in place to cover that?

[JohnLunzer]

@Korijn, I'm in full agreement with your assessment.

Perhaps we could start by identifying the most commonly used elements and put abstractions in place to cover that?

This is what I had in mind. I see what Flexx has now as an acceptable core to start with. As for the rest of the web, I imagined a flexible plug-in system to allow for the user community to create and share element/API abstractions that integrate as if they were part of the core.

@almarklein, please do not interpret my statements as demands. I find Flexx interesting and useful. I offer my perspective as a new user in hopes that my anecdotes and experience can prove useful.

[almarklein]

I like the idea of making this two-layer approach somewhat more explicit. At this point the node attribute is hardly (not?) documented. The docs should make clear that the properties of the widgets expose an easy to use Pythonic API, and that more is possible by making use of the html nodes directly. Each widget should document what type of node it is based on, so that those who want to make use of it can do so, without having to read the source. Maybe even point to MDN docs, yes.

This should make it clear that Flexx' "Easy API" is relatively small and that more is possible if you know/learn a bit of web-stuff. So the message should be something like "Apps are written purely in Python, and with some knowledge of web dev you can make use of HTML5's features" (but phrased better).

That still leaves the question of how complete the Pythonic API should be. My feeling is that this can grow rather organically. E.g. @JohnLunzer wanted the autoplay feature, let's add it (a PR would be nice :P). Though with moderation; let's keep it relatively simple. At the least limited to features currently supported by all major browsers, and features that are "common". I suppose it also depends on the situation though; if someone is eager to create a feature rich VideoWidget and is willing to maintain it ...

I agree that the lines to currently turn on autoplay are not very appealing. So that's code that you would not put in a demo, unless its an example of how the low-level API can be used to leverage full html5 functionality.

[almarklein]

@almarklein, please do not interpret my statements as demands.

I am not. This is great feedback. This discussion is interesting and important :)

Why a plugin system and not just packages that extend flexx with more components?

[JohnLunzer]

Haha, I originally wrote a "plug-in" system (in quotes) to indicate any system which allows extending Flexx's core capabilities. I took off the quotes because I thought they might be confusing.

The xonsh project has an active user community which often wants to extend the core capabilities of the project. Being unable to cope with the large volume of feature requests they designed an extension system that might be worth taking a look at.

[almarklein]

Frankly, I don't see the need for an extension system. If someone wants to build a real sophisticated VideoWidget than he/she can do so in a module that others can import. Possibly packing it up and putting it on pypi. Users can then do:

from awesome_flexx_videowidget import BetterVideoWidget
...

Xonsh is different, since its an app, and needs to detect and load extensions at runtime.

[JohnLunzer]

@almarklein, I'm certain you would know better than I on this, it was only a consideration I thought to bring up because part of the system appears to be to promote sharing with the community through a sort of central repository. I'm sure a full extension system is not needed to support that type of activity.

[Korijn]

It might be hard to try and pre-emptively come up with the finest cherries to pick here.

@JohnLunzer Maybe a good question to ask is: what were your main obstacles when getting to grips with Flexx from a pydev-standpoint?

[JohnLunzer]

@Korijn, primarily my lack of web-dev experience. I should say, I expected that I should have trouble and I'm not at all disappointed by having to learn some.

That said, I am usually able to go into python sources to dig out some greater understanding but in the case of Flexx I found this frustrating because it wasn't clear what the link was between the Flexx elements and the HTML/JS elements. But @almarklein already addressed this as a point of improvement.

I should also point out that Flexx is not alone in suffering this disconnect. Packages which aggressively wrap C/C++ libraries can also suffer from this. In most cases, as is the case here, equally as aggressive documentation is usually sufficient to address the disconnect.

[drafter250]

oops maybe I should have added my #342 here.

I was perusing the phosphor documentation and it seems like phosphor is focused on the higher level layouts and base functionality you would use to compose more discreet widgets from.

How hard would it be to auto-generate the python code for the phosphor layer of widgets that would then be used to compose a more pythonic level of widgets?

in the future maybe it would allow the use of other javascript front ends like bootstrap and make it easier to keep up with changes?

[almarklein]

I have considered auto-generating the code related to wrapping Phosphor, but I think its not worth it, because 1) there are not that many widgets to wrap; 2) the specifics to make widgets Pythonic (i.e. what properties to expose and how to name them) are different between widgets, so still plenty of manual input there; 3) while some changes in Phosphor might simply require a re-run of the generator, other might need a rewrite of it, and code that generates code is typically not the easiest :P

[almarklein]

#465 introduces minsize and maxsize, which gets rid of the most-needed use-case for apply_style(). Apart from the fact that this improves layout in a few ways, this should make Flexx feel a little less webby :)

[almarklein]

I've tried to take the lessons from this discussion into #486.