Python web UI 也来了

第一个网站我看过有很多类似的竞品 像国人开发的 PyWebIO( https://github.com/pywebio/PyWebIO/) 还有个很流行的 streamlit( https://streamlit.io/)

别说还挺好看的哈

为啥不用前端写

不太懂这个

这种只能当玩具吧，Python 库做的封装，自定义 UI 很多得直接改库了

怎么用着还有点卡顿....

这种开发方式有什么应用场景吗

Switcher 和 radio button 的动画处理逻辑太怪了，让人觉得卡

@Tenlp @darkengine 用着卡是因为, 每个 UI 交互, 都走 ws 协议传给后端程序去处理逻辑了, 这奇怪的交互方式

这响应速度让我怀疑穿越到了十多二十年前的 ie 时期......

很卡啊，UI 还不错

要是有人基于 PyScript 写一个类似 react 的框架，绝对火。

这个响应速度，简直绝了。

简单看了一下源码, 跟踪了一下依赖包.

https://github.com/justpy-org/justpy/blob/master/justpy/htmlcomponents.py#L76

干了很多脏活累活, 这种包, 后续维护下去, 苦不堪言.

可能最终都会是不堪重负, 不了了之.

GUI 的方案已经很多了, 没必要用 python 写.

web 系的方案, 成熟可靠. 实在讨厌 web, 还有 flutter + dart 可以选择.

dart 语法非常简单, python 开发者基本不用学. 上手写就行了.

这些小众方案, 往往浪费很多时间研究, 最终发现都是不满足需求.

@novolunt 歪楼，diagrams 的官网是哪个主题

后端写 ui 不方便，写多了发现还是 html+js+css 好用。python 有 https://github.com/python-eel/Eel 可以配合其他现代前端，和 go 的 wails 一样通过 websocket 调用

如果这个方案, 都能接受的.

相信 flutter web 的加载速度, 也能接受.

起码 flutter web 持续优化加载速度. 而这种方案, 可能就别想了.

PS:

rust 生态, tauri + vue, 写桌面版, 也是一个很好的方案.

python 不适合这种场景, 就别瞎浪费时间了.

有这功夫, 又学会一门语言了(dart+flutter).

@yunyuyuan UI 层确实是 html/js/css 的主战场.

既然已经接受了 html 方案. 就不应该继续使用 python + eel 这种优点全无的方案.

flutter(上手更简单), rust + tauri 和 go + wails 都是更好的选择.


> PS:


flutter 和 tauri, 我都有写产品实践.

flutter 写 mobile app 体验一流.
tauri 可以快速把一个 前端(vue/react) 项目, 直接转换成 desktop app, 基本一行代码都不改.

各有优势. tauri 的优势是可以无痛复用整个前端生态, web 有的, 都可以复用. 这比 flutter 有天然优势.
flutter 另起炉灶, 基本在复刻 web 生态的路上. 任重道远.

总之, 当下时间节点, UI/GUI 方案, 都有很成熟可靠的方案.

不要浪费时间在没有任何优势的方案上. 可能你的产品还没写完, 项目就先死了.

用起来好卡……Firefox

这个挺对我胃口的，我基本只需要一个 GUI ，把自己写的库里的函数暴露出去，然后给用户输入参数的地方。
折腾了一会 pyqt 觉得实在太复杂了，放弃了。

@ChrisFreeMan dash 了解一下, 基于 react flask 的框架

原来不只我卡，我感觉慢了 0.3s

Python 的 lambda 语法不太好……

这也太慢了，速度起码再提高 1000 倍才能正常用

这么想不开吗

@tulongtou 新项目卡很正常，可以套个 PyO3
@HugoChao
@villivateur

卡是因为网络延迟，服务器在国外，如果是国内服务器根本不会感觉到卡。
不过可以试一试微软的 Blazor Server https://learn.microsoft.com/en-us/aspnet/core/blazor/?view=aspnetcore-7.0#blazor-server

和这个其实本质上相同，都是通过后端生成 html --> 然后把浏览器的事件发送到后端 --> 然后后端再生成需要的改变发送到浏览器 --> 浏览器再更新页面，也就是浏览器里有一个脚本，只做两件事，监听事件发送给后端，接收后端的数据更新页面，其他所有的逻辑全部都在后端实现。

好处是，很多事情框架帮你做了，你写起来仿佛是在写一个本地应用，不需要考虑前后端是怎么交互的，不需要写接口，不需要去写 js ，然后 js 再调用后端，后端在处理请求，然后后端处理后返回，再写 js 更新 ui ，你可以直接在后端控制 dom ，可以直接在前端调用本地 api ，也可以后端主动控制前端。
如果说传统的 webapp 像是两个人 一个人让另一个人使用自己的手，而这种框架就像是一个人使用自己的手一样符合直觉和方便。
其次前端只有一个页面和一个 js ，需要加载的东西很少，所以速度可以很快（对于一个单页应用）。

当然，这种框架也是有很多缺点，比如说延迟，一旦延迟高了就很难用了，比如 nicegui.io 延迟 300ms ，不过如果放在国内就基本上感受不到卡了。
其次是服务器需要维护长连接，这是会消耗服务器资源的，所以用户量不能太多，只适合比如开发本地应用，或者用户量少的应用。

如果你是开发用户量少，或者跨平台应用，是可以试一下的。

接近 1s 的延迟，基本上是没法用于生产的

这个不就是前几代的 Material Design 吗？

延迟是因为，点击 “Check me!” ，js 发送事件到后端，后端处理后返回 “把多选框打勾”，前端收到后更新多选框状态。
因为 nicegui 服务器在国外，延迟 200ms 以上，所以这个过程需要很久，如果在国内，则不会感受到明显延迟。

streamlit 重度用户。类似的工具还有 Dash （ Plotly 家的）之类的，Gradio 之类的，R Studio 的 Shiny ，这些工具基本都是定位机器学习模型推理的的可视化工具，所以基本都是 Py / R 开发优先，首要目的都是给这两个语言的使用者提供性能过得去，能小范围访问的 Web 服务，保证开发尽可能简单，提供常用的控件，一般不用做生产环境 Web 服务。

@0o0o0o0 这个和 elixir phoenix 是类似架构？

哈哈，有 Java Awt 和 Apache Wicket 那味儿了。

为啥 python 不把点击按钮事件放到前端？点个 checkbox 都要网络传输，完全没必要啊。

@Leviathann 我稍微看了一下 phoenix 好像还是 MVC ，和 blazor 或者这个 nicegui 还是有区别的，blazor 状态是存储在服务器中的，包括 dom 的结构，前端基本上只负责发送事件和接收更新，页面上的控件的状态也是后端控制的，开发的时候更接近于开发一个原生应用，而不是 webapp ，而 MVC 状态是存储在前端的，后端是无状态的。

@tool2d 因为好写，本质上这种框架不是为了让用户多好用，而是为了让开发者更好用，如果只考虑用户好不好用，那么传统的框架以及足够了，这个框架的任何功能你都可以使用其他方法实现。
这种框架的思想就是做一个远程 app （类似远程桌面），开发 app 的时候开发者就像在开发一个本地应用，不需要考虑前后端交互的问题，也不需要考虑如何局部更新等等，甚至不需要写 js ，只需要后端语言就可以了（当然有的框架 html css 还是要写的），而使用的时候却可以在任何平台使用。
当然也是有局限的，那就是网络延迟不能太高，用户量不能太大。

让我想起早期用 dreamweaver 开发 asp 网页来了, 拖拖拽拽, 点击按钮就刷新网页, 渲染修改后的页面.

@0o0o0o0 都 2022 年了，前端技术早就不一样了。可以用 wasm 丢一个 py runtime 在前端辅助运行，这样前端就有 UI 内部状态了。

有必要才通过 websocket 访问后端，这样才足够合理。

现在前端交互很复杂，OP 这种写写小项目可以。如果每次都用 websocket 访问后端，UI 一旦复杂度上升，那么用户体验就断崖式下跌。

为啥 checkbox 和 switch 操作起来那么慢？

不会前端，在前司的时候拿一楼说的 pywebio 写过小工具给同局域网下的同事用，很方便。

怎么这么卡，这能用吗

比 streamlit 灵活，但是好卡

@tool2d 你说的 wasm 也有，blazor wasm （ server 直接改一下配置就可以自动编译为 wasm ）但是这两个还是有区别的，blazor wasm 本质上就是纯前端，和 vue 差不多，就是用 c#做 js 的事情（当然操作 dom 还是需要 js ），还是需要和后端进行交互，你还是需要再写一个后端，而 blazor server 是前后端一起写，前端是一个瘦客户端。这两个可以说根本不是同一个应用，没有对比的必要。

前端交互要分类，如果只是表单类的操作不会有什么问题，因为输入很有限，如果是复杂交互比如拖拽或者画图什么的，采样率比较高的交互，的确还是需要使用 js （不过可以把已有的组件封装为 blazor 组件）。

所以说这种框架也是有自己的限制的，有优点也有缺点。
简单来说，很适合用户数量较小表单类应用，因为开发速度快，项目比较轻巧。
你可以试一试这个项目： https://www.blazor.zone/

想起了正方教务系统的老版本……也是每个 UI 操作去请求一下后端，然后选课的时候就是自己给自己制造 DDoS

这响应速度让我以为回到 3G 时代

实在是卡
:)

