背景当下，构建交互式应用程序的主流技术是 Web 技术，其中包括 HTML、CSS 与 JavaScript。在过去的 10 年，Web 技术生态发生了翻天覆地的变化，包括层出不穷的开发框架，诸如 React、Vue、Svelte，也包括日新月异的前端工程化工具，比如 Webpack、esbuild、Vite 等等。但归根结底，他们都逃不开 HTML、CSS、JavaScript 三剑客的范畴。Web 技术生态成熟、稳定，然而却存在一个致命的问题：使用 Web 技术去构建跨平台应用程序并不是一件简单的事情。这也是为什么许多平台特定的框架（platform-specific frameworks）与跨平台框架（cross-platform frameworks）依然受到欢迎的原因。比如其中最著名的跨平台框架 Flutter，它部分基于浏览器引擎的技术，实现了「编写一次，全平台运行」的目标。而且这些框架，也基本不使用 HTML、CSS 这些 Web 技术。这是为什么呢？苦 HTML+CSS 久已因为 HTML 诞生的目的问题，以及 HTML 与 CSS 的开发体验问题。HTML 即超文本标记语言，最初是三十年前为了制作可链接的文档而发明的，而不是为了做应用程序。它更多是一种标记而不是一种语言。大多数人甚至都不将编写 HTML 视为编程，因为它根本不是一种编程语言。直到出现 HTML5 （通常被称为 H5）、CSS3 和 ES5 版本之后的 JavaScript，人们才逐渐开始用这些技术制作 Web 应用程序。在那之前，HTML 只是用于完成他最开始的目的。但做成 Web 应用的可行性，最大还是来自于 JavaScript 性能的提升。上面是 Lin Clark 介绍 JavaScript 性能历史的一张图。从2008年开始，JavaScript 性能就开始飞速提升。这对于应用程序的最终用户来说有巨大的好处，因为做出来的应用程序终于不卡了，甚至可以对性能有所期待了。但是，对于开发者来说，仍然逃不开编写 HTML+CSS。就算使用一些前沿的前端框架，如 React、Vue、Angular 等，我们仍然需要编写类似 HTML 的代码，并仔细调整 CSS 或者 CSS 预处理器（如 SCSS、Saas）的样式表。这缓慢、枯燥、而且乏味。太多的人力、时间被浪费在实现图形用户界面的细节上，使用一些并不是一开始就为了 UI 而设计的技术。这导致开发者经常要来回调整样式、处理浏览器兼容性问题、应用奇怪的 CSS 技巧、避开性能陷阱等等。另外，还需要在过度发展的 NPM 生态系统中，使用那些复杂的前端工程工具来进行应用程序的构建。这个过程效率也非常低下，开发体验非常痛苦。更不要说 Web 应用在跨平台需求中会遇到更多的陷阱，比如平台兼容性、体积大小、性能问题，等等。此刻，我们质疑，坚持使用 HTML 和 CSS 的理由到底是什么？其他非 Web 框架然后我们再回过头来看看其他的非 Web 框架。Electron 首先被我们排除。虽然微软用它做出了 VSCode 这样成熟的跨平台应用程序，但也投入了巨大的成本，并且一般开发者可没有这么雄厚的财力。但最关键的是，VSCode 其实是用 Web 技术做出来的，Electron 只是帮助它做成了跨平台应用而已。看看我们还有什么其他选择：有一些是自计算机黄金时代开始就存在的特定平台的框架，例如 Windows 的 MFC，macOS 的 Cocoa，以及 UNIX/Linux 的 GTK。其他一些则是更现代的移动端框架，如专门为 iOS、Android 或其他移动操作系统专门服务的开发框架。而在跨平台框架中，值得注意的是广泛采用的 Qt 框架。但它主要用于桌面软件开发。这里的跨平台主要是指跨越不同的桌面操作系统，如 Windows/Linux/macOS，但这几年 Qt 也逐渐在往移动端与 Web 端在努力，虽然没有取得什么成就。第三种就是这几年开始流行的全新跨端方案，如 Flutter，它是一个以移动端为主的跨平台框架，但在 Web 端和桌面端也有所作为。随着近年来 Web 应用的比例不断增加，桌面端应用逐渐式微。但正是因为 Web 应用在跨端上的致命问题，这些非 Web 框架仍有一席之地，并且看上去也具有不可替代性。当然，其中的某些年代过于久远的开发框架，开发人员的体验甚至比编写 HTML 更糟糕，因为他们可能被迫编写类似于这样的命令式和面向对象的代码。var count = 0 let stack = new VStack let text = new Text("Count: \(count)") stack.add_child(text) let button = new Button("Increment") button.set_onclick(