目前国内只有一个封闭的开发平台取得了巨大成功，这个平台是微信小程序，相比原生 APP 开发，微信小程序的开发成本更低，而且还跨平台，所以其实也能算是低代码，微信小程序就是很封闭，只能运行在微信上，还得使用专门的框架和工具，连注册账号和发布应用都要人工审核，但依靠微信的影响力和用户量，这些都不是主要问题 。
在这个问题上，jabdp低代码平台已经实现了全部开源，https://gitee.com/jabdp/jabdp 。
低代码平台的难点在哪？在我看来低代码平台的难点是如何同时满足易用性和灵活性，因为它们经常是冲突的，以低代码平台中必备的可视化页面编辑器为例，要怎么实现页面布局？主要有三种做法：
- 基于 flexbox/float 方式来布局，这种方式灵活性强，但牺牲了易用性，需要使用者至少懂点 css，不然弄不明白 。
- 基于绝对定位来布局，这种方式易用性强，想拖哪就拖哪，但又失去了灵活性，要支持多分辨率就得手机和 PC 单独编辑，而且不好实现根据内容自动撑开高度 。
- 提供水平/垂直分栏的容器，通过它们组合来实现各种布局，这种方式处于上面两者之间，灵活性和易用性都不突出，只适合用在移动端或后台类的页面 。
所以复杂灵活的可视化编辑器有可能吃力不讨好，那偏向易用性呢？有些低代码平台追求「零代码」，让普通人都能用起来，但这样会面临另一个意想不到的强大竞品：「Excel」，对于普通人来说 Excel 就是一个好用的数据库，可以添加数据、修改数据、查找数据、排序过滤等，还能做图表，无需开发应用就能管理数据 。
前段时间在吴伯凡的课程里听到一个故事，原文是这样的：
雷军很吃惊地发现，小米的整个管理系统，就是采购部门也就是供应链部门抱着一台电脑，生产部门抱着一台电脑，销售部门抱着一台电脑，电脑里都是Excel，三个部门打开以电脑后就对数字，这就是小米的流程管理 。但从另一个角度看，这个故事却告诉我们，小米刚开始几年仅靠 Excel 就能生产几百万台手机，创造几百亿流水了，因此很多时候 Excel 就足够了，目前有些在线编辑的 Excel 平台，还出现了类似 Airtable 那样的新型 Excel，还有专门做漂亮表单的 Typeform 等，甚至连 Notion 这个文档工具都内置一个小数据库，这类产品在易用性上远好于各种零代码平台 。
同行知道这些事情以后不相信，认为这是天下奇闻 。一个一年生产几千万台手机的公司，管理流程竟然是这样的，这种流程出问题也是很自然的 。
文章插图
前端如何低代码？前端开发的主要工作是界面、交互和业务逻辑，20 年前的 FrontPage 和 Dreamweaver 就实现了可视化编辑页面，但它们生成的代码远不如手写，后来随着前端重构的流行，开发者又回归到通过写代码来制作页面 。
现在可视化页面编辑器主要用于制作静态原型，或者官网及落地页，很少用在前后端交互比较多的页面中，因为动态数据难以在可视化编辑器里展示，比如 if xxx 的时候显示 yyy 要怎么显示呢？所以界面开发效率提升主要靠 UI 组件库 。
前端 UI 组件库十几年前就有了，比如 YUI 是在 2006 年发布，jQuery UI、Ext JS 也紧跟着在 2007 年发布了，但这些组件库在产品线中用得不多，你想想百度搜索、贴吧、知道、百科的各个页面中，有哪些东西是通用的？能想到的恐怕只有轮播图、弹出层、下拉菜单这几个，这些在整体开发中占比不高，即便都用上对整体效率提升也不明显，所以前面也提到低代码平台不适合用在面向用户的产品中 。
但在企业应用中情况就不一样了，这些应用页面相似度更高，大部分是表格表单，而且更重视功能而不是个性化展现，因此更容易实现复用 。
在企业应用里甚至可以简化成表格展现，第一列是时间，第二列是用户名，第三列是文本，虽然展现差了很多，功能却是一样的 。
后端如何低代码？在后端方面，低代码平台主要能解决这几类问题：
- 系统开发通用性问题，比如
