什么是低代碼

低代碼是指通過少量代碼就可以快速生成應用程序的開發平臺，通過可視化進行應用程序開發的方法，使具有不同經驗水平的開發人員可以通過圖形化的用戶界面，使用拖拽組件和模型驅動的邏輯來創建網頁和移動應用程序。

可視化 是低代碼唯一不可缺少的功能。

可視化編輯

對于實現可視化編輯來說，必要條件是聲明式。與聲明式相對的，還有一種編碼模式叫命令式。

比如要實現一個藍色的方塊，HTML、CSS 就是聲明式，來實現它，只需要這么寫：

而如果換成使用命令式的 javascript 來實現，則可能會這么寫：

兩種方式最終展現效果是一樣的，但這兩種代碼在實現思路上有本質區別：

聲明式直接描述最終效果，不關心如何實現。而命令式則關注如何實現，明確怎么一步步達到這個效果。

回到可視化編輯器的角度看，它們的最大區別是：聲明式可以直接從展現結果反向推導回源碼，命令式則無法做到反向推導。

反向推導是編輯器必備功能，比如編輯器里的常見操作是點選這個區塊，然后修改它的顏色，在這兩種代碼中如何實現？

如果是聲明式的 HTML CSS，可以直接改 style 的 background 值，而基于 Canvas 的命令式代碼則無法實現這個功能，因為無法從展現找到實現它的代碼，因為命令式代碼實現同樣效果的可能方式是無數的，除了前面的示例，下面這段代碼也可以實現一樣的效果：畫一條長 100，粗 100 的線段，在最終視覺呈現上也可以看做是一個矩形。

因此可以簡單得到一個結論：命令式代碼無法實現可視化編輯，而可視化編輯是低代碼唯一不可少的功能，所以所有低代碼平臺必然只能采用聲明式代碼，這也是為什么所有低代碼平臺都會有內置的 DSL。

聲明式語言的優缺點

這些聲明式語言有以下優點：

（1）容易上手，因為描述的是結果，語法可以做得簡單，非研發也能快速上手 HTML 及 SQL。

（2）支持可視化編輯，微軟的 HTML 可視化編輯 FrontPage 在 1995 年就有了，現在各種 BI 軟件可以認為是 SQL 的可視化編輯。

（3）容易優化性能，無論是瀏覽器還是數據庫都在不斷優化，比如可以自動改成并行執行，這是命令式語言無法自動實現的。

（4）容易移植，容易向下兼容，現在的瀏覽器能輕松渲染 30 年前的 HTML，而現在的編譯器沒法編譯 30 年前的瀏覽器引擎代碼。

而這些語言的缺點是：

（1）只適合特定領域，命令式的語言比如 JavaScript 可以用在各種領域，但 HTML CSS 只適合渲染文檔及界面，SQL 只適合做查詢。

（2）靈活性差，比如 SQL 雖然內置了很多函數，但想只靠它實現業務是遠遠不夠的。

（3）調試困難，遇到問題時如缺乏工具會難以排查，如果你在 Firefox 出現前開發過頁面就會知道，由于 IE6 沒有開發工具，編寫復雜頁面體驗很差，遇到問題要看很久代碼才發現是某個標簽沒閉合或者 CSS 類名寫錯了。

（4）強依賴運行環境，因為聲明式只描述結果而不關注實現，因此強依賴運行環境，但這也帶來了以下問題：

1）功能取決于運行環境，比如瀏覽器對 CSS 的支持程度決定某個屬性是否有人用，雖然出現了新的 CSS 提案，但 Firefox 和 Safari 都不支持，而且上手成本太高，預計以后也不會流行。

2）性能取決于運行環境，比如同一個 SQL 在不同數據庫下性能有很大區別。

3）對使用者是黑盒，使用者難以知道最終實現，就像很少人知道數據庫及瀏覽器的實現細節，完全當成黑盒來使用，一旦遇到性能問題可能就不知所了。

4）技術鎖定，因為即便是最開放的 HTML 也無法解決，很多年前許多網站只支持 IE，現在又變成了只支持 Chrome，微軟和 Opera 在掙扎了很多年后也干脆直接轉向用 Chromium。同樣的即便有 SQL 標準，現在用的 Oracle/SQL Server 應用也沒法輕松遷移到 Postgres/MySQL上。低代碼行業未來也一樣，即便出了標準也解決不了鎖定問題，更有可能是像小程序標準那樣發展緩慢，功能遠落后于微信。

因為低代碼就是一種聲明式編程，所以這些聲明式優缺點，就是低代碼的優缺點。

低代碼的實現方案

以前端的實現來說，其核心是界面渲染。前面提到前端 HTML CSS 可以看成一種描述界面的低代碼 DSL，因此前端界面實現低代碼會比較容易，只需要對 HTML CSS 進行更進一步封裝，定義 JSON schema。比如用類似如下的方式來描述頁面：

這里大家幾乎全都使用 JSON 主要是兩方面原因：

低代碼平臺編輯器幾乎都是基于 Web 實現，JavaScript 可以方便操作 JSON。JSON 可以支持雙向編輯，它的讀取和寫入是一一對應的。因此界面呈現上的低代碼實現起來，我們只需要豐富物料庫，通過拖拽這些物料拼出想要的東西后生成 json 描述即可。

再來說說交互邏輯的實現。

前面說到前端界面低代碼是比較容易，但交互及邏輯處理卻很難低代碼化，目前常見實現有三種方案：

1、使用圖形化編程；

2、固化交互行為；

3、使用 JavaScript；

先說第一種圖形化編程，這是非常自然的想法，既然低代碼的關鍵是可視化，那直接使用圖形化的方式編程是否可行？

但這么做局限性很大，本質的原因是命令式的代碼無法可視化。即便將循環、分支判斷、或操作符等等這些抽象為一塊塊的積木，也難以像拼接積木一樣得到想要的東西，因為積木拼接這種方式只適合用來實現簡單的邏輯，對于復雜的交互邏輯非常難以實現。

再來說固化交互行為，如果是面向特定領域，低代碼平臺可以先將這個領域難以圖形化的邏輯預置好，讓使用者只需做簡單的處理，使用的時候只需要調整參數就行。當然這個方案最大的缺點是靈活性很低。

因此要實現更靈活的控制，還是得支持第三個方案：JavaScript，目前很多低代碼平臺只在界面編輯提供可視化編輯，一旦涉及到交互就得寫 JavaScript，但該方案脫離了低代碼范疇、不是低代碼。

下面來看個實例，以阿里的 datav 中的藍圖編輯器為例，它就是同時支持了 3 種方案進行互補：

一些簡單邏輯用戶可以自己通過藍圖編輯器去添加然后串并聯這些節點來實現。對于使用場景較多的一些較復雜的行為可以內置固話。而對于較復雜的邏輯用戶可以自己通過 js 處理。

總結：

通過以上分析，可以看出在定制化較強的業務中，低代碼幾乎沒有用武之地，但基于特定領域或方向的低代碼平臺還是很有意義的。將其作為一類工具，趁手時即可使用。