低代码开发，是一种开发模式，通过图形化用户界面来配置和创建应用软件，而不是用传统模式那样主要依靠手写代码。对应的，提供给开发者的这类低代码开发功能实现的软件，称为低代码开发平台(LCDP)。低代码开发模式的开发者，通常不需要具备非常专业的编码技能，或者不需要某一专门领域的编码技能，而是可以通过平台的功能和 约束来实现专业代码的产出。
从定义中我们可以看到，低代码开发的工作方式主要依赖操作图形化的用户界面，包括拖拽控件，以及修改其中可被编辑区域的配置。而随着前端项目的日趋复杂，这种方式已不再适应现代项目的需求，于是渐渐被更专业的工程化的开发模式所取代。
开发途径
但是，快速生成项目代码的诉求从未消失。人们也慢慢找到了实现这个目的的两种路径：
一种是在高度定制化的场景中，基于经验总结，找到那些相对固定的产品形态，例如公司介绍、产品列表、活动页面等，开放少量的编辑入口，让非专业开发者也能使用。
另一类则相反，顺着早期可视化开发的思路，尝试以组件化和数据绑定为基础，通过抽象语法或 IDE 来实现自由度更高、交互复杂度上限更高的页面搭建流程。这种项目开发方式通常需要一定的开发经验与编码能力，只是和普通编码开发方式相比，更多通过操作可视化工具的方式来达到整体效率的提升，因此被称为低代码开发。
在实际场景中，尤其是商用的低代码平台产品，往往提供的是上面两种开发方式的结合。
基于编写 JSON 的低代码开发
当我们去审视一个项目前端部分的最终呈现时，可以发现：
一个项目的前端部分本质上呈现的是通过路由连接的不同页面。而前端开发的目标就是最终输出页面的展示与交互功能。
如果学过浏览器基本原理，你会知道：每一个页面的内容在浏览器中，最终都归结为DOM 语法树（DOM Tree）+ 样式（Style）+ 动态交互逻辑（Dynamic Logic）。
在组件化开发的今天，一个规范定义的组件包含了特定功能的 DOM 子树和样式风格。因此页面的内容又可以定义为：组件树（Component Tree）+ 动态交互逻辑（Dynamic Logic）。
而基于 JSON-Schema 的低代码开发的切入逻辑是：
在特定场景下，例如开发中后台增删改查页面时，大部分前端手动编写的代码是模式化的。
页面组件结构模板和相应数据模型的代码组织，可以替换为更高效的 JSON 语法树描述。
通过制定用于编写的JSON 语法图式（JSON Schema），以及封装能够渲染对应 JSON 语法树的运行时工具集，就可以提升开发效率，降低开发技术要求。
编写 JSON 开发的高效性
编写 JSON 语法树开发的高效性体现在：
由于只用编写 JSON ，而隐藏了前端开发所需的大量技术细节（构建、框架等），因此降低了对开发人员的编码要求，即使是非专业的开发人员，也可以根据示例和文档完成相应页面的开发。
由于只用编写 JSON ，大量的辅助代码集成在工具内部，整体上减少了需要生成的代码量。
可以对中后台系统所使用的常用业务组件进行抽象，然后以示例页面或示例组件的方式，供用户选择。
编写 JSON 开发的缺点
但另一方面，这种方式也存在着一些不足：
• 输入效率：单从组件结构的描述而言，使用 JSON 描述的代码量要多于同等结构的 JSX 语法，对于有经验的前端开发者而言，通常无法第一时间感受到效率的提升。
• 学习记忆成本：由于引入了新的 JSON 语法图式，无论对于前端开发者、后端开发者还是非专业的人员来说，上手的学习成本都不可避免。此外，不同组件存在不同属性，要在实际编写过程中灵活运用，对记忆量也是一个考验。而反复查阅文档又会造成效率的下降（对于这个问题，有个优化方案是利用 IDE Snippets 的选项功能生成对应的语法提示）。
• 复用性和可维护性：对于多页面存在可复用业务组件的情况，在 JSON 编写的模式下往往需要手动复制到各页面 JSON 中，牺牲了复用组件的可维护性。此外，对于功能复杂的页面，对应的 JSON 长度也会让维护体验变得不太美好。
• 问题排查难度增加：这个问题涉及面向人群，如果是非专业的人员从事 JSON 的开发过程，当遇到问题时，在如何排查上可能造成阻碍，因此通常需要配备额外的专业人员来提供技术支持。
总结
基于配置的前端低代码开发对普通的项目开发流程做了抽象，将编写不同功能模块的代码变为只编写组件语法树描述信息，这种方式在一定程度上降低了使用者的技术要求，提升了开发的效率，所以我们要积极拥抱低代码开发平台，为自己减压！
