随着 ChatGPT 的出世，整个前端行业都受到了 非常大的挑战 。
传统的 GUI 模式是基于机器无法与普通用户之间进行有效沟通与展示的产物，而未来可预见的是 AI 将大幅度降低用户与机器之间的交流难度，当普通的对话模式能够完成大部分的用户需求之后，GUI 是否还有存在的必要？
随着 GUI 的必要性逐渐降低，前端同学的方向又在哪里？ 今天我们就来聊聊前端的价值，以及对 AI 的部分看法。
前端的价值
通常情况下，一个产品的基石大都是由后端来决定，很多公司老板或者团队 TL 觉得前端就是在做些门面功夫，或者锦上添花的工作。
事实上，前端开发是直面用户的第一道门面，与用户的距离最近。抛开复杂的底层数据逻辑，前端即是创造者 ，同时也是用户。
作为前端，我们可以拿到第一手的用户体验反馈数据，可以在交互体验上有着更深入的研究。在此基础上，可以协助业务做更多的创新体验，甚至打造一个全新的产品。底层数据的逻辑可以是通用型的，但表现出来的产品则可以是多样性的。
总的来说，前端的价值具体表现在用户体验上，而核心其实是业务创新。借助 AI 可以解放我们更多的重复工作，而且也变相降低我们去学习其他语言的成本，可以让我们更加注重业务需求、 创意 、体验这些细节上。即使这个过程转变会不顺畅，但这注定是我们要面对的，不如尽早转变心态，努力提升。
技术的革新从来都不会等待，历史的滚轮也不会因为部分人而停止，作为一个优秀的工程师只有持续学习才能避免被淘汰。
但是，目前整个前端的技术生态已经趋于完善，已经很难有新的技术、框架的诞生和大的改革了。这一次，我建议你把握住低代码这个方向！
低代码是一种机遇
低代码从 20 年左右的爆发到现在，一直不缺的就是争议，中间不断地有人力挺，也有人频繁的质疑。但不可否认的是，一旦在业务中引入低代码体系，或多或少都会提升研发链路中的效率，而随着产品与业务的耦合度增高，这个领域提高的效能也会随之增加。
低代码的英文直译可以理解为使用最低端的方式去完成一个项目。
这里的低端应该会有点歧义，并不代表要做过程低端，而是相比较高大上的 coding 或者很高级的操作来说，更加的通俗能够让普通人快速的理解与使用。
那么，这里的“低端”是指什么呢？更少的代码量？还是更低的开发成本？
低代码的技术方案跟代码的多与少并没有直接关系，一个庞大而复杂的业务一定是没法通过节约代码量来完成既定的业务需求。业务复杂度不会凭空消失，只不过是将通用的复杂度通过工程化的手段转嫁到平台之中，而低代码的价值则是降低了其他团队的开发、维护、沟通与资源成本等。
那到底什么才是低端的方式？简单粗暴直接的就是最低端的方式，所以无论实现的技术方案是 No Code 还是 Less Code，一个成熟的低代码产品提供出来的方案一定可以快速、简单的解决某个领域问题。
既然低代码需要去解决一个领域的问题，那么它的形态就不限于前端可视化搭建了。这也是很多传统型的 SASS、PASS 产品能够快速提供低代码产品的原因，业务已经高度聚合，同时都是在某个领域深耕了多年，有一些行业壁垒与用户基础，再配合上低代码的搭建模式，可以更快减少用户的接入成本。
如何打造一款通用型低代码产品？
目前市面大部分的低代码方案都在集中解决某个领域的问题，比如运营、建站类型，但这些产品也有一些不足之处：
- 它们的 Pro Code 产物结构会比较复杂，臃肿的代码在性能体验上也会有所折扣，而且复杂的结构也不利于二次开发，产品无法保证可延续性；
- 一般这种低代码产物与自己的后端服务耦合比较多，一旦接入使用，就会存在一定的业务约束，但一个稍具规模的公司肯定希望将数据拿捏在自己的手上，这也是都想做低代码轮子的原因。
而且 C 端业务的变化非常复杂，营销类型很吃业务与创意设计，如果从营销场景切入低代码产品无疑将面对一大波竟品的对线，无论从业务成熟度、产品知名度都会被吊打，一个产品一定要接受不断地业务迭代才能完成迭代升级的良性循环。另外 C 端用户的获客成本高昂、付费意识普遍低下。
与之相对的，中后台业务场景的需求量非常大，但它们的布局加功能都比较固化，大部分可以基于物料 + 基础布局完成页面组装，即使存在多种不同系统之间的样式交互的略微差别，我们也可以通过主题配置的方式来兼容。
基于上述的情况，小册的低代码产品将主打通用，功能做到与业务完全解耦，将业务场景控制在中后台管理系统中，限制产品的业务边缘，减少接入、使用与学习成本。
小册的目标是打造一款通用性的中后台的低代码产品附带营销搭建类型的模块，所以实际上的产品可以理解为中台数据驱动搭建 MFF 产品与 C 端营销搭建业务产品两种组合而成。
MFF（Model For Frontend）
与常规的 Schema to View 的模式不一样，中台化产品的概念 MFF（Model For Frontend）有如下特点：
- 无缝对接现有后端服务，尽可能减少后端业务逻辑改动，减少传统业务的改造成本；
- 解决业务复用能力设计、组件使用门槛问题以及减少现有组件接入成本；
- 减少对现有前端业务的侵入，提供 Pro Code 与 Less Code 模式，支持页面与组件级别的引入；
- 可以引入 AI 模型，可以针对不同的业务进行训练提供匹配度较高的 Schema。
整体的流程模型如上图所示，与市面常见直接页面拖拽搭建产品不同的是：中台化产品更关注于从服务端业务数据转换这个过程，而非搭建可视化的结果，并且产物与 Pro Code 跟容易结合，下图是中台化产品的界面：
可视化搭建编辑器
大部分可视化搭建类的架构设计一样，整个系统也采用分层的设计，尽可能将责任细化。整个应用分为如下洋葱🧅图所示的几个模块：
- 最底层是搭建协议，基于标准化的协议，可以将区块、模版快速引入到当前编辑器的内容编排当中快速完成工作，也可以将定义好的页面组件保存为自定义的区块、模版后期直接一键使用；
- 第二层是编辑器层，这一层主要实现了根据底层协议来装填物料、页面内容编排、画布预览区域的渲染器显示；
- 第三层是针对编辑器的一些扩展开发，如组件平台可以管理远程的组件，资源管理可以控制编辑器设置器中的一些素材，页面管理可以对编辑器保存和发布的页面进行管理，应用服务可以将编辑器保存的数据存储起来下次再使用；
- 最顶层就是聚合前面几层组合的搭建平台，由于是分层设计的，因此可以在多个不同的项目中扩展使用搭建服务。
以上低代码产品，将由掘金畅销小册作者 CookieBoty 与掘金签约作者 wangly19 一起实现。
CookieBoty，禾观科技泛端技术专家，近十年专注于研发效能提升相关的工程化与低代码领域，掘金小册《基于 Node 的 DevOps 实战》与 《NestJs 实战》的作者。
wangly19，税友集团资深前端开发，拥有丰富的中后台与移动端开发经验，专注于营销搭建系统与前端工程化实践
具体的课程安排如下：
学完之后，你可以获得：
✅一套基础、可定制的私有低代码产品；
✅低代码开发原理与核心技术方案解析；
✅大型项目架构设计与落地能力提升；
✅NestJS 开发与 DevOps 体系落地指南。
这一次，与 CookieBoty 与 wangly19 一起构建产品全链路体系，解决前端工程化瓶颈！
限时优惠
想要通关低代码，掌握前端工程化，这本小册千万别错过！
原价 ¥69.9 ，上新 6 折特惠，扫码免费试读↓↓↓
