由低代码引发对前端的思考

最近低代码技术的热点时不时闯入技术人的视野，市场上出现了不少的低代码平台或工具，让我不禁开始审视并思考这些工具的定位和作用。

前端技术大体可划分为三代。从最早的页面切图布局开始，到由ajax无刷新更新技术为突破并以jquery为核心的第二代前端生态，再到现今流行的由nodejs后端技术为突破而衍生出的一系列以前端构建工具为关键的第三代前端生态。

目前的前端主流技术栈（vue/react系列）真的适合大部分前端需求吗？

前端需求的变化：由以页面布局展示为主，逻辑脚本为辅的展示型需求 升级到 展示与逻辑并重的胖客户端应用型需求。

显然第一代前端技术满足了展示布局为主的初期需求，从第二代前端技术开始其实就已经满足了应用型前端需求，那为何前端技术又发展出第三代？我觉得主要是为了应对大型前端开发的工程化和可维护性需求，这个“大型”包含两层含义：一是代码体量够大，业务逻辑够多；二是访问量大。

但是又有多少公司或项目有这种大型的开发需求？保守估计，百分之七十的前端开发不是这种大型需求，用户量过百万的应用在全国范围内只能算少数，更何况活跃用户量，并发访问用户量，就一个比一个少。全国大部分的用户资源和用户精力都被少数的头部企业所占据，因此，很明显，以nodejs为基础的构建型前端技术栈并没有真正满足大部分前端开发者，因为这些技术体系通常都是出自大公司，是为了满足大公司的开发需求，或者是多少带有炫技成分在里面，像这些： babel，typescript，less，sass，VRA三框架... 对于大多数前端需求来说，必要性真的不大，而因为前面那些技术的使用，又必须引入编译打包的概念，这样就引出了一大堆打包工具和一大堆配置。对很多前端来说，这些东西带来复杂性的同时并没有带来明显的收益。各种媒体大肆宣传，说xxx框架多厉害，多牛逼，有多少先进特性！但于我何干？能给我带来超值收益吗？有多少前端会去结合自己的需求和实际场景进行冷静思考，其实大部分前端也只是随大流，只是为了随“主流”而用。主流的声音并不代表实际的主流需求。天下攘攘皆为利往，其实经常在网上发声宣传的大多是 培训教育机构，框架官方及利益相关者，刚好满足其需求的头部大厂，资深技术博主，这几个哪个背后没有利益驱使？

当然，对大部分中小型前端项目来说，这些新技术并不是全盘否定，而应该思考一个问题，这些技术中有哪些真正解决了我的痛点，真的带来了超额受益？只有想清楚了这个问题，才能知道哪些新技术让我们有足够的动力去采用和拥抱，哪些可以忽略。

大道至简。能简单绝不复杂化，因为简单意味着 高可靠，低脑耗，易维护 三个根本优势。引入新的技术就意味着引入新的概念，而概念越多，整个系统及流程的复杂度会成倍增加，这与大道至简的原则是相违背的。所以，只在某个新概念极为必要的时候才引入。所以我们就要考察在前端一堆新技术中，哪些才是极必要的概念？

要知道哪些新技术是极必要的，那我们就要明白，在第二代前端体系中，有哪些痛痛点？我觉得有以下几点：
1. 直接操作dom而出现的面条式代码，导致维护地狱。
2. 第二代体系中，几乎没有标准的复用机制，严重阻碍系统规模的扩增。
3. js回调地狱。
第一个痛点，VRA三大框架都充分解决了：双向绑定，数据驱动 完美解耦了逻辑与视图。
第二个痛点，组件化开发，也是三大框架的核心价值，解决了前端的复用痛点。
第三个痛点，es6或typescript 提供的 async/await 技术，补上了回调的缺陷甚至使前端的异步机制成为优势。

思路理清楚，我们就要从nodejs为基础的编译打包式技术栈中逃离出来，让前端重回简单。不要编译，不要打包，不要babel，不要typescript，不要less/sass，不要eslint，不要vuex/redux，... ，只引入必要的三个特性：双向绑定，组件化开发，async/await 。

vue和react都支持直接script标签引入，一定程度上满足了数据驱动和组件化开发需求。而 async/await 随着现代浏览器的逐步兼容，到es7就彻底原生支持了。其实，随着时间推移，自定义组件也会被浏览器支持，到时，VRA三大框架的历史使命就结束了，前端重回大道至简。

但现阶段，实际项目中为了兼容旧浏览器，只能通过引用vue script标签的方式解决前两大痛点，第三个痛点只能暂时忍一下，其实通过抽离异步函数代码到外层，通过合理组织代码，也能一定程度上避免回调地狱。

聊了这么多前端，我们再回到低代码，前端的低代码方案中有没有比较符合我们理念的呢？貌似还真有一个，百度开源的 amis 已经比较靠近我们能简则简的原则，这里是 码云 上的开源地址：https://gitee.com/baidu/amis ，文档中已经介绍得很详细了，这真的是一个让人眼前一亮的项目。尤其适合2B端，内部管理系统。

说到管理系统，不得不吐糟下目前网上流行的管理系统脚手架或套装，比较有代表性的是 iview-admin 和 vue-element-admin 。说的是快速起步，快速开发，但真的起步快吗？其实管理系统往往针对公司或集团内部人员，或者是2B端的，这类系统的用户量基本都不大，只要系统满足安全性和可用性就够了，甚至安全都不需要考虑，只要后端接口把好权限，安全性就不是前端的事儿，前端只要满足可用这一点需求就可以了，其他的优化细节往往都是多余。这类场景和需求，系统的价值和重点在后端，前端的开发和维护不应该浪费太多精力和时间。这类的前端管理系统就应该选择简单稳定的技术，快速出成果，然后把剩余精力转到更有价值的地方，多留点时间给自己的身体和家庭也好。

回到主题，低代码的热潮势不可挡。一部分低代码平台的定位是服务非技术人员，一部分是服务技术人员，还有一些想要兼得两者。非技术人员应该是要吃到低代码热潮的大部分红利，我觉得低代码主要是为他们服务的，至于他们目前实际吃到多少红利，我就不清楚了。但就技术人员来说，对低代码工具的选择标准主要有：可独立部署，免费开源，易于扩展，便于二次开发。目前市场上能充分满足这些条件的不多，前端的amis还算不错，思路简洁，有配套的图形化开发工具和源码；后端的还没太去深入了解，主要还是因为后端对低代码的需求不是很迫切，能完全满足后端通用开发需求的低代码工具几乎没有，而有的也是局限性比较大，只能作为辅助工具，并没有带来太多优势。反而前端可以借助低代码工具来大幅提高生产力。

所以总结下来，低代码热潮主要受益的有两波人：首先对于非技术人员，后端托管式的一条龙服务让这些人的能力边界瞬间大增，对他们来说，前端和后端的概念是透明的，他们不用管什么前后端，他们只用面向低代码平台；而对于技术人员尤其是前端开发者，低代码工具有大幅提高产出效率的潜力。

最后的感想：前端技术大潮一浪过去一浪又来，作为有限精力的个人，应该抓住一些标准性的不变的东西，绝大多数前端新技术都是私有规则，这些私有规则随着时间推进绝大多数会被扔进历史的垃圾桶，把有限的精力浪费在这些私有规则上本质上就是在浪费生命。所以，最重要的一点，技术人在面对新技术的时候，要冷静，要能看透本质，学会有取有舍。