作為軟件工程師的你，一定聽說過低代碼（LCNC） 工具吧？來自谷歌的低代碼趨勢圖顯示，人們對“低代碼”一詞的興趣越來越濃厚。

圖 1：谷歌趨勢圖

此外，低代碼方面的相關投入也不斷加大，來自 Spreadsheetweb 的調查數據顯示如下：

圖 2：Spreadsheetweb 調查統計

盡管受全球經濟形勢持續低迷的影響，低代碼相關投資熱度驟減，但是 Spreadsheetweb 預測：到 2027 年，“低代碼開發平臺市場”將達到 848 億美元（預測平均值）規模，前景非常樂觀。

圖 3：Spreadsheetweb 調查統計

不過數據歸數據，回到低代碼本身，它真的對軟件開發有幫助嗎？

本文從低代碼工具與開發應用程序的經典方式，低代碼工具創建真正自定義應用程序的功能，以及低代碼工具替代方案（網站模板和經典 IDE）等方面，給低代碼市場的火熱潑一潑冷水。

1.什么是低代碼？

低代碼工具有望解決構建 Web/移動應用程序所涉及的大量成本和時間問題，盡量減少或干脆免去花費在昂貴工程資源上的資金，至少廠商是這樣承諾的。

典型的低代碼工具試圖通過為用戶提供拖放式界面來開發 Web 應用程序，即用戶將 UI 元素放在畫布上，將它們彼此連接后，再連接到數據源，并為某些元素添加某些操作，從而構建應用程序。

換句話說，低代碼工具為可視化軟件開發提供了一個環境，而不是用工程師在 IDE 中編寫代碼這種傳統方式。低代碼方法被認為更高效，而且只需較少的專業技能即可。

以下是在谷歌上搜索“無代碼工具”時，第一頁上提及的幾款低代碼工具：

圖 4：包括 Bubble、Retool、Microsoft Power Apps、Adalo、Webflow 和 Google Appsheet

2.低代碼繼承了可視化編程語言的弊端？

雖然被宣傳為一種全新的軟件開發方法，實則低代碼工具并不新穎，在經驗豐富的工程師眼里它就是一種熟悉的“可視化編程語言”。

可視化創建程序的想法從編程早期就存在了，但由于一些原因，它從未被廣泛采用。

據維基百科解釋，“可視化編程語言（VPL）允許任何用戶通過圖形方式操作程序元素，而不是用文本方式。”

現在不妨將這句話與維基百科對低代碼開發平臺的定義進行比較：“低代碼開發平臺允許程序員和非程序員采用圖形化用戶界面并進行配置，并不非要用傳統的計算機編程方式來創建應用軟件。”

這兩個解釋聽起來是不是有些相似？還是完全相似？想要知道為什么低代碼并非我們想象般前景廣闊，有必要先分析一下可視化編程語言為何并未廣受歡迎。

Ivan Danyliuk 在其文章中表示：可視化編程最適合定義空間關系（圖形元素和 UI），而文本編程最適合定義時間關系（時間軸上的事件順序）。

換句話說，人腦很容易可視化映射空間的物理對象，而不是使用文本來描述它們；很容易以文本方式描述事件的順序（算法或指令），而不是繪制流程圖。這是人腦的一種自然屬性，因此不要逆著來，最好適應這樣的規律。

使用可視化編程的另一個問題是，相對于更容易、更快將想法付諸實踐的用鍵盤打字，它實際上增加了另一層抽象（鼠標和屏幕）。換句話說，打字比移動鼠標更快。

Ivan還認為（我認同）：“可視化編程語言”從未廣泛流行起來的原因，在于人們希望以文本方式而不是以可視化方式給出指令。從我的角度來看，這與低代碼工具從長遠來看會失敗的原因一樣——算法更擅長以文本形式讀寫。低代碼/無代碼工具試圖像“可視化編程語言”那樣以可視化方式對待軟件開發，這同樣繼承了可視化編程語言的弱點，在我看來，注定落得同樣的命運。

