前端设计人员的工作是创建HTML、CSS和展示内容的JavaScript代码，为Web产品打造用户界面。在我看来，前端设计是一座将设计与开发工作连接起来的桥梁。

当然，这一岗位的名称也不一定就是“前端设计师”。公司里负责这一任务的职位有很多种叫法，比如说：

UI开发人员
客户端开发人员
UI工程师
设计工程师
前端架构师
设计师/开发人员
原型工程师
创意工程师
开发设计师（Devigner，微软的发明）

不管这些人顶着的是什么名头，他们的职责都是为网站用户界面编写代码。前端设计人员的日常工作包括：

制作语义HTML标记。重点关注可访问性，为浏览器、辅助技术、搜索引擎等使用HTML的环境提供友好的体验。
创建CSS代码。塑造Web体验，处理颜色、排版、响应式布局、动画等可视UI元素。前端设计人员要构建的是弹性化的CSS代码，具备模块化、灵活性、兼容性和可扩展等属性。
编写主要用于操作DOM中对象的JavaScript。例如在单击折叠面板标题时打开或关闭折叠面板，或者关闭一个导航面板等。
进行跨浏览器和设备的测试。确保UI在桌面PC、智能手机、平板电脑等支持Web的设备（甚至未来可能出现的联网设备）上都能赏心悦目、正常工作。
优化前端代码的性能。创建轻量级、快速加载、流畅无卡顿的体验。
与设计师协作。将品牌、设计愿景和用户体验的最佳实践正确地在浏览器中展示出来。要注意的是，浏览器才是实际用户使用你的实际产品的现实场景所在。
与后端和应用程序开发人员合作。确保前端代码与后端代码、服务、API等技术架构正常兼容。

看完这段总结，你可能会吐槽说作者在扯什么废话。但我之所以要阐明这些职责是要强调：这是一项艰苦且细致入微的工作，需要大量的思考、责任心和关注度。前端设计是一项全职工作，需要当作一个专业岗位来认真对待。

或者你也可能在看完这段总结后想到：“这不是前端开发人员要干的事情吗”嘛，也许就是这回事。一篇题为“大分工”的文章是这样总结的：“前端开发”这个词的涵义现在非常广泛了，因为“JavaScript能做的事情变多了”。

“大分工”文中的图片，其中CSS连接着“前端的前台”与“前端的后台”两大部分

“前端开发”现在包含了一大堆内容。以前我还开玩笑说，我们前端设计人员是呆在“前端的前台”，还有很多开发人员是在“前端的后台”。这种分法挺切合实际的，因为这种大分工直接影响了React这样的JavaScript框架。

迷失在React中的前端设计师

React的网站的欢迎页面是这样介绍自己的：“用于构建用户界面的JavaScript库”。

正好，我就是负责构建用户界面的！这可就是我的专长了，而且我专业打造用户界面已经有十多年，React应该是我的地盘才对。

然而它并不是。或者至少对于我前端设计师的工作来说React没啥用。

Dan Abramov在他的文章“UI设计的元素”中阐述了他在构建大规模应用程序的UI时面临的许多挑战。我觉得这篇帖子文章精准地指出了“前端的后台”和“前端的前台”之间的分界线。文章提到的内容看起来都很关键，但我承认有很多部分其实我也没看懂。他提到了保持数据同步、缓存失效、状态管理、处理路由差异等一堆注意事项，幸好我的工作从来不涉及这些内容，将来我也不想碰它们。

像React这样的JS框架的流行并不是偶然产物。这些框架为开发人员构建大型应用程序时的实际需求提供了解决方案。我很高兴这些框架可以帮助这些应用程序开发人员处理那些问题。

但是这些解决方案也有副作用，那就是侵占了HTML和CSS的空间。前端Web开发中HTML和CSS负责的部分被塞进了一个JavaScript“箱子”。这可是给前端设计师打了一颗难对付的曲线球。

之前的一篇文章中我分享了自己学习React的艰难经历，并收获了许多人热情的帮助意见。但我也收到了很多像我一样困惑的人们的（通常是私人的）信件，现在都还没停。作为佐证，最近伟大的Jonathan Snook（我一直以来的偶像，他的经历比我丰富的多）写了一篇文章分享了他自己学习React的痛苦历程：

我哪像是开发老手啊，简直像个大三学生似的。我经常茶饭不思就是为了搞清楚某些内容，结果越学越难受。有时我研究一两天时间都没取得任何进展，然后只能去找人给我讲课；本来讲的内容我应该自己搞明白才对，显得我很没用的样子。

看起来前端设计师们都卡在React上了，所以我觉得这里有些内容应该探讨一番。

组件大乱炖

React中的一切都是组件。用户在屏幕上看到的一个按钮是一个组件；处理单击该按钮时发生事件的业务逻辑是一个组件；单击应用程序时，应用程序引导用户的路径是一个组件；从头到脚都是组件。

