Python web UI 也来了

2022-11-22 10:49:29 +08:00
 novolunt

抛开速度不谈 hah ,还是挺喜欢 py 的

https://nicegui.io/

之前分享的 diagrams

https://diagrams.mingrammer.com/

14288 次点击
所在节点    Python
75 条回复
paramagnetic
2022-11-22 13:05:00 +08:00
这个挺对我胃口的,我基本只需要一个 GUI ,把自己写的库里的函数暴露出去,然后给用户输入参数的地方。
折腾了一会 pyqt 觉得实在太复杂了,放弃了。
shinession
2022-11-22 13:15:49 +08:00
@ChrisFreeMan dash 了解一下, 基于 react flask 的框架
HugoChao
2022-11-22 13:20:44 +08:00
原来不只我卡,我感觉慢了 0.3s
fgwmlhdkkkw
2022-11-22 13:21:31 +08:00
Python 的 lambda 语法不太好……
fgwmlhdkkkw
2022-11-22 13:21:59 +08:00
@ChrisFreeMan #13 那必须要自备游标卡尺了……
tulongtou
2022-11-22 13:22:04 +08:00
这也太慢了,速度起码再提高 1000 倍才能正常用
cssk
2022-11-22 13:30:05 +08:00
这么想不开吗
novolunt
2022-11-22 14:11:33 +08:00
@tulongtou 新项目卡很正常,可以套个 PyO3
@HugoChao
@villivateur
0o0o0o0
2022-11-22 14:29:06 +08:00
卡是因为网络延迟,服务器在国外,如果是国内服务器根本不会感觉到卡。
不过可以试一试微软的 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 ,不过如果放在国内就基本上感受不到卡了。
其次是服务器需要维护长连接,这是会消耗服务器资源的,所以用户量不能太多,只适合比如开发本地应用,或者用户量少的应用。

如果你是开发用户量少,或者跨平台应用,是可以试一下的。
duan602728596
2022-11-22 14:30:28 +08:00
接近 1s 的延迟,基本上是没法用于生产的
hertzry
2022-11-22 14:41:12 +08:00
这个不就是前几代的 Material Design 吗?
0o0o0o0
2022-11-22 14:44:29 +08:00
延迟是因为,点击 “Check me!” ,js 发送事件到后端,后端处理后返回 “把多选框打勾”,前端收到后更新多选框状态。
因为 nicegui 服务器在国外,延迟 200ms 以上,所以这个过程需要很久,如果在国内,则不会感受到明显延迟。
pandachow
2022-11-22 14:48:53 +08:00
streamlit 重度用户。类似的工具还有 Dash ( Plotly 家的)之类的,Gradio 之类的,R Studio 的 Shiny ,这些工具基本都是定位机器学习模型推理的的可视化工具,所以基本都是 Py / R 开发优先,首要目的都是给这两个语言的使用者提供性能过得去,能小范围访问的 Web 服务,保证开发尽可能简单,提供常用的控件,一般不用做生产环境 Web 服务。
Leviathann
2022-11-22 14:50:44 +08:00
@0o0o0o0 这个和 elixir phoenix 是类似架构?
wangxiaoaer
2022-11-22 14:53:05 +08:00
哈哈,有 Java Awt 和 Apache Wicket 那味儿了。
tool2d
2022-11-22 14:54:32 +08:00
为啥 python 不把点击按钮事件放到前端?点个 checkbox 都要网络传输,完全没必要啊。
0o0o0o0
2022-11-22 15:07:14 +08:00
@Leviathann 我稍微看了一下 phoenix 好像还是 MVC ,和 blazor 或者这个 nicegui 还是有区别的,blazor 状态是存储在服务器中的,包括 dom 的结构,前端基本上只负责发送事件和接收更新,页面上的控件的状态也是后端控制的,开发的时候更接近于开发一个原生应用,而不是 webapp ,而 MVC 状态是存储在前端的,后端是无状态的。
0o0o0o0
2022-11-22 15:14:49 +08:00
@tool2d 因为好写,本质上这种框架不是为了让用户多好用,而是为了让开发者更好用,如果只考虑用户好不好用,那么传统的框架以及足够了,这个框架的任何功能你都可以使用其他方法实现。
这种框架的思想就是做一个远程 app (类似远程桌面),开发 app 的时候开发者就像在开发一个本地应用,不需要考虑前后端交互的问题,也不需要考虑如何局部更新等等,甚至不需要写 js ,只需要后端语言就可以了(当然有的框架 html css 还是要写的),而使用的时候却可以在任何平台使用。
当然也是有局限的,那就是网络延迟不能太高,用户量不能太大。
imdong
2022-11-22 15:21:29 +08:00
让我想起早期用 dreamweaver 开发 asp 网页来了, 拖拖拽拽, 点击按钮就刷新网页, 渲染修改后的页面.
tool2d
2022-11-22 16:43:56 +08:00
@0o0o0o0 都 2022 年了,前端技术早就不一样了。可以用 wasm 丢一个 py runtime 在前端辅助运行,这样前端就有 UI 内部状态了。

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

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

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/897007

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX