有好、有壞，但更多的是處于一個(gè)發(fā)展中的狀態(tài)。

一先說(shuō)好的地方

最明顯的就是能快速開(kāi)發(fā)，可視化界面和預(yù)構(gòu)建組件，肯定減少了大量編寫代碼的時(shí)間，構(gòu)建應(yīng)用程序這塊要比傳統(tǒng)的開(kāi)發(fā)模式快了幾個(gè)數(shù)量級(jí)，大概5-10倍的開(kāi)發(fā)效率提升肯定是有的。

然后像是快速做出原型這種，加快了很多速度。以前寫代碼的時(shí)候就像是在賭博，寫了大半天跑個(gè)測(cè)試心驚膽戰(zhàn)，生怕跑出個(gè)紅跑出個(gè)黃，要么就是進(jìn)去一頭牛，出來(lái)一個(gè)球。

現(xiàn)在低代碼平臺(tái)給你個(gè)前端頁(yè)面就能開(kāi)始做，有什么疑惑或者問(wèn)題，直接在頁(yè)面上跑，有什么報(bào)錯(cuò)或者bug都能快速顯示出來(lái)，省了很多時(shí)間，但凡做過(guò)程序的人都會(huì)明白這意味著什么。

最后就是對(duì)老板和企業(yè)來(lái)說(shuō)的提本增效，說(shuō)實(shí)話跟咱們打工人沒(méi)什么關(guān)系，但是正因?yàn)檫@個(gè)，低代碼才能流行起來(lái)，市場(chǎng)需求擺在這，就像雷軍說(shuō)的，豬都能飛起來(lái)。

再來(lái)說(shuō)些缺點(diǎn)

首先就是老生常談的功能受限，某些復(fù)雜的應(yīng)用程序需求可能超出了低代碼平臺(tái)的范圍，因此還是得用寫代碼的方式補(bǔ)上，其實(shí)要說(shuō)能用寫代碼的方式補(bǔ)上也還好，很多平臺(tái)硬是不給你留這個(gè)接口，你只能干瞪眼，怎么辦，做還是不做？不做就沒(méi)功能，做就要從頭開(kāi)始做，換誰(shuí)都得氣的罵娘。

其次就是過(guò)于復(fù)雜的情況做不了，你像是一些原本定制化跟業(yè)務(wù)邏輯復(fù)雜的程序，低代碼是做不出來(lái)的，比例3D游戲引擎、火箭發(fā)射系統(tǒng)等等，高度定制的底層系統(tǒng)沒(méi)法做，這是低代碼平臺(tái)本身的局限。

還有很多低代碼平臺(tái)被廠商鎖定，應(yīng)用程序沒(méi)辦法遷移到其他平臺(tái)或獨(dú)立導(dǎo)出，那你怎么辦，萬(wàn)一有一天人家倒閉跑路了，你的程序就跟著人沒(méi)了。

哪怕是國(guó)外最大的兩個(gè)低代碼平臺(tái) OutSystems 和 Mendix 也是這種"運(yùn)行時(shí)"的套路，你沒(méi)有辦法脫離他們的平臺(tái)做自己的程序，這真的很要命。而且像國(guó)外這兩家用的技術(shù)都是老框架了，跟國(guó)內(nèi)的環(huán)境基本上也是水土不服。

國(guó)內(nèi)的 iVX 就沒(méi)有這些問(wèn)題，因?yàn)楸旧砭褪菄?guó)內(nèi)環(huán)境出來(lái)的，組件和國(guó)內(nèi)互聯(lián)網(wǎng)生態(tài)集成都還不錯(cuò)，也沒(méi)什么平臺(tái)鎖定，自定義擴(kuò)展的程度高，最重要的還是能導(dǎo)出源碼.

光生成代碼這一點(diǎn)就超過(guò)現(xiàn)今的絕大多數(shù)低代碼平臺(tái)了，像 Mendix 是可以導(dǎo)出代碼，但是大多數(shù)時(shí)候都跟自家的運(yùn)行環(huán)境強(qiáng)關(guān)聯(lián)，導(dǎo)致的代碼根本就用不了。

當(dāng)然，iVX 也沒(méi)法做大型游戲引擎、復(fù)雜的底層系統(tǒng)這種，如果需要的話，還是建議你老老實(shí)實(shí)地從底層純代碼做起。