前端全职岗位依然坚挺，广大同志不必惊慌

我最近刚好在找新工作。过程当中，很多雇主在收到简历后都表示满意，但随后又提到我好像太偏前端，想了解我在后端和全栈开发方面有没有经验。在我看来，这股歪风在 2021 年之前就吹过一波，总有人感觉 Web 开发或者说前端专家已经不足以支撑一个全职岗位了。所以我当时就做过如下解释。

请注意：前端开发者擅长的不只是 HTML、CSS 和 JavaScript 这些“简单”的编程语言。前端开发者需要主动为未知的场景构建交互界面，他们的水平直接决定着最终用户的实际体验。

Web 绝不只是普通的编译目标，更是一个允许用户完全控制其外观风格的平台。它也是唯一一个拥有充足弹性，能够承受种种修改调整的平台。Web 同时面向桌面、Android 和 iOS，依托同一套代码库就能实现。只有敬业的前端开发者才清楚自己到底在干什么，而不会愚蠢地指望依靠一款插件或者扩展程序就奇迹般地让所有人都能获得满意的产品访问体验。

这里我还想再强调一句：无论最终选择什么平台，使用哪种编程语言，或者指定什么框架和库，最终跑在 Web 用户设备上的仍然是 HTML、CSS 和 JavaScript。

其中每一样（HTML 相对会好一点）都可能引发性能问题、跨浏览器功能冲突，并在难以预料的低配置、低网络质量环境中造成令人头痛的用户访问障碍。大家都知道，糟糕的性能表现只会让用户愤然“点叉”离去，某些服务无法正常访问甚至可能导致法律和合规性问题，导致我们被送上审判席。

我曾在全球最大的网站（包括 yahoo.com、bing、微软等等）和 Firefox、Edge 等浏览器上做过开发，这些开发商始终专注于一个目标：不要因为响应缓慢或者“错误”提示而被用户怒喷。所以我们得跟众多内部向外部合作伙伴携手，了解他们产品无法正常运行的原因。合作对象可能是扩展程序供应商、框架创建团队或者开发小组。在 Mozilla 和微软的“性能俱乐部”里，我们也一直在遇到各种问题：Web 产品中包含大量毫无意义的 HTML、几乎用不上的 CSS 和让人崩溃的 JavaScript，它们都在被无脑发送给用户。而这么做的原因，就是要让开发人员更便捷、更灵活地用一套框架搞定所有构建工作。

正是由于向全栈开发的转变，导致我们的 Web 体系越来越臃肿，它不仅拉低了客户满意度，也让用户平白付出了不必要的流量。

当然，造成 Web 产品质量堪忧还有另一个原因：组件设计缺乏大局观。

现在的 Web 产品压根不是按照文档或者作为网站进行构建的。相反，它们被视作一个个独立的组件，每个组件都非常灵活以适应不同的运行环境。这听起来很棒，但开发者开始随意进行组装，想起什么就塞进来什么。有时候，我们会发现 20 多种不同的、高度可定制的按钮组件，而它们执行的其实是同一种操作。

有经验的前端开发者肯定立马能察觉到其中的问题，并追踪到相应的资源浪费。

前端开发者究竟该如何定义？他们是：

• 浏览器性能专家

• 跨平台开发专家

• 辅助功能专家

• 合规知识专家

• 设计和测试部门间的桥梁

• 最终用户的客服代表

但很多人的观念都被市场导向给扭曲了。他们之所以看不起前端开发者，主要是因为大多数人根本不知道做好这份工作需要哪些能力。

CSS 和客户端 JavaScript 不算真正的编码也完全是奇谈怪论。更讽刺的是，那些宣称自己不想碰 CSS 的家伙，给出的理由往往是“太难了，太怪了”。CSS 也不单纯是在调色加填充，它有自己的网格、子网格和伸缩布局框，这是一套完全成熟的布局系统，还能实现动画和响应式渲染。通过媒体和容器查询，开发者可以获得惊人的灵活性；通过级联层，大家甚至可以控制浏览器呈现当前设计的具体方式。

所以选择权在雇主手里。你可以聘请前端开发者专职构建自己的产品，也可以随随便便凑合搭建起来，再聘请性能和辅助功能顾问修复其中的问题。但请注意，越是来到生产下游，产品的优化和修复就越是困难，且往往会与新功能产生冲突。

所以当雇主们问我为什么“只做前端”时，我以自豪的心情解释了这一切，并强调我以身为前端工程师为荣。

附录：其实同样的道理也适用于市场上的其他职位。好的数据库工程师能帮你省下几秒钟的加载时间；优秀的云工程师能帮你节约云运营成本；优秀的后端工程师能确保你的服务器只跑有用的负载，用不着为一大堆根本没用的前端代码运行优化管线。如今科技大厂都在收缩规模，所以市场上的人才水准随之提升。也许请一位 10 倍全栈“技术大师”的预算现在没准够请 3 位专项技术专家，毕竟他们刚刚逃离要拿全部收入的 80% 交房租的“宇宙一线城市”。