前端苦HTML+CSS久已

　　当下，构建交互式应用程序的主流技术是 Web 技术，其中包括 HTML、CSS 与 JavaScript。

　　在过去的 10 年，Web 技术生态发生了翻天覆地的变化，包括层出不穷的开发框架，诸如 React、Vue、Svelte，也包括日新月异的前端工程化工具，比如 Webpack、esbuild、Vite 等等。

　　但归根结底，他们都逃不开 HTML、CSS、JavaScript 三剑客的范畴。

　　Web 技术生态成熟、稳定，然而却存在一个致命的问题：使用 Web 技术去构建跨平台应用程序并不是一件简单的事情。

　　比如其中最著名的跨平台框架 Flutter，它部分基于浏览器引擎的技术，实现了「编写一次，全平台运行」的目标。而且这些框架，也基本不使用 HTML、CSS 这些 Web 技术。这是为什么呢？

　　因为 HTML 诞生的目的问题，以及 HTML 与 CSS 的开发体验问题。

　　HTML 即超文本标记语言，最初是三十年前为了制作可链接的文档而发明的，而不是为了做应用程序。它更多是一种标记而不是一种语言。大多数人甚至都不将编写 HTML 视为编程，因为它根本不是一种编程语言。

　　直到出现 HTML5 （通常被称为 H5）、CSS3 和 ES5 版本之后的 JavaScript，人们才逐渐开始用这些技术制作 Web 应用程序。在那之前，HTML 只是用于完成他最开始的目的。

　　但做成 Web 应用的可行性，最大还是来自于 JavaScript 性能的提升。

　　上面是 Lin Clark 介绍 JavaScript 性能历史的一张图。从2008年开始，JavaScript 性能就开始飞速提升。这对于应用程序的最终用户来说有巨大的好处，因为做出来的应用程序终于不卡了，甚至可以对性能有所期待了。

　　就算使用一些前沿的前端框架，如 React、Vue、Angular 等，我们仍然需要编写类似 HTML 的代码，并仔细调整 CSS 或者 CSS 预处理器（如 SCSS、Saas）的样式表。

　　太多的人力、时间被浪费在实现图形用户界面的细节上，使用一些并不是一开始就为了 UI 而设计的技术。这导致开发者经常要来回调整样式、处理浏览器兼容性问题、应用奇怪的 CSS 技巧、避开性能陷阱等等。

　　另外，还需要在过度发展的 NPM 生态系统中，使用那些复杂的前端工程工具来进行应用程序的构建。这个过程效率也非常低下，开发体验非常痛苦。更不要说 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 更糟糕，因为他们可能被迫编写类似于这样的命令式和面向对象的代码。

　　Flutter 真正实现了跨平台，可以制作所有桌面、移动和 Web 应用程序。

　　不过也还是有开发者不喜欢 Flutter，因为它引入了另一种新的、陌生的语言 Dart，以及额外的虚拟机负担。

　　Flutter 真正的问题在于与现有生态系统的兼容性，因为人们倾向于更喜欢重用已建立的资源和维护成熟的应用程序。编程语言也是出于同样的原因。

　　为了解决 Flutter 的一些问题，有些优秀开发者们尝试开发了 Flutter 的 JavaScript 版本，虽然后来失败了。因为 Flutter 本身正在迅速迭代，以至于两者无法融洽。不过这部分的工作导致诞生了 Kraken 框架，它允许编码人员编写 HTML，并使用 Flutter 引擎进行跨平台渲染。

　　尽管如此，我们不得不承认，HTML+CSS 是表示 UI 的一个很好的组合，因为：

　　但是在实践中，UI 的工程有时是没有意义且不必要的。假设我们已经有了设计师提供的高保真设计原型，编码人员需要做的是：

　　使用代码重新实现设计原型，这在 99% 的情况下是 HTML+CSS 的事情。

　　第一部分总是让人头疼的源头：涉及大量的细节、耗时、需要与设计师进行讨论反复沟通，沟通成本很高，如果设计更新，代码也需要更新，也许还需要另一场“昂贵”的讨论。

　　更不用说，这种工作通常被视为费时费力没技术含量工作，也因此就有了大家听到的前端程序员通常被其他非前端程序员所鄙视。

