不断扩大对前端开发商的责任

这是我的文章“当前端意味着全栈时”的加长版，这篇文章发表在斯利普出版的精彩增量杂志上。这在某种程度上也是我的其他两篇文章“大鸿沟”和“哎呀，我想我们现在是全栈开发人员”的演变。

当我发现WordPress主题中的style.css文件时，我就爱上了前端开发。那就是所有魔力的地方(就是！)。对我来说。我可以(可以！)。更改其中的几行代码，就可以完全改变网站的外观。这是一款令人难以置信的游戏。

通过摆弄HTML和CSS，我可以改变您对一些写作的感觉。我可以让你在买活动门票时感觉更舒服。我可以增加你和朋友分享东西的机会。

那是在任何人付钱让我成为前端开发人员之前很久，但即使在那时，我也感受到了这份工作提供的令人陶醉的刺激组合。前端开发是这种富有表现力的艺术形式，但通常受到直接通信消息和实现业务目标等需求的限制。

前端开发是艺术与逻辑的交汇点。商业和表达的交叉。左脑和右脑都有。设计和书呆子的鸡尾酒。

回顾我从中学到大学选择的课程，我在以计算机为重点的课程和以艺术为重点的课程之间来回穿梭，所以我想我找到了一种方法来同时做这两种课程作为职业也就不足为奇了。

“前端开发人员”这个术语有相当好的定义和理解。首先，这是一个职称。我敢打赌，你们中的一些人确实有名片在上面写着这一点，或者一些变体，比如：“前端设计师”、“用户体验开发人员”或“用户界面工程师”。围绕这些意味着什么的争论对我来说并不是特别感兴趣。我发现不同的工作和不同的公司的角色是如此的不同，以至于职称永远不足以描述事情。获得这份工作更多的是展示你比其他任何事情都更清楚自己在做什么。

标题的变化只是细微差别。更大的情况是，只要工作是建立网站，前端供应商就会专注于浏览器。字面意思是：

作为“浏览器人”，总会有一些真理随之而来。其一是不同浏览器的整体格局，尽管标准团体尽了最大努力，但它们的行为仍然略有不同。就在今天，在我写这篇文章的时候，我处理了一个错误，我从API得到的日期字符串的格式是这样的，当我试图对它使用.toISOString()JavaScript API时，Firefox会抛出一个错误，但在Chrome中没有问题。这就是作为前端开发人员的生活。这就是我的工作。

即使在整个浏览器环境中，仅在台式计算机上，用户使用浏览器的方式也存在差异。他们的窗户开了多大？他们的操作系统上是否激活了暗模式？那台显示器的色域怎么样？像素密度是多少？带宽情况如何？他们使用键盘和鼠标吗？一个还是另一个？都不是吗？所有这些问题也同样适用于移动设备，那里即使不是更复杂，也是同样复杂的浏览器环境。等你仔细看一看HTML电子邮件就知道了。

这有很多未知因素，针对这种未知环境进行开发的答案牢牢掌握在前端开发人员手中。

这份工作最重要的方面是什么？使用这些浏览器的人。这就是我们建造东西的原因。这些都是我试图用我疯狂的CSS技巧打动的人。这些就是我要找的人来买我的小玩意儿。我所有的商业图表都依赖于他。谁的反应能像风中的纱线一样左右我的情绪。这些用户，我们有充分的理由把他们放在基座上，他们比浏览器拥有更广阔的视野。他们说不同的语言。他们想要不同的东西。他们正在努力解决不同的问题。他们有不同的体能。他们有不同程度的紧迫感。同样，帮助他们完全掌握在前端开发人员手中。我们在文本编辑器中输入的字符和我们希望服务的用户之间几乎没有什么联系。

作为一名前端开发人员，我们置身于我们正在建造的东西和我们为之建造的人之间的第一线，这是我们中的一些人真的很享受的地方。

那是很重的东西，不是吗？我甚至还没提到你的反应呢。

“我们关心用户”这句话可能会让人觉得有点珍贵。我认为，在一家运作良好的公司里，从CEO到下层，每个人都会关心用户。不过，这是不同的。当我们编写一个<；按钮>；时，实际上就是将一个按钮放入用户直接交互的浏览器窗口。当我们调整颜色时，我们精确地调整了视力正常的用户在看到我们的作品时看到的内容。

