这是我文章“当前端意味着全栈时”的扩展版本，该文章发表在Stripe推出的精彩的Increment杂志上。它也是我另外几篇文章的演变，例如“巨大的鸿沟”和“哎呀，我想我们现在都是全栈开发人员了。”
我爱上前端开发的那一刻，是我在WordPress主题中发现了style.css文件。对我来说，那里才是所有魔法的所在（仍然是！）。我能够（可以！）更改其中的几行代码，彻底改变网站的外观和感觉。这是一个令人难以置信的游戏。
通过调整HTML和CSS，我可以改变你对一段文字的感觉。我可以让你对购买活动门票感到更舒适。我可以增加你与朋友分享内容的可能性。
那是在任何人付钱让我成为前端开发人员之前，但即使在那时，我也感受到了这份工作带来的令人陶醉的刺激混合体。前端开发是一种富有表现力的艺术形式，但往往受到诸如需要直接传达信息和实现业务目标等因素的限制。
前端开发处于艺术与逻辑的交汇点。商业与表达的交汇。左右脑的结合。设计与极客的鸡尾酒。
我爱它。
回顾从中学到大学选择的课程，我在以计算机为中心的课程和以艺术为中心的课程之间来回切换，所以我想我找到一种将两者作为职业的方式也就不足为奇了。
“前端开发人员”这个术语定义明确且易于理解。首先，它是一个职位名称。我敢打赌，你们中的一些人确实有印着这个职位名称的名片，或者类似的变体，例如：“前端设计师”、“用户体验开发人员”或“用户界面工程师”。围绕这些职位名称的含义的争论对我来说并不特别有趣。我发现这些角色在不同的工作和公司之间差异很大，以至于职位名称永远不足以描述它们。获得这份工作更多的是展示你了解自己在做什么，而不是其他任何东西¹。
Chris Coyier
前端开发人员
职位名称的变体只是细微差别。更大的图景是，只要工作是构建网站，前端开发人员就会专注于浏览器。从字面上看
- 前端 = 浏览器
- 后端 = 服务器
即使这份工作在几十年里发生了变化，这种区别在很大程度上仍然适用。
作为“浏览器人员”，某些真理会随之而来。其中之一是存在各种各样的浏览器，尽管标准组织做出了最大努力，但它们的行为仍然略有不同。就在今天，当我写作时，我处理了一个错误，其中我从API获得的日期字符串格式使得Firefox在我尝试在其上使用.toISOString() JavaScript API时抛出错误，但在Chrome中却没问题。这就是前端开发人员的生活。这就是工作。
即使在台式电脑的浏览器环境中，用户使用浏览器的差异也很大。他们将窗口打开多大？他们在操作系统上启用了深色模式吗？该显示器的色域如何？像素密度是多少？带宽情况如何？他们使用键盘和鼠标吗？一个或另一个？都不使用？所有这些问题也适用于移动设备，在那里存在同样复杂甚至更复杂的浏览器环境。等你仔细看看HTML电子邮件时，你就知道了。
有很多未知数，而针对这个未知环境进行开发的答案牢牢掌握在前端开发人员手中。
这项工作最重要的方面是什么？使用这些浏览器的用户。这就是我们构建事物的原因。这些人是我试图用我精湛的CSS技能打动的人。这些人是我试图让他们购买我的小部件的人。我所有业务图表都依赖于他们。他们的反应可以像微风中的毛线一样左右我的情绪。这些用户，我们出于充分的理由将他们放在基座上，他们的环境比浏览器要广阔得多。他们说不同的语言。他们想要不同的事情。他们试图解决不同的问题。他们有不同的身体能力。他们有不同的紧迫程度。同样，帮助他们牢牢掌握在前端开发人员手中。在我们键入文本编辑器中的字符与我们希望为之服务的用户之间几乎没有什么东西。
成为前端开发人员使我们站在我们正在构建的事物和我们为之构建事物的用户之间的最前沿，而这是我们中的一些人真正喜欢待的地方。
这真是意义重大，不是吗？我甚至还没有提到React。
“我们关心用户”这件事可能感觉有点珍贵。我认为在一家高效运转的公司里，每个人都会关心用户，从首席执行官到最基层的员工。但情况有所不同。当我们编写一个<button>时，我们实际上是在将一个按钮放入浏览器窗口中，用户可以直接与之交互。当我们调整颜色时，我们正在调整当用户看到我们的作品时，他们所看到的颜色。
这与陶瓷艺术家从粘土中拉出一个咖啡杯的把手没什么区别。它将工艺应用于数字体验。虽然后端开发人员可能非常关心网站的用户，但正如Monica Dinculescu曾经在一次关于此的谈话中告诉我的那样，“将这项责任外包出去”。
我们已经确定前端开发人员是浏览器人员。这项工作是让事物在浏览器中良好运行。因此，我们需要了解浏览器使用的语言，即：HTML、CSS和JavaScript²。这不仅仅是我这个老派的原教旨主义者在说；通过几十年的日常前端开发工作，我们了解到，掌握这些基础语言对于我们做好工作至关重要。即使我们不直接使用它们（HTML可能来自其他语言中的模板，CSS可能由预处理器生成，JavaScript可能主要用框架的语言编写），最终发送到浏览器的仍然是HTML、CSS和JavaScript，因此调试主要发生在那里，并且浏览器的能力得到发挥。
CSS永远是我的最爱，而HTML感觉最需要关注——但JavaScript是我们真正需要检查的。过去十年见证了JavaScript从一种用于少量交互效果的语言发展成为在整个Web设计和开发堆栈中使用的主要语言。有可能在网站上工作并且只编写JavaScript。这是一个真正的巨大变化。
JavaScript在浏览器中功能强大。从某种意义上说，它取代了HTML和CSS，因为这两种语言都无法做到JavaScript做不到的事情。HTML由浏览器解析并转换为DOM，JavaScript也可以完全创建和操作DOM。CSS有自己的模型，即CSSOM，它将样式应用于DOM中的元素，JavaScript也可以创建和操作CSSOM。
但这并不完全公平。HTML是浏览器在执行构建网站所需的其他工作之前解析的第一个文件。这种首位性是HTML独有的，并且是使网站快速加载的关键部分。
事实上，如果HTML是唯一一个通过网络传输的文件，那么它应该足以提供网站的基本信息和功能。
这种理念称为渐进增强。我自己也是粉丝，但我并不总是完美地遵循它。例如，当<form>的action属性指向可以处理表单的URL时，它在HTML中可以完全正常工作。渐进增强会让我们以这种方式构建它。然后，当JavaScript执行时，它接管提交并让表单通过Ajax提交，这可能是一种更好的体验，因为页面不需要刷新。我喜欢这样。更进一步，任何位于表单外部的<button>如果没有JavaScript就完全没有用，因此本着渐进增强的精神，我应该等到JavaScript执行后才能将该按钮放在页面上（或者至少显示它）。这是一种情况，即使是我们那些拥有最佳意图的人也可能无法始终完美地遵循规则。只是把按钮放进去，山姆。没人会死的。
JavaScript的强大功能使其成为我们这些在网络上工作的人的有吸引力的目标——特别是在JavaScript作为一种语言不断发展变得更加强大和符合人体工程学，以及用JavaScript构建的框架变得更加强大的情况下。早在2015年，JavaScript的使用量就出现了惊人的增长，WordPress联合创始人Matt Mullenweg就给开发人员世界布置了作业：“深入学习JavaScript”³。他再正确不过了。五年后，JavaScript在接管前端开发方面做得很好。特别是如果你看看前端开发工作的话。
虽然Web年鉴可能会显示，在排名前几百万的网站中，只有5%使用React，而85%的网站包括jQuery，但当查看前端开发工作要求时，这些数字几乎颠倒了。
我确信所有这些背后都有复杂的经济原因，但工作对人们来说非常重要和个人化，所以它非常重要。
所以我们是在JavaScript的海洋中，为人们构建事物的浏览器人员。如果我们从实际的日常任务层面对这项工作进行观察，它有点像这样
- 将设计转换为代码
- 以响应式设计的思维方式思考，使我们能够跨设备环境进行设计和构建
- 系统地构建。构建组件和模式，而不是一次性的东西。
- 将语义应用于内容
- 考虑可访问性
- 担心网站的性能。优化一切。减少、重复使用、回收。
仅仅第一个要点对我来说就感觉像是大学学位。总的来说，所有这些要点当然都是。
不过，整个列表有点抽象，所以让我们将其应用到我们可以查看的内容上。如果这个网站是我们当前的项目呢？
我们的大脑和手指疯狂起来！
- 让我们用CSS网格构建布局。
- 那些是什么字体？我们需要加载它们的全部内容还是可以对其进行子集化？它们加载时会发生什么？这种布局感觉会受到字体偏移卡顿的严重影响。
- 这里有一些重复的模式。我们可能应该创建一个卡片设计模式。每个网站都需要一个好的卡片模式。
- 这个配色方案太棒了。这些颜色在数学上有关联吗？我们应该为每个颜色定义变量，还是根据需要修改单个色调？我们会在 CSS 中使用自定义属性吗？颜色仅仅是颜色，也许我们不需要为了这个目的使用 CSS 的层叠特性。我们是否应该只使用 Sass 变量？我们是否会使用 CSS 预处理器？
- 这里的源代码顺序有点棘手。我们需要对内容进行排序，以便屏幕阅读器用户能够理解。我们应该开个会讨论内容的预期顺序，即使我们使用 CSS Grid 对内容进行视觉上的重新排列。
- 这里的照片拍摄得非常漂亮。但有些照片与网站的背景颜色相匹配……我们可以在这里使用 alpha 透明的 PNG 吗？它们总是那么大。有没有下一代格式可以帮助我们？或者我们应该尝试让 JPG 的背景与网站的背景无缝匹配。谁来写这些图片的
alt文本？ - 这里使用了一些图标。内联 SVG，对吧？肯定是某种 SVG，而不是图标字体，对吧？我们应该构建一个完整的图标系统吗？我想这取决于我们如何更广泛地构建这个东西。我们有构建系统吗？
- 这里的整个前端计划是什么？我可以使用原生 HTML、CSS 和 JavaScript 来编写这个东西吗？好吧，我知道我可以，但团队的期望是什么？客户的期望是什么？因为它属于一个已经使用 React 的系统，所以它需要使用 React 吗？或者 Vue、Svelte 或其他什么？是否有 CMS 参与？
- 我很高兴设计师不仅考虑了“桌面”和“移动”尺寸，还处理了一个介于两者之间的尺寸。这些尺寸总是很尴尬。这里没有交互信息。当搜索字段获得焦点时，我们应该做什么？点击汉堡菜单时会显示什么？我们在这里使用页面级过渡吗？
我可以继续说下去。至少根据我的经验和与同行交流，前端开发者就是这样思考的。
不过，很多事情一直都是我们的工作。在我们从事这项工作以来，我们就在每一个网站上提出并回答这些问题。每个网站都面临着不同的挑战，这很棒，也让这份工作充满乐趣，但也有很多重复。
让我来谈谈这篇文章的标题。
虽然我们已经做了很多年这些事情，但我们开始被期望做很多新的事情，特别是如果我们使用现代 JavaScript 框架构建网站的话。所有现代框架，尽管它们喜欢在某些事情上意见不一，但在一个重要的事情上达成了一致：一切都是组件。根据需要嵌套和组合组件。即使是原生 JavaScript 也朝着自己的 Web Components 模型发展。
我喜欢组件这个概念。它允许你和你的团队构建对你和你正在构建的东西来说最有意义的抽象。
你的 Card 组件执行卡片需要执行的所有操作。你的 Form 组件按照你的网站所需的方式处理表单。但对于像我这样的老开发者来说，这是一个新的概念。JavaScript 中的组件以服务器端组件从未实现的方式流行起来。我曾参与过许多 WordPress 网站的开发，我做的最好的事情就是将模板分解成一些任意的 include() 语句。我还参与过 Ruby on Rails 网站的开发，其中使用了包含少量局部变量的局部视图。这些对于构建可重用部件很有用，但它们与 JavaScript 框架今天提供给我们的强大组件模型相去甚远。
所有这些自定义组件的创建使我成为了一种我以前从未担任过的网站级架构师。举个例子。当然，我有一个 Button 组件。当然，我有一个 Icon 组件。我将在我的 Card 组件中使用它们。我的 Card 组件位于一个 Grid 组件中，该组件负责布局和分页。整个页面实际上都是由组件构建的。Header 组件包含 SearchBar 组件和 UserMenu 组件。Sidebar 组件包含 Navigation 组件和 Ad 组件。整个页面只是一个特殊的组件组合，它可能基于 URL，假设我全力使用 JavaScript 构建我们的前端。所以现在我自己处理 URL，我基本上是整个网站的架构师。[大量出汗]
就像我告诉你的，一大堆新的责任。
负责显示内容的组件几乎肯定不会在其内部硬编码数据。它们被构建成模板。它们被构建为接受数据并根据该数据构建自身。在过去，当我们进行这种模板化时，数据可能已经到达了我们正在处理的页面上。在 JavaScript 驱动的应用程序中，数据更有可能是由JavaScript 获取的。也许我会在组件渲染时使用 fetch 获取它。在我目前正在使用的技术栈中，前端使用 React，API 使用 GraphQL，我们使用 Apollo Client 来处理数据。我们在 React 组件中使用一个特殊的“钩子”来运行查询以获取我们需要的数据，并在我们需要更改数据时使用另一个特殊的钩子。猜猜谁来做这项工作？是专门从事此数据层工作的其他类型的开发人员吗？不，它已经成为前端开发人员的领域。
说到数据，网站通常必须处理所有这些其他数据，这些数据并非来自数据库或 API。这些数据实际上仅在网站当前时间点相关。
- 哪个选项卡当前处于活动状态？
- 这个模态对话框是打开还是关闭？
- 手风琴的哪一部分已展开？
- 此消息栏是处于错误状态还是警告状态？
- 您分页了多少页？
- 用户向下滚动页面滚动了多远？
前端开发人员长期以来一直在处理这种状态，但正是这种状态让我们之前陷入困境。可以使用一个简单的修饰符类（如 <div class="modal is-open">）来打开模态对话框，并且使用 .classList.toggle(".is-open"); 切换该类非常简单。但这只是一种纯粹的视觉处理。页面上的其他任何内容如何知道该模态是否打开？它会询问 DOM 吗？在许多过去 jQuery 风格的应用程序中，是的，它会询问。从某种意义上说，DOM 成为我们网站的“真相来源”。这种架构导致了各种各样的问题，从简单的名称更改以奇怪的隐蔽方式破坏功能，到难以理解的应用程序逻辑使错误修复变得困难。
前端开发人员集体思考：如果我们以更谨慎的方式处理状态会怎样？作为一种概念，状态管理成为了一件事。JavaScript 框架本身内置了该概念，第三方库也为其铺平了道路并继续铺平道路。这是责任扩大的另一个例子。谁负责状态管理的架构？谁来执行和实现它？这不是其他角色，而是前端开发人员。
待办事项清单中的责任正在扩大，但还需要将所有这些内容整合在一起。多少状态可以在单个组件级别处理，多少需要在更高级别处理？多少数据可以在单个组件级别获取，多少需要从上层传递？设计本身也起作用。组件的样式有多少应该限定在其自身范围内，多少应该来自更全局的样式？
近年来，设计系统如此流行也就不足为奇了。我们无论如何都在构建组件，因此系统地思考它们是自然而然的。
让我们再次看看我们的设计。
可以开始一系列新的思考！
- 假设我们使用 JavaScript 框架，使用哪一个？为什么？
- 即使我们使用 JavaScript 框架构建，我们也可以静态渲染此网站吗？或者服务器端渲染？
- 这些食谱来自哪里？我们可以启动一个 GraphQL API，以便在需要时请求任何我们需要的内容吗？
- 也许我们应该选择一个具有 API 的 CMS，以促进我们想要进行的前端构建。也许是一个无头 CMS？
- 我们如何进行路由？我们选择的框架对这类事情有自己的看法还是没有？
- 我们需要哪些组件？
Card、Icon、SearchForm、SiteMenu、Img……我们可以构建这些组件吗？我们是否应该在基础框架之上开始使用某种设计框架？ - 我们可能需要哪些客户端状态？至少包括当前搜索词、当前选项卡、汉堡菜单是否打开。
- 此网站是否有登录系统？已登录的用户是否显示不同的内容？
- 我们是否可以在这里利用第三方组件？
- 也许我们可以找到那些花哨的图像组件，它们可以执行模糊加载、延迟加载等等。
这些都是如今属于前端开发人员的领域，此外还有我们已经需要做的所有事情。执行设计、语义、可访问性、性能……所有这些仍然存在。您仍然需要精通 HTML、CSS、JavaScript 以及浏览器的运作方式。成为一名前端开发人员需要掌握大量的技能，而且这些技能还在不断增长。这是网络不断发展壮大的自然结果。更多的人使用网络，互联网接入也在增长。围绕网络的经济也在增长。浏览器的功能也在增长。对网络上可能实现的功能的期望也在增长。这里没有什么正在缩减。
我们已经到了大多数前端开发人员都不了解所有责任的地步。仍然有很多开发人员做得很好，他们专注于设计，并在创意和实施良好的 HTML 和 CSS 方面表现出色，即使寻找此类人才的职位发布正在减少。
有一些专注于系统的开发人员，甚至还有一些专门帮助其他公司构建和实施设计系统的整个代理机构。还有一些专注于数据开发人员，他们在使数据在整个网站中流动并处理业务逻辑方面感觉最自在。虽然所有这些人可能在他们的名片上都印着“前端开发人员”，但他们的职责甚至对工作期望可能大不相同。一切都很美好，我们会及时找到方法来讨论所有这些。
事实上，在过去十年中，我们谈论构建网站的方式发生了很大变化。我早期接触 Web 开发的一部分是通过 WordPress。WordPress 需要 Web 服务器才能运行，是用 PHP 编写的，并将数据存储在 MySQL 数据库中。尽管 WordPress 已经发展了很多，但所有这些仍然完全相同。我们使用首字母缩写词来描述这个“技术栈”：LAMP，即 Linux、Apache、MySQL 和 PHP。请注意，整个技术栈中的所有内容都由后端技术组成。作为前端开发人员，LAMP 中的任何内容与我无关。
但从那时起，其他技术栈也出现了。一个流行的技术栈是 MEAN（Mongo、Express、Angular 和 Node）。注意我们如何开始逐渐转向更多前端技术？Angular 是一个 JavaScript 框架，因此随着此技术栈的流行，将前端作为技术栈的重要组成部分的讨论也随之兴起。Node 和 Express 都是 JavaScript，尽管是服务器端版本。
Node 的存在是这个故事的重要组成部分。Node 不是类似 JavaScript 的东西，它完全就是 JavaScript。它使已经熟练掌握 JavaScript 的前端开发人员能够进行服务器端工作，而无需过多扩展。
“无服务器”（Serverless）是一个更现代的技术流行语，它主要指的是在云服务器上运行少量代码。大多数情况下，这些代码片段是用 Node 编写的，由 JavaScript 开发人员编写。如今，专注于 JavaScript 的前端开发人员可能会编写自己的无服务器函数，并且本质上成为了自己的后端开发人员。他们会认为自己是全栈开发人员，而且他们是对的。
Shawn Wang 今年为一个新的技术栈创造了一个术语：STAR 或者说 设计系统、TypeScript、Apollo 和 React。这对我来说非常不可思议，不仅因为我有点喜欢这个栈，还因为它是一种谈论网站的技术栈的方式，而这个栈完全是前端技术。这是一个很大的转变。
如果您在阅读本文后感到有点焦虑，我表示歉意。如果您觉得在理解所有这些东西方面落后了，**您并不孤单。**
事实上，我认为我还没有和任何一位开发人员谈过，他们告诉我他们对整个网站构建世界感到完全自在。每个人都有弱点或整个领域，他们根本一无所知。您不仅可以专注于某个领域，而且专注于某个领域是一个非常好的主意，我认为无论您是否计划，您最终都会在某种程度上专注于某个领域。如果您有幸能够计划，请选择您喜欢的东西。您会做得很好。
生活中唯一不变的就是变化。
– 赫拉克利特 – 激励海报 – Chris Coyier
很棒的文章，Chris！谢谢。
一篇很棒的文章。感谢您的结语。到最后，我的冒名顶替综合症开始发作了。
Chris，这是一篇很棒的文章！文章组织得非常好。
感谢 Chris 的这篇文章。
阅读时我仿佛置身于另一个世界。写得非常好。
React 是大型框架中最古老的一个，这一点很明显。
流行的原因在于其简单性。非常适合新手。但与 Angular、Svelte、Vue 相比，它在很多方面都过时了。
Angular 比 React 更古老。
Vue 实际上是 Angular 和 React 的混合体。
Svelte 是唯一一个尝试完全不同事物的框架，这很可能是它尚未流行起来的原因。
至于 React 非常适合新手，Vue 被广泛认为比 React 更容易上手，而 React 已经比 Angular 更容易上手了。
一如既往地，关于这个主题的精彩文章。我想说，随着前端变得越来越复杂，安全性也是一项日益增长的责任。
我也有类似的背景故事，小时候我对艺术和计算机都很感兴趣，并且通过 CSS 的强大和简单性爱上了所有这些网络事物。当我构建我的第一个网站时，我记得在发现 Chrome 中的 Web 检查器之前的那种挫败感，而这反过来帮助我掌握了 CSS 盒模型。那也是我发现 CSS-Tricks 的时候。我最终涉足了其他编程语言、设计，然后是油画一段时间，最终又回到了网络——使用 WordPress 构建网站。我从未真正适应 WordPress 或 PHP——只是在每个任务出现时解决它，并尝试以“正确”的方式完成所有事情。当我真正开始深入研究 JavaScript 时，jQuery 似乎已经开始过时了，而且我一直更喜欢避免使用库和框架。
那是 2015 年。我从 Zell Liew 在这里发表的“Gulp for Beginners”文章中了解了 Node 和 npm（而且我喜欢使用 Gulp！）。然后在 2016 年，我阅读了有关 MEAN 栈、Meteor、React、ES6、Babel、Webpack、模块等等的信息，并且比以往任何时候都感到更加困惑。我发现了 ShopTalk Show 播客，感觉好多了（这提醒我需要更多地收听它！）。
我觉得有一半的挑战在于理解什么做什么、它解决什么问题，以及为什么要或何时使用它。一旦您开始理解它帮助的一些事情，其他事情就会自然而然地发生，并且您可以在此基础上积累知识。我仍然在很多方面落后，有时会感到不知所措，但有时也会感到充满力量。前端开发人员可以做很多事情——JAMstack、渐进式 Web 应用、SVG 动画、画布 API…… 您几乎可以构建任何您想要的东西，而且这一切都发生在网络上，访问网络变得越来越方便。即使在 2000 年代初我还是个孩子的时候，我也认为点击一个网站并发现它根本不是一个网站，而是一种交互式艺术或游戏，这是一种神奇的事情。
有时我只会做设计工作，有时我只会编写代码，但大多数时候我更像是一个前端**设计师**，这个术语由 Brad Frost 在这篇文章中提出 ➜
我仍然在每个任务出现时解决它，并尝试以“正确”的方式完成所有事情，在学习和积累知识的过程中不断学习和积累。并且知道我并不孤单，并且最终这一切（某种程度上）都归结为 HTML、CSS 和 JavaScript，这多少让人感到欣慰。
听到其他人说 CSS 是他们最喜欢的，我感到很高兴，因为 CSS 一直是我最喜欢的，而且显然这不是一件普遍的事情。
您在这里有很好的同伴。:)
我读过的关于前端最好的文章之一。谢谢
绝对精彩的文章，Chris。作为一个几乎没有开发技能的设计师，它让我对前端有了全新的认识。
天哪，我正在尝试自学前端 Web，这篇文章让我感到恶心。自由职业的开发人员如何才能跟上所有这些变化并找到工作？这太荒谬了。
很棒的文章，总结了我目前的想法。一句话：疲惫。我是一名全栈开发人员，我的一个前端项目是一个使用 AngularJs 构建的单页 Web 应用程序。几年后，我变得非常熟练，我的老板建议我们应该使用 Angular2.0。突然间，我被期望能够用 TypeScript 编写代码，理解组件，并有效地从头开始学习一个全新的框架，仅仅是为了制作与之前完全相同的 Web 应用程序。（我拒绝了）。但从那时起，我一直试图跟上（阅读：赶上）所有新的 Web 技术，这样我不会感到如此绝望地脱节，但老实说，根本没有时间。现在，在所有其他内容之上，您还有基于云的服务，它们可以提供一种全新的创建 Web 应用程序的方式以及其他所有内容。几乎不可能仅仅跟上现有的东西以及它们的功能，以了解是否有更好的方法来解决手头的问题。
在这一点上，作为一名前端开发人员，全栈开发人员？我甚至不知道如何描述我们所做的事情了。我只能说，我们基本上什么都做。
Chris，很棒的文章。我完全同意。对于我这样从 HTML 和 CSS 开始并热爱它们的人来说，前端开发似乎变得越来越复杂。再加上考虑客户端项目的 CMS 方法并为他们设置访问权限以自行进行编辑（然后培训他们），需要处理的事情很多。责任大大增加了。我不确定雇主对这些角色中所需知识的尊重是否也随之增长，因为在我观察到的我的地理区域中，职位名称似乎都塞满了“做所有事情”的内容，但薪资却很一般。我确实有时会质疑所有这些变化对于基本网站项目是否真的必要，但选项并不缺乏，我想这也是一件好事。我仍然热爱这项工作，但毫无疑问，跟上这些变化通常会让人不知所措，尤其是在学习时间如此有限的情况下。
精彩的阅读！知道我并不孤单，在某些方面感到落后或不足，这真是太好了。我喜欢认为我足够了解可以完成任何扔给我的工作，但我确实觉得我应该学习更新的技术。
此外，关于 PHP include() 的内容让我忍俊不禁，并且让我回想起早期 PHP 编程的片段，所以谢谢您，Chris！
很棒的阅读！
这就是我需要的精神疗法。感谢您，Chris，将我们职业中的陷阱提炼成这篇急需且无价的文章。
感谢你，Chris，听到像你这样的人这么说，我感到很欣慰。我从事这份工作近10年了，最近一直在找工作。前端开发职位描述中列出的各种期望和不同的技术，有时即使是实践者也会感到有些不知所措。
我觉得随着前端开发的扩展和融入更多传统的程序员理念，它变得有些混乱了。在面试中，我可以热情地谈论设计、用户、浏览器以及你上面提到的所有内容，但现在到了面试当天，一切都变成了LeetCode和Dijkstra算法。所以这些现在也加到了清单上了。
</sigh>哇，真是太棒了。我能把这篇文章提名为我2020年最佳文章吗？太喜欢了，有很多值得思考的东西。感谢你用文字表达出难以言喻的内容！
前端开发的职业生涯非常类似于电影中配角的角色。配角是电影中最关键的部分。他/她的演技和对角色的热情可能超过或等于主角。他们身兼数职，例如提升剧本、鼓励其他演员、给观众留下持久的印象。在经济方面，配角们很艰难。他们的成功大多取决于运气或好的商业剧本。在空闲时间，他们会参加戏剧、舞台表演，以此来磨练或提升自己的技艺。另一方面，主角已经在观众心中树立了形象，通过身份象征、票房收入等。类似地，后端开发人员已经经历了具有竞争力的教育和经验来设计和构建数据库系统。前端开发人员的成功取决于你的工作，你如何成功地完成工作并解决组织的业务需求。其他有助于你成功的因素包括你对技艺的渴望、有时是运气以及在成为前端开发人员的旅程中保持理智。死记硬背JS框架是不会让你走到哪里的。除了你自己，还有很多人会在这个领域帮助你取得成功。
一篇写得如此优美的文章
有趣的文章……看到最后我确实觉得自己像个冒牌货。
我第一次接触网页开发是在将近15年前，但不知何故，我设法避免学习除HTML、CSS和WordPress之外的任何东西。我经常觉得我应该学习Javascript和PHP，但总有各种干扰，我用花哨的WordPress主题和插件来实现复杂的功能。我终于决定停止制作WordPress网站，开始为一家公司工作。只拥有一个客户既让人轻松，又让人焦虑。我觉得我需要了解与我们网站相关的所有内容，并将其全部简化。我不知道接下来该学什么。
除了组件和状态管理之外，我们还有语义方面——文章中提到了这一点——但它也可以与许多SEO技术结合起来：从优化标记以创建精美的结构到使用微数据。我相信它可能包含在“性能”主题中，因为很大一部分SEO优化来自为用户提供闪电般的网站速度；因此，每次我们想到它时，责任清单都会不断增长。
顺便说一句，Chris的文章写得很好！感谢你撰写了这篇精彩的文章。
精彩的帖子！具有讽刺意味的是，我花了6周时间才读到它，因为它被埋在我的浏览器中其他100个标签后面——我正在启动一个绿地个人项目，并决定使用React，尽管在过去的两年里我一直只进行Vue开发，所以我一直都在快速学习React和Redux以及CSS-in-JS等等。
我使用React的原因（即使我非常不喜欢它，相比之下Vue更好！）是因为我觉得我应该了解它，如果不了解它，我就会错过一些东西。
这篇文章可能挽救了那个项目——我想我会坚持使用React，但除此之外，我刚刚开始阅读Go教程，认为也许我会用它来构建这个项目的后台，而不是坚持使用我已知的某些东西，比如Sanity、WordPress或Keystone，如果我继续这样做，我可能会永远迷失在杂草丛中。
我已经在思考类似的想法有一段时间了。前端开发人员的责任逐年增加，而设计师则被期望在Figma中绘制漂亮的图片。作为一名UX设计师，我渴望将我在语义HTML、CSS、动画和可访问性方面的技能运用到实践中，但不行，我必须记录无数的缺陷来将其整理成型，并等待一堆没有人有时间处理的增强功能。
我很乐意拥有这些直接影响用户体验的领域。我认为它们就是体验！设计师用来构建界面的工具缺乏HTML、CSS和一些基本JavaScript提供的各种细微差别。
你认为JavaScript已经取代了HTML和CSS的想法我并不认同，但我毫不怀疑这是事实。我觉得我们正因此陷入复杂性的泥潭。我希望看到设计师迎接这一挑战，并减轻开发人员的一些负担。