主要是十几年前跟 C/C++、java 比，写起来自由方便，无需编译部署简单。
放到现在来说除去市场惯性因素，JS/TS 、Python 这些其实效率更高，[]和{}区分定义对前端来说也更少出现因为某些 phper 辖 JB 乱用 array 导致接口数据定义乱飞的情况

@ChrisFreeMan 你说的不就是 flutter web 的路线，以及 skyline 渲染引擎吗

@wuyiccc 因为 arm64 的 linux 和 windows 机器还非常少见，所以文档里没给 arm64 的 sdk 链接。实际上有个非常简单的办法获取 arm64 的 flutter sdk ，就是先下载 x64 的 sdk 正常配置，然后去 flutter/bin/这个目录下把 cache 目录删了，这个目录里就是 x64 版本的 dart sdk ，最后执行 flutter doctor ，脚本发现 cache 空了，就会根据当前机器的系统和架构自动下载合适的 dart sdk 到 cache 目录下，这样就完成了 arm64 flutter 环境的配置。

@wuyiccc 支持 windows arm64 的，准确来说是全平台都支持 arm64 ，包括 Linux （我已经在打 arm64 的 Linux 包了）
https://docs.flutter.dev/reference/supported-platforms

https://i.imgur.com/clX3knF.png

我是拿一台几十块的机顶盒刷 armbian 后装 casaos ，再加一个 128G 的 U 盘，就做成了一个低功耗的轻 nas ，直接扔在入户信息箱里。
主要的用途就是 gitea 代码仓库、tailscale 组网、迅雷和百度离线下载、内网文件中转和共享，偶尔还会用它编译测试写的程序在 arm 下是否运行正常。

个人体感来说确实比游戏稍微好一点，主要还是环境因素，现在的辣鸡环境对客户端影响很大，但对游戏影响更大……不过我不觉得 flutter 能代表整个客户端的情况，flutter 在某种程度上已经是客户端的最后一口气了，你能找到 flutter 的好的坑位还好，如果找不到转了客户端去写原生，那大概率比继续做游戏更坑。。

火山有部分音色支持：
https://www.volcengine.com/docs/6561/97465

我早就说闲鱼的卡不该让 flutter 背锅的，终于有人有一样的见解了啊～

另外对新入坑的朋友苦劝一句，远离混合方案，会变的不幸——纯 flutter>原生>混合！！！切记

windows： https://pub-web.flutter-io.cn/packages/fluent_ui
演示： https://bdlukaa.github.io/fluent_ui/

macos： https://pub-web.flutter-io.cn/packages/macos_ui
演示： https://macosui.github.io/macos_ui/

linux(ubuntu)： https://pub-web.flutter-io.cn/packages/yaru
演示： https://ubuntu.github.io/yaru.dart/

当然就像 1 楼说的，很多桌面项目并没有那么复杂，手搓组件库并不难，比如我参照 deepin 的设计写的这个这个应用：
https://github.com/debuggerx01/dde_gesture_manager
演示： https://www.debuggerx.com/dgm_web/#/
说明手册： https://www.debuggerx.com/2022/01/21/dgm-manual

前端转换，转好了再上传🐶

canvas.toDataURL(type, encoderOptions)

deepin🐶

100 出头的三模 84 键机械键盘
30 块的 usb 鼠标
二手显示器当扩展屏
旧手机当系统资源监视器
mini 路由器把有线网转成热点给手机用
魔百盒用于跑 clash 给开发机提供代理服务
USB 风扇、制冷杯、铝制水杯、茶叶等……

@shawndev darwin 就是 mac ，这里都列的意思显然是说需要支持全平台，会 iOS 开发的可不一定会 mac 程序开发； HTTP/GRPC 都是封装好的协议，这个除外的意思显然不是说它过时，而是说工作需要直接做更底层一些的 Linux 网络编程，比如嵌套字、多路复用这些吧

如果是类似工控机点餐机那种，只需要开机打开一个图形应用然后点点点，那就直接 xinitrc 指定程序就行，参考：
https://wiki.archlinuxcn.org/wiki/Xinit#%E5%9C%A8%E6%B2%A1%E6%9C%89%E7%AA%97%E5%8F%A3%E7%AE%A1%E7%90%86%E5%99%A8%E7%9A%84%E6%83%85%E5%86%B5%E4%B8%8B%E5%90%AF%E5%8A%A8%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F

