前端开发工作规划和展望（我认为前端的职责需要重新划分）
前端开发工作规划和展望（我认为前端的职责需要重新划分）因此，我希望将来，人们会考虑将 Web 客户端开发中的这些新职责分开。让我起名的话，我会称之为“Web UI”和“Web Core”。作为前端开发人员，我们在日常工作中并不熟悉这些东西。与此同时，真正的 UI 工作并没有减少。创建持久、可重用、灵活、易用且可访问的组件仍然是一项很大的挑战。设计师和产品所有者的工作干净利落，才能带来最好的 UI 和最佳的用户体验。这一点，从每天都会听到的新 Web API（如Web Assembly、Web Worker、Web GPU 等）中就可以看到。我们为应对那些新增的层所做的工作不仅和“基本 UI”相关。相反，我们会借助浏览器提供的新功能，将之前在后端处理的一些东西移到“前端”。以 Web Assembly 为例。Web Assembly 让我们可以在浏览器中运行一些库，而且具有原生性能。你不能在 Web Assembly 层做 DOM 操作。不过，
本文最初发布于的 Murat Çorlu 个人博客。
得益于云服务的高度抽象，大多数项目的后端工作都日益减少。仅使用一些公有云服务（如Firebas或CloudKit）提供的动态协同数据，就可以创建出功能完备的客户端应用程序。我们不需要维护任何服务器，就可以实现身份验证。有许多身份验证提供者，甚至是一些身份验证服务，都可以帮我们做到这一点。
而且显然，事情不止于此。不难想象，将会有更多的数据库服务，我们可以直接从前端读取或写入数据，而且安全、高效。项目的大部分后端工作将只是多个云服务之间的相互连接和配置。
那么，每位 Web 开发人员都将是一名“前端开发人员吗”？当然，总还是需要更为底层的服务器端专家的，至少还需要他们来创建那些云服务。但是，Web 项目中 90%的工作可能将在客户端完成。这将意味着，“前端”的新职责和挑战将越来越多。
这一点，从每天都会听到的新 Web API（如Web Assembly、Web Worker、Web GPU 等）中就可以看到。我们为应对那些新增的层所做的工作不仅和“基本 UI”相关。相反，我们会借助浏览器提供的新功能，将之前在后端处理的一些东西移到“前端”。
以 Web Assembly 为例。Web Assembly 让我们可以在浏览器中运行一些库，而且具有原生性能。你不能在 Web Assembly 层做 DOM 操作。不过，你可以做一些非常消耗 CPU 的事情，如图像处理、数据加密，甚或是机器学习。
Web Workers 让我们可以在渲染周期之外运行其他 JavaScript 例程，而且不会阻塞 UI。WebGPU让我们可以充分利用 GPU 的能力，更高效地进行图像计算、加密计算或 3D 渲染。WebRTC 让它可以与客户端 App 的另一个用户建立点对点连接，并发送/接收任何数据，包括视频流或音频流。文件系统访问 API 提供对用户本地文件系统的完全访问，可以读/写文件和目录。
作为前端开发人员，我们在日常工作中并不熟悉这些东西。与此同时，真正的 UI 工作并没有减少。创建持久、可重用、灵活、易用且可访问的组件仍然是一项很大的挑战。设计师和产品所有者的工作干净利落，才能带来最好的 UI 和最佳的用户体验。
因此，我希望将来，人们会考虑将 Web 客户端开发中的这些新职责分开。让我起名的话，我会称之为“Web UI”和“Web Core”。
Web UI 开发人员或许，我们可以将 Web UI 开发人员的职责大致罗列如下：
- Web 组件
- CSS
- 路由
- 表单
- 动画
- 可访问性
- Web 字体
- 画布
- SVG、SVG 过滤器
作为前端开发人员，这些都是我们很熟悉的工作事项。它们都和 UI 及用户交互直接相关。我们都知道，如果你考虑成为所有这些领域的专家，并能够创建一个实现相当不错的 Web 应用程序，会面临许许多多的挑战。
这个领域也是当前流行的 Web 框架所针对的领域。我们可以用 Lit 构建组件，用Angular管理复杂的表单，或是用 Tailwind 创建响应式网格。（最后一个是开玩笑。）
Web Core 开发人员Web Core 开发人员可能主要负责业务逻辑和客户端 App 中类似服务后端的部分，主要包括数据管理、业务逻辑和可扩展性（和当前后端开发人员的工作非常类似，是吗？），它们不会直接修改 UI。如果要为 Web Core 开发人员列出一些技术名称的话，或许可以列出下面这些：
- WebGL——WebGPU
- Worker
- Web Assembly
- Web Crypto
- IndexedDB
- 文件系统访问 API
- WebRTC
里面没有 React 或 Angular。这里没它们什么事。但对于复杂的 Web 应用程序，那些 API 就像是宝藏。此外，面对一位资深 React 开发人员，问他 WebGPU 或 WebAssembly 的专业知识是不公平的。
示例项目团队结构考虑一个管理照片/视频的 Web App 项目。我们将开发一个 Web 应用程序，可以向库里添加照片和视频，并可以对它们进行编辑、分类或分享。
我们不会为这个应用开发任何后端代码。我们将使用一个数据库服务和一个文件存储服务，并搭配一个身份验证服务一起使用。这些服务都是完全托管的外部服务。图像/视频编辑将完全在客户端完成。我们将以端到端加密的方式将所有数据存储到存储服务上。
如你所见，在这个项目中，不管是 UI 还是“Core”，都有相当多的事情要做。UI 端的挑战有：
- 一个精致的 UI，用于显示和搜索照片和视频，以及将它们添加到库中。
- 一个功能齐全且易于使用的 UI，用于编辑图像和视频。
- 和其他人分享相册，评论照片。
- 尽可能提高该 App 的“可访问性”。
另一方面，Core 端也面临着巨大的挑战：
- 编写一些“Web Workers”，以非阻塞的方式与云服务通信。
- 编写一个非常高效的图像操作库。
- 编写一个非常高效的视频编辑库。
- 一个加解密 API，在将图像和视频发送到存储服务之前以及获取到它们之后对其进行加解密。
- 将部分数据存储在本地，使 App 可以离线运行，并能稍后通过服务同步。
我想，当我们像这样列出任务时，任务类型的划分就非常清楚了。“Web Core”任务是纯粹的 I/O 挑战，从不涉及 DOM 或 CSS。另一方面，“Web Core”团队将为“Web UI”团队提供的 API 与当前“前-后”端世界的 API 非常相似。JS 接口代替了 REST 或 GraphQL API。
小结头衔和学科并不是让开发者永远坚守职责的高墙。相反，它们帮助我们一次只专注于一件事。注意力分散是我们这个时代最严重的疾病之一。我认为，对于每一位 IT 专业人员来说，关注质量而不是数量是非常有价值的。
查看英文原文：https://www.infoq.cn/link?target=https://medium.com/@muratcorlu/front-end-may-soon-need-new-sub-disciplines-60a4cde20562
