Brython and web stack (UI toolkits and backend engines)?

[ed2050]

Question for others: what do you use for full stack web development?

Brython is fantastic. I'm so so happy to write browser scripts in python instead of ugly-as-sin js. Brython makes me many times more productive. But it's just one piece of the web stack.

Issue

For complex applications, you need a mix of frontend behavior (browser scripts) and backend behavior (server side code). Brython fills the browser side. You still need a backend and communication between the two.

I've been doing this manually til now. My scripts grew slowly over time, and I added little bits of backend behavior piecemeal as needed via python HTTPServer and ajax calls. It works, but development is slow and requires significant debugging to figure out browser / server gotchas (like CORS issues or certain features only working on https).

You also need a frontend UI for controls. Slides, buttons, dialog boxes, etc. I've been doing this manually as well, crafting html buttons, styling with css, binding them in brython. I built some libraries over time to help. But still, it's slow. Raw html / css takes time and has many issues to sort out.

Now I'm rethinking this approach and looking for better solutions.

Question

Here's my question: what do other brython folks do for UI and backend? Do you handle all this manually? Use js libraries to help with UI? Python frameworks for the backend, like flask? What's your solution to a full stack web app?

Ideal Solution

My ideal solution is something that integrates python on the front and back end. That seemlessly handles communication between the two. That eliminates low-level html / css generation for the UI.

I recently found a new toolkit that's very promising: nicegui. It's a python web stack that handles UI and a backend server. You write very simple server code, like

ui.button ('Click me', on_click = lambda : ui.notify('You clicked me!'))

This puts a button on the page and pops up a custom dialog when clicked. You can run any backend functionality in the on_click callback: the page sends a button activation message to the server, and runs your python callback server-side. Or you can set js code to run on the frontend.

I see nicegui as a complement to brython, not a replacement. Sure, you could implement many features in either one. But some functions are better handled on backend, and some on frontend. Integrating brython with nicegui gives the best of both worlds. Nicegui accepts arbitrary js / css / html, so it should be straightforward to use them together.

Other Approaches

Flask could potentially do similar things, but my impression is that it's more an html template engine. You'd still be crafting your own UI with html / css, and you'd still handle front/back communucation manually with ajax calls. Maybe I'm wrong and it does more than that.

Has anyone used nicegui before? What other toolkits do people use for web stack development?

[manatlan]

Hi ... I'm an old brython fan boy ...

But since 2 years, i'm working on my own python web stack ... named htag : https://github.com/manatlan/htag
(and thanks to brython, which helps me to define my lib !)
While it's ready for desktop/single apps ( pywebview, android apk, chrome app mode, and pure html (with pyscript)) ...
It's not ready yet for the web (but it will be soon), with the lib https://github.com/manatlan/htagweb (which is basically just a "runner" (web server) to serve htag's apps to many users/sessions)

It's a little bit "like" nicegui & co ... but only pure python (no js/vuejs things) ...
and it doesn't provide "gui widgets ready-to-use" ... it's very low level !