这些单拿出来都不是问题，但是当我们看到一个包含一大堆组件的应用程序时感到不知所措也是正常的，因为这些组件的功能天差地别，开发者还得一点点把它们捋顺才行。再次引用Jonathan的言论：

这些东西就那么一下子涌进来了，一开始很难分清谁是属于谁的。“噢原来这个是Redux，那个是React，还有一个是lodash，总算明白了。”

我们要处理的不只是React，还有它的小伙伴们。

我现在的工作涉及多个React代码库，这些代码库包括业务逻辑、展示代码、数据操作代码等让人头疼的形式，（在我看来）它们纠缠在一起装在不透明的文件结构中。睁大眼睛找一找的话可能会找到一些HTML，当然这些HTML是负责实现的，但无疑是淹没在其他内容中了。

我承认我感到非常失败，直到我看到Dan Abramov的文章“展示组件和容器组件”时才看到了一丝希望。Dan谈到了展示组件（沉默组件）和容器组件（智能组件）之间的差异。这篇文章总算让我感觉自己在这个疯狂的JS世界中可能还有那么一点立足之地的。

我研究一个基于React的客户端项目已经有大约一年半了，我很高兴能走上这条由这位前端设计师在全新的JS世界中开辟出来的道路，也很高兴能向大家分享我的旅途经历。

全新JS世界中的前端设计师领地

随着模式库的流行，Dave Rupert认为我们需要为每位客户提供“微型Bootstrap”。

响应式交付产品应该是风格类似Twitter Bootstrap的全功能系统，可根据客户的需求量身定制。

他切中了要害，特别是“为客户需求量身定制”这部分。这就是设计系统爆炸式增长的源头：所有这些模式库都包含了某种解决组织棘手的UI问题的方案。

回到Bootstrap上来，过去的问题是开发人员可以把Bootstrap的CSS和JS文件连接起来，但必须手动将Bootstrap的HTML转换为他们自己的环境。

在这个全新的世界中事物有另一套运行机制。我们现在拥有可直接消费的组件，这意味着组件的结构、样式和行为都可以打成一个简洁的包。这从很多层面上带来了令人激动的变革。

在React世界中有像Material UI和React Bootstrap这样的框架，可以将这些流行的前端UI库转换为可直接消费的React组件。这些预制解决方案自有其用武之地，但同时许多组织还在制作自己的自定义UI组件库以满足需求，诸如Salesforce的React闪电设计系统、IBM的React Carbon设计系统、Shopify的Polaris等等。

因此考虑到可直接消费的UI组件，我对Dave的观点修正如下：

前端设计交付产品应该是风格类似React Bootstrap的全功能系统，可根据客户的需求量身定制。

这是一个微妙但重要的区别。前端设计人员不仅可以创建组件的参考HTML、CSS和展示JS，还可以创建可直接消费的HTML、CSS和展示JS，然后让后端开发人员为其注入活力。但请注意，“根据客户需求量身定制”的原则没变。我不是说“只使用React Bootstrap”，而说的是要创建一个UI组件库来满足你的特定需求。

在我看来，可直接消费的UI组件可以作为大分工之间的桥梁。它在前端的前台和前端的后台之间创建了良好的沟通渠道。

所以为了实现这一点，在本文开头列出的职责列表中需要添加以下内容：

创建一个展示UI组件的库。然后打包起来供其他开发人员使用。
为每个展示组件编写一个稳健且直观的组件API及API文档。以便使用组件的开发人员可以轻松将所需内容插入组件中。
确定组件库应该有多大的灵活性或刚性。与开发人员合作，确定每个组件应该是开放/可组合还是硬性/锁定的。
将展示组件作为产品来维护。这意味着我们必须处理版本控制、部署、管理、发布说明等维护软件产品的各种操作。

最重要的是，我们必须卷起袖子学习像React这样的JS框架。也不是要学习和React相关的所有内容，只学对前端设计工作有用的React知识即可。

可消费的UI组件长什么样？

这种组件长什么样呢？例如一个警报组件：

组件的基础内容（用JSX编写）如下所示：

<div
  className={`c-alert ${variant}`}
  role='alert'
  {...other}
>
    <Icon
      name={iconName}
      className='c-alert__icon'
    />
  <div className='c-alert__body'>
    <h2 className='c-alert__title'>{title}</h2>
    <div className='c-alert__description'>
      {children}
    </div>
  </div>
</div>

我们正在为由应用程序开发人员填写的动态数据（例如标题）创建插槽。

组件构建好后应该能让别人使用。一种方法是在应用程序中放一个“ui-components”文件夹，但更好的方法是将它作为自己的产品发布出去（看，我正在发布我自己的UI框架！）。这样一来其他开发人员就能用下面的命令获取你的组件库：

npm install our-react-design-system

