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.
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
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).
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,
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).
13 comments
[ 3.6 ms ] story [ 37.7 ms ] thread- 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.
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!
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
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).