前端的工作以后还会继续拆分吗？

大家好，我是Kason。作为前端，你有没有跟UI斗过？脑中场景前端：“上线时间定了，什么时候出设计稿？出稿后还要加班开发测试！”UI：“快来了，别急~”前端：“做好了先给我，我画个静态页面”UI：“快来了，别急~”前端是哭了，后台无语，毕竟考验承受一切……你遇到过这样的情况吗？您认为根本原因是什么？如何最有效地解决这个问题？本文将提供一个可以参考的思路和产品。欢迎文末讨论问题原因。在《现代Web发展困境与突破》一文中，作者牛岱谈到了目前前端与UI的合作模式如下：图片来自《现代Web发展困境与突破》UI在设计软件上完成设计逻辑,绘制页面样式并传递给前端。前端重现UI绘制的样式，使用CSS+HTML在网页中重新绘制样式，绘制完成后再添加功能逻辑。为什么前端需要重复绘制UI设计软件绘制的页面样式？就因为UI用的是设计软件，前端还需要编程吗？因此，理想的分工应该是这样的：图片来自《现代Web开发困境与突破》，即UI完成设计逻辑和页面样式（通过设计软件），软件生成静态页面代码可用根据规范在前端，前端根据生成的代码逻辑编写功能。说白了：前端不用画静态页面。虽然这个过程中有很多难点需要解决，比如：对于UI来说，页面是一个层，对于前端来说是一个组件。如何对齐两者的差异UI需要了解基本的页面布局（floating,flex,absolutepositioning...）才能生成符合响应式规范的静态页面。有丝分裂是这方面的一次大胆尝试。一次大胆的尝试BuilderIO是一个低代码平台，主要通过拖拽生成页面。有丝分裂的作者是BuilderIO的CEO。用一张图概括一下有丝分裂的定位：左起第一行是：sketch、Figma、BuilderIO，前两者是知名设计软件，后者是低代码平台。当UI使用这些软件完成页面设计时，插件输出给mitosis后，mitosis可以输出成各种知名的前端框架代码。设计图一步成为前端框架代码，前端无需绘制静态页面。他是如何做到的？现代前端框架使用组件作为逻辑和视图划分单元。并且可以描述组件。比如React的Fiber，Vue的VNode都是描述组件信息的节点类型。mitosis将设计图转换为独立于框架的JSON，如下所示：{"@type":"@builder.io/mitosis/component","state":{"name":"Steve"},"nodes":[{"@type":"@builder.io/mitosis/node","name":"div","children":[{"@type":"@builder.io/mitosis/node","bindings":{"value":"state.name","onChange":"state.name=event.target.value"}}]}]}这个JSON描述了一个组件类型（即component），其中包含statename，nodes代表组件对应的视图。如果导出目标是React，那么代码如下：exportfunctionMyComponent(){const[name,updateName]=useState('Steve');return(

);}仔细看这张图，你会发现有丝分裂也可以反向输出到设计软件。是的，有丝分裂本身也是一个框架。有趣的是，他更像是一个前端帧拼接器。他采用了：React的Hooks语法Vue的响应式更新Solid.js的静态JSXSvelte的预编译技术Angular的规范上面的代码示例，如果用mitosis语法写成：exportfunctionMyComponent(){conststate=useState({name:'Steve',});返回();}一条意想不到的道路？一开始我们讲了前端无法直接使用设计软件生成静态代码的两个痛点：对于UI来说，页面是一个层，对于前端来说是一个组件。如何对齐两者之间的差异需要对UI有基本的了解。页面布局（浮动、弹性、绝对定位...）可以生成具有复合响应规范的静态页面。我们想象一下，当使用mitosis开始一个新的项目时，流程是这样的：初始代码code是由懂设计的前端基于mitosis开发的，输出的是设计稿。专业UI基于设计稿（符合组件规范和响应式规范）。通过有丝分裂将设计稿打磨输出为任何前端框架代码。前端基于框架代码开发。这样一来，上面的痛点就迎刃而解了。小结在项目开发过程中，前端需要配合后端。久而久之，一些前端同学涉足接口转发的中间层，成为了业务+Node工程师。同样，前端也需要配合UI。未来会不会像上面想象的那样，有一群UI+前端工程师？欢迎加入人类优质前端框架群，与大家一起成长