控件元素怎么居中啊

OP 加油，streamlit 八个亿美元被收购的，争取也把这个做成若干个小目标

这种 Ui 框架受众不是懂 js ，css 这样的工程师，而是科学家，数据分析员，业务人员，用来搭各种内部简单应用的

不太认为卡的原因是海外服务器的原因，在本地网络和公司网络（外企，日本线路）的环境下测试都很卡。

感觉主要是为了给 python 程序加 GUI 用的。比如说拿 pytorch 写了点东西，如果要做成后端服务就还是不如这种直接出 UI 那么方便。感觉像是 gradio 和 lightning app 的定位

@0o0o0o0 我从国外访问也有肉眼可见的延迟。

@jedihy 你可以 ping 一下那个网站，国外也得看距离，就像日本到美国，光速也有时间呀哈哈哈

在本地测试了一下，确实是会有一点点“卡”的感觉，主要是前端 js 处理事件的过程耗费了一些时间，如果加上服务器延迟会更卡一些。

自学 python 的小白，主要做商业数据分析，看到标题进来看看。我们领导要求搞一个部门内部数据查询和 BI 展示的平台，目前在折腾 streamlit ，各位大神们还有什么更好的推荐吗？

demo 用 quasar 写的？？

速度感人

找到在本地速度也慢的原因了,每次处理完事件之后都会延迟 200ms 再把事件发送给服务器，目前不知道为什么这么设置，这导致无论什么操作都要延迟 200ms

