谷歌裁撤包括 Flutter 在内的诸多团队， Flutter 前景如何？是否还值得投入

小打小闹，说是

前景堪忧

谷歌只是主导，更多还是很多大佬参与开发维护的，这个不用担心吧

@Helsing 会让开发者担心 flutter 的背书吧.看到这种新闻肯定就要犹豫的了

现在 Google 重心转到了 kotlin 和 jetpack compose ，flutter 不怎么上心做了

只是裁员，不是裁撤

那个是整个公司级别的裁员，又不是针对某个团队裁撤。
这些标题每次都那么夸张，前几天还有个帖子说 Google 把整个 Python 团队裁掉的。。

果然只有 JavaScript 最安心,不用担心烂尾

这两天沸沸扬扬的「 Rabbit R1 就是个 Flutter app 」把 Google 吓坏了 /s

@infyni #4
之前看到一个 React 大佬的博客，Facebook 现在对 React 更不上心，现在还不是好好的

影响肯定有，有些重大功能和系统最新的特性支持没有公司全职开发，靠社区还是会比较吃力。但是 flutter 现在完成度已经很高了，是跨平台方案里综合水平最高最能打的，就算是把 flutter 相关的开发全裁了，停止所有支持，其优势也最少能保持 3 年，毕竟现在同 level 有能力的公司都在减少 UI 技术的投入，还在大力发展 UI 技术的公司实力和积累都差一截。(如果不裁员，flutter 至少是为未来 3 至 5 年的最优解，如果早期的那些核心开发大佬没走，这个优势很可能保持 5 年以上……)
其实，与其担心 flutter 的前景，还不如担心整个前端乃至“传统 IT”的前景。继续发展下去，AI 会平等的创死每一个人，前后端开发的投入和市场都会持续减少，甚至现在搞 AI 的那帮天之骄子最后也要失去资源，谁也不用说谁，都逃不掉

@debuggerx #11 QT 、AvaloniaUI ，这些不行吗？

AI 出来后，让它《写一个日赚过万的 App 》，会咋样呢？

换句话说，AI 的能力边界是什么呢？

@wxf666 QT,AvaloniaUI 主要都是桌面端，对移动端的支持差 flutter 不止一点半点，发展到现在，移动端的复杂性已经远大于桌面端了，所以但凡在跨平台方案的前提里囊括移动端，可选项也就没几个了。
你能让 AI 《写一个日赚过万的 App 》，为什么别人不能，为什么提供 AI 服务的公司不能自己让 AI 《写一个日赚过亿的 App 》？如果你以为 AI 是外挂，用了可以让人在游戏世界叱咤风云，那么实际情况很可能跟现在很多游戏一样，结果不过是变成人均外挂的神仙斗法，最后整个游戏乌烟瘴气，大家都没得玩。

@debuggerx #13
ai 尤其是个人 ai 发达后最容易受影响的就是个人终端，比如手机 app 的形式。说不定很快手表等智能穿戴设备就可以做大部分手机 app 能做的事情，唯一剩下的就是大屏展示了。而传统 pc 端影响小一些：都坐在电脑目前了还有什么不方便用的？

flutter 之前做过 主要靠 Dart 语言撑着 类 Java 语言 做移动端如果做过 Java 比较好上手(做 Kotlin 也好) 现在不好说 但是 Flutter 的应用运行感觉有点慢...

@Chad0000 继续发展下去，可能以后手表手机不需要触摸屏，电脑不需要鼠标键盘，而是只需要麦克风摄像头甚至脑机接口，本质上变成一样的“AI 终端”，除了屏幕尺寸没有任何区别了

大背景是科技行业的裁员潮并没有停止。谷歌整体都裁，flutter 团队并没有背更多的比例

现在学东西不要考虑那么长远了，就看能不能快速上来作出项目，配合 AI 辅助编程顺利与否，谁也说不清楚 2 年之后演变成什么状态了

@debuggerx #13 看了看 AvaloniaUI 的展示案例，确实手机端很少，只有两个。界面看起来还行。。

QT 我一时也想不到，手机上的应用有啥。。

所以你觉得 AI 的能力边界是什么呢？

其他人也能写出赚这么多钱的，那就直接让他《写一个机器人，能日种几亩田》之类的。。？

都去搞 AI ，能融资赚钱才是王道。5 年后再看 AI

@debuggerx 是这样的！

@coolmenu 看公司需求，怎么能多干几年，就学啥...

https://github.com/flutter/flutter/issues 5k+ 的 issue ，何时能修好啊

不能赚大钱的部门不是我皮查伊的兄弟

说的很多遍了, Flutter Dart 这一套是邪道, 迟早完蛋. 别浪费时间了.

@debuggerx #11

好奇对 react 这边是怎么看的。

我个人觉得 flutter 的自绘和 dart 语言使得它似乎并不是最好的选择?

@flyqie react native 如果没了还可以写写 ionic

@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 在跨平台领域的完全进化体。

不赞成楼上的看法， 我觉得未来谷歌会彻底放弃 flutter.
1.按照目前国内小程序和 uniapp 的趋势来看，h5app 没啥问题，普通人看不出来，
2. 如果要做跨平台，android 内嵌 webview, pc
内嵌 webview 完全可以解决 ui 和样式不统一的问题，ios 可能未来要放开第三方独立内核才有更好的解决方案。

微信 pc 端和安卓客户端完全可以使用统一的 chrome 版本

再不济，谷歌还有 jetpack compose 的跨平台方案，为啥还要支持 flutter?

用 Expo 呗，RN 新架构已经彻底移除了 js bridge ，还不错的.

移动端 Flutter 已经是目前最能打的跨平台方案了，尽管性能还是不尽人意，其他的吹牛的年数虽然多，但是没什么用，只要 APP 与原生结合过多就直接歇菜，Flutter 发展这么多年，现在已经到最成熟的时期了，毕竟可用的第三方库已经比较完善了，google 放不放弃意义不大，毕竟连 compose 这种东西都没多少开发者愿意用了。