低代码，要怎么低？和低代码有关的十大问题( 四 ) 或许是因为Mendix和Outsystems的收

平台锁定这个问题在国内更严重，有种说法是古代中国属于大陆农业文明，农业文明的特点是强调自给自足，能不求人就不求人，这个长期影响很难改变，所以国内公司一变大就希望什么都自己掌握，信不过别人。
目前国内只有一个封闭的开发平台取得了巨大成功，这个平台是微信小程序，相比原生 APP 开发，微信小程序的开发成本更低，而且还跨平台，所以其实也能算是低代码，微信小程序就是很封闭，只能运行在微信上，还得使用专门的框架和工具，连注册账号和发布应用都要人工审核，但依靠微信的影响力和用户量，这些都不是主要问题。
【低代码，要怎么低？和低代码有关的十大问题】在这个问题上， jabdp低代码平台已经实现了全部开源，。
低代码平台的难点在哪？在我看来低代码平台的难点是如何同时满足易用性和灵活性，因为它们经常是冲突的，以低代码平台中必备的可视化页面编辑器为例，要怎么实现页面布局？主要有三种做法：

基于 flexbox/float 方式来布局，这种方式灵活性强，但牺牲了易用性，需要使用者至少懂点 css ，不然弄不明白。
基于绝对定位来布局，这种方式易用性强，想拖哪就拖哪，但又失去了灵活性，要支持多分辨率就得手机和 PC 单独编辑，而且不好实现根据内容自动撑开高度。
提供水平/垂直分栏的容器，通过它们组合来实现各种布局，这种方式处于上面两者之间，灵活性和易用性都不突出，只适合用在移动端或后台类的页面。

除了布局，还有另一个问题是要不要支持自定义 class？不支持的话灵活性差，改个字体所有地方都要配一遍，而支持又导致易用性差，不了解 css 的用户会发现改了一个地方影响到别的了，要想不一样还得新建一个 class ，有理解上的成本。
所以复杂灵活的可视化编辑器有可能吃力不讨好，那偏向易用性呢？有些低代码平台追求「零代码」，让普通人都能用起来，但这样会面临另一个意想不到的强大竞品：「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 年发布了，但这些组件库在产品线中用得不多，你想想百度搜索、贴吧、知道、百科的各个页面中，有哪些东西是通用的？能想到的恐怕只有轮播图、弹出层、下拉菜单这几个，这些在整体开发中占比不高，即便都用上对整体效率提升也不明显，所以前面也提到低代码平台不适合用在面向用户的产品中。
但在企业应用中情况就不一样了，这些应用页面相似度更高，大部分是表格表单，而且更重视功能而不是个性化展现，因此更容易实现复用。