Live data from Hacker News

Nice GUI

nicegui.io

11–20 of 21 posts

Re: Nice GUI

#11

Earlier quoted context omitted.

Nice!. 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, thoug…

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.

Re: Nice GUI

#14
What does this tell about this industry when after several decades of web programming a tool to display the most basics UI elements can still be featured on HN?

Re: Nice GUI

#15
post #12

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/ >

Is there a version of this that doesn't need server state? I've been thinking of making something like that.

Re: Nice GUI

#16
post #14

What does this tell about this industry when after several decades of web programming a tool to display the most basics UI elements can still be featured on HN?

SW enginering is about reinventing the wheel every couple of years.

This looks like a copy of Google's material design.

Re: Nice GUI

#17
Really ugly imo - it's that very early 2010s style - way-too-flat, not enough hinting and too many animations.

Re: Nice GUI

#18
post #17

Really ugly imo - it's that very early 2010s style - way-too-flat, not enough hinting and too many animations.

It's just Material design. The style looks a bit old, but it's literally just 2-3 years ago since this was the latest from Google.

Re: Nice GUI

#19

Earlier quoted context omitted.

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, thoug…

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…

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"?

Re: Nice GUI

#20
post #18
post #17

Really ugly imo - it's that very early 2010s style - way-too-flat, not enough hinting and too many animations.

It's just Material design. The style looks a bit old, but it's literally just 2-3 years ago since this was the latest from Google.

Oh yeah that makes sense Material design is both ugly and dorky to use.
Post reply on HN