但是这种方式不适合自用，比如输入法就不好搞，建议还是起一个最简单的窗管，除了上面别人提到了的 i3wm 这种平铺式，还可以考虑 openbox 这种配置简单的堆叠式窗管

辨别错误和垃圾信息所花的时间精力提高了。

如果默认允许这样玩了，谁还下载 APP🐶

@flyqie 个人认为 react 是独立的前端概念形成以来，最伟大、影响最深远的前端思想。react 改变了前端开发的思路和模式，之后的各种 web 前端框架以及 flutter 乃至 swiftui ，compose 其实都是 react 思想的应用于特定场景和目的的产物。很多人可能不喜欢 react 而倾向于 vue 或者 svelte 等等，但其实更多的是工程上的区别，比如谁的 api 设计得更易用，谁在某些方面上的性能表现更出色，而不是“纯思想”上的对比。但是思想伟大并不意味着 react 在工程上也就无可挑剔，我用 js 写过 class 组件模式的纯 react 项目，也用 ts 做过 hooks 模式的，还写过不同版本的 next.js 和 taro ，虽然同是 react 系方案思想都一样，但其实开发体验差异是很大的，所以虽然我个人很推崇 react ，但是并不是很看好 rn 这种“在上层对齐各平台差异，底层使用原生组件”的跨平台模式。虽然我也很喜欢 ts 的语法，但是并不认为 js/ts 是足够适合跨平台的语言(原因看下面对 dart 的评价)
做跨平台，无外乎就是自绘和包装复用平台组件这两种模式，基于 web 的跨平台方案比如 electron 或者 webview2 ，其实本质也可以认为是利用浏览器内核做的“自绘”，但相比于 flutter/qt 的那种自绘要重得多。复用平台组件的模式一定会存在渲染不一致，依赖真机环境调试验证，框架和应用代码中存在大量判断分支，某个平台增加新特性或组件后需要持续适配投入大量精力的问题，这些是原理上难以避免的，反倒是很多人以为的性能问题，其实并不是那么的无解。所以一开始了解 flutter 是自绘的方案，我就认为这是一个加分项，一是其表现力的“上限”更高，二是由于自绘所依赖的底层相对都很稳定(比如 opengl ，canvas 这些东西)，所以其本身也可以更加稳健，无需经常被平台牵着鼻子走，有问题持续优化总会越来越好。
我写过十好几种语言，dart 是我目前为止最喜欢的语言。除去个人喜好，客观来说 dart 其实是一门很适合跨平台的语言，首先是它原生支持 jit 和 aot ，分别可以实现前端开发时即时生效，边写代码边看效果(也就是所谓 hot reload 或者 live edit)的高效开发(比 java,oc,qt 这些强)，以及在各个平台上无需虚拟机和复杂依赖而高效地运行(比 js/ts 这些需要解释器和 swift,kotlin 跨平台运行难度高的强)。再来这门语言的语法总的来说相当平庸(褒义)，但凡了解过 java,js,python 等主流语言就可以很快上手，而且吸收了各种现代的语法特性，取得了开发效率和学习难度之间的平衡(比 go,rust 等特立独行的好掌握，比 kotlin 这种语法糖多到腻的简单)，相对比较简单的语法特性也让它的 sdk 跨平台维护的成本较低，现在可以直接同时 compile 到 native binary 和 js 的语言就不多。很多人受不了 dart/flutter 的点无外乎是所谓的“嵌套”，我觉得主要是两点，一个是没有认识到 UI 的本质其实就是嵌套，用嵌套来表达 UI 其实才是最高效且接近本质的方式，再来就是被原生和 web 开发 UI 描述和逻辑分离的固有模式束缚，内心里抵触把整个 UI 应用抽象成“UI=fn(state)”这样统一的模型。其实 jsx 也是“ui in js”的方案，react 有段时间也推崇过“css in js”乃至“all in js”(个人认为它们没有普及成功更多是因为 js 本身的能力问题以及相关工具链没跟上导致的)，可以认为 flutter 就是实现了终极版的“all in dart”，是一种 react 在跨平台领域的完全进化体。