背景
當下，構建互動式應用程式的主流技術是 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 框架。
Ele
ctron
首先被我們排除。雖然微軟用它做出了
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)
不是編寫 聲明式 且響應式的程式碼，就像 程式設計師一直夢寐以求的 這樣：
structAppState{count: i32}VStack {Text("count: \(state.count)")Button("Increment") { state.count += 1 }}
這就是為什麽 Flutter 看起來像是開發應用程式的靈丹妙藥：
Flutter 是聲明式且響應式的。
Flutter 真正實作了跨平台，可以制作所有桌面、移動和 Web 應用程式。
不過也還是有開發者不喜歡 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 的事情。
為剛剛重新實作的 UI 添加業務邏輯。
第一部份總是讓人頭疼的源頭：涉及大量的細節、耗時、需要與設計師進行討論反復溝通，溝通成本很高，如果設計更新，程式碼也需要更新，也許還需要另一場「昂貴」的討論。
更不用說，這種工作通常被視為費時費力沒技術含量工作，也因此就有了大家聽到的前端程式設計師通常被其他非前端程式設計師所鄙視。
一些聰明的開發者想出了使用編譯器技術或更具體地說是轉換器技術來實作設計到程式碼的解決方案，將整個高保真設計轉換為機器生成的 HTML+CSS 程式碼。這個就是所謂的 Design to Code。
但它是為產品經理和設計師量身客製的，而不是為開發人員。這種內在問題包括但不限於：
生成的程式碼可讀性差，不符合計畫中現有的編碼風格。
生成程式碼的不易整合。如果它依賴於另一個第三方庫怎麽辦？如果生成的程式碼更新了，整個大片的變化在版本控制系統中體現是否合理？
像 Sketch 或 Figma 這樣的設計工具，總是可以設計出比 HTML+CSS 可以實作的更高級的視覺效果。他們甚至可以精確控制每一個像素。而很多時候，生成的程式碼可能無法產生與設計原型完全相同的 UI，絕對需要一些修補程式。但如果生成的程式碼更新了，修補程式就無法再套用了怎麽辦？
總之，從開發者的角度來看，Design to Code 不是一個好的技術解決方案。
現在讓我
們看看什麽是 Design as Code。
Design as Code
在 VGG 所倡導的 Design as Code 開發流程中，使用者可以在某種程度上拋棄 HTML+CSS。
因 為設計稿完全替代了 HTML+CSS 的角色，設計就是程式碼。請記住 VGG 的 第一性原則：透過消除冗余的開發工作來彌合設計與開發兩方之間的巨大鴻溝。
很明顯的優勢： 圖形化使用者介面的設計和開發只需要進行一次，因為兩者實際上是一體的。 因此兩者的摩擦、討論會減少，這讓雙方都更高效。
對於開發人員來說， 他們能夠直接在設計檔上編寫業務邏輯 ，然後由 VGG 將其執行為一個互動式圖形應用程式。這可以節省大量重復的工作，不僅提高了開發人員的工作效率，也為整個團隊增加了工作效率。
Design as Code 的想法很簡單，但它實作起來非常困難，比如會遇到來自編譯器技術、編程介面抽象和圖形渲染方面的工程挑戰。
因此，為了實作 VGG 的 Design as Code 開發流程
VGG 定義了下一代向量圖形規範 VGG Specs (https://docs.verygoodgraphics.com/specs/overview)
實作了 VGG runtime 開源引擎 (https://github.com/verygoodgraphics/vgg_runtime)
提供各種 VGG 容器，實作了對各種平台和框架的嵌入式支持。
VGG 天生就有著對開發生態很好的相容性。相比於低程式碼，VGG 是一套真正為開發者設計的工具。小結：
VGG 主打 Design as Code，直接使用設計稿代替 HTML+CSS 去實作使用者介面。
VGG 將設計稿變成了跨平台的套用，為開發者節約了更多的時間與成本。
基於以上兩點，VGG 以及它主打的 Design as Code 可以為現代互動式套用開發帶來巨大的好處。在終端使用者對使用者介面的實際使用效果沒有明顯感知差異的前提下，大大提升了套用開發者的開發體驗，甚至可以讓設計師、產品經理來承擔一部份的界面開發工作：無非是把現有的設計工具當作一個 UI Builder 來使用罷了。
下面參照來自 VGG Github 首頁的一張圖，來更好地說明 Design as Code 的概念與 VGG 的有機組成：
展望
在這篇文章中，我們討論了 Web 技術、特定平台的框架、跨平台框架、Design to Code 解決方案以及基於 VGG 開源引擎的 Design as Code 開發流程。
我們提出了 Design as Code 的概念，介紹了 VGG 作為一個全新的開發互動式圖形應用程式的框架。但 VGG 仍然年輕，因為還有許多技術挑戰需要克服，VGG 執行時引擎現已開源，歡迎大家一起參與 VGG 開源社群共建。
關於 VGG 的更多細節將在後續的文章中討論。如果您感興趣，可以繼續閱讀官方部落格和文件
https://blog.verygoodgraphics.com/
關於 VGG
VGG（VeryGoodGraphics）是新一代跨平台套用開發解決方案。VGG 倡導 Design-as-Code 的理念，讓開發者可直接基於設計稿編程，快速將設計原型交付為可互動的套用。
特性一：無程式碼完美還原設計稿
VGG
自研的開源圖形引擎能渲染出高保真設計稿中的任意細節，可直接將設計稿作為使用者介面，省去前端與客戶端開發者使用程式碼去復原設計稿的開發工作，降低他們與設計師之間的溝通摩擦成本。
特性二：原生跨平台、嵌入式支持已有開發框架
VGG 透過完全或者部份嵌入的方式，支持在任意一種已有的 APP 基礎上進行增量式開發，主持主流平台與框架。
特性三：指令碼與 WebAssembly 支持
VGG 還同時支持平台無關的 JS 指令碼與 WebAssembly 模組，在提供快速業務邏輯開發能力的同時支持高效能計算。
特性四：高度的生態相容性
VGG 提供的 SaaS 服務目前已實作對主流設計生態的相容（Figma/Sketch/Adobe Illustrator），並提供 Figma 外掛程式幫助設計稿快速同步。將來還計劃為開發者提供開發輔助工具，打通從套用 UI 設計到套用研發的完整流程。
GitHub ：https://github.com/verygoodgraphics
官網 ： https://verygoodgraphics.com /
部落格 ： https://blog.verygoodgraphics.com /
