基于浏览器的客户端和原生的客户端，是不是存在无法跨越的差距?

vsc 表现很可以

在稍微现代一点的电脑上，如果不是看到能打开控制台，我都不知道好多客户端是 electron 写的。如果你感觉存在明显的差距是不是该换电脑了……

在 android 上反正是的

@gwy15 mbp 16 寸，符不符合你对"稍微现代一点的电脑"定义。

主要是质感的问题，原生写的感觉硬朗，web 写的总感觉软绵绵

用 MFC 吧，保证硬朗。

确实感官上有比较明显的区别

VSCode 算是优化的非常好的了，既如此还是又慢又占用非常多的内存，而且经常崩溃

设计也是一方面。
某种意义上，原生界面其实设计更为先进，那可是 80 年代就在研究交互的那群大神精心打磨出来的。
而现在，为了美观和快速迭代，现在的界面设计把当初的很多优点都抛弃了。所以界面好看了，但各种交互设计莫名的不顺手。

https://www.oschina.net/news/112547/windows-95-ui-design

流畅度还要看具体情况，
如果是一些适合浏览器呈现的动画效果，因为现代浏览器优化做的足够好，实际上顺滑度是优于原生的。

但问题是浏览器并不是为客户端软件而生的，他的很多东西并不适合客户端应用。
这就导致了用浏览器做网页，丝滑流畅，但是用来做客户端应用总是会有一种迟钝的感觉 - 说不起来哪里不对劲。
再说绘图效果也不理想，一些桌面控件做出来还没有原生自绘的好看。

现在网页框架的要求也是一路狂奔，例如最新的 react / antd 4.0 用 IE 或者旧的 Chromium 已经跑不动，曾经用 miniblink （ 一种用于桌面软件界面开发的 Chromium 49 内核 ）试了一下 - 很多控件都不正常，卡到动不了，当然上个最新的上百 MB 的 electron 或 cef - 那他是很流畅。

浏览器是一个重型武器，开一个页面至少是上百 MB 内存，如果是 vscode 这些那几 GB 的内存很轻松就没了，而且用浏览器做界面，那就要大量的用到 javascript，但是做客户端不可壁免的要调用操作系统的 API 接口 - 但是 JS 做这事非常的吃力，这一来一回都要消耗时间，每个调用慢 0.1 秒没什么，但用户点击一下来个成千上万次的循环 - 那感觉就很不好了。

举一个开源项目 wubiLex 为例
https://github.com/aardio/wubi-lex
这个界面也不错了，但是这个软件最终的体积只有 820KB, 体积只相当于一个小的 jpeg 图像文件，不需要任何运行时框架，也不需要带浏览器壳子。

类似这样的客户端，用浏览器套壳是很难做出来的，一个浏览器壳子都不止 820KB 了。
所以我们一般说小、轻、快，体积小了 - 自然也就快了。

浏览器不也是一种特殊的客户端嘛，哈哈

浏览器的客户端完全是为了妥协人手不足，同时也要有点跨平台需求的情况
至于性能肯定比不上全原生的，特别是原生的控件有硬件加速的支持下，这点在 mac 上比较明显，windows 上什么乱七八糟的程序都有，甚至大部分程序都停留在 GDI 绘制层面上，那可能和浏览器客户端比不相上下

个人的使用感受：Win 10 上 UWP 写的客户端，也不怎么干脆

没什么区别，
Windows WPF 用 xaml 画 UI
Linux Gtk/Glade 用 xml 画 UI

与 electron 基于浏览器 js 用 html 画 UI 没有本质区别

感觉是的，就像 vsc 优化的再好，流畅程度上还是能感觉到和原生的差距。

如果你用过知乎的 app 客户端，你会怀疑相比 web 体验，简直是负优化。

@iConnect 知乎 APP 这个例子不太合适，因为知乎 APP 正是题目中说的“基于浏览器的客户端”，而不是“原生的客户端”。

不过知乎的安卓 APP 做的是真烂，动不动界面黑块卡死，明明内置了企鹅家的 x5 内核，却时灵时不灵，一会是 x5，一会又是 webview，太烂了。知乎的人也别怪到 x5 身上，哔哩客户端用的也是 x5，毛事没有。

/t/640801

@ybw #4 哪年的？

R7 M.2 16G 用 electron 都能明显感受到不流畅。我觉着我电脑配置应该超过全国半数用户了。
electron 没有独占功能我会尽量用网页版。