V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
推荐学习书目
Learn Python the Hard Way
Python Sites
PyPI - Python Package Index
http://diveintopython.org/toc/index.html
Pocoo
值得关注的项目
PyPy
Celery
Jinja2
Read the Docs
gevent
pyenv
virtualenv
Stackless Python
Beautiful Soup
结巴中文分词
Green Unicorn
Sentry
Shovel
Pyflakes
pytest
Python 编程
pep8 Checker
Styles
PEP 8
Google Python Style Guide
Code Style from The Hitchhiker's Guide
novolunt
V2EX  ›  Python

Python web UI 也来了

  •  
  •   novolunt · 79 天前 · 10252 次点击
    这是一个创建于 79 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

    https://nicegui.io/

    之前分享的 diagrams

    https://diagrams.mingrammer.com/

    73 条回复    2022-11-24 20:31:41 +08:00
    Alias4ck
        1
    Alias4ck  
       79 天前   ❤️ 2
    第一个网站我看过有很多类似的竞品 像国人开发的 PyWebIO( https://github.com/pywebio/PyWebIO/) 还有个很流行的 streamlit( https://streamlit.io/)
    Tink
        2
    Tink  
       79 天前
    别说还挺好看的哈
    sherlockwhite
        3
    sherlockwhite  
       79 天前
    为啥不用前端写😂
    sherlockwhite
        4
    sherlockwhite  
       79 天前
    不太懂这个
    RockShake
        5
    RockShake  
       79 天前
    这种只能当玩具吧,Python 库做的封装,自定义 UI 很多得直接改库了
    Tenlp
        6
    Tenlp  
       79 天前
    怎么用着还有点卡顿....
    GoCoV2
        7
    GoCoV2  
       79 天前
    这种开发方式有什么应用场景吗
    darkengine
        8
    darkengine  
       79 天前   ❤️ 1
    Switcher 和 radio button 的动画处理逻辑太怪了,让人觉得卡
    w88975
        9
    w88975  
       79 天前
    @Tenlp @darkengine 用着卡是因为, 每个 UI 交互, 都走 ws 协议传给后端程序去处理逻辑了, 这奇怪的交互方式
    lookStupiToForce
        10
    lookStupiToForce  
       79 天前
    这响应速度让我怀疑穿越到了十多二十年前的 ie 时期......
    darkengine
        11
    darkengine  
       79 天前
    @w88975 那这个交互逻辑就有问题了,弄个 loading 状态也好啊
    zaul
        12
    zaul  
       79 天前
    很卡啊,UI 还不错
    ChrisFreeMan
        13
    ChrisFreeMan  
       79 天前
    要是有人基于 PyScript 写一个类似 react 的框架,绝对火。
    deplivesb
        14
    deplivesb  
       79 天前
    这个响应速度,简直绝了。
    akaHenry
        15
    akaHenry  
       79 天前   ❤️ 3
    简单看了一下源码, 跟踪了一下依赖包.

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

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

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

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

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

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

    这些小众方案, 往往浪费很多时间研究, 最终发现都是不满足需求.
    bojue
        16
    bojue  
       79 天前
    @novolunt 歪楼,diagrams 的官网是哪个主题
    yunyuyuan
        17
    yunyuyuan  
       79 天前
    后端写 ui 不方便,写多了发现还是 html+js+css 好用。python 有 https://github.com/python-eel/Eel 可以配合其他现代前端,和 go 的 wails 一样通过 websocket 调用
    akaHenry
        18
    akaHenry  
       79 天前
    如果这个方案, 都能接受的.

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

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

    PS:

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

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

    有这功夫, 又学会一门语言了(dart+flutter).
    akaHenry
        19
    akaHenry  
       79 天前
    @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 方案, 都有很成熟可靠的方案.

    不要浪费时间在没有任何优势的方案上. 可能你的产品还没写完, 项目就先死了.
    villivateur
        20
    villivateur  
       79 天前
    用起来好卡……Firefox
    paramagnetic
        21
    paramagnetic  
       79 天前
    这个挺对我胃口的,我基本只需要一个 GUI ,把自己写的库里的函数暴露出去,然后给用户输入参数的地方。
    折腾了一会 pyqt 觉得实在太复杂了,放弃了。
    shinession
        22
    shinession  
       79 天前
    @ChrisFreeMan dash 了解一下, 基于 react flask 的框架
    HugoChao
        23
    HugoChao  
       79 天前
    原来不只我卡,我感觉慢了 0.3s
    fgwmlhdkkkw
        24
    fgwmlhdkkkw  
       79 天前
    Python 的 lambda 语法不太好……
    fgwmlhdkkkw
        25
    fgwmlhdkkkw  
       79 天前
    @ChrisFreeMan #13 那必须要自备游标卡尺了……
    tulongtou
        26
    tulongtou  
       79 天前
    这也太慢了,速度起码再提高 1000 倍才能正常用
    cssk
        27
    cssk  
       79 天前 via iPhone
    这么想不开吗
    novolunt
        28
    novolunt  
    OP
       78 天前
    @tulongtou 新项目卡很正常,可以套个 PyO3
    @HugoChao
    @villivateur
    0o0o0o0
        29
    0o0o0o0  
       78 天前
    卡是因为网络延迟,服务器在国外,如果是国内服务器根本不会感觉到卡。
    不过可以试一试微软的 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
        30
    duan602728596  
       78 天前
    接近 1s 的延迟,基本上是没法用于生产的
    hertzry
        31
    hertzry  
       78 天前
    这个不就是前几代的 Material Design 吗?
    0o0o0o0
        32
    0o0o0o0  
       78 天前
    延迟是因为,点击 “Check me!” ,js 发送事件到后端,后端处理后返回 “把多选框打勾”,前端收到后更新多选框状态。
    因为 nicegui 服务器在国外,延迟 200ms 以上,所以这个过程需要很久,如果在国内,则不会感受到明显延迟。
    pandachow
        33
    pandachow  
       78 天前
    streamlit 重度用户。类似的工具还有 Dash ( Plotly 家的)之类的,Gradio 之类的,R Studio 的 Shiny ,这些工具基本都是定位机器学习模型推理的的可视化工具,所以基本都是 Py / R 开发优先,首要目的都是给这两个语言的使用者提供性能过得去,能小范围访问的 Web 服务,保证开发尽可能简单,提供常用的控件,一般不用做生产环境 Web 服务。
    Leviathann
        34
    Leviathann  
       78 天前
    @0o0o0o0 这个和 elixir phoenix 是类似架构?
    wangxiaoaer
        35
    wangxiaoaer  
       78 天前
    哈哈,有 Java Awt 和 Apache Wicket 那味儿了。
    tool2d
        36
    tool2d  
       78 天前
    为啥 python 不把点击按钮事件放到前端?点个 checkbox 都要网络传输,完全没必要啊。
    0o0o0o0
        37
    0o0o0o0  
       78 天前
    @Leviathann 我稍微看了一下 phoenix 好像还是 MVC ,和 blazor 或者这个 nicegui 还是有区别的,blazor 状态是存储在服务器中的,包括 dom 的结构,前端基本上只负责发送事件和接收更新,页面上的控件的状态也是后端控制的,开发的时候更接近于开发一个原生应用,而不是 webapp ,而 MVC 状态是存储在前端的,后端是无状态的。
    0o0o0o0
        38
    0o0o0o0  
       78 天前   ❤️ 1
    @tool2d 因为好写,本质上这种框架不是为了让用户多好用,而是为了让开发者更好用,如果只考虑用户好不好用,那么传统的框架以及足够了,这个框架的任何功能你都可以使用其他方法实现。
    这种框架的思想就是做一个远程 app (类似远程桌面),开发 app 的时候开发者就像在开发一个本地应用,不需要考虑前后端交互的问题,也不需要考虑如何局部更新等等,甚至不需要写 js ,只需要后端语言就可以了(当然有的框架 html css 还是要写的),而使用的时候却可以在任何平台使用。
    当然也是有局限的,那就是网络延迟不能太高,用户量不能太大。
    imdong
        39
    imdong  
       78 天前
    让我想起早期用 dreamweaver 开发 asp 网页来了, 拖拖拽拽, 点击按钮就刷新网页, 渲染修改后的页面.
    tool2d
        40
    tool2d  
       78 天前
    @0o0o0o0 都 2022 年了,前端技术早就不一样了。可以用 wasm 丢一个 py runtime 在前端辅助运行,这样前端就有 UI 内部状态了。

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

    现在前端交互很复杂,OP 这种写写小项目可以。如果每次都用 websocket 访问后端,UI 一旦复杂度上升,那么用户体验就断崖式下跌。
    Yeen
        41
    Yeen  
       78 天前
    为啥 checkbox 和 switch 操作起来那么慢?
    lithiumii
        42
    lithiumii  
       78 天前 via Android
    不会前端,在前司的时候拿一楼说的 pywebio 写过小工具给同局域网下的同事用,很方便。
    montaro2017
        43
    montaro2017  
       78 天前 via Android
    怎么这么卡,这能用吗
    kxy09
        44
    kxy09  
       78 天前
    比 streamlit 灵活,但是好卡
    0o0o0o0
        45
    0o0o0o0  
       78 天前
    @tool2d 你说的 wasm 也有,blazor wasm ( server 直接改一下配置就可以自动编译为 wasm )但是这两个还是有区别的,blazor wasm 本质上就是纯前端,和 vue 差不多,就是用 c#做 js 的事情(当然操作 dom 还是需要 js ),还是需要和后端进行交互,你还是需要再写一个后端,而 blazor server 是前后端一起写,前端是一个瘦客户端。这两个可以说根本不是同一个应用,没有对比的必要。

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

    所以说这种框架也是有自己的限制的,有优点也有缺点。
    简单来说,很适合用户数量较小表单类应用,因为开发速度快,项目比较轻巧。
    你可以试一试这个项目: https://www.blazor.zone/
    clf
        46
    clf  
       78 天前
    想起了正方教务系统的老版本……也是每个 UI 操作去请求一下后端,然后选课的时候就是自己给自己制造 DDoS
    BowenYoung
        47
    BowenYoung  
       78 天前
    这响应速度让我以为回到 3G 时代
    bear1man
        48
    bear1man  
       78 天前
    实在是卡
    :)
    lo0pback
        49
    lo0pback  
       78 天前
    控件元素怎么居中啊
    dayeye2006199
        50
    dayeye2006199  
       78 天前 via Android
    OP 加油,streamlit 八个亿美元被收购的,争取也把这个做成若干个小目标

    这种 Ui 框架受众不是懂 js ,css 这样的工程师,而是科学家,数据分析员,业务人员,用来搭各种内部简单应用的
    duan602728596
        51
    duan602728596  
       78 天前
    不太认为卡的原因是海外服务器的原因,在本地网络和公司网络(外企,日本线路)的环境下测试都很卡。
    ControlNet
        52
    ControlNet  
       78 天前
    感觉主要是为了给 python 程序加 GUI 用的。比如说拿 pytorch 写了点东西,如果要做成后端服务就还是不如这种直接出 UI 那么方便。感觉像是 gradio 和 lightning app 的定位
    jedihy
        53
    jedihy  
       78 天前
    @0o0o0o0 我从国外访问也有肉眼可见的延迟。
    0o0o0o0
        54
    0o0o0o0  
       78 天前
    @jedihy 你可以 ping 一下那个网站,国外也得看距离,就像日本到美国,光速也有时间呀哈哈哈
    0o0o0o0
        55
    0o0o0o0  
       78 天前
    在本地测试了一下,确实是会有一点点“卡”的感觉,主要是前端 js 处理事件的过程耗费了一些时间,如果加上服务器延迟会更卡一些。
    MelodyZhao
        56
    MelodyZhao  
       78 天前
    自学 python 的小白,主要做商业数据分析,看到标题进来看看。我们领导要求搞一个部门内部数据查询和 BI 展示的平台,目前在折腾 streamlit ,各位大神们还有什么更好的推荐吗?
    xujianxing
        57
    xujianxing  
       78 天前
    demo 用 quasar 写的??
    Mexion
        58
    Mexion  
       78 天前
    速度感人
    0o0o0o0
        59
    0o0o0o0  
       78 天前
    找到在本地速度也慢的原因了,每次处理完事件之后都会延迟 200ms 再把事件发送给服务器,目前不知道为什么这么设置,这导致无论什么操作都要延迟 200ms
    bugcoder
        60
    bugcoder  
       78 天前
    @pandachow 请问 streamlit 怎么样? dash 用过一段时间,感觉比 Shiny 差远了,自己写扩展插件很难,相当于要学完 react 再套上一层 dash 的皮。而且项目维护的人少,感觉 Anaconda 公司就没什么投入。
    pandachow
        61
    pandachow  
       77 天前
    @bugcoder 比 Dash 好写不少,目前是我的主力,我觉得现在同类就在 Streamlit 和 Gradio 里面选一个就好了。
    likunyan
        62
    likunyan  
       77 天前
    谷歌风格啊
    Rrrrrr
        63
    Rrrrrr  
       77 天前
    终于知道什么叫卡了
    mihuan12
        64
    mihuan12  
       77 天前
    看都不看,火不起来的
    Daniel17
        65
    Daniel17  
       77 天前
    这么慢吗
    chrawsl
        66
    chrawsl  
       77 天前
    有种老旧电脑运行 windows11 然后装满 2345 全家桶的既视感
    kujio
        67
    kujio  
       77 天前
    卡卡的
    0o0o0o0
        68
    0o0o0o0  
       77 天前
    继续看了一下,是基于 justpy 的 https://github.com/justpy-org/justpy ,input 默认延迟是 200ms ,是可以调的,主要是为了应对用户输入的时候服务器频繁交互,完全可以设置为 0 。只不过 nicegui 现在还不是正式版本,没有去调这个,所以会这么卡。
    jtsai
        69
    jtsai  
       77 天前
    效果和易用性都不如原生的 HTML
    xintianyou
        70
    xintianyou  
       77 天前
    组件操作这么卡,真有人会用吗
    liunianmiyu
        71
    liunianmiyu  
       77 天前
    推荐看下 flet, 用 python 写 flutter 应用的,https://flet.dev/
    xiaotianhu
        72
    xiaotianhu  
       76 天前
    有学这个轮子的功夫 vue 早学会了吧。
    而且前端更重要的是生态,这玩意有啥生态。最后需要点啥 害的自己看源码手搓轮子。
    lixile
        73
    lixile  
       76 天前
    @ChrisFreeMan 虽然 但是 我现在再给公司内部也一个大数据呈现的 web 因为不会前端用的就是 dash+plotly 背后好像封装的就是 react
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   实用小工具   ·   5022 人在线   最高记录 5556   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 47ms · UTC 05:44 · PVG 13:44 · LAX 21:44 · JFK 00:44
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.