这距离一位陶艺家从泥土中拉出把手做咖啡杯不远。它是将工艺应用到数字体验中。虽然后端开发人员可能非常关心站点的用户，但正如Monica Dinculescu在一次关于此的对话中告诉我的那样，他们“将责任外包”。

我们确定前端开发人员是浏览器用户。这项工作就是让软件在浏览器中运行良好。因此，我们需要了解浏览器使用的语言，即：HTML、CSS和JavaScript²。这不仅仅是我是一个老派的原教旨主义者；这是通过几十年的日常前端开发工作，了解这些基础语言对我们做好工作至关重要。即使我们不直接使用它们(HTML可能来自另一种语言的模板，CSS可能来自预处理器，JavaScript可能主要是用框架的说法编写的)，浏览器最终是HTML、CSS和JavaScript，因此调试在很大程度上发生在那里，浏览器的功能也在发挥作用。

CSS永远是我的最爱，而HTML感觉它是最需要爱的--但JavaScript才是我们真正需要研究的，在过去的十年里，JavaScript已经从一种用于少数交互效果的语言发展成了整个网页设计和开发过程中使用的主要语言。在网站上工作，除了JavaScript什么都不写是可能的。一场真正的翻天覆地的变化。

JavaScript在浏览器中是万能的。从某种意义上说，它取代了HTML和CSS，因为这两种语言都不能做JavaScript不能做的事情。HTML由浏览器解析并转换为DOM，JavaScript也完全可以创建和操作DOM。CSS有自己的模型CSSOM，该模型将样式应用到DOM中的元素，JavaScript也可以创建和操作该模型。

不过，这不太公平。HTML是浏览器在完成构建站点所需的其余工作之前解析的第一个文件。这种第一是HTML独有的，也是让网站变得快速的重要部分。

事实上，如果HTML是唯一通过网络传输的文件，那么应该足以提供站点的基本信息和功能。

这种哲学叫做渐进式强化。我自己也是一个粉丝，但我并不总是完全坚持这一点。例如，当<；form>；的action属性指向可以处理该表单的URL时，<；form>；可以在HTML中完全起作用。“渐进式增强”会让我们以这种方式建造它。然后，当JavaScript执行时，它接管提交并通过Ajax提交表单，这可能是一种更好的体验，因为页面不需要刷新。我喜欢那样。更进一步说，如果没有JavaScript，表单外部的任何<；button&>都是完全没有用的，所以本着渐进式增强的精神，我应该等到JavaScript执行之后，才能将该按钮放到页面上(或者至少显示出来)。在这种情况下，即使是我们这些好心的人也可能不会总是完美地遵纪守法。把纽扣放进去，山姆。没人会死的。

JavaScript的全能让它成为我们这些在网络上工作的人的一个吸引人的目标-特别是JavaScript作为一种语言已经发展到更加强大和符合人体工程学，用JavaScript构建的框架变得更加强大-更是如此。早在2015年，JavaScript的使用率就已经非常明显地经历了令人难以置信的增长，WordPress的联合创始人马特·穆伦韦格(Matt Mullenweg)给开发者世界布置了作业：“深入学习JavaScript”³。他说得再对不过了。五年后，JavaScript在接管前端开发方面做得很好。尤其是当您查看前端开发工作时。

虽然网络年鉴可能会告诉我们，在排名前无数的网站中，只有5%的网站使用REACT，而包括jQuery在内的这一比例为85%，但当环顾一下前端开发工作需求时，这些数字几乎是颠倒的。

我相信这一切都有奇特的经济原因，但工作对人来说是同样重要和个人的，所以它非常重要。

因此，我们是JavaScript海洋中的浏览器人员，为人们构建东西。如果我们从实际的日常任务层面来看这份工作，它有点像这样：

从响应性设计的角度思考，使我们能够在各种设备上进行设计和构建。

对我来说，仅仅是第一个要点就像是大学文凭。综上所述，所有这些观点都是肯定的。

不过，这整个列表有点抽象，所以让我们把它应用到我们可以看到的东西上。如果这个网站是我们目前的项目呢？

那些是什么字体？我们是否需要全部加载它们，或者我们可以将它们子集吗？当他们装货时会发生什么？这种布局感觉真的会受到字体转换堵塞的影响。

这里有一些重复的模式。我们也许应该做一个卡片设计模式。每个网站都需要一个好的卡片图案。

