（本文翻译改编自 VGG 官方博客 Introducing VGG and Design-as-Code Workflow）
背景
当下，构建交互式应用程序的主流技术是 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
首先被我们排除。虽然微软用它做出了
VS
Code 这样成熟的跨平台应用程序，但
也投入了巨大的成本，并且一般开发者可没有这么雄厚的财力。但最关键的是，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 = 0let stack = new VStacklet text = new Text("Count: \(count)")stack.add_child(text)let button = new Button("Increment")button.set_onclick(|| count += 1 text.set_text("Count: \(count)"))stack.add_child(button)
不是编写
声明式
且响应式的代码，就像
程序员一直梦寐以求的
这样：
struct AppState { count: i32}
VStack { Text("count: \(state.count)") Button("Increment") { state.count += 1 }}
这就是为什么
Flutter
看起来像是开发应用程序的灵丹妙药：
不过也还是有开发者不喜欢 Flutter，因为它引入了另一种新的、陌生的语言 Dart，以及额外的虚拟机负担。
Flutter 真正的问题
在于与现有生态系统的兼容性，因为人们倾向于更喜欢重用已建立的资源和维护成熟的应用程序。编程语言也是出于同样的原因。
为了解决 Flutter 的一些问题，有些优秀开发者们尝试开发了 Flutter 的 JavaScript 版本，虽然后来失败了。因为 Flutter 本身正在迅速迭代，以至于两者无法融洽。不过这部分的工作导致诞生了
Kraken
框架，它允许编码人员编写
HTML
，并使用
Flutter
引擎进行跨平台渲染。
等等...发生了什么？
在非 Web 框架中再次编写 HTML？
Design to Code
不！再也不想写 HTML 了！
尽管如此，我们不得不承认，
HTML+CSS
是表示 UI 的一个很好的组合，因为：
-
HTML 负责内容的结构，CSS 负责内容的样式。
-
但是在实践中，UI 的工程有时是没有意义且不必要的。假设我们已经有了设计师提供的高保真设计原型，编码人员需要做的是：
-
使用代码重新实现设计原型，这在 99% 的情况下是 HTML+CSS 的事情。
-
第一部分总是让人头疼的源头：涉及大量的细节、耗时、需要与设计师进行讨论反
复沟
通，沟通成本很高，如果设计更新，代码也需要更新，也许还需要另一场“昂贵”的讨论。
更不用说，这种工作通常被视为费时费力没技术含量工作，也因此就有了大家听到的前端程序员通常
被其他非前端程序员所鄙视。
一些聪明的开发者想出了使用编译器技术或更具体地说是转换器技术来实现设计到代码的解决方案，将整个高保真设计转换为机器生成的 HTML+CSS 代码。
这个就是所谓的
Design to Code
。
但它是为产品经理和设计师量身定制的，而不是为开发人员。这种内在问题包括但不限于：
总之，从开发者的角度来看，Design to Code 不是一个好的技术解决方案。
现在让我们看看什么是 Design as Code。
Design as Code
在 VGG 所倡导的
Design as Code
开发流程中，用户可以在某种程度上
抛弃 HTML+CS
S
。
因为设计稿完全替代了 HTML+CSS 的角色，设计就是代码。请记住 VGG 的
第一性原则：通过消除冗余的开发工作来弥合设计与开发两方之间的巨大鸿沟。
很明显的优势：
图形用户界面的设计和开发只需要进行一次，因为两者实际上是一体的。
因此两者的摩擦、讨论会减少，这让双方都更高效。
对于开发人员来说，
他们能够直接在设计文件上编写业务逻辑
，然后由 VGG 将其运行为一个交互式图形应用程序。这可以节省大量重复的工作，不仅提高了开发人员的工作效率，也为整个团队增加了工作效率。
Design as Code 的想法很简单，但它实现起来非常困难，比如会遇到来自编译器技术、编程接口抽象和图形渲染方面的工程挑战。
因此，为了实现 VGG 的 Design as Code 开发流程
