前言

no code 或是 low code思想其实一直伴随着软件开发的工程化发展，但是从软件架构的视角其实low code远远不能只局限于前端视觉的呈现，还包含常规业务逻辑的实现（数据存储、数据查询、甚至调度等），通常应用领域越垂直越容易达成no code的效果。最近自己在构想设计一种专门用于低代码应用快速开发的语法，先记录一些简单的思路。

低代码发展到现在，在领域中一定是已经有许多前人沉淀的成果，任何一个深远的计划，一定不能仅仅是通过拍脑袋做决策–虽然这会显得自己看起来更聪明（不费吹灰之力）。

相关书籍：《Low-Code/No-Code》、《代码精进之路》、《低代码在制造行业数字化实践》、《实战低代码》、《低代码引擎技术白皮书》、《Building Low-Code Applications with Mendix》、《Low-Code Application Development with Appian》、《Low-Code Apps For Dummies》。

开源项目：飞猪xRender、百度amis、amplication、LowCodeEngine、Node Red等。

缘起

设计一种新的用于低代码的新语法并不是为了造轮子而造，一定是基于自己的应用场景所衍生出来的需求，于我而言，对应的场景是需要有一种足够灵活的定义常规前端交互和前后端通信协议的工具，而不仅仅局限于视觉的可视化和对拖拖拽拽。DSL某个角度上可以具备更好的可扩展性，存在无限的可能，应用类似Java语法中注解和反射的思想，关注概念的实质而不是表象，重“实”不重“名”。

除了类似 xrender 这样的表单可视化以外，泛化的low code可以包含像工作流，并拓展到协议的定义、数据存储、多种语法的生成以及垂直业务的原子功能实现上。从而把之前关于n8n、dify表单和工作流的调研以及其他许多开源项目的思路串起来。

杂谈

在自定义语法DSL的实现中，最成熟的开发工具可能是yacc或是antlr这两种工具。也注意到身边有一些小伙伴对于实现自定义DSL或是对于实现一种自己的语法解析工具感兴趣，但是因为信息差永远是存在的，也因为越来越多跨专业的同学们从事软件开发的工作，因此没有了解过编译原理之类的专业知识，可能会在工具或框架选择上走一些弯路。实际上任何一个专业领域发展了这么多年，一定是会有很多成熟的开发范式或是工具链的存在。

之前自己也尝试过用Typescript实现一个简单的Java语法转Golang的开源项目，项目还处于半成品状态，能够做一些基础的语法转换的工作。通过这个项目的实践，发现语法转换即使是已经具备一定的专业基础知识以后，也还有很多需要精雕细琢甚至粗重的体力活的工作。举例来说，关于泛型推导的语法适配就是一个极其耗时和需要大量时间调研和琢磨的工作，试想 private Map<String,Integer> map = new HashMap<>; 和 var map$1 = make(map[string]int)，既有类型推导和适配的问题，也有初始化的语法问题，甚至保留关键字的冲突问题。

虽然低代码的概念这些年开始兴趣，但是低代码的思想却至少是二十年前就已经存在，结合我自己过去的工作经验，换一个视角来看，Visual Basic的可视化组件拖拽可以视为一种half code的思路，Visual C++的控件时态区分为设计时和运行时就已经是在为定义组件设计/运行时代可视化的标准范式所做的努力，后来Borland公司推出的开发工具Delphi或C++ Builder某种程度上可以理解为将可视化开发做为其产品的一个核心卖点，Power Builder对于数据管理的垂直领域在可视化方向走得更靠前一些，而在工业控制领域Labview及后来的组态软件又为垂直市场的开拓引领潮流。