那是一个华丽的配色方案。这些颜色在数学上是相关的吗？我们应该制作变量来单独表示它们，或者我们是否可以根据需要只改变单一的色调？我们是否要在CSS中使用自定义属性？虽然颜色只是颜色，但我们可能不需要它们的级联力量来实现这一点。我们应该只使用Sass变量吗？我们要使用CSS预处理器吗？

这里的源订单很棘手。我们需要订购东西，以便它们对屏幕阅读器用户有意义。我们应该召开一次会议，讨论内容的预期顺序，即使我们在视觉上使用CSS网格移动了一些东西。

这里的照片拍得很漂亮。但其中一些颜色与网站…的背景颜色相匹配。我们能摆脱阿尔法透明的PNG吗？它们总是那么大。有什么下一代格式可以帮助我们吗？或者我们是否应该尝试将JPG的背景与站点的背景无缝匹配。谁在为这些写替代文本？

这里有一些正在使用的图标。内联SVG，对吧？当然是某种SVG，不是图标字体，对吧？我们应该建立一个完整的图标系统吗？我想这取决于我们将如何在更广泛的范围内建造这个东西。我们到底有什么建造系统呢？

这里的整个前端计划是什么？我可以用普通的HTML、CSS和JavaScript编写代码吗？嗯，我知道我可以，但是团队的期望是什么呢？客户的期望是什么？它需要是反应性的东西，因为它是已经反应的东西生态系统的一部分吗？或Vue或Svelte或其他什么？有没有CMS参与？

我很高兴设计师不仅考虑了“桌面”和“移动”的尺寸，还考虑了介于两者之间的尺寸。那些总是很尴尬的。不过，这里没有互动信息。当搜索字段被聚焦时，我们应该做什么？当那个汉堡包被敲击时会显露出什么？我们是否在这里进行页面级转换？

我可以说个不停。这是前端开发人员的想法，至少在我的经验和与同行交谈时是这样。

不过，其中很多事情一直是我们的工作。只要我们一直在做，我们就会在我们建立的每个网站上询问和回答这些问题。每个网站都有不同的挑战，这很棒，让这份工作很有趣，但也有很多重复的地方。

虽然我们多年来一直在做这方面的工作，但我们还需要开始做一大堆新的事情，特别是如果我们正在讨论使用现代JavaScript框架构建站点的话。尽管所有的现代框架都喜欢对一些事情持不同意见，但它们都同意一件重要的事情：一切都是组件。您可以根据需要嵌套组件并将其拼接在一起。即使是原生JavaScript也朝着自己的Web组件模型发展。

我喜欢这种组件的想法。它允许您和您的团队构建对您和您正在构建的内容最有意义的抽象。

您的Card组件完成了您的卡需要做的所有事情。您的表单组件执行表单的方式与您的网站需要执行表单的方式相同。但对于像我这样的老开发人员来说，这是一个新概念。JavaScript中的组件以一种服务器端组件从未有过的方式站稳脚跟。我在许多WordPress网站上工作过，在那里我做的最好的事情就是将模板分解成有点随意的include()语句。我在Ruby on rails站点上工作过，其中的部分参数接受少量局部变量。这些对于构建可重用部件很有用，但它们与今天JavaScript框架为我们提供的健壮组件模型相去甚远。

所有这些自定义组件的创建使我以一种我过去不是的方式成为一名站点级架构师。这里有一个例子。当然，我有一个按钮组件。我当然有一个图标组件。我将在我的Card组件中使用它们。My Card组件位于网格组件中，该组件对它们进行布局和分页。整个页面实际上是由组件构建的。Header组件具有搜索栏组件和UserMenu组件。边栏组件有一个导航组件和一个广告组件。整个页面只是一个特殊的组件组合，它可能基于URL，假设我全力以赴地使用JavaScript构建我们的前端。所以现在我自己处理URL，我基本上是整个网站的架构师。[大汗淋漓]。

几乎可以肯定的是，负责显示内容的组件没有使用其中的数据进行硬编码。它们被构建为模板。它们被构建为接受数据并基于该数据构建自身。在过去，当我们做这种模板化时，数据可能已经到达我们正在处理的页面。在JavaScript驱动的应用程序中，这些数据更有可能是由JavaScript获取的。也许我会在组件呈现时获取它。在我现在使用的堆栈中，前端在Reaction中，API在GraphQL中，我们使用Apollo客户端来处理数据。我们在Reaction组件中使用一个特殊的“钩子”来运行查询来获取我们需要的数据，当我们需要更改该数据时使用另一个特殊的钩子。猜猜那是谁干的？是否有其他类型的开发人员专门从事此数据层工作？不，它已经成为前端开发者的领域。