　　一些聪明的开发者想出了使用编译器技术或更具体地说是转换器技术来实现设计到代码的解决方案，将整个高保真设计转换为机器生成的 HTML+CSS 代码。这个就是所谓的 Design to Code。

　　但它是为产品经理和设计师量身定制的，而不是为开发人员。这种内在问题包括但不限于：

　　生成代码的不易集成。如果它依赖于另一个第三方库怎么办？如果生成的代码更新了，整个大片的变化在版本控制系统中体现是否合理？

　　像 Sketch 或 Figma 这样的设计工具，总是可以设计出比 HTML+CSS 可以实现的更高级的视觉效果。他们甚至可以精确控制每一个像素。而很多时候，生成的代码可能无法产生与设计原型完全相同的 UI，绝对需要一些补丁。但如果生成的代码更新了，补丁就无法再应用了怎么办？

　　总之，从开发者的角度来看，Design to Code 不是一个好的技术解决方案。

　　因为设计稿完全替代了 HTML+CSS 的角色，设计就是代码。请记住 VGG 的第一性原则：通过消除冗余的开发工作来弥合设计与开发两方之间的巨大鸿沟。

　　很明显的优势：图形用户界面的设计和开发只需要进行一次，因为两者实际上是一体的。因此两者的摩擦、讨论会减少，这让双方都更高效。

　　对于开发人员来说，他们能够直接在设计文件上编写业务逻辑，然后由 VGG 将其运行为一个交互式图形应用程序。这可以节省大量重复的工作，不仅提高了开发人员的工作效率，也为整个团队增加了工作效率。

　　Design as Code 的想法很简单，但它实现起来非常困难，比如会遇到来自编译器技术、编程接口抽象和图形渲染方面的工程挑战。

　　VGG 天生就有着对开发生态很好的兼容性。相比于低代码，VGG 是一套真正为开发者设计的工具。小结：

　　基于以上两点，VGG 以及它主打的 Design as Code 可以为现代交互式应用开发带来巨大的好处。在最终用户对用户界面的实际使用效果没有明显感知差异的前提下，大大提升了应用开发者的开发体验，甚至可以让设计师、产品经理来承担一部分的界面开发工作：无非是把现有的设计工具当作一个 UI Builder 来使用罢了。

　　在这篇文章中，我们讨论了 Web 技术、特定平台的框架、跨平台框架、Design to Code 解决方案以及基于 VGG 开源引擎的 Design as Code 开发流程。

　　我们提出了 Design as Code 的概念，介绍了 VGG 作为一个全新的开发交互式图形应用程序的框架。但 VGG 仍然年轻，因为还有许多技术挑战需要克服，VGG 运行时引擎现已开源，欢迎大家一起参与 VGG 开源社区共建。

　　关于 VGG 的更多细节将在后续的文章中讨论。如果您感兴趣，可以继续阅读官方博客和文档

　　VGG（VeryGoodGraphics）是新一代跨平台应用开发解决方案。VGG 倡导 Design-as-Code 的理念，让开发者可直接基于设计稿编程，快速将设计原型交付为可交互的应用。特性一：无代码完美还原设计稿VGG 自研的开源图形引擎能渲染出高保真设计稿中的任意细节，可直接将设计稿作为用户界面，省去前端与客户端开发者使用代码去复原设计稿的开发工作，降低他们与设计师之间的沟通摩擦成本。特性二：原生跨平台、嵌入式支持已有开发框架VGG 通过完全或者部分嵌入的方式，支持在任意一种已有的 APP 基础上进行增量式开发，主持主流平台与框架。特性三：脚本与 WebAssembly 支持VGG 还同时支持平台无关的 JS 脚本与 WebAssembly 模块，在提供快速业务逻辑开发能力的同时支持高性能计算。特性四：高度的生态兼容性VGG 提供的 SaaS 服务目前已实现对主流设计生态的兼容（Figma/Sketch/Adobe Illustrator），并提供 Figma 插件帮助设计稿快速同步。将来还计划为开发者提供开发辅助工具，打通从应用 UI 设计到应用研发的完整流程。球速体育官方网站