UI原生代码开发即将死去...

受到华为新平台的冲击。很多厂商都在讨论是不是要适配新的平台。但是通过我们最近一段时间的探索，发现商用移动设备在功能趋同化的同时，如果推出API/SDK不兼容的设备。会最终导致UI原生代码开发的衰落，甚至死亡。

大家有观点欢迎拍砖。

混沌中发展

作为一个使用过Delphi, Visual C++开发过Windows 95的程序员。回顾过往，不禁感叹程序员的一生会接触到很多的编程技术和架构。在商业环境变迁甚至是国际政治环境变迁越来越频繁的今天。如何以不变应万变往往是一种奢求，野望。

对于UI移动开发和桌面开发以前都是公司的两个部门。
一直习惯Windows开发的程序员，和一直使用X-Window开发的程序员，泾渭分明，老死不相往来。
一直在 iOS上开发APP的程序员有一种优越感，觉得 Android开发好像没有他们高级。

Web开发好像又是另外一个套路（W3C标准)。遵循着和原生开发完全不同的套路。

Java开发曾经也想统一桌面和移动，Applet也曾经有一段时间在做。但是后来还是被自身的笨重所淘汰。

移动开发风起云涌的时候，iOS和Android都在发展自己的原生开发工具集合。一个是基于Obj-C, Swift,一个是基于Java, Kotlin。两个阵营楚河汉界，每个网络公司都在按照两个阵营组织前端开发团队。但是随着小程序的推出，WeChat, AliPay, Telegram等都有自己嵌入的小程序。也各自开发了自己的SDK。我们需要面对的前端发布渠道又开始增多了。后来Apple, Google 推动了一下PWA技术来方便网络应用像APP一样运行在手机上。Google甚至走的更远，推出了Chrome Book这种偏重于网络应用的笔记本。Flutter似乎要统一各个端的应用了。但是新的技术层出不穷。新的平台差异不断涌现。最终世界不是我们想象的样子。

为了统一各个端的设备开发。业内还是有不少的技术。这些探索都是有意义的。
 

从HarmonyOS“原生”开发说起

HarmonyOS加入操作系统和移动设备混战是真的可歌可泣。开创一个完全不兼容的原生开发框架真的还是值得尊敬。

从我的角度看，Android的原生APP开发也不一定能成为真正的原生。Java开发的APP并不能直接和操作系统内核直接沟通。甚至App甚至大多数没有操作系统的root权限。所以，我们只能说这又是一个Android版的Eclipse。Java虚拟机的开发才能真正称之为原生。应用开发者只能使用操作系统包装好的一些功能而已。

但是HarmonyOS的“原生” APP难道真的是原生的吗？不是的，他们并不直接跟OS沟通。而是一个基于JS引擎的虚拟机上运行的程序。

我能说这是沙箱吗？您的APP和OS之间有一层虚拟机沙箱。

而HarmonyOS的ArkUI, ArkTS, 都是基于TypeScript的。所以为了方便的使用这个原生开发的框架。我们就需要和Android“原生”一刀两断。重写所有代码！而我们可能能得到的承诺是，以后你的程序可以在所有的HarmonyOS上运行，这就包括移动设备，PC，车载系统。

这种严厉的隔绝和个性，毕竟让很多小的开发厂商望而却步。但是从中我们看到的是JS在前端开发的强势地位。以至于华为热切的拥抱过来。

我们在学习HormoneyOS开发时深切的感到这种开发模式和WeChat小程序开发有很多相似之处。但是，他们不兼容。这也不能成为我的国的标准。如果能够统一WeChat小程序开发和华为“原生”开发，那将是多么大的贡献啊。

伟大的VS Code

VS Code是一个广大程序员熟悉的应用。VS Code又是一个复杂的应用。如果不是这样的应用，也许不能说明本地开发已经被舍弃。开发平台不使用本地语言来做已经是由来已久。

Delphi, VC++的开发本来就是用自己作为开发工具。这是本地开发。但是同时代的X-Windows上的开发工具已经开始用不同的编程语言了。Emacs用的是Lisp语言。Eclipse用的是Java语言。拜SWT所赐，Eclipse可以在不同的桌面平台显示几乎相同的窗口组件。而Microsoft也有自己的
Visual Studio基于.net平台开发IDE的经历。Eclipse在 Java平台的缓慢，还是让我们望而却步。

但是VS Code这个开发平台，开始全面使用JS平台进行开发桌面应用。标志着Web应用在桌面端的崛起。VS Code是基于 Elektron 底层框架。所以它能够基本上在Mac, Windows上拥有基本相同的行为。

VS Code的性能非常好，功能相当复杂，插件相当的多。着足以说明对与一个桌面应用。JS的技术栈能够做到的水平。也说明了JS引擎的优化程度已经超过了Java，而且更适合在UI领域的开发。

HarmonyOS和VS Code都选择了JavaScript技术栈。
 

我们的选择Tauri

Tauri 2.0 终于发布了，这个版本不仅延续了桌面版的应用。也开始支持iOS和Android开发。我们看到了一丝曙光。

现在大多数的软件开发团队，都是由技术积累的，我们在研究Flutter时，发现需要学习一门新的语言Dart。而React Native只能支持React框架。而公司现有的代码，我们各种各样的积累。需要跨端的时候，JS是首选的。而Tauri框架的选择灵活性给我们很大的灵活性。Electron只支持桌面开发，它注定不在我们的视野中。

而现在大多数的移动，桌面应用，对于本地资源的依赖越来越小。而且很多应用本身的就是Web发布在先。所以我们遇到的Rust开发其实并不多。这样，Tauri的执行效率和超小的发布包就让人爱不释手。

对比Elektron需要发布庞大的Chrome引擎，Tauri使用各个平台的原生引擎。这一点肯定是源自对原生引擎的兼容性的信任。我们有理由相信，Web引擎之间的差异。比操作系统原生窗口组件的差异小的多。这比Eclipse的SWT需要单独适配每个操作系统的方式有了很大的不同。

Tauri的设计目标和原则更适合我们的开发场景。我们利用App, Desktop应用，在一定程度上是为了程序比Web有更好的运行效率。另外，我们可能更需要的是App Store的发布渠道。

Tauri能一统天下吗？不知道。

得标准者得天下，得用户这得天下

现在看，只有Web开发是大家还能够遵守的最后一点儿共识。IE和Chrome的标准之争最终还是以Chrome的完全胜出结束。Windows Edge也不得不遵守更加广泛使用的功能。

Web应用必须在各个端都能展示和使用。如果押宝的话，我相信基于Web的开发，毕竟只有设备尺寸的不同。而没有API的不同。让本地开发变成一种少数人的奢侈，和设备厂商的炫技吧。商业APP开发，我们还是要用Web开发的技术栈。高效的完成功能。用户能用的功能。如果一定要标新立异，又有一些新的不兼容的东西出现。好吧，让我们看看他的价值。如果用户不买单，我们还是坚持现在的技术路线，毕竟，它已经能够支持99.99%的用户需求了。

参考
SWT: The Standard Widget Toolkit | The Eclipse Foundation
深入解析三大跨平台开发框架：Flutter、React Native 和 uniapp-CSDN博客
鸿蒙(HarmonyOS)应用开发指南_鸿蒙开发-CSDN博客

安装包体积减少91%！Tauri基础入门，下一代全平台开发框架，Tauri对比Electron有什么优势？-CSDN博客