-
全棧平臺
- 阿里-云鳳蝶
- 云鳳蝶自由畫布之道:分層模型
- 阿里-金蟬
- 阿里-宜搭
- 阿里-天馬
- 騰訊-積木
- 騰訊-lowcode
- 無遠(yuǎn)開發(fā)平臺
- 奧哲
- ivx
- 閃電數(shù)據(jù)管理
- 巴克云
- 數(shù)式科技
- 明道云 支持公共云和私有部署,私有部署在Github可獲得免費社區(qū)版下載
- 輕流
- 速融云
- 簡道云
- 炎黃盈動
- 廣州天翎myApps
- 活字格
- 起步科技
- 金蝶云-蒼穹
- 普元
- OpsMind
- xdeer
- 湘北智造
- 表單大師
- Zion/載航
- Appsmith(Github)
- 白碼
- 捷碼
- 支持業(yè)務(wù)系統(tǒng)/管理系統(tǒng)、可視化大屏、3D園區(qū)低碼快速開發(fā)
-
支持離線部署
頁面搭建
僅包含前端部分的 low code 平臺
- MAKA
- 易企秀
- 上線了
- 兔展
- 稿定設(shè)計
- 壹伴
- 創(chuàng)客貼
- 點石
- 京東-通天塔
- 阿里-imgcook
- 轉(zhuǎn)轉(zhuǎn)-魔方
- 人人貸-活動運營平臺
- 美團-樂高
- 百度-h5
- 政采云-魯班
- 攜程-民宿CMS
- 攜程-樂高
- 知乎-Versatile Editor
- [阿里-bi designer_blank_nofollow](https://github.com/dt-fe/weekly/blob/v2/164.精讀《數(shù)據(jù)搭建引擎 bi-designer API-設(shè)計器》.md)
-
店鋪裝修
非獨立頁面,依附于業(yè)務(wù)系統(tǒng)存在的頁面搭建
- shopify
-
有贊-微頁面
- 淘寶店鋪裝修
- 阿里-飛冰
- 阿里-formilyjs
- 阿里-gaea-editor
- 阿里-sula
- blockVisualEditor
- pager
- 運滿滿-碼良
- X-Page-Editor
- Vue-Layout
- antd-visual-editor
- pipeline-editor
- panel-magic
- 百度外賣-blocks
- Esview
- gen
- bee gen pro
- 百度-amis
- 唯品會-ams
- vue-admin
- 魯班 H5
- 華炎魔方
- h5-factory
- vision
- brick-design
- 隨心秀
- yh5
- rxeditor
- activity-YD
- layoutit
- Ramiko
- jeecg-boot
- sparrow-js
- Tefact: Tefact 輕量級無代碼/低代碼,H5、表單編輯器
- 星搭: 星搭無代碼平臺,快速構(gòu)建中后臺、小程序
- 好未來曉黑板go-zero微服務(wù)框架: 你不需要懂微服務(wù),懂業(yè)務(wù)就行
- cube:快速搭建中后臺頁面
- react-visual-design: 基于react的h5組件搭建
- Web Designer
- h5maker
- pl-drag-template
- form-generator:Element UI表單設(shè)計及代碼生成器
- form-render:通過 JSON Schema 生成標(biāo)準(zhǔn) Form,基于React
- Vue Json Design
- rebuild
- W5 SOAR
- https://github.com/blocks/blocks
- https://github.com/frappe/frappe
- https://github.com/ipselon/structor
- https://github.com/vigetlabs/colonel-kurtz
- https://github.com/BuilderIO/builder
- https://github.com/vuegg/vuegg
- https://webcodesk.com/
-
辦公/管理系統(tǒng) a.k.a no-code
- 黑帕云
- 維格表
- 阿里云-Teambition
- 阿里云-RPA
- SeaTable
- 蒲公英-Tracup
- 蒲公英-Seed
- 伙伴云
- monday.com
- Airtable
-
聲明式編程
行業(yè)綜述
- 精讀《對低代碼搭建的理解》
- 頁面可視化搭建工具前生今世
- React.js 可視化編輯工具
- 對低代碼、零代碼產(chǎn)品的一些看法
- 對 aPaaS 的產(chǎn)品認(rèn)知
- 無代碼編程
- 萬物代碼化:從低代碼、云開發(fā)到云研發(fā)的思考
- 《早早聊搞搭建》搞過搭建的我收獲了什么?
-
技術(shù)點
- 可逆計算
- 161.精讀《可視化搭建思考 - 富文本搭建》
- 面向 Model 編程的前端架構(gòu)設(shè)計
- 流動的數(shù)據(jù)——使用 RxJS 構(gòu)造復(fù)雜單頁應(yīng)用的數(shù)據(jù)邏輯
- 使用 React 寫個簡單的活動頁面運營系統(tǒng) - 設(shè)計篇
- 【電商】用可視化編輯,解構(gòu)看起來非常炫酷的專題頁面
- 如何搭建一個功能復(fù)雜的前端配置化框架(一)
- 可視化拖拽組件庫一些技術(shù)要點原理分析
-
國外
- https://www.honeycode.aws/
- https://developers.google.com/appmaker
- https://powerapps.microsoft.com/zh-cn/
- https://www.zoho.com/creator/
- https://www.salesforce.com/
- https://www.appian.com/
- https://bubble.io/
- https://www.adalo.com/
- https://thunkable.com/
- http://www.vvveb.com/vvvebjs/editor.html
- https://www.forestadmin.com/
- https://mobirise.com/
- https://paperbits.io/
- https://builderx.io/
- https://grapesjs.com/
- https://reactstudio.com/
- https://www.wix.com/
- https://university.webflow.com/
- https://www.squarespace.com/
- https://www.framer.com/
- https://www.figma.com/
- https://www.mendix.com/zh/
- https://www.outsystems.com/
- https://retool.com/
- https://www.quickbase.com/
- https://layoutit.com/
-
https://www.claris.com/zh/filemaker/
一切改進都是源自于人類的缺陷
How we think
- 人腦是串行的,無法有效并行思考多條線索
-
人腦不適合思考并行執(zhí)行的多線程
- 【單線程】把共享變量的編程模式改成事務(wù)整體提交的模式
-
人腦不適合思考同時呈現(xiàn)在屏幕上的多個獨立的業(yè)務(wù)流程
- 代碼是按發(fā)生時間組織的,在一起的代碼未必是邏輯上有關(guān)聯(lián)的業(yè)務(wù)流程
- 【按業(yè)務(wù)切分文件】閱讀者應(yīng)該可以按照自己的任務(wù)目標(biāo)來跟蹤索引,而不是默認(rèn)一個按鈕點擊引起的處理邏輯都一定要寫在一個大文件里
- 【按變更頻率切分文件】業(yè)務(wù)變更是閱讀的首要原因,代碼應(yīng)該按照業(yè)務(wù)變更的頻率來組織。會同時變更的代碼應(yīng)該放在一起
人腦很難管理多份獨立可變的狀態(tài),本質(zhì)上每個獨立變化的狀態(tài)就是一個獨立的線程
- 驅(qū)動狀態(tài)數(shù)量熵增的三大因素:
- 因為交互體驗的要求,從后端到富客戶端到3d動畫,狀態(tài)被復(fù)制多份,越來越靠近展示層
- 因為硬件物理的約束,內(nèi)存從CPU統(tǒng)一尋址,到異構(gòu)計算,CUDA,每個硬件核都有一層自己的內(nèi)存
- 因為數(shù)據(jù)量的增長,從統(tǒng)一的OLAP從庫,到Data Lake,Data Mart,數(shù)據(jù)被復(fù)制成越來越份,流水線越來越長
- 對抗?fàn)顟B(tài)數(shù)量熵增的手段:
- 【聲明式數(shù)據(jù)聯(lián)動】減少獨立變化的狀態(tài),用表達式來表達 derived state
- 【全局虛擬數(shù)據(jù)層】借鑒Unix的統(tǒng)一文件抽象,引入一層統(tǒng)一的虛擬數(shù)據(jù)層。盡可能把狀態(tài)轉(zhuǎn)化成 cache
- 代碼是按發(fā)生時間組織的,在一起的代碼未必是邏輯上有關(guān)聯(lián)的業(yè)務(wù)流程
-
人腦很難理解新增對原有行為的劇烈變化,更習(xí)慣逐層穩(wěn)定疊加。也就是人更希望“控制變量”
- css 最大的難度在于不正交,新增一條對規(guī)則會引起意想不到的效果
- 【局部化布局】swiftui 的 HStack/VStack/ZStack 布局規(guī)則數(shù)量少,每條規(guī)則作用都是局部的穩(wěn)定的疊加
- 性能優(yōu)化往往需要破壞局部性,因為局部的自治容易引起重復(fù)勞動
- 【局部化IO】系統(tǒng)自動實現(xiàn) I/O 的批量等可以自動化做的全局優(yōu)化
- 【局部化IO】業(yè)務(wù)寫成自治的,但是可以附加額外的手工全局調(diào)優(yōu)。而不是強制要求把業(yè)務(wù)邏輯從局部抽出去
How we perceive
- 人眼只能在狹窄的感受野里獲得信息
- css 最大的難度在于不正交,新增一條對規(guī)則會引起意想不到的效果
-
人對時間的感知是來自于對空間的感知
-
人希望在一個屏幕內(nèi)從上往下的獲取時間順序上從早到晚的信息
- callback 的編程方式破壞了屏幕上的順序和時間順序的直接映射關(guān)系
- 【協(xié)程式IO】用協(xié)程取代 callback,把屏幕上的代碼擼直
通過 status 字段驅(qū)動的業(yè)務(wù)狀態(tài)機破壞了屏幕上的順序和時間順序的直接映射關(guān)系
- 【協(xié)程式業(yè)務(wù)流程】用協(xié)程取代 status 狀態(tài)機,把屏幕上的代碼擼直
-
因為感受野的限制,源代碼沒有空間展示所有的細(xì)節(jié)
- 類型定義,內(nèi)存分配等“細(xì)節(jié)”占用了大量的視覺區(qū)域
- 【IDE細(xì)節(jié)隱藏】在文本上省略掉細(xì)節(jié),由 IDE 進行補全,當(dāng)鼠標(biāo)移動上去的時候才展示出來
- 人最習(xí)慣的空間整理方式仍然是層狀的文件夾
- 所有的“架構(gòu)”設(shè)計,最終都是對文件夾和文件的設(shè)計。但是一個維度的靜態(tài)索引(文件夾嵌套)無法滿足所有可能的檢索需求
- 【IDE按需索引】由 IDE 來補全文件夾分類不能滿足的索引需求,針對閱讀者的任務(wù)來設(shè)計IDE索引
- 類型定義,內(nèi)存分配等“細(xì)節(jié)”占用了大量的視覺區(qū)域
-
視桿細(xì)胞容易忽略形狀和順序的差異,但是對顏色更敏感
- 語法高亮占用了寶貴的資源,但是并沒有考慮閱讀者的訴求
- 【IDE按需高亮】對于不同的任務(wù),閱讀者希望找到的重點是不同的,語法高亮應(yīng)該結(jié)合任務(wù)來做
How we collaborate
- 人與人之間最高效的溝通的方式是面對面的交互式聲波震動
-
人類低下的溝通帶寬根本上限制了一個團隊的規(guī)模
- 上線速度要求越快越好,但是加人帶來的邊際效益遞減
- 減少開會拉齊,團隊?wèi)?yīng)該盡可能地自治,而不是什么都要靠 feature team 橫向拉通
高內(nèi)聚,低耦合
- 【靜態(tài)鏈接包】編程工具應(yīng)該提供更多的組合可能,而不是所有的組合都要在運行時用面向?qū)ο蟮亩鄳B(tài)來實現(xiàn)
- 【按變更頻率切分包】分工應(yīng)該按照變更頻率來確定,分工應(yīng)該是明確的
-
盡可能由最終用戶,或者靠近最終用戶的團隊來解決問題,而不是長距離傳遞需求
- 最終用戶編程:直接讓需求提出者自己來實現(xiàn)需求
- 把“學(xué)習(xí)”內(nèi)置到工具里,需要內(nèi)置一個教學(xué)工具
- 最終用戶的編程工具開發(fā)難度高,成本高,投入超過了單個軟件的回報
- 【編輯器預(yù)制】把“公式編輯”,“店鋪裝修”等常見共性需求提前預(yù)制
- 教學(xué)工具的目標(biāo)是教學(xué),而不是把自己標(biāo)桿為更先進的生產(chǎn)力
- 【教學(xué)內(nèi)置】提供教學(xué)模式和生產(chǎn)力模式的無縫切換
- 把“學(xué)習(xí)”內(nèi)置到工具里,需要內(nèi)置一個教學(xué)工具
- 低代碼編程:通過提前預(yù)制,把工作量前置,減少應(yīng)用開發(fā)者的規(guī)模,從而可以在組織架構(gòu)上把開發(fā)者內(nèi)置到用戶組織內(nèi)部。與此相對應(yīng)的是文檔驅(qū)動的外包式開發(fā)。
- “預(yù)制”來自于對共性需求的提前預(yù)判
- 【非功能性需求云化】非功能性需求的實現(xiàn),都是運行在相似的機器上
- 操作系統(tǒng)
- k8s
- RPC 框架
- 開發(fā)者都是人類
- 編程工具
- 溝通工具
- 用戶都是人類
- 【SaaS組件】IM / 電話 / 短信
- 【Ui組件】字處理器 / 表格
- 【CRUD生成】慣用的展現(xiàn)和交互
- 列表詳情
- 樹狀層級
- 表格結(jié)構(gòu)
- 可拖拽白板
- 【SaaS組件】相對穩(wěn)定的業(yè)務(wù)流程
- 登錄注冊
- 支付
- 行業(yè)內(nèi)相對穩(wěn)定的業(yè)務(wù)共性流程
- 電商
- HR / 招聘
- 銷售管理 / CRM
- “預(yù)制”來自于對共性需求的提前預(yù)判
How we learn
- 最終用戶編程:直接讓需求提出者自己來實現(xiàn)需求
-
人的“歸納/理解/學(xué)習(xí)”能力高度依賴于可視化交互式地操縱與反饋
- 幫助應(yīng)該放在任務(wù)執(zhí)行的地方,與其說“可視化”,不如說是“可發(fā)現(xiàn)”
- 【填空題變選擇題】單獨的語法手冊是不好使的,必須提供界面上的按鈕,把填空題變成選擇題,這樣才能啟發(fā)學(xué)習(xí)
- GUI 設(shè)計器 / 店鋪裝修
- 公式編輯器
- 審批 / 工作流設(shè)計器
- trigger 流程設(shè)計器
- 人習(xí)慣于用手觸碰一下對象,然后觀測其反饋,從而歸納學(xué)習(xí)
- 不可觀測的行為無法學(xué)習(xí)
- 生產(chǎn)環(huán)境的bug無法本地復(fù)現(xiàn),我怎么找規(guī)律?
- 【TestInProduction】tracing,大量的 tracing,流量回放
- lowcode 平臺的bug沒有任何線索,除了找平臺開發(fā)者,我能怎么辦?
- 不能要求用戶了解所有的內(nèi)部細(xì)節(jié),“平臺”要做到可依賴
- 業(yè)務(wù)邏輯問題的定位和生產(chǎn)環(huán)境的bug定位一樣,靠 tracing
- 反饋太慢的行為給人的負(fù)面感受是指數(shù)增加的
- 本地機器太慢了跑不起來,需要上公司的沙盒環(huán)境來復(fù)現(xiàn)問題
- 【云IDE】
- 改完了代碼需要重新編譯重新加載
- 【LanguageServer】交互式開發(fā)的時候跳過不必要的編譯
- 【所見即所得】所見即所得的 GUI 開發(fā),本質(zhì)上就是用解釋器執(zhí)行,換取編譯時間的縮減
- 【HMR】重加載的時候保持頁面狀態(tài)
no code / low code / pro code
一切的改進都是源自于人類的缺陷
- 幫助應(yīng)該放在任務(wù)執(zhí)行的地方,與其說“可視化”,不如說是“可發(fā)現(xiàn)”
- no code:自己編程給自己用,給用戶的感覺是一個更強大的辦公/實用軟件。主要的手段是用圖形化操作等方式降低學(xué)習(xí)曲線。no code 一定要面向非常固定的領(lǐng)域才能做到好用。
- low code:編程給其他人用,為此創(chuàng)造了一個 citizen developer 的概念。主要的手段是平臺預(yù)制好常見的需求,減少需要從頭寫的代碼。low code 也要面向指定的領(lǐng)域才能讓平臺提前預(yù)測需求,但相比 no code 可以不把使用場景限定得那么死。
- pro code:low code 的平臺自己不會選擇 low code 來創(chuàng)建這個平臺本身,因為 low code 并沒有降低從頭構(gòu)建一個系統(tǒng)的成本。但是 pro code 的平臺自己會選擇 pro code 來創(chuàng)建這個平臺本身,比如 react 開發(fā)者會選擇用 react 來創(chuàng)建自己的開發(fā)工具,因為 pro code 的工具和平臺都是以從根本上降低從頭構(gòu)建一個系統(tǒng)的復(fù)雜度為目標(biāo)的。