说到数据，网站通常需要处理的所有其他数据都不是来自数据库或API。在这个时刻，真正与网站相关的数据才是真正的数据。

前端开发人员与这种状态打交道已经有很长时间了，但正是这种状态让我们之前陷入了麻烦。可以使用简单的修饰符类(如<；div class="；mode is-open&34；>；)打开模式对话框，并且使用.classList.toglg("；.is-open"；)；切换该类非常容易，但这是一种纯粹的视觉处理。页面上的其他内容如何知道该模式是否打开？它会问DOM吗？在过去的许多jQuery风格的应用程序中，是的，它会。在某种意义上，DOM成为我们网站的“真理之源”。这种体系结构产生了各种各样的问题，从简单的命名更改以奇怪而隐秘的方式破坏功能，到难以推理的应用程序逻辑使得修复bug成为一个困难的命题。

前端开发人员集体认为：如果我们以更深思熟虑的方式处理状态会怎么样？国家管理，作为一个概念，变成了一件事。JavaScript框架自己构建了这个概念，第三方库已经并将继续为此铺平道路。这是扩大责任的又一例证。谁设计了国家管理？谁来执行和实施它？它不是其他角色，它是前端开发人员。

在要做的事情清单中有不断扩大的责任，但在拼凑起来方面也有工作要做。这种状态中有多少可以在单个组件级别上处理，有多少需要在更高级别上处理？这些数据中有多少可以在单个组件级别获得？应该从上面过滤多少数据？设计本身就起到了作用。此组件的样式中有多少应该限定在其自身范围内，有多少应该来自更多的全局样式？

难怪设计系统在最近几年大受欢迎。不管怎样，我们都在构建组件，所以系统地考虑它们是很自然的。

即使我们使用JavaScript框架构建，我们也可以静态呈现这个站点吗？还是在服务器端呈现呢？

那些食谱是从哪里来的？我们能不能让GraphQL API运行起来，这样我们就可以在任何需要的时候请求任何我们需要的东西？

也许我们应该选择一个具有API的CMS，它将促进我们想要做的那种前端构建。也许是无头CMS？

我们的路线是怎么走的？对于这样的事情，我们选择的框架是自以为是还是不自以为是？

我们需要哪些部件？卡片、图标、搜索表单、站点菜单、img…。我们能把这些脚手架搬出去吗？我们是否应该从基础框架之上的某种设计框架开始呢？

我们可能需要的客户端状态是什么？当前搜索词，当前标签，汉堡是否打开，至少。

这个网站有没有登录系统？登录的用户显示的内容有什么不同吗？

也许我们可以找到一种奇特的图像组件，它可以执行模糊加载和延迟加载等等。

这些都是现在前端开发人员的领域，除了我们已经需要做的所有事情之外。执行设计、语义、可访问性、性能…。这些都还在那里。您仍然需要精通HTML、CSS、JavaScript以及浏览器的工作原理。作为一名前端开发人员，需要一堆不断增长的技能，这是网络变大的自然结果。越来越多的人使用网络，互联网接入也在增长。围绕网络的经济增长。浏览器的功能不断增强。人们对网络上可能发生的事情的期望与日俱增。这里没有太多的缩水现象。

我们已经到了大多数前端开发人员不知道全部责任的地步。有很多开发人员仍然在为自己做得很好，他们相当专注于设计，擅长创造性的、实现良好的HTML和CSS，尽管寻找这种职位的帖子越来越少。

有专注于系统的开发人员，甚至整个机构专门帮助其他公司构建和实现设计系统。有一些专注于数据的开发人员让他们感觉最自在，让整个网站的数据流动起来，让业务逻辑变得紧张而繁重。虽然所有这些人的名片上可能都有“前端开发人员”，但他们的职责甚至对他们工作的期望可能会有很大的不同。一切都很好，我们会想办法及时讨论这一切的。

事实上，在过去的十年里，我们谈论网站的方式已经发生了很大的变化。我早期的一些介绍。

.