you can create yours ... (see mines : https://github.com/manatlan/htbulma (using bulma/css))
but you can easily create yours usings materialjs, alpinejs, etc ... or anything you want ...

Here are demos, on a python host : https://htag.glitch.me/ (using htagweb)
and in a pure html (using pyscript) page, in repl mode : https://raw.githack.com/manatlan/htag/main/examples/pyscript_demo.html

[ed2050]

Cool, thanks @manatlan. I'll check it out.

[shlomil]

Currently I'm looking for a widget toolkit that could integrate nicely with Brython.
NiceGui is really cool. One of it's elements is a Vue/Python bridge.
I wonder if one could implement that bridge on client side and have NiceGUI interact with Brython or a brython webworker instead of going to the server for every UI event.

[ed2050]

Totally agree. Nicegui is a great toolkit. Not perfect, but improving. The guys behind it are very responsive. I've been using a mix of nicegui and brython for 6+ months. My strategy has been: - nicegui for most page UI and application state - brython for client-side interaction with DOM (update page title, open new page) and UI niceties that don't affect data or functionality (zooming images in and out, highlighting, changing css dynamically, etc) Basically like MVC with nicegui handling M, brython handling C, and V split 90/10 between them. Integrating brython with nicegui would be great. It could take several different forms: 1. Minimal - Making nicegui apps able to run brython scripts on the page (what I'm doing), with no interactions between them 2. Aware - Making brython able to interact with nicegui components through a standard interface. Brython could update nicegui elements and vice verse through a limited method call interface on shadow objects. 3. Full blown - Fully integrating brython to use the same objects as nicegui, where the same code can be used seamlessly in either environment. 1 is easy, just load brython interpreter and off you go. 2 and 3 are progressively more difficult, due to different execution models (nicegui stores all state server side, communication via web sockets, difficult to interact with DOM). There would be definite advantages to tighter integration, as nicegui requires server communication for every tiny change on the page (mostly, a few updates are handled by js VUE components in the browser). My sense is it would take a lot of work to make brython recognize and interact with nicegui objects. I could be wrong. I raised the possibility of integrating brython and nicegui with the devs late last year. I would say that nicegui devs are open to it, but tepid considering the amount of work and their other priorities. On brython side, there was little interest as the mission is to provide a complete python environment, not develop web app toolkits. Completely understandable from both sides. My takeaway is that seriously exploring integration would require new devs and a separate project. I'm interested, but quite busy with other projects now. If someone got a project off the ground, I would contribute bits and pieces when able. HTH, Edward

[shlomil]

Using websockets means that all widget communication goes through some api which might be easy to replace with a postMessage to brython code.

That being said, I saw your discussion with the NiceGUI developers. I't seems to me that they will not go in this direction, and I tend to agree with them - NiceGUI seem to already be doing a lot of data related work on the serverside and a move to brython will mean you loose many features. Forking the project or creating a project that is heavily inspired by NiceGUI might be the way to go.

[manatlan]

Currently I'm looking for a widget toolkit that could integrate nicely with Brython.

That's exactly what I'm working on ...

Check https://raw.githack.com/manatlan/htag/main/brython/bryted.html
And in the burger menu (at top right) : choose "htui for brython (first tries)"

It's a little "widget library" for brython, that works on client-side only. (currently it exposes message box, prompt, confirm, drawer, tabs, form and splitters .)
It will be named "htui4brython" ... (because I've working on the same thing for htag only : "htui" (to replace htbulma) ... apis will be the same !)

In fact I'm porting a subset of htag on brython side : named "htag4brython" (https://github.com/manatlan/htag/tree/main/brython)
(It's basically the same way for crafting components (as real htag)... to be able to reuse components with minimal efforts)

"Bryted" is an online editor that works on client side, using htag4brython + brython ... but storage is on server-side in an htag+htagweb app.
Bryted let me test brython on client-side in a brython context.

"htag" is the same concept as nicegui (without vuejs, only pure python)... but without widgets (htui will try to change that)

[ed2050]

Thanks Shlomi, I generally agree with that. Just a few clarifications: Using websockets means that all widget communication goes through some api

which might be easy to replace with a postMessage to brython code.

Yes and no. You could easily replace the part of the API that parses websocket messages on the client (currently js). But you still have to turn those messages into client side actions. Interfacing from a brython websocket handler to the many client-side js VUE components seems rather challenging to me. The idea is simple, but implementation could be rather time consuming with many pitfalls and obscure data conversion issues that are hard to debug. At least in my experience writing browser extensions in brython to interface with native Chrome APIs, it's a slog. NiceGUI seem to already be doing a lot of data related work on the

serverside and a move to brython will mean you loose many features

That depends how you approach it: - If you rip out existing js websocket handlers to replace with brython code, then it's complex but you don't necessarily lose features (unless some js behaviors are too difficult to replicate in brython). - If you try to shift significant functionality from serverside to clientside, then yes. But why would you do this? Nicegui and brython fill different roles. The goal is not to port nicegui to brython. - If you use brython to supplement nicegui by adding client side functionality where lacking, then no. You aren't losing any features; nicegui is gaining. I don't see value in replacing existing code. Brython should be used for things nicegui doesn't do or does poorly. To your point about nicegui devs - Do they want to replace existing websocket functionality with brython? No. As you said, that would be a waste of resources. We all agree on that. Are they open to integrating brython in a way that adds functionality, without requiring significant rewrites of existing code? I think yes. Understandably, it's not a priority for them. They won't spend their time on it. But I think they would accept contributions from others if mature enough. Regardless, a separate project is the best way forward.

…

On Wed, Apr 10, 2024 at 3:09 PM Shlomi Loubaton ***@***.***> wrote: Using websockets means that all widget communication goes through some api which might be easy to replace with a postMessage to brython code. That being said, I saw your discussion with the NiceGUI developers. I't seems to me that they will not go in this direction, and I tend to agree with them - NiceGUI seem to already be doing a lot of data related work on the serverside and a move to brython will mean you loose many features. Forking the project or creating a project that is heavily inspired by NiceGUI might be the way to go. — Reply to this email directly, view it on GitHub <#2281 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIKNAOFQABCLCISX7Q2UJDDY4VB2LAVCNFSM6AAAAAA6FODAYKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TANZRHE4DG> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[shlomil]

I wrote just for fun a 100 line BryceGui as a POC.
The interesting part is on the bottom of the script - you may notice that this code works as a Brython script:

import ui

def clicked1(e):
  ui.notify("clicked button 1")

def clicked2(e):
  ui.notify("clicked button 2")

ui.Button("hello button1", on_click=clicked1)
ui.Button("hello button2", on_click=clicked2)
ui.run()

So, it seems that it is possible to wrap Vue+Quasar and make something like NiceGui for Brython.

[ed2050]

Nice. I couldn't load the code. So you're importing nicegui ui module into brython? If you just want a UI toolkit to run on brython, that could work. I didn't consider that approach. My apps need a server for things that aren't possible in the browser (rename files, update image db, etc). Nicegui backend makes my life easier than rolling my own (which I did for many years).

…

On Wed, Apr 10, 2024 at 7:01 PM Shlomi Loubaton ***@***.***> wrote: I wrote just for fun a 100 line BryceGui as a POC <https://codepen.io/shlomil-the-sans/pen/xxejeQm?editors=1000>. The interesting part in on the bottom of the script - you may notice that this code works as a Brython script: import ui def clicked1(e): ui.notify("clicked button 1") def clicked2(e): ui.notify("clicked button 2") ui.Button("hello button1", on_click=clicked1) ui.Button("hello button2", on_click=clicked2) ui.run() So, it seems that it is possible to wrap Vue+Quasar and make something like NiceGui for Brython. — Reply to this email directly, view it on GitHub <#2281 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIKNAOH74R6JRKC5UYLJRVTY4V5BFAVCNFSM6AAAAAA6FODAYKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TANZUGU3DI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[shlomil]

No. It's not imported from NiceGui.
It's a toy implementation "from scratch" of a wrapper over Vue/Quasar which imitates NiceGui's Api.

[manatlan]

Yes, it's really interesting ! Thanks for sharing But like ed said ... Sometimes you'll need to interact with a real cpython instance, to be able to create/rename files in filesystem...(For example) And it won't be possible in pure brython. It will be only possible in things like nicegui/htag ... Notice, that in a pyscript env, you can go a step further, but you'll never can go out of the browser vm instance (without tweaking chrome securities, or using a cef). (Htag + matplotlib can work ootb in pyscript, while nicegui couldn't yet (coz of the httpserver instance)) Le mer. 10 avr. 2024, 23:12, Shlomi Loubaton ***@***.***> a écrit :

…

No. It's not imported from NiceGui. It's a toy implementation "from scratch" of a wrapper over Vue/Quasar which imitates NiceGui's Api. — Reply to this email directly, view it on GitHub <#2281 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABEZQR5GBXDOI24FJCU6JDY4WTNDAVCNFSM6AAAAAA6FODAYKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TANZWGQ2DQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[shlomil]

Umm ... Just like you have js for server side (AKA node.js) and JS for client side (AKA browser's js engine) and they communicate by api calls, You may have cpython on the server (to do DB stuff and whatever) and Brython on the client. I fail to see an issue with this.

[ed2050]

I don't have js on server side or client side. That's why I use brython. :P The issue is how to connect your brython client and cpython server. Who maintains app state? How do you keep data from both in sync? Yes it's very doable, there are many ways to handle it. I'm interested in concrete ready-to-use application-level solutions. What do you suggest?

…

On Thu, Apr 11, 2024 at 9:45 AM Shlomi Loubaton ***@***.***> wrote: Umm ... Just like you have js for server side (AKA node.js) and JS for client side (AKA browser's js engine) and they communicate by api calls, You may have cpython on the server (to do DB stuff and whatever) and Brython on the client. I fail to see an issue with this. — Reply to this email directly, view it on GitHub <#2281 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIKNAOGNKBE763ZYAC2R4SDY4ZESHAVCNFSM6AAAAAA6FODAYKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TAOBQHEZTO> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[denis-migdal]

To answer your question we'd need to know more about the data you want to sync (do you really need to sync it ? to sync it all ? to you need incremental/complete sync ? etc.).

There are lot of different technical solutions depending on the needs :

• REST API
• Websockets
• IndexDB
• localStorage
• Server Sent Events
• SQL database
• cookies
• etc.

Once the solution implemented, adding new communications is very very quick if designed properly.
But for that we need to know what you need exactly.

For example, I developed a very simple HTTP REST server in Python for educational purpose, where you add a new route simply by adding a file. It takes a few days, but once done, adding new routes take seconds.

[shlomil]

Who maintains app state? How do you keep data from both in sync? Yes it's
very doable, there are many ways to handle it. I'm interested
in concrete ready-to-use application-level solutions. What do you suggest?

In most cases the app state should be stored on the client and the client alone.
The data has only one source - on the server/DB and a client pulls data and requests to perform updates.
This solves any synchronization issue you might have.
In NiceGUI's case the above concepts do not apply, as far as I can tell, but these concepts are the base for most of the well known full-stack framworks today.

My choice for server side is usually FastAPI and adding Brython makes it full stack Python, which is cool.
As I said, it could be nice to wrap Vue/Quasar components and have them all available in Brython to complete the stack which I require.

[manatlan]

I've just released my htagui https://github.com/manatlan/htagui
Which is a gui toolkit for htag...

You can see it, in live on https://raw.githack.com/manatlan/htag/main/examples/pyscript_demo.html, click HELP, and select the last example "using htagui' (which is a real htag app, in a pyscript page, and reals pypi packages)

The same thing run in a classic cpython instance ... (The main goal)

Btw, I've ported it to a full brython html app.
See https://raw.githack.com/manatlan/htag/main/brython/bryted.html ... On the burger menu, choose htagui4btython

It's the same apis, and works in the same way .. so the main "App" class is exactly the same...
The first is full server side (state on server) ... The second is full client side (state in client)

For sure, it's not vue/quasar/nicegui ... But it's a lot simpler. And there are rooms for improvments in htagui

I don't know where to go with that ...
But perhaps, it could be possible to create special htag class powered with brython ... It's the only way I see

[ed2050]

My questions were mostly for Shlomi. Sorry I wasn't clear about that. @manatlan - certainly htagui has potential to fill these roles. I look forward to seeing its continued development. @denis - indeed there are many options and considerations in choosing a framework. I wasn't posing questions about my particular projects. They were intended as open ended questions, examples of how to start evaluating different frameworks. Each project will have different needs and make different evaluations. @shlomi - your analysis seems overly simplistic to me. If you all want it is bare-bones "python runs on both ends", then your proposals can be enough. Personally I've already done that for many years. It still leaves a lot of unsolved issues. For instance, you need to: - create an API to shuttle data back and forth between client and server - decide when to trigger updates from client to server - implement polling strategies in client to check server for updates - duplicate input validation and error checking on both ends (server shouldn't blindly trust client data, client shouldn't wait for server round-trip to catch simple issues) - make sure data received on client end represents the same structures as on server end. it sounds simple but it's no small thing. differences in json encoders / decoders, issues in transmission, many other sources of possible difference. eg your server takes a dict, encodes as json, and sends it down the pipe, where client decodes the json. same data right? oops no, any integer keys on server end are suddenly strings on client side. js may not notice the difference, but brython does. - transform your server-side data into your client-side UI widgets for proper display. again not as simple as it sounds. - devise a way to report meaningful errors from server to client and vice versa (simple http response codes like 404 not found or 503 service temporarily unavailable don't give enough info for complex apps to make decisions or inform users intelligently) - diagnose why your client and server suddenly stopped being able to exchange messages today when everything worked fine yesterday before the latest chrome update That's just off the top of my head. All things I've dealt with over the years. Those are issues an end-to-end framework can handle or greatly simplify. I don't want to be a plumber mucking around with http pipes and shuttling data anymore. I want to focus on application logic. I want a complete web stack. That's where I'm coming from. Everyone has different needs of course. I do see value in your suggestions. For some projects, your approach can be great. It just doesn't sound like a fit for my needs. Perhaps I'm wrong.

…

On Thu, Apr 11, 2024 at 10:03 PM Denis Migdal ***@***.***> wrote: To answer your question we'd need to know more about the data you want to sync (do you really need to sync it ? to sync it all ? to you need incremental/complete sync ? etc.). There are lot of different technical solutions depending on the needs : - REST API - Websockets - IndexDB - localStorage - Server Sent Events - SQL database - cookies - etc. Once the solution implemented, adding new communications is very very quick if designed properly. But for that we need to know what you need exactly. For example, I developed a very simple HTTP REST server in Python for educational purpose, where you add a new route simply by adding a file. It takes a few days, but once done, adding new routes take seconds. — Reply to this email directly, view it on GitHub <#2281 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIKNAOCFJ63DMEMK64IDIWLY433D7AVCNFSM6AAAAAA6FODAYKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TAOBYHA3TM> . You are receiving this because you authored the thread.Message ID: ***@***.***>