关于前端:前端这个工种未来会继续拆分么

大家好，我是卡颂。

作为前端，你和 UI 撕过逼么？

前端：“上线日期定死了，你什么时候出设计稿？你不出稿子前面开发、测试都得加班！”

UI：“快了快了，别催～”

前端：“做好的先给我吧，我画动态页面”

UI：“快了快了，别催～”

前端 流泪，后端 缄默，究竟 测试 承当了所有 ……

你遇到过这种状况么？

您感觉实质起因是什么？如何能力最高效解决这个问题？

本文会提供一种思路以及可借鉴的产品。

欢送文末就这个问题探讨

在古代 Web 开发窘境与破局一文中，作者牛岱谈到以后前端与 UI 的配合模式如下：

图片来自“古代 Web 开发窘境与破局”

UI在设计软件上实现设计逻辑、绘制页面款式，交付给前端。

前端依据 UI 绘制的款式重现用 CSS+HTML 在网页中再绘制一遍款式，绘制结束后再增加性能逻辑。

为什么 UI 用设计软件绘制的页面款式，前端还须要反复绘制一次？仅仅因为 UI 用设计软件，而前端须要编程么？

所以，现实的分工应该如下：

图片来自“古代 Web 开发窘境与破局”

即 UI 实现设计逻辑与页面款式（通过设计软件），软件依据标准生成前端可用的动态页面代码，前端基于生成的代码编写性能逻辑。

大白话讲就是：

前端不必画动态页了

尽管这套流程有诸多难点须要解决，比方：

对于 UI 来说，页面是一张张图层，对于前端则是一个个组件，怎么对齐这两者差别
须要 UI 理解根本的页面布局（浮动、flex、相对定位 …），能力生成合乎响应式标准的动态页

然而，瑕不掩瑜，如果能跑通这套流程，开发效率将极大晋升。

mitosis 就是这方面的一次大胆尝试。

BuilderIO是一家低代码平台，主做拖拽生成页面。mitosis的作者是 BuilderIO 的CEO。

用一张图概括 mitosis 的定位：

左起第一排别离是：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 类型（即组件），其蕴含状态 name，nodes 代表组件对应的视图。

如果输入指标是React，那么代码如下：

export function MyComponent() {const [name, updateName] = useState('Steve');

  return (
    <div>
      <input
        value={name}
        onChange={(e) => updateName(e.target.value)}
      />
    </div>
  );
}

如果你认真看这张图会发现，mitosis还能反向输入到设计软件。

是的，mitosis自身也是个框架。有意思的是，他更像是个 前端框架缝合怪。

他采纳了：

React的 Hooks 语法
Vue的响应式更新
Solid.js的动态JSX
Svelte的预编译技术
Angular的标准

下面的代码例子，如果用 mitosis 语法写：

export function MyComponent() {
  const state = useState({name: 'Steve',});

  return (
    <div>
      <input
        value={state.name}
        onChange={(e) => (state.name = e.target.value)}
      />
    </div>
  );
}

咱们在开篇谈到妨碍前端间接应用设计软件生成动态代码的两个痛点：

对于 UI 来说，页面是一张张图层，对于前端则是一个个组件，怎么对齐这两者差别
须要 UI 理解根本的页面布局（浮动、flex、相对定位 …），能力生成复合响应式标准的动态页

咱们构想一下，当应用 mitosis 开启一个新我的项目，流程如下：

由懂设计的前端基于 mitosis 开发初始代码
代码输入为设计稿
业余 UI 基于设计稿（合乎组件标准、响应式标准）润色
设计稿经由 mitosis 输入为任意前端框架代码
前端基于框架代码开发

这样，就解决了以上痛点。

在我的项目开发过程中，前端须要与后端配合。长此以往，一部分前端同学涉足接口转发的中间层，成为 业务 +Node工程师。

同样，前端也须要与 UI 配合，会不会如上文所构想，将来会呈现一批 UI+ 前端 工程师呢？

关于前端:前端这个工种未来会继续拆分么

脑中的场景

问题起因

一次大胆尝试

小小神思

未曾构想的路线？

总结