Can we move to a @ui.page-only world?

[evnchn]

With NiceGUI 3.0, we dropped the concept of the shared client for the UI elements outside of @ui.page function, but for the name of existing code to "work", we have this "script mode" where NiceGUI wraps your code into @ui.page for you.

But, with recent discussions, it has been brought to my attention that it "works" to some extent only, with the following discrepancies to 2.x behaviour.

1. Client is not shared, so you still have to migrate shared-state logic to using https://nicegui.io/documentation/event
2. Given the following, if you have time-varying UI elements such as ui.label(str(time.time())) in your code, every time you refresh it it's the same.
3. In various places in the code we actively detect script mode and disable functionalities which would not work in the first place. Look at https://github.com/search?q=repo%3Azauberzeug%2Fnicegui%20script_mode&type=code

Maintaining this "script mode" is tough, since:

1. We need to think about an extra case in writing our code.
2. We don't have Pytest for this mode.

Consider this: For 2.x upgrade to 3.0, code which needs migration will migrate straight to @ui.page. What's left are the code which still works, my hypothesis is that it may be a small amount.

And so, maybe in 4.0 we can finally drop the "script mode" and we basically follow FastAPI in a sense that with the exception of the root parameter used for Single-Page Applications, "no decorator no talk" for pages.

Question is: are there genuine uses, other than the easy running of demos and small scripts, that the "script mode" is of use?

[falkoschindler]

For me personally "the easy running of demos and small scripts" is a huge advantage of script mode. It's like Jupyter for NiceGUI. I use it for debugging code snippets from the community, demonstrating simply NiceGUI concepts, or even experimenting with NiceGUI-agnostic Python code. And the fact that almost all demos are one or two lines shorter and an indentation less complex, adds up.

Apart from that I think that the cost of maintaining the script mode is far smaller than it was for the auto-index client. We now have basically one switch right at the start and the rest behaves like the script was wrapped in a page function.

Oh course, I'm open for counterarguments. But at the moment I'm very happy with the script mode and would like to keep it.

[python-and-novella]

I think , we should tell beginner what does not work in script mode.
e.g. Anything which need to be defined in global scope shouldn't be defined in script mode. script mode has no real global scope.

[evnchn]

Hot take: if you can successfully tell that to a person, that person is definitely not a beginner.

And so @ui.page becomes more like "I should use it no matter what" to beginners, which is also the case generally speaking.

[rodja]

I think the new root parameter is much better that @ui.page because it naturally brings devs to use the much faster and generally beneficial SPA setup with ui.pages. I envision @ui.page to take a backseat -- still allowed but more of an advanced nerdy feature. When finding a releasable set of features I was very ok in dropping auto-index pages for root parameter. Then @falkoschindler came up with the Script Mode. The main benefit is that it works very very similar to root page. So I'm fine with the few extra hurdles we need to take. Mainly I'm optimistic that we can explain it easily and users are not irritated. Something like:

If you do not use a root page function in ui.run your whole script is the root page and get's re-executed for every browser visit.