3.編寫代碼在軟件行業永遠不會過時

此外在我看來，低代碼工具不是圖靈完備的——用低代碼工具只能達到有限的配置集。

如果一個系統能解決任何計算問題，不管有多困難，只要它有足夠的時間和內存以及相關的指令，就可以說它是圖靈完備的。

由于指定指令（時間關系和事件順序）的最佳方式是文本形式，指定這些指令的能力將因低代碼工具的性質而被削弱，因此使整個方法受到限制。

編程語言實際上是自然語言的計算機可讀版本，足以描述任何數量的對象之間的任何關系。

這意味著為了在低代碼工具中保持靈活性，要想構建一個真正符合特定需求的應用程序，用戶就要在低代碼工具中編寫代碼（SQL 查詢、JavaScript 注入或模板等），這在前面提到的一些工具中已成為可能，最終使低代碼工具成為了 IDE。

看看下邊的邏輯：

• 我想構建一個盡量減少代碼編寫量的應用程序；
• 我使用低代碼工具創建一個應用程序；
• 我需要擴展應用程序以滿足我的特定要求，因此我在低代碼工具中編寫代碼；
• 由于我已經在編寫代碼了，何不先安裝一個 IDE，然后用正常的方式編寫代碼？

因此，為了能夠構建功能完備的軟件，低代碼工具需要與 IDE 融合，因此將與當前產品（Visual Studio 和 JetBrains）競爭。

從我的角度來看，向 IDE（即 UI 構建器）添加低代碼功能比從頭開始構建新的復雜 IDE 來得容易。

此外，低代碼工具基于瀏覽器，因此 IDE 也必須基于瀏覽器，這限制了其功能。這就是為什么我認為編寫代碼在軟件行業永遠不會過時。

4.為何沒人談論模板市場？

模板、入門工具包、主題、樣板，這些詞的含義非常相似，即一組文件和文件夾充當應用程序的起點。

有各種示例，比如 Github 上的免費模板（比如 create-react-app 或 react-material-admin）、有大量 WordPress 主題的 ThemeForest、Template Monster、Creative-Tim 和 Flatlogic 以及專門面向 Web 模板的資源等。

自 2013 年發布以來，僅 Flatlogic 就銷售了至少 20000 份許可證。Metronic 銷售的許可證超過 100000 份。免費模板的使用則更廣泛。每天有多少用戶在使用 create-react-app？

在我看來，模板創造了真正的價值。也許這是我的偏見，但我不知道任何單單使用低代碼構建的實際應用程序。

最終，人們需要自定義應用程序作為代碼，而不是作為服務，因為擁有代碼為定制、擴展和集成提供了無限的機會。

所以關鍵是模板市場是需要顛覆和創新的市場，而低代碼市場不是這樣的市場，因為最終每個人都需要編寫代碼。首先，模板市場很活躍。

可能最重要的玩家是 Envato，單單它一家的年收入就超過 2 億美元，盈利達 3600 萬美元。

我估計，就今天的整個市場規模而言，如今幾大市場玩家獲得的實際收入至少達 10 億美元。但是你從來沒有在新聞中聽說過這個市場。

我認為低代碼工具方面的投入多得多，模板/主題方面卻沒有投入，這是由于向投資者推銷不用編程就能創建 Web 應用程序的“靈丹妙藥”要容易得多，因為大多數投資者并不通曉技術，因此不明白本文中解釋的這些內容。

各種“研究”預測幾年后低代碼市場規模可達到多少億美元也起到了造勢的效果，相反根本沒人談論模板市場。

這就是為什么我們創建了一個工具，可以根據一些輸入（比如技術堆棧、UI 設計和數據庫模式）生成全棧 Web 應用程序的代碼庫。

我們并不在產品上貼上無代碼標簽來緊跟潮流，而是解決實際市場的實際問題。

作者：Philip Daineka

標題：??Hard limits of low-code/no-code and what is an alternative solution??