NiceGUI – easy-to-use, Python-based UI framework | Hacker News Reader

NiceGUI – easy-to-use, Python-based UI framework

github.com

46 pointsgilad13 comments

I’m not the target audience so plenty of grains of salt, but I was curious and took a look. I haven’t worked in Python for a few years, but I figured I have enough background to anticipate some patterns. Foremost among them, I expected some variation of either:

- UI = fn(state)

- UI = [black box of state] + fn(something)

I sure wasn’t prepared for bare render statements with no assignments or return values! I looked into the examples for how things get removed or reordered in the most likely places I’d expect to find them and… I didn’t find them?

I mean, it’s definitely conceivable this could be “easy to use” if these imperative render statements are ~equivalent to a re-render, but it bucks against a lot of design UI API principles I’ve seen flourishing regardless of the tech stack, and raises a lot of questions about what happens after state changes invalidate previous imperative calls.

It’s entirely possible there’s something I’m missing! I only took a curious glance. But that glance definitely left me with the impression that either there’s more magic than described or there’s a lot of imperative state necessary to handle anything past init.

Hi Ken_At_EM, thanks for looking into our code! Our approach with context managers for defining "belonging" in NiceGUI resembles the nesting of elements in HTML. By implementing the __enter__ and __exit__ methods, we can manage the context when used with a "with" expression. In NiceGUI, elements pass down to the default_slot (https://github.com/zauberzeug/nicegui/blob/main/nicegui/elem...), which is a 1:1 representation of Vue slots.

We maintain a slot stack (https://github.com/zauberzeug/nicegui/blob/main/nicegui/slot...) to keep track of the current context (see http://127.0.0.1:8080/documentation#auto-context). When creating a new element, it finds its parent slot on the slot stack (https://github.com/zauberzeug/nicegui/blob/main/nicegui/elem...).

What do you think. Does it make sense? We appreciate your feedback!

> Hi Ken_At_EM […] see http://127.0.0.1:8080

Maybe imperative UI declaration needs a little extra care to keep its state consistent after all :D

Please take my silly glib response as a friendly jab not a meanspirited one… but this made me chuckle a couple times! Good luck with your project nonetheless

GUIs are Pythons greatest weakness. We need a solid electron/tauri clone with a JS front end and a Python backend and good deployment tools.

Check https://github.com/r0x0r/pywebview

pywebview (https://github.com/r0x0r/pywebview) is an excellent suggestion and is already being used in NiceGUI to create a native desktop window with "native=True" option (see http://127.0.0.1:8080/documentation#ui_run).

Awesome. Seems like a solid building block.

We understand the need for a solid Electron-like solution with a Python backend and good deployment tools, and that's where NiceGUI aims to fill the gap with it's 1.2 release (https://news.ycombinator.com/item?id=35386990).

Very cool!

I think JS ecosystem needs a gradio-like pattern such as this one. I'm tired of how incredibly artificially low-level frontend development has become. I don't want to solve functional programming puzzles to make a button do something,

Why are the radio and checkboxes slow on my nearly $2k smartphone?

How does it compare with remi? https://github.com/rawpython/remi

Looking at the examples, for quick UIs, REMI seems simpler. And PySimpleGUI (https://github.com/PySimpleGUI/PySimpleGUI) offers REMI as a backend to deploy on web too (PySimpleGUI is pretty simple to learn).

Performance is not good. Slow UI click. Tried radio and select boxes.

Reply on news.ycombinator.com