组件库安装好后开发人员就可以插入这个警报组件：

import Alert from "our-react-design-system/components/Alert";
<Alert 
  variant="success"
  iconName="checkbox"
  title="Profile updated!"
>
  You have successfully updated your profile.
</Alert>

这个副本来自哪里？是什么引发了警报？这就是后端开发人员操心的事情了。他们把这些展示组件包装在智能层中，这些智能层处理业务逻辑、数据操作等实现该警报组件所需的内容。

我喜欢可消费的UI组件

我同React打交道的这一年半时间里，我最喜欢的内容并不是React专属的，它就是可直接消费的组件这个概念。这也是为什么我对Web组件热情高涨的原因所在，因为它们是Web原生的，可以与不同的JS框架互操作。

可直接消费的UI组件的概念有很多优点：

它集中了前端代码库。允许前端专家在单一源头中管理标记、样式和展示JS。这样就不会让前端代码散落得到处都是，并让前端设计人员更加慎重地设计前端代码架构。他们可以迭代并改进UI组件代码，并将这些更改传播到使用组件的所有场景中。
前端设计人员控制了前端代码。我参与过的很多项目中，很多非前端开发人员复制并粘贴了他们需要的标记，并省略了他们不理解的属性。果然，ARIA属性似乎神秘地消失了，div被直接推到了ul标签下，文档结构自然一团糟。以前这种情况下前端设计师无能为力，只能在深夜独自垂泪。但使用可直接消费的UI组件后，前端设计人员就能保持对UI代码的控制权，并为其他开发人员提供与之交互的API，不用再暴露源标记、样式和展示JS了。
可以将最佳前端实践融入组件。令人激动的重大变革。由于UI组件现在是集中管理的，因此你可以将最佳前端实践融入组件中，而其他开发人员可以免费获得这些最佳实践。我之前写的文章介绍了自动生成ID以创建更易访问的表单控件的方法。应用程序开发人员不用再操心需要死记硬背的细节事项，可以腾出精力专注于其他更有价值的任务。

我的工作流程

我最近的演讲谈到了我的这种新工作方式的流程，要点包括：

具体的工作流程涉及很多细节，需要单独撰文介绍了。

我在React世界中仍在设法解决的问题

作为前端设计师，我很高兴自己终于在JS的新世界中找到了立足之地。之前很多人都希望我能分享我的React旅途中的新动态，这篇文章就是答案。虽然React有很多令人喜爱的地方（特别是我在上面重点介绍的可消费组件），但有些情况下我还是会遇到问题，或者还在寻找解决办法：

我想看到什么

我希望看到更多的前端设计师站出来，学习React（和/或其他JS框架和/或Web组件）的前端部分。再说一遍，你不必学习React的所有相关内容，只需学习可以为这些环境提供出色的标记、样式和展示JS的部分。这会对你创建的产品带来直接而重要的贡献。
我希望看到后端开发人员认识到前端设计的重要性。并在代码库中为前端人员腾出空间。当然，现在什么事情都在JavaScript的范畴之内，但划出界限还是很重要的，所以要尽量为其他领域的技能留出展现价值的空间。
求求大家了，请意识到专家的价值所在。组织别再假模假样地雇用一些“全栈开发人员”了，聘请一些专家吧。因为要做的工作太多了。前端的前后台都需要专业人士处理，专家才能精于此道，而全才只能给出及格分而已。
我希望看到组织/行业层面更加细分需求。“我们正在招聘一名React开发人员”到底是什么意思？“React开发者”和“前端开发者”都是很宽泛的说法，所以要澄清一下。你在寻找的是专注于标记和样式的员工？还是要创作中间件和业务逻辑？抑或是负责管理数据和数据库？管理构建流程？别说什么都要干，参见上一条。
因为现在“一切都是JavaScript包揽”、“一切都是组件”，所以在这种大环境下做好区分需要缜密的思考。这还是细分的话题。我非常喜欢将UI组件库作为一个单独的产品进行管理的想法，因为这样以来前端的前后台之间就有了明确的分界线。无论如何你的项目都要区分清楚UI侧的代码与应用侧的代码。另外非常重要的是在代码库中为不同专业的人留好各自的空间。
别再扯什么React爱用不用之类的废话了。这样讲话有意义吗。是团队选择技术方案，要创造能让擅长不同技术的人们通力协作的环境，而不是把人随便踢出去。
学习这些库是可以的，但没想当什么全栈开发人员。有的前端人员也会干后端工作，反之亦然；很多人想做全栈，也很棒！但做专家也很有意义，要做的事情太多了，谁的才能都有施展的空间。

这是一次有趣的旅程，我期待能继续学习和提升下去。感谢阅读。

英文原文：http://bradfrost.com/blog/post/frontend-design-react-and-a-bridge-over-the-great-divide/

创作场景

大前端时代，UI 设计师也需要学习框架！