@pandachow 请问 streamlit 怎么样？ dash 用过一段时间，感觉比 Shiny 差远了，自己写扩展插件很难，相当于要学完 react 再套上一层 dash 的皮。而且项目维护的人少，感觉 Anaconda 公司就没什么投入。

@bugcoder 比 Dash 好写不少，目前是我的主力，我觉得现在同类就在 Streamlit 和 Gradio 里面选一个就好了。

谷歌风格啊

终于知道什么叫卡了

看都不看，火不起来的

这么慢吗

有种老旧电脑运行 windows11 然后装满 2345 全家桶的既视感

卡卡的

继续看了一下，是基于 justpy 的 https://github.com/justpy-org/justpy ，input 默认延迟是 200ms ，是可以调的，主要是为了应对用户输入的时候服务器频繁交互，完全可以设置为 0 。只不过 nicegui 现在还不是正式版本，没有去调这个，所以会这么卡。

效果和易用性都不如原生的 HTML

组件操作这么卡，真有人会用吗

推荐看下 flet, 用 python 写 flutter 应用的，https://flet.dev/

有学这个轮子的功夫 vue 早学会了吧。
而且前端更重要的是生态，这玩意有啥生态。最后需要点啥 害的自己看源码手搓轮子。

@ChrisFreeMan 虽然 但是 我现在再给公司内部也一个大数据呈现的 web 因为不会前端用的就是 dash+plotly 背后好像封装的就是 react

200 天前, 对该项目的评价, 已经过时了(因为 nicegui 1.0 实现方案已更改)
更新一下对这个项目的评价: 目前推荐 (小工具可用)
详细最新评价如下:


https://s.v2ex.com/t/947702#reply1

试了下。。
把组件放到页面上容易，，但把页面搞美观很困难，，不知道怎么搞