最近一直在想前端與 DSL 的一些聯繫與發展，DSL 的概念在後端工程師中可能會更加熟悉，但在前端領域中也是充斥着 DSL 的身影。
DSL（Domain Specific Language）中文翻譯爲領域特定語言，例如 SQL、JSON、正則表達式等。與之形成對比的是 GPL（General Purpose Language），中文翻譯爲通用程式語言，我們熟悉的C、C++、JavaScript、Java 語言等就是。
DSL 的特點，在《領域特定語言》這本書中的描述，按照我自己的理解爲：
主要分爲三類：外部 DSL、內部 DSL、語言工作臺 。
// jQuery
$('#my-div')
.slideDown()
.find('button')
.html('follow');
// Mocha
describe('User', function () {
describe('#save()', function () {
it('should save without error', function (done) {
var user = new User('Luna');
user.save(done);
});
});
});
<div>
<header>title</header>
<section>content</section>
<footer>footer</footer>
</div>
Web 前端並不是只有 HTML/CSS/JS ，其實歷史的洪流中還有 Silverlight、Flash、ActiveX 等，然而各種原因網際網路選擇了 HTML/CSS/JS 。JS 的初衷並不是爲了構建複雜 UI 而設計的，所以對於越發複雜的 Web 前端，前端的 UI DSL 也是在循序漸進的發展，HTML/CSS/JS 的規範不斷的在改進迭代，業界更是不滿足於現在標準而不斷的擴充套件，從 CSS 到 Less/Sass 、 JS/JSX、Vue 和 Angular 都有各自的元件和 Template 實現，再使用轉譯器，最終執行等效的程式碼。
通過基於現有語言，擴充套件或結合創造一種新的 UI DSL，對於前端開發者的接受程度可能會高，但現實原因只可能更復雜，各種標準規範委員會、瀏覽器廠商、前端 Runtime 等等。小程式則爲了提高互動體驗結合 Native 和 WebView 的各自優勢，UI DSL 趨向於 Web 端語法，對 Web 前端開發人員友好。
相比 Web 端，行動端因爲其原生的獨特性 UI DSL 則是出現了斷崖般的升級。例如 Object-C 到 Swift UI、Android 的 Kotlin Anko、跨平臺 Flutter 的 Dart。各語言背後都是大廠商的支援，初衷都是想開發出更好構建 UI 的語言，大家的趨勢都是 UI as Code 。
本質上行動端、Web 端雖然有些許不同，但都是前端，問題領域高度一致。UI as Code 在我看來，這個 Code 的意思，就是一門通用程式語言，然後基於這個程式語言來建立一門內部 DSL 來構建 UI ，邏輯和 UI 的程式設計都是同一門語言，更加高效並減輕開發者的負擔。
Web 前端也有類似的發展趨勢。CSS 出現了各種 CSS in JS 的方案，JS/HTML 擴充套件爲 JSX，雖然還是有着濃重的 HTML/CSS 色彩。隨着現在許多成熟的元件框架庫出現，在開發中後臺的時候，除了JS ，很多時候就幾乎只組裝元件和一些簡單的佈局，已經沒有寫很多 CSS 和直接操作 DOM。這就感同身受了一句話：「 程式設計就是在爲自己的應用程式設計 DSL 「 ，就是使用元件針對你開發的應用程式構建內部 DSL（封裝元件、方法），通過犧牲一部分通用性靈活性提高開發效率。
Facebook 可以構建出 JSX ，Microsoft 可以創造出 TS ，國內也有 Vue ，相信前端在語言層面上的更大的機遇是會抽象出更加好用的 DSL。
前端搭建系統/視覺化平臺，難點多難度大，投入風險高，潛在的回報也巨大。大廠商都在投入研發通用性更高的視覺化搭建平臺，適用範圍更廣；小廠商則會針對特定業務來開發搭建系統，難度稍低見效快。如果把範圍限定在二者之前，在一個適當的業務領域裏，研發與業務領域專家充分溝通，投入研發相關的模型和 DSL ，以視覺化作爲輔助，在靈活性和效率上找到一個平衡點，可以大大提高領域生產力。
我們經常會去嘗試建立拖拽加設定的視覺化搭建系統來解決各種不同的業務。沒有銀彈，系統的複雜度不會消失，只會轉移，這裏就容易產生COBOL 謬論：」 程式語言很難是因爲它不像我們平常交流的語言，如果把程式語言設計爲像我們平常用的語言，就會容易多了 「。"前端很難，我們把它做成可拖拽的視覺化平臺，就不需要前端開發了"。
antd 相當於是就是構建了基於 JSX 的 DSL ，在中後臺前端開發領域，通過抽象基礎的互動展示邏輯， 犧牲了極少的的可延伸性，通用性和靈活性都達到了一定程度。
視覺化搭建系統中有一個難題是，當視覺化搭建無法實現某些需求，開發者通過修改程式碼來實現需求後，之後可能就無法再繼續轉到平臺上。對於程式碼和視覺化搭建的互轉是一個難題。如果換一個思路，視覺化搭建轉成的程式碼，不是直接的 HTML/CSS/JS，而是一個新的內部 DSL 或外部 DSL ，這個 DSL 背後的模型的在靈活性和程式碼/視覺化的互轉上有特定的設計，程式碼修改，只要符合這個 DSL 的規範，則可以轉爲視覺化的平臺中。這就又回到上面的討論，沒有銀彈，以 UI as Code 爲趨勢，在某一方面上犧牲，縮小領域，換取高效。
不管是內部 DSL 或外部 DSL，盲目的創造 DSL ，造成的問題就是，大家學習與理解的負擔越來越大，因爲使用多種語言比使用一種語言複雜得多，開發可能沒有提效反而更加複雜而容易造成 bug 。
但程式的複雜性不會消失，不使用 DSL，也會需要使用不同的程式庫，好的程式庫的設計就必不可少，可謂 「 程式庫設計就是語言設計 」。然而一個好的 DSL 也應該是讓人容易理解並且容易使用，降低學習成本。
當大家陷入大量業務開發的時候，不防跳出細節，看看一些抽象和理論的東西來找找靈感。隨着網路的提速 5G、6G ，還是 AI、AR/VR 的高速發展，前端互動模式的改變和創新，前端可以探索的東西應該是越來越多的。