Nice GUI(nicegui.io)
nicegui.io
Nice GUI
https://nicegui.io/
20 comments
It's so slow. Why does it take seconds to update a toggle? And it seems to keep overriding itself (not debounced? racing the input?)
To write web gui in Python, there are some other open source alternatives.
If just want to port simple shell interactive interface to web gui, can check https://github.com/pywebio/PyWebIO
If want to get a production level dashboard by using Python, https://wave.h2o.ai/ <<Realtime Web Apps and Dashboards for Python and R>>
If just want to port simple shell interactive interface to web gui, can check https://github.com/pywebio/PyWebIO
If want to get a production level dashboard by using Python, https://wave.h2o.ai/ <<Realtime Web Apps and Dashboards for Python and R>>
Is there a version of this that doesn't need server state? I've been thinking of making something like that.
Really ugly imo - it's that very early 2010s style - way-too-flat, not enough hinting and too many animations.
I searched a couple minutes and couldn't see a list of supported platforms. Should I assume that since it's HTML based it would work on all of them, including iOS and Android?
Pretty GUI, feels awful to use. Maybe client side reactions with corrections would be better?
Amazing python to website framework. It is just what I was looking for!
Nice!.
Is it intentionally slowed down? The reaction (for example when I click the checkbox) seem very slow in the demo page.
Is it intentionally slowed down? The reaction (for example when I click the checkbox) seem very slow in the demo page.
I was noticing this as well. I believe it's because each ui element must do a request to perform actions server-side (notice how the on_click handlers are python lambda functions).
This is probably the main drawback; you need your server to be located physically close to where the UI is open or there will be a very noticable delay. It's probably pretty snappy when the server and browser are on the same machine, though.
This is probably the main drawback; you need your server to be located physically close to where the UI is open or there will be a very noticable delay. It's probably pretty snappy when the server and browser are on the same machine, though.
Another choice would be optimistic UI updates (assume the checkbox will end up checked. If not, revert to unchecked and display feedback about an error).
I’ve tended to use this in UIs which rely on server state, and it usually makes things feel much snappier. In my experience it’s rare that an optimistic update isn’t fulfilled as expected, so the user experience is improved overall.
I’d hesitate to do it absolutely everywhere, though. In large forms it would be preferable to do batch updates rather than updating on every field interaction, for example.
I’ve tended to use this in UIs which rely on server state, and it usually makes things feel much snappier. In my experience it’s rare that an optimistic update isn’t fulfilled as expected, so the user experience is improved overall.
I’d hesitate to do it absolutely everywhere, though. In large forms it would be preferable to do batch updates rather than updating on every field interaction, for example.
That causes rubberbanding, doesn't it, where the checkbox looks checked at first and then unchecks itself a few seconds later when the server says "nope"?
It can, yes, but the snap back should always be accompanied by feedback to allow the user to understand what happened.
There are pitfalls (what if the user thinks a setting saved and closes their browser, but it failed after they closed the tab?) which are addressable but it takes work and complexity. I think optimistic UI can be helpful. Generally speaking it’s a layer of complexity I’d tend to try to avoid, though.
Tools like Relay for graphql come with excellent implementations of this which I’d say are worth using if you’ve adopted the library, for example.
There are pitfalls (what if the user thinks a setting saved and closes their browser, but it failed after they closed the tab?) which are addressable but it takes work and complexity. I think optimistic UI can be helpful. Generally speaking it’s a layer of complexity I’d tend to try to avoid, though.
Tools like Relay for graphql come with excellent implementations of this which I’d say are worth using if you’ve adopted the library, for example.
Nope, it's doing a round-trip to the server on each interaction. You can inspect the websocket and see the messages. The notifications are generated by a Python function running on the server, there's no client-side logic.
Seems like it could be improved by having instant client side reactions, while letting the notifications come in with the response from the server so it seems more snappy to the user
Yes, you are right