2022年国内外前端发展态势

作者: wechat 发布时间: 2022-10-18 浏览: 1002 次 编辑

前端是否厌倦了新趋势，并寻求稳定？

一、简介

过去两年挺不容易的，在全球范围内引发了许多变化。自从我们的生活逐渐"搬到了线上"，IT行业也顺势参与了数字转型。前端开发也在从技术探索再到落地实践等各个方面发生了很多变化。因此，我们尽可能的将前端2020年和2022年的数据并排呈现，以便更好地进行比较。

最著名的前端开发笑话“新的一天，新的框架”似乎已经过时了。当然，新的框架和库确实出现了，但在某些领域，朝着潮流创新的竞赛慢慢让位于成熟和稳定。

1.1 本文数据来源

  • 3703份有效填写的调查问卷
  • 125个国家的数据
  • 19位前端领域的专家

1.2 调查问卷分布

共计3703份问卷,其他: 84份,其中问卷分布如下:

  • 北美: 807份
  • 南美: 252份
  • 欧洲: 1918份
  • 非洲: 98份
  • 亚洲: 465份
  • 澳洲: 79份

除此之外，我们还邀请了19位当代前沿专家分享他们对调查结果的看法和评论。他们的见解不仅是知识的事实来源，还将为您提供不同前端开发主题的思考素材。再次向我们的每一位评论员致谢——没有你的知识和经验，这份报告就不会如此精彩。向他们表达一些感激之情！

我们也鼓励您积极参与结果分析！如果我们对前端人员有所了解的话，那就是每个人都有自己的意见，很少把它们留给自己——这很好，因为它推动了整个行业的发展。每个图表和表格都有一个“共享”按钮，以防您想与朋友开始讨论或只共享报告的一个特定数据点。

最后，向所有3703名填写该调查的前端人员表示衷心的感谢——没有你，就没有报告！

二、 开发者和工作条件

2.1 对于软件工程来说，过去几年最大的变化是远程办公

"高达56%的受访者表示远程工作，其中只有5%在办公室工作。大规模远程工作的概念如此新颖，以至于2020年的调查甚至没有测量这个数据点。

今年的一个大问题是，完整的远程工作将继续存在，还是我们将看到混合工作更受欢迎。大多数工程师显然更喜欢远程工作——不需要通勤，很少有人在肩膀上敲打分散注意力。然而，分享信息和复制办公室内已经存在的自发讨论仍然是一个挑战。" --- Gergely Orosz

2.2 你现在工作的形式是什么？

  • 远程办公: 59.7%
  • 公司办公: 5%
  • 混合办公: 35.3%

2.3 做前端开发的不仅仅是前端工程师

今年，一些从事前端开发的人在“其他”选项中共享的职位包括：

  • 一个训练营的学生刚刚开始学习前端
  • 一位自学成才的开发者在一所非技术大学学习，他爱上了frontend
  • 有时将代码推向生产的产品经理
  • 技术大牛，不时帮助前端团队
  • 前端开发架构师
  • 设计系统总监
  • 一个也会编码的设计师
  • 平面设计师和开发者
  • 全干工程师：一个人开发一切，包括前端开发

这应该不足为奇：但它总是很好地提醒我们，前端是一个非常容易上手的技术领域，即使在没有太多前端背景的情况下，这种情况很常见。

2.4 你从事前端工作的时间有多久?

  • 超过5年: 28.4%
  • 超过10年: 24.1%
  • 超过3年: 22.9%
  • 超过1年: 18.9%
  • 不足1年: 5.7%

2.5 开发者技术水平

  • 中级: 28.9%
  • 高级: 28.6%
  • 技术经理: 19.6%
  • 初级: 13.1%
  • 技术负责人: 4.6%
  • 首席技术官: 2.9%
  • 其他: 2.3%

2.6 在更大的前端团队中工作变得越来越普遍

27%的受访者表示在拥有50多名前端工程师的公司工作。同时，30%的开发者分享了5个或更少的前端开发者在他们公司的工作方式。50%的受访者在拥有10名或以上前端工程师的公司工作。

这个统计数据显示了一个有趣的二元性。在拥有大量前端团队的公司工作的前端工程师几乎与在少数人团队或单独工作的公司一样多。

这些公司的开发经验和期望相差很大。大公司在前端平台团队的同时，还将更重视开发人员体验。辅导也更常见。在较小的地方，每个开发人员的责任更大，获得反馈的选项更少。

作为一名前端工程师，我建议随着时间的推移，在这两种环境中工作，以最大限度地学习。

50%的前端工程师在拥有10名或以上前端开发人员的公司工作，27%的工程师在拥有50名或以上前端开发人员的公司工作，这一统计数据也可能是团队为大型前端团队构建工具的有趣提示。这些地方似乎越来越多。

2.7 公司规模

  • 大于501人: 30.1%
  • 51~200人: 20.4%
  • 11~50人: 19.9%
  • 2~10人: 10.5%
  • 201~500人: 10.2%
  • 仅此1人(个人公司/自由职业者): 8.8%

2.8 公司前端人数

  • 少于5人: 29.2%
  • 10~50人: 23.7%
  • 5~10人: 19.9%
  • 多于100人: 18.2%
  • 50~100人: 9%

2.9 本次调查问卷很少有非技术占主导地位的公司的人员参与填写

只有18%的填写调查的人说他们在非技术占主导地位的公司工作。82%的人认为自己在软件开发公司、开发机构或者技术占据主导地位的公司工作。很难说这项调查是否涉及到在更传统的公司工作的人，或者是否真的有更多的工程师在软件作为业务核心的地方工作。

无论如何，值得记住的是，调查结果绝大多数来自技术型公司。

2.10 以下哪项最能描述贵公司？

  • 软件开发公司/开发机构: 41.6%
  • 技术占主导地位: 41.2%
  • 非技术占主导地位: 12.3%
  • 其他: 2.9%
  • 政府部门: 1.9%

三、 框架

3.1 开发人员在选择框架时都会考虑到如何做到良好的实践和落地

"对我来说，2022年结果的故事是框架的兴起。开发人员似乎越来越希望元框架能够更快、更有信心地工作。调查显示，受访者越来越可能关注以下最佳实践（例如性能和最终用户体验），这完全解释了这种向元框架发展的趋势。"-- Sébastien Chopin(NuxtLabs首席执行官兼Nuxt作者)

3.2 在过去的一年里，您使用并喜欢以下哪些框架？

  • React: 76.2%
  • Next.js: 43.1%
  • Vue: 28.9%
  • Angular: 22%
  • Svelte: 16.9%
  • Gatsby: 11.6%
  • Nuxt.js 9.4%
  • Remix: 8.8%
  • Ember.js: 4.5%
  • 其他: 4.3%
  • Backbone.js: 1.9%

3.3 在过去的一年里，您使用过的框架中，哪些是您不喜欢的？

  • Angular: 51%
  • React: 25%
  • Gatsby: 17.7%
  • Vue: 17%
  • Backbone.js: 11.3%
  • Ember.js: 9.4%
  • Next.js: 8.3%
  • Svelte: 4.6%
  • Nuxt.js 4.1%
  • 其他: 2.8%
  • Remix: 2.5%

3.4 无障碍性

无障碍性是今年受访者的一个主要关注点，63%的人预测在未来几年内它将越来越受欢迎。框架往往提供不同的方法来解决这个问题，其中有一些值得注意的例子，包括Next/Nuxt Image、HTML validator和WebHint。Chrome Aurora团队正在与Angular、Next和Nuxt等元框架合作，以确保实现这些最佳实践。我预测，在未来几年，我们可能会看到所有这些主要框架的持续改进。

组件驱动开发也受到大多数开发人员的欢迎，考虑到React、Vue、Svelte甚至Web组件的流行，这一点很有意义（如今年的独立成功案例——Wordle）。

渐进式Web应用程序(PWA)也越来越流行，开发人员热衷于使用相同的核心代码库充分利用跨平台开发。我们还看到像开放网络倡导组织(Open Web Advocacy,简称OWA)这样的组织推动苹果拥抱开放网络。这绝对是一个值得效仿的空间。

无头CMS(headless CMS)也在进步，采用率更高，并更多地集成到框架中。对于我来说，Nuxt 3已经发布了新的Prismic、Strapi、Sanity、Storyblock和Directus模块，可以零配置或者极少需要额外的配置即可使用。

3.5 您希望在未来学习以下哪些框架？

  • Svelte: 49.2%
  • Remix: 36.2%
  • Next.js: 33.5%
  • Vue: 28.1%
  • React: 16.2%
  • Nuxt.js 13%
  • Gatsby: 10.5%
  • Angular: 8%
  • Ember.js: 3.2%
  • 其他: 2.7%
  • Backbone.js: 1.3%

我还注意到另一个趋势，这是没有明确提到这项调查。边缘渲染最初由CloudFlare及其worker平台驱动。调查中的大多数部署目标都发布或实现了自己的serverless或edge functions，这并不是偶然的，用户很快就会采用这些功能。Nuxt 3、Remix或Sveltekit等框架正朝着这个方向发展，直接在CDN级别实现按需渲染。随着服务器呈现的应用程序在减少延迟和降低成本方面的相应收益，我预测这将成为2023年的一个重点。

四、库

4.1 Redux&Lodash–广泛使用，喜欢还是…不喜欢？

"无论您如何看待Redux和Lodash，前端开发人员（自愿或不自愿）肯定会使用它们。在喜欢和不喜欢的解决方案中，他们都名列前三，这让我想知道，为什么人们会使用他们不喜欢的解决方案。我有几个理论。"-- Andrzej Wysoczański(Software House前端负责人)

4.2 在过去的一年里，您使用的并喜欢的库有哪些？

  • Axios: 61.5%
  • Lodash: 46.6%
  • Redux: 37.3%
  • Date-FNS: 34.6%
  • Moment: 31.9%
  • Apollo: 26%
  • RxJS: 23.5%
  • 其他: 8%
  • Ramda: 7.3%
  • Relay: 2.1%

根据我的经验，Redux被软件公司及其客户广泛使用，因为它适用于需要复杂状态管理的大型项目。然而，Redux的入门门槛相当高。如果开发人员从头开始学习Redux，并且这对他们来说是全新的，那么他们最初可能并不喜欢它。但是，他们必须学习，也要学习，因为近20%的受访者希望在未来掌握Redux，尽管这很难。或者，人们可能意识到，为了在前端开发中获得一份好工作，有Redux经验对他们的简历很有好处。

就Lodash而言，我唯一合乎逻辑的解释是，我们的受访者必须在进入项目时就有这些解决方案，他们使用这些解决方案是出于必要，而不是出于乐趣。

4.3 在过去的一年里，您使用过的库中有哪些您最不喜欢？

  • Redux: 47.7%
  • Moment: 41%
  • Lodash: 19.8%
  • RxJS: 18.7%
  • Axios: 10.9%
  • Apollo: 10.4%
  • Ramda: 5.3%
  • Date-FNS: 3.9%
  • Relay: 3.7%
  • 其他: 2.2%

似乎前端用户从Moment走向Date-FNS，这是一个好迹象。我感到震惊的是，超过40%的人仍然在他们的项目中使用Moment，无论他们的情绪如何。这个库已经失去了支持，甚至它的官方网站上也有创作者的留言说，如果你正在考虑使用Moment，你可能应该寻找替代品。幸运的是，只有5%的受访者渴望了解未来的Moment，所以这个库很可能走向衰落。

我们的“志趣相投”奖获得者Axios以超过60%的得票率肯定进入了稳定阶段。它在前端市场已经有很长一段时间了，人们对此很清楚，它更像是一种“标准”而不是一种“趋势”。难怪，它提供了体面的数据下载、通信以及与后端的一般合作。问题仍然是，Axios的反对者宁愿使用GraphQL，还是他们真的不喜欢使用它？

4.4 你将来想学习以下哪一个库？

  • Apollo: 41.3%
  • RxJS: 34.8%
  • Relay: 25.5%
  • Redux: 19.3%
  • Ramda: 13.9%
  • Date-FNS: 10.5%
  • Lodash: 8.9%
  • Axios: 8.8%
  • Moment: 5.2%
  • 其他: 2.8%

在提到GraphQL之后，我需要在这里对另外两个解决方案进行评论。由于Apollo用于与GraphQL的无缝连接，我认为它在“使用过的和喜欢过的”类别中会高得多。当我注意到40%的开发者希望在未来学习Apollo时，我的希望又复活了（这使它保住了第一的位置）。这意味着Apollo的社区正在稳步增长，我预计在下一份报告中会有更多用户使用这个库。

Apollo，其小菜一碟般简单的配置是最著名的一个在这里，但也许不远的将来,Relay可能就是其最大的竞争。Relay更复杂，仅适用于React和React本机应用程序，但26%的前端开发人员希望学习该库。如果更多的人使用Relay，更多的项目将实施它，这可能会导致更多的参与。我将继续关注GraphQL，因为我有一种感觉，这将是未来前端世界可以惊讶的地方。

4.5 设计系统(没有角逐出明显的胜出者)

"设计系统空间非常零散。没有一个单一的设计系统超过市场的24%。这是React的一大不同之处，React占据了大部分前端市场。我认为这可以简单地解释为，因为一家公司对设计系统的选择大多是“艺术”的，没有两个人有完全相同的设计品味。 "-- Olivier Tassinari(MUI首席执行官兼Material UI联合创始人)

4.6 在过去的一年里，您最喜欢以下哪种设计系统？

  • 个人自定义: 29.5%
  • Material UI/MUI: 23.5%
  • Tailwind UI: 22.5%
  • Bootstrap: 12.6%
  • 其他: 5.1%
  • AntDesign: 4.4%
  • Vuetify: 2.3%

作为一个侧面观察，结果中可能存在偏差。调查提出“Material UI/MUI”作为一个预定义的答案，我很高兴看到我们是领先的选择，然而，对于大多数人来说，Material UI是Material设计的同义词。因此，不清楚受访者是否从设计（设计系统）或代码角度（Material设计React UI库/框架）选择了这个答案。

4.7 样式工具,SCSS占据了半壁江山

” 哇哦，看看SCSS，加油！如果一个孩子是在SASS被释放的那天出生的，他们今天就已经到了可以学习开车的年纪了。这对于任何软件工具来说都是难以置信的长寿，尤其是在前端开发工具快速发展的世界中。"

"近一半的受访者表示，他们不仅使用SASS，而且它是我的最爱，这让我难以置信，我碰巧也同意，因为它也是我的最爱。"

"我认为它的语法相当不错，尽管我倾向于只使用一些特性，比如嵌套和轻混合用法。从某种意义上说，Sass现在面临的是CSS本身。我想变量是开发人员使用Sass的主要原因之一，但是自定义属性已经出现在CSS中，它们的支持无处不在，几乎不需要Sass变量。即使嵌套在CSS标准机构中也有发展势头，因此我们将拭目以待，看看随着时间的推移，它是否会削弱Sass的使用。" "不过，Sass是一个棘手的问题，它并不意味着你只会用到它。例如，PostCSS（仅在此处的“其他”部分中表示）在某种程度上设计为与SASS结合使用，至少是可选的。与CSS模块类似。虽然您可以单独使用CSS模块，但您几乎可以轻松地将其与Sass一起使用。这恰巧是我最喜欢的组合，它并不像下一个广受欢迎的组合那样特别深奥。js提供了现成的支持此组合的功能。“-- Chris Coyier(CSS-Tricks和CodePen的创始人)

4.8 在过去的一年里，以下哪种样式工具是您最喜欢的解决方案？

  • SCSS: 49.5%
  • Tailwind: 35%
  • Styled Components: 33.5%
  • CSS Modules: 24.9%
  • Emotion: 8.5%
  • Chakra: 7.3%
  • 其他: 5%
  • Vanilla Extract: 3.5%

哇哦，没想到Styled Components占据了这么高的比例 ！这让我印象深刻的是，问题只是关于样式化工具的使用，但是Styled Components几乎也意味着React的使用。因此，看到这一大占比，尤其是结合了Emotion、Chakra以及Vanilla Extract，我想这一切主要是在React环境中看到的，这表明了React对于本次调查的参与者来说是多么的占主导地位。这让我想起了其他大型JavaScript框架。Vue的人在哪里？我没有看到其他文件中特别提到的任何内容。他们可能只是…没想过？样式是Vue单文件组件领域的内置功能。在Vue中，你不会做出很多样式工具的决定，因为它只是为你准备的。这让我又回到了Sass。正如在Next.js中使用Sass很简单一样。所以你也可以在Vue、Svelte或Astro等更新的元框架中轻松使用Sass。

如果知道JavaScript框架在这里的使用情况有多严重，那么看到常规的ol元素的CSS仅仅是一个小插曲就不足为奇了。一旦您处于组件驱动的架构中，拥有适用于这些组件的CSS，并通过JavaScript的可用性提供额外的实用程序，人们利用这一点是有意义的，尽管性能不高。

Tailwind的受欢迎程度在这里也不足为奇。如果五年前你问我是否认为像“Tailwind”这样的东西会流行起来，我会说“不”，但我错了。我从无数的开发人员那里听说，使用HTML类来设计样式的想法只需要点击一下就可以了。我有自己的怀疑。如果做得好，Tailwind生成的CSS很可能会更小（对于像CSS这样的阻塞资源来说尤为重要），人们似乎无论如何都喜欢将工具的选择带来一个很好的性能优势。

很高兴看到像Vanilla Extract这样的工具试图在样式中提供各种现代开发人员人机工程学，并且非常专注于确保良好的性能是默认行为。这通常意味着“提取(extracting)”“vanilla”CSS，如果你遵循他们的命名双关语。

所有这些都让我想到，如果我们能看到数据，比如说，流量排名前5000的网站的风格选择，结果会是什么。或者在互联网上发布的最后5000个网站上做出的选择。或者GitHub上开发最活跃的5000个网站。这会相似吗？很难说他们是否会完全不同。但我想到了WordPress发布的令人震惊的数据：43%的互联网用户。这并不是说你不能建立一个基于JavaScript框架的WordPress网站，有些人是这样做的，但我相信这些WordPress网站中有一小部分是这样的。那么他们在做什么？他们是Sass的大用户吗？难道你不认为它们中有相当一部分是普通的CSS，仅仅因为WordPress本身不提供任何内置的样式工具吗？或者，这些站点中的大多数并不是真正由开发人员构建的，而只是自助部署？

看着样式工具的选择随着时间的推移而改变，这当然很有趣。我唯一可以肯定的是，几年后，这项调查会有惊喜，这在今天是不可能的。

4.9 开发工具

"很高兴看到前端调查涵盖了这个主题。您可以看到，越来越多的人开始对使用在线代码编辑器进行一些工作感兴趣，这非常令人兴奋。云开发只会继续增长，我希望看到更多的程序员和公司将他们的开发环境从本地转移到Cloud。"-- Ives van Hoorne(CodeSandbox联合创始人)

4.10 在过去的一年里，您使用了以下哪些开发工具？

  • Eslint: 83.4%
  • Prettier: 79.8%
  • Webpack: 76.8%
  • TSLint: 38.5%
  • Vite: 25%
  • Esbuild: 24.3%
  • Rollup: 22.1%
  • Parcel: 14%
  • 个人自定义的工具: 7.9%
  • Bun: 0.7%

这项调查证实了我们在CodeSandbox上已经注意到的情况。我们看到越来越多的人将他们的开发转移到网上，这也表明人们对云开发的普遍兴趣有所提高。仅在过去一年里，人们就创建了超过1200万个沙盒，占我们创建的沙盒总数的一半！

我对未来感到非常兴奋，因为我相信Cloud将使软件开发更容易访问和协作。我很高兴看到前端开发人员的回答反映了这种兴趣。至于我在这里对未来的期望，转向云开发可能比我们所有人想象的要快得多......

五、 Typescript

5.1 Typescript继续使Web开发不再那么令人沮丧

"TypeScript并不打算停止每年获得越来越多的公众关注。如果你将2022年的答案与两年前的答案进行比较，你会发现这一点。使用TypeScript的人数增加了7个百分点，已经达到了84% ！"-- Marcin Gajda(Software House的前端团队经理)

5.2 去年，你用过Typescript吗？

  • 用过: 84.1%
  • 没用过: 15.9%

我们都可能同意，TypeScript受到了开发人员的普遍欢迎，业界在未来几年不会放弃这项技术。这是怎么发生的？在网上讨论中，人们经常称赞TypeScript在错误发生之前就阻止了整个类别的错误。这反过来又使开发更快，应用程序更可靠。

我不想在这里争论，但既然你们问我是什么让这么多开发人员喜欢TypeScript，我想说的是，TS让Web开发方式比以前少了很多令人沮丧的地方。在经历了太多年的Web开发之后，前端开发人员不想重复多次在代码编辑器和浏览器之间来回切换的经历，以猜测为什么“undefined is not a function”。毕竟，“雪是白的(陈述一般事实)”类型的错误通常是由诸如变量拼写错误或参数放置错误之类的小错误引起的。

然后TypeScript拯救了我们，由微软推出，并在所有主要IDE中得到支持。现在，在前端编写代码感觉更加受控和简单。就我个人而言，我还喜欢在编写使用数据结构的代码之前设计数据结构，这为整个开发过程增添了额外的乐趣。

TypeScript不仅试图赢得开发者的心，而且还努力成为前端行业标准，不仅仅是针对Angular项目。可以肯定的是，完全不使用TypeScript的新商业项目已经很少了，在未来几年里，找到它们只会更加困难。如果你比较一下关于使用TypeScript和公司类型的问题，很明显，科技行业在他们的软件项目中自信地朝着TypeScript迈进。

以下为本次调查问卷中,各主要公司类型中对于TS的使用情况:

公司类型未使用采用TS
未提供类型32.67%67.33%
政府组织19.35%80.65%
非技术占据主导地位的公司19.21%80.79%
软件公司12.73%87.07%
技术占据主导地位的公司12.16%87.84%

为了进一步支持我的说法，过去一年里不接触打字的人更多地在非科技公司或政府组织工作......这反过来又常常激怒前端开发人员，他们不喜欢使用过时的技术。结果表明：与技术相关的竞争和动态竞争分别约为13%和20%。

5.3 展望TS的未来

就TypeScript的未来而言，预测发生了很大的变化。2020年，前三大选择之间势均力敌。受访者没有给出TypeScript和JavaScript之间会发生什么的明确答案。我敢打赌，两年前，我们仍然不确定TypeScript只是一种暂时的时尚，还是会在我们心中停留更长时间。考虑到前端世界中不断发生的事情，以及新解决方案出现的频率，谨慎一点是完全可以理解的。

5.4 在您看来，以下哪种TS的场景最有可能发生？

场景投票率
TypeScript将超越Javascript，成为新的前端标准43%
Javascript和TypeScript同样受欢迎27.6%
JavaScript将变成类似Typescript的东西16.6%
JavaScript仍将是前端标准11.8%
大家会将TS遗忘1%

本篇文章带来了更明确的答案。大多数人认为TypeScript将成为Web开发的主要解决方案，占43%。我知道，结果还没有超过50%，但如果你在玩“谁想成为百万富翁？”这就是你在“向观众提问”这条生命线中的结果，你不会打赌吗？我认为，当我们看到新出现的解决方案时，这种转变背后的主要原因就变得很清楚了。用TypeScript本机编写的库显著增加，大多数新的开发工具都支持现成的TypeScript。

最后但并非最不重要的一点是，在2022年3月，当微软宣布在JavaScript中引入TypeScript的类型语法时，我们可以实时观察到“JavaScript将变成类似TypeScript的东西”的答案变得比以往任何时候都更为现实。这意味着浏览器可以理解TS，但不支持类型检查。然而，目前，前端社区对该提案表示冷遇，我认为它没有机会以当前形式被纳入ECMA标准。这也意味着JS不会很快变形为TS的克隆体，但肯定有什么东西在传播。

六、 静态站点生成器(Static-site generators,后面简称为SSG)

6.1 SSG解决方案正在蓬勃发展

"越来越多的大公司不怕用SSG切换到无头CMS。Jamstack解决方案不再是一种新的尖端技术，对他们来说似乎不再是实验性的。"-- Samuel Snopko(Storyblock的DevRel负责人)

6.2 在过去一年中，您使用了以下哪种SSG？

SSG使用率
Next.js43.6%
没用到任何框架或库35%
Gatsby22.7%
Nuxt.js9.8%
其他7.3%
Hugo5.6%
Vuepress3.6%

我认为这项新的比赛将在接下来的几个月里带来一些令人兴奋的惊喜，而领先的三位是Next.js，Gatsby，和Nuxt.js将需要发展得更快 ！

6.3 您最喜欢使用以下哪种SSG？

SSG类型得票率
没用到任何框架或库37.7%
Next.js36.9%
Gatsby8.4%
其他6%
Nuxt.js5.8%
Hugo2.4%
Vuepress1.2%

最重要的功能将是增量生成，这将很快成为每个框架的必备功能。这使得小的更改更快、更容易–无需重新生成整个网站，只需更新需要更新的部分。此外，我预计本地化和个性化策略将大幅提升，这将成为框架的内部部分。

七、 宿主

7.1 部署相关，大规模迁移到云端是否意味着传统托管的终结？

"我注意到的第一件事是，越来越多的人正在从他们自己的服务器上的传统主机转移，结果与2020年相比下降了8个百分点。

就我个人而言，我认为这是注定要发生的，我不认为"我们正在从传统的托管"是一件坏事。开发人员正在寻求优化他们的时间和生产力，如果他们能够找到一种方法来完成初始设置所需的大部分工作，他们将采用这些服务。这就是我在这里看到的情况，我认为从长远来看，更多的人会离开它，但它会停止存在吗？不，我不这么认为，一些系统仍然需要非常定制的托管，他们可能无法从提供商那里获得，所以他们选择自己制作。随着云托管的发展，迁移将继续发生。"-- Gift Egwuenu(Cloudflare开发者)

7.2 您最常将应用程序部署到哪里？

云端选择得票率
Amazon Web Services45%
个人机器36.2%
Vercel25.4%
Netlify25.2%
Google 云平台13.6%
Azure13.1%
其他7%
Cloudflare Pages3.6%

另一种选择是将前端托管转移到云提供商，综合结果为64% ！Amazon Web Services仍然以45%的回复率位居榜首，考虑到AWS是市场上最大的云服务提供商之一，这并不奇怪。

GCP(Google Cloud Platform)和Azure在今年的结果中处于次要地位，均落后于AWS，各获得约13%的选票。亚马逊肯定在做一些不同的事情，我真的很想知道，如果Azure进一步推动Azure静态Web应用，结果会有所不同吗？

对于我来说，看到像Vercel和Netlify这样的服务越来越多地被采用，这也很有趣。多年来，这些公司通过提供前沿的服务，包括为开发者提供免费服务，证明了他们在游戏中处于领先地位。反过来，这为任何愿意学习和使用其服务来主持其项目的人创造了一个较低的进入壁垒。

我还认为Cloudflare Pages应该为自己感到自豪。该解决方案对调查来说相对较新，但近4%的受访者选择CP作为他们的首选托管选项。此外，甚至Cloudflare的工作人员也经常出现在“其他”部分。这只意味着前端开发人员愿意尝试并采用新的服务来部署 serverless 应用。

7.3 CI/CD。前端连接软件开发生命周期的所有阶段

大多数前端人员（80%的受访者回答“是”）将CI添加到他们的工作流程中。我相信这是个好消息，它表明人们将软件开发生命周期的所有阶段都结合到了他们的工作流中。

7.4 您是否使用CI？

  • 使用: 79.7%
  • 不使用: 20.3%

就个别解决方案而言，GitHub Actions在本次调查中占据首位，2022年超过56%，而2020年为35%。这表明，更多的前端用户在日常生活中转向GitHub Actions。也许是因为GitHub在你想到CI的时候，极力主张将动作作为首选。加入微软的影响可能是多年来微软受到更多爱的原因之一。

从我个人的经验来看，这些结果似乎确实是真的。我过去使用Circle CI和Travis CI，但现在当我需要设置CI时，我默认使用GitHub操作。

7.5 在过去一年中，您使用了哪些CI解决方案？

方案选择得票率
Github Actions56.5%
Jenkins31.6%
Gitlab CI30.7%
Circle CI17%
Azure DevOps/Pipelines16.5%
Bitbucket Pipelines13.4%
Travis CI8.3%
其他7.9%

我们还可以在“其他”选项中看到更多的解决方案（不包括在调查的集合答案中）。我说的是Teamcity、Click Deploy、Envoyer等服务是CI的首选选项。对我来说，这意味着有一些小众提供商，你可能没有听说过，但他们仍然必须是稳定和可靠的，因为开发者确实选择他们作为CI的首选。

八、 微前端

8.1 微前端正在走向成熟

"如今，微前端受到了各种公司的欢迎。除其他外，Netflix、PayPal和美国运通已在其一些系统中实施了这种架构方法。我相信这是微前端成熟的正确途径。采用这种架构的大公司只会为社区提供更快的反馈循环，突出最佳实践和反模式。 "

"此外，业界对微前端的讨论也越来越多。我所见过的几乎每一次前端会议都至少有一位发言者、一个小组或一个案例研究报告。"-- Luca Mezzalira(AWS首席解决方案架构师)

8.2 您是否在过去一年中使用过微前端相关的技术?

  • 是: 24.6%
  • 否: 75.4%

该社区开始拥有更成熟的工具，如用于客户端渲染应用程序的Single-SPA或模块联邦(Module Federation)，但我们仍在寻找服务端渲染的“方法”。

8.3 您经常采用的微前端方案有哪些？

方案选择得票率
Single-SPA35.9%
Web Components24.3%
模块联邦22.5%
其他12.4%
Bit3.2%
Systemjs1.8%

这里仍有很长的路要走。例如，如何使用"蜡烛版本"(canary release)或蓝绿部署在生产中部署微前端？或者，在使用Preact或React 18等服务端渲染框架时，如何利用部分混合？

尽管如此，与两年前相比，微前端确实取得了进步，上述结果清楚地证明了这一点。我认为在未来几年，更多的组织将采用这种方法，新的工具和模式将与前端社区共享并由其创建。我很高兴看到微前端的未来。

九、 浏览器技术

9.1 42%的WebSocket是怎么回事？我本以为会低于5%

"从历史上看，我（和我周围的其他人）只需要这些API来获得更高级、更像本地应用程序的体验。因此，结果相当令人惊讶，尤其是42%的使用过WebSocket的受访者，而我估计只有不到5%的人会真正有需求。我想知道选择WebAssembly背后的主要动机是什么：性能、使用JavaScript以外的其他语言的可能性、缺乏更好的选择？"-- Jay Phelps(Netflix Web平台,WebAssembly社区小组成员和RxJS核心团队成员)

9.2 在过去的一年里，您使用了以下哪些浏览器技术？

Technology得票率
Websockets API42.1%
Clipboard API35.6%
Geolocation API31.1%
没用任何24.8%
File System Access API21.5%
Fullscreen API14.5%
WebGL14%
WebRTC API11.4%
WebAssembly10.4%
其他1.7%
WebHID API0.4%

我有一些理论。最简单的解释是，仍然存在某种抽样错误，或者我和受访者对问题的解释不一定是内联的。开发人员是否在生产网站上以商业层面使用了给定的技术，或者他们只是在“无法工作”的情况下对其进行了私人编码实验。这将有助于弥补我的期望和结果之间的差异。

然而，我认为真正的原因是多方面的，包括浏览器技术实际上比以往任何时候都更频繁地使用。即使在不一定需要实时性的情况下也可以使用WebSocket，像Firebase这样的平台一如既往地流行。各种技术的相对使用顺序似乎也是合理的。

File System Access API 仍然很新（例如Firefox尚不支持），因此我想知道有多少使用它的网站仍在倒退到旧版本。

我个人很欣赏WebAssembly。它还很年轻，需要一些改进（尤其是浏览器中的客户端），但WebAssembly是第一个真正标准化的字节码。这对于许多用例来说都是一个吸引人的特性，不仅在浏览器中，而且在服务器端或离线应用程序中。由于WebAssembly是一个编译目标，即虚拟化机器代码，因此它不打算以与x64或ARM相同的方式手动编写。这意味着大多数开发人员都是从其他高级语言编译到WebAssembly的。

我很想知道这种语言的流行程度。我希望前三个是C/C++、Rust和AssemblyScript，Golang在WebAssembly社区中的流行程度也很高，因此值得一提。

从长远来看，工具应该使WebAssembly成为大多数开发人员实际上不需要关心的实现细节。就像iOS开发人员通常不关心编译到ARM一样。但标准化和社区发展是一个缓慢的过程，所以我认为我们离这一现实还有十多年的距离。

十、 代码管理

10.1 浏览器编辑器正在兴起。这只是远程工作的结果吗？

10.2 桌面代码编辑器

"Visual Studio Code一直是桌面代码编辑器的领导者。在前端开发方面，该团队一直在做很多改进，以加快开发速度并跨平台工作。在GitHub上使用VS代码的能力也扰乱了在线编辑器之战，如果你不知道，可以在GitHub中按“.”，它会为你在线启动VS代码。没有人想到它也会进入这个市场，在发布codespaces之后。"--Santosh Yadav(谷歌开发者专家，Auth0大使。)

10.3 你最喜欢的桌面代码编辑器是什么？

IDE得票率
VS Code74.4%
JetBrains IDE (WebStorm)18.8%
Vim3.3%
Sublime1.4%
其他1.1%
Atom1%
Brackets0.1%

当涉及到桌面编辑器时，要想从VS代码中夺走桂冠，需要付出一些认真的努力。开发人员一直在为VS代码创建一些令人惊叹的扩展，与其他代码编辑器（如WebStorm）相比，这些扩展具有明显的优势。

10.4 在线代码编辑器

对于在线代码编辑器，我对StackBlitz所做的事情感到非常惊讶。特别是引入Web容器，这样就可以在浏览器中运行NodeJs，这真是太棒了！CodeSandbox多年来一直是领导者之一，但我可以看到Stackblitz的激烈竞争。你可以在Web容器之后使用Stackblitz做很多事情，尤其是在线运行npm脚本。我喜欢CodeSandbox上提供的部署选项–您只需点击按钮即可在Netlify或Vercel上部署，这很酷。

10.5 你最喜欢的在线代码编辑器是什么？

online IDE得票率
没有任何喜欢的41.5%
CodeSandbox34.8%
StackBlitz15.1%
Replit4.3%
其他4.3%

我认为在线代码编辑器的使用只会从这里增加。现在，许多公司正在走向完全远程化，在线编辑是降低成本的一个很好的选择。你不需要投资高端笔记本电脑——CodeSandbox或StackBlitz可以帮你。每个开发人员都知道设置本地开发环境是多么的痛苦，在线代码编辑器可以在几分钟内完成。

10.6 版本控制提供程序

对于版本控制，GitHub是许多开发人员的明确选择，难怪GitHub多年来推出的各种功能令人惊讶：GitHub Action、CodeSpaces、VS Code Online、新的GitHub代码搜索、人工智能副驾驶……我可以继续讲述所有这些功能如何使开发人员的日常生活更轻松。GitHub操作消除了开源开发者对外部提供者的依赖，他们获得了免费的开源构建。

10.7 你最喜欢的版本控制提供商是什么？

vcs得票率
GitHub75.8%
Gitlab14.6%
BitBucket6.3%
没有2.1%
其他1%
Perforce0.2%

Gitlab和Bitbucket提供了许多企业迫切需要的自托管选项的优势。但尽管如此，GitHub是开源开发者的家园，它只会增长，The State of Octoverse[1]就是一个明确的指标。

十一、 测试

11.1 测试状态中的惊喜：前端开发人员从未进行过更多的测试！

"我从事软件测试工作已经近十年了，测试前端应用程序一直是质量保证人员最常用的活动之一。但是开发者呢？这份报告给我讲了一个令人惊讶的故事。"--Dawid Dylowicz公司（Onfido QA负责人）

11.2 谁负责您的软件开发团队中的测试？

测试人员得票率
开发者和QA43.4%
只有开发者自己24.5%
大多时候依靠开发者20.3%
大多时候依靠QA同学9.5%
只有QA2.3%

对我来说，最令人震惊的结果是测试责任从测试人员转移到开发人员。事实证明，在88%的情况下，开发人员至少和QAs一样参与测试。

11.3 在过去的一年里，你自己进行过软件测试吗？

  • 是: 80.5%
  • 否: 19.5%

11.4 你会写哪些类型的测试?

类型占比
UT(单元测试)91.1%
集成测试61.5%
e2e(End-to-end UI tests)55.9%
其他2.1%

作为测试工程负责人，我的核心职责之一是鼓励我们的质量保证人员成为教练，帮助开发人员参与测试。因此，我很高兴看到我自己的经验反映在调查中，显示其他团队在这方面也取得了巨大进展。

11.5 在过去一年中，您是否使用了以下测试工具？

测试工具占比
Jest80.1%
Testing Library49%
Cypress47.9%
Mocha21.4%
其他11.1%
Super Test5.4%

作为《软件测试周刊》的策展人，我注意到很多测试人员和开发人员选择JavaScript进行测试。如今，更多的人写像Cypress和Playwright这样的工具，而不是Selenium。因此，我并不惊讶地看到，近一半的受访者已经试用过Cypress。除了Jest，它是最流行的测试工具。这表明人们对更健壮的测试越来越感兴趣，并青睐具有良好DX（开发人员体验）和使用与开发相同语言的工具。

十二、 实践

12.1 您多久处理一次应用程序?

类型从不很少偶尔频率较高经常
SEO优化28%23%22.5%16.1%10.4%
可访问性9.2%20.1%26.5%27.1%17.1%
响应式1.5%4.7%13.2%30.2%50.3%
性能1.2%4.7%20.7%37.9%35.7%
用户体验0.7%1.9%9.4%32.4%55.7%
开发体验2.5%5.8%18.4%37.2%36.1%

12.2 良好的实践并非一刀切——它们取决于您的团队

"对于项目管理，69%的受访者使用Scrum或Kanban。52%的Scrum比33%的Kanban更常见，17%的受访者同时使用两者。三分之二的前端开发人员在完成项目时使用这两种方法之一。"

"受访者没有报告使用这两种方法的公司大多是技术占据主导地位的公司，这与我在文章《大技术如何运作技术项目》中的发现以及令人好奇的Scrum的缺失不谋而合。"

"单元测试在前端工程师中很普遍，近75%的受访者编写了此类测试。整合测试和端到端测试也很常见，大约一半的受访者编写了这些测试。"--Gergely Orosz(The Pragmatic Engineer创始人)

12.3 您在前端项目中使用了哪些方法/良好做法？

方法占比
Code Review79.8%
CI & CD73.9%
Versioning62.9%
Scrum52.9%
Git Flow41.8%
kanban33.8%
Containerization32.6%
其他1.4%

Code Review在行业内很常见，80%的受访者表示他们遵循这种做法。有趣的是，Code Review在哪里不太可能成为一种实践？对于那些不进行Code Review的人来说，前端工程团队的规模与工程师是否进行Code Review之间有着密切的联系：

  • 在大公司工作的工程师不进行Code Review的可能性最小。
  • 在员工人数不超过50人的公司工作的工程师不进行Code Review的可能性是在大公司工作的工程师的两倍或更多。
  • 可以理解的是，一人公司更有可能进行Code Review。

以上大部分内容都不足为奇：工程师越多，Code Review不仅在发现问题方面，而且在更好地传播知识方面带来的价值就越大。

CI/CD在行业内广泛存在。令人好奇的是，大约有四分之一的工程师不使用CI/CD。

"没有编写单元测试、没有CI/CD和没有进行Code Review是相互关联的。"

这是本次调查中更有趣的发现之一。不做两个编写单元测试、CI/CD和Code Review的工程师可能不会同时做这三个。

这一发现并不令人惊讶，因为这三种工具是相互关联的。当没有自动测试运行时，CI/CD就没有什么意义了。大多数Code Review工具无缝集成到CI/CD工具中。

尽管如此，这一发现表明，通过引入单元测试和设置CI/CD，Code Review可能会随之而来。或者，也许是另一种方式：希望进行Code Review的工程师倾向于编写测试，并将建立CI/CD。

以下是本次调查调查问卷参与者提出的工程实践。如果您还没有尝试其他方法，不妨参考以下建议：

  • 基于主干分支开发
  • Feature标志和Feature切换
  • 结对编程(敏捷开发)
  • Lint
  • 代码规范
  • 代码文档注释
  • Stakeholder Map
  • 设计冲刺(Design sprints)
  • 原型设计
  • 语义化发布
  • “把任务快速完成”
  • 视觉回归测试
  • 高效编程

12.4 搜索引擎优化仍然做的不好-还要多久才能重视并解决这个问题？

只有10.4%的前端开发者总是关注搜索引擎优化，16%的开发者经常这样做。然而，俗话说，细节决定成败。这可能是因为许多受访者创建了相对封闭的应用（仪表板、管理或用户面板、某种管理系统），其中搜索引擎优化不是最关键的部分。

12.5 你多久做一次应用程序的搜索引擎优化(SEO)?

频率占比
从不28%
极少23%
偶尔22.5%
经常16.1%
持续在做10.4%

这就是我们最初的想法！然而，当我们看到剩下的选项并注意到以下几点时，我们松了一口气：

  • 80.5%的受访者总是或经常关注应用程序的响应性。
  • 73.5%的应用程序（始终或经常）牢记其性能。
  • 高达88.1%的人总是或经常关注用户体验。

这让我们非常高兴，因为所有这些元素（响应性、性能和用户体验）对搜索引擎优化也很重要。

随着谷歌（和其他搜索引擎）在让互联网成为一个伟大的地方方面施加了很大的压力，用户处于其中心位置。因此，到2022年，搜索引擎优化的发展将远远超过一堆HTML标签和内容。重要的是，它不仅适用于网站，也适用于PWA和移动应用程序！

12.6 对于前端的搜索引擎优化，什么是重要的？

对于初学者来说，就是响应式。对于大多数在不同设备上工作的项目来说，这是必须的。最近，一些平台（推特）开始暗示AMP（另一种搜索引擎优化友好的网络应用移动版本）的退役。这使得RWD更加重要。

说到性能，这显然包括很多方面。从搜索引擎优化的角度来看，这一切都是关于页面速度的，不仅是速度，而且是页面体验。2020年11月，谷歌增加了三个新的页面体验信号，构成了他们所说的Core Web Vitals[2]。这些在2021 6月左右成为谷歌排名算法：最大内容绘制（LCP）、第一输入延迟（FID）和累积布局偏移（CLS）。以上三项是每一个前端最应该重视的指标。

接下来是用户体验，这是一个非常广泛的主题。然而，有一件事是肯定的：许多SEO已经使用SXO这个词来表示典型的搜索引擎优化必须包括用户体验。

那么，搜索体验优化就是将谷歌（和其他搜索引擎）的技术优化与为用户打造最佳网站相结合。在我们的应用程序生态系统中，有什么能更好地以用户期望、行为和成功的方式为用户服务？

但这也有另一个非常显著的优点。满意的用户=保留（或返回）用户。

好的用户体验会影响转化率，有助于留住用户，或者让他们想要获得更多体验。所有这些通常意味着更好的盈利，这是大多数商业应用程序的重心。

12.7 可访问性

"首先，我将从一个非常重要的概念开始，即在收集产品需求的早期阶段就应该考虑可访问性，即您是否以WCAG 2.1 AA标准为目标，以及您的客户是否期望这种实现。回到结果！"--迪利普·马韦(技术Leader、教育家和技术文章写作者)

12.8 您多长时间关注应用程序的可访问性

频率占比
从不9.2%
极少20.1%
偶尔26.5%
经常27.1%
持续在做17.1%

令我震惊的是， “总是”的答案竟然低至17% ！这让我认为，前端开发人员仍然是被动的，而不是积极主动地实现可访问性。我在过去几年中看到的是，工程师们现在正在积极地运行自动化可访问性工具，作为其CI/CD的一部分，这无疑有助于提高工程师和软件团队其他关键成员的技能。

令我惊讶的是，可访问性没有用户响应性、性能或用户体验那么重要。我有一种感觉，由于公司产品的可访问性差，现在可能会对公司产生法律影响，我预计这一情况在未来会改变。

与2020年开始关注可访问性的问题相比，考虑到这些类别在某种程度上是“是”或“否”，我觉得大多数前端程序员都觉得他们关心可访问性，尽管在大多数情况下，这只是一个特别的审查或审计。

我希望在接下来的几年里，我们能看到像安全性一样的可访问性，我们将在设计软件产品时考虑到可访问性。与过去几年中安全至关重要的情况类似。

12.9 用户体验、响应式和性能

"用户体验往往是出现问题后的最后考虑。因为功能是第一位的，所以适应这些功能的用户界面是第二位的。因此，用户体验是一项昂贵而及时的工作，只有在大型专业公司才能做到。"

"虽然大多数受访者仍然倾向于使用自己的设计系统和样式，如SCSS，但用户体验需求仍然往往落在程序员身上，他们只需要获得一个功能来实现，而没有任何故事板或用户流示例。"--阿德里安·特瓦罗格(“Development & Design”创作者)

12.10 您多久关注应用程序响应式

频率占比
从不1.5%
极少4.7%
偶尔13.2%
经常30.2%
持续在做50.3%

12.11 您多久关注应用程序的性能

频率占比
从不1.2%
极少4.7%
偶尔20.7%
经常37.9%
持续在做35.7%

12.11 您关注用户体验的频率如何?

频率占比
从不0.7%
极少1.9%
偶尔9.4%
经常32.4%
持续在做55.7%

测试在编码中是如此重要的一项任务，以至于没有人能够再想象不经过适当测试就可以发布某些内容。这同样适用于用户体验测试，在我的选择中，它应该是写入CI/CD工作流的另一个元素。

有时，由于CTR失败，用户无法完成任务。但是，由于没有涉及用户体验测试，任务本身经常充满了未被发现的错误。

代码评审和设计评审也是如此。设计审查应始终考虑用户对迭代的体验，以提高编译速度和代码任务的性能，以及用户任务（例如用户通过UI完成操作的时间） 。

我得出的结论是，现如今前端开发普遍给予了测试和审查更多的考虑，尤其是在代码方面，这些同样的考虑应该应用于用户界面和用户体验，因为它们对任何系统的成功都至关重要。

12.12 开发人员体验。到底是用户的体验最重要还是开发者的体验最重要？

"事实上，我对其中的一些结果感到惊喜。有时，开发者的主要关注点似乎是他们自己的开发体验，甚至以牺牲用户体验为代价。这些结果证明并非如此。开发者体验是用户体验的前提，这就是它应该被优先考虑的方式。如果我们不为用户体验构建软件，那么我们到底在做什么？ "--肯特·C·多德(Remix联合创始人)

12.13 你大概多久关注应用程序开发人员的体验？

频率占比
从不2.5%
极少5.8%
偶尔18.4%
经常37.2%
持续在做36.1%

不幸的是，我对可访问性的结果并不感到惊讶。至少我们对自己诚实。承认我们的缺点是改善缺点的第一步！希望这些结果能给我们敲响警钟，提醒我们自己，对于大量用户（包括使用辅助技术的用户和未使用辅助技术的用户）来说，可访问性是用户体验的重要前提。事实上，对于一些用户来说，他们对你开发的应用程序有任何“体验”的唯一方式就是考虑可访问性，因此我们最好采取相应的行动。

十三、 前端的未来

"前端可能正在进入稳定阶段"--马雷克·加伊达(Software House CTO)

13.1 在你看来，这些趋势/解决方案中，哪一种会越来越受欢迎，哪一种会在两年后逐渐消失？

类型更加流行没有变化消亡没有观点
可访问性(A11y)63.1%30.5%0.4%6%
原子设计23.9%37.1%8.6%30.5%
组件驱动开发58.4%27.9%1.5%12.1%
跨平台应用60.6%24.8%3.3%11.3%
GraphQL42.4%34.7%9.1%13.8%
无头CMS39.4%30.8%4.8%25.1%
JAMStack26.5%29.8%10.8%32.9%
微前端37.2%23.5%13.3%26.1%
在线页面生成器29.8%35.8%11.8%22.6%
渐进式 Web 应用程序 (PWA)42.6%34.4%11.8%11.2%
服务端渲染60.5%27%4.8%7.6%
Web Components45.2%27.1%11%16.7%
WebAssembly(WASM)45.5%25.4%5.6%23.6%

我注意到数字背后的第一件事是我最喜欢的sin(x)/x函数以及它与一般编程的关系。软件开发仍处于早期阶段，是一个行业中的幼儿。有一些布道者宣称，所有的东西都已经在主题X中说过了，因此目前的方法应该被视为标准。一分钟后，激烈的讨论开始了，人们对这个话题有180°的看法，所以技术转向了Y。然后看，第一种方法又卷土重来，稍作调整，防止它过于极端，更接近 "中心"。之后，Y的粉丝们调整他们的解决方案，使之更接近 "中心意见"。最终，两个极端成为一个 "妥协"，变成了某种标准。这被称为函数的退火（是的，我以前想当数学老师）。看看下面的图表就知道了。

sin（x）/x函数图

sin（x）/x函数图

看起来，前端开发正在进入一个更加 "稳定 "的阶段。一些问题，如可访问性或服务端渲染，已经不再需要讨论了。然而，几年前，前端还处于这条道路的起点，方法反映了完全不同的愿景、想法和方法。IT界的每个人都知道 "每天都有新的前端框架 "的笑话。但现在这种情况少了，我们正处于罪孽功能放缓和扁平化的阶段，稳定的过程开始了。

让我们来分析一下我从调查问卷的回复中可以挑出的一些趋势稳定的例子。

早在2020年，20%的受访者预测了微前端的死亡，而现在看来，它们并没有消失。 微前端仍然有边界的意见，我想知道未来的妥协会是什么样子。Luca Mezzalira在他的 "Micro-frontend "一书中提出了12种不同的微前端概念，这意味着解决方案本身仍在内部结晶。我怀疑投票支持微前端的人与投票反对的人所支持的概念是不同的。

服务端渲染已经严重扁平化了（60% VS 5%），但我很惊讶这就是稳定轴的落脚点。历史课：页面最初是在后端渲染的。然后人们说："这有点傻，在互联网上转来转去，慢得令人难以置信，应该由前端的浏览器来做"。然后反对派说。"好吧，但它还是有点慢，也许我们应该回到后端去？" 对方的回应是："嘿，在服务器上做一点，在客户端做一点，怎么样？" 所以我们基本上又回到了原点，这正是20年前的工作方式。但是这一次，我们在多年的新经验、实验和内部改变后，能够修改这个方法。

我的猜测是，领域驱动的设计是下一个目标。9年前的想法是将业务逻辑与技术问题（路由、数据库、性能、优化等）分开。有描述应用程序的代码，也有工程和技术的代码。每个人都为这个想法而疯狂，但几乎没有人能够做到这一点。概念是正确的，只是时机不对--矛盾的是，我们没有足够成熟的技术来执行这项任务。 目前，这种技术正在发生转变，如果有人大声支持DDD，他们可能是对的。我们终于有了将理论转化为实践的工具，并将业务逻辑与技术部分真正分开。上面列表中的一些解决方案，如无头CMS，正是这样做的。

13.2 开发者的权力和责任

早在史前时代，曾经有一个巨大的、统一的应用程序。当新的人进入项目时，他们被告知做什么和怎么做，没有讨论和选择。

现在，如果你想在你的前端团队中建立责任感和所有权，确保开发人员对技术和工程问题有很多发言权。这不是关于应用程序的功能，而是关于它将如何被构建。公司终于开始在事情的决策上给予开发者更多的自主权，而不是在他们头上做重要的决定。不仅仅是因为前端程序员赚了很多钱。人们对自己的工作越有发言权，就越有主人翁意识。

在问题中包括的趋势中，我们已经有了组件驱动开发，GraphQL，微前端和网络组件--所有的应用程序都以这样的方式划分，软件团队中的每个人都可以在自己的部分工作，而这些部分以后将被纳入一个更大的整体。但每个开发人员都对自己的领域负责，并决定如何完成。 这100%符合更广泛的开发者自主权的概念，有无数的问题解决选项。

13.3 一个应用程序可以管理所有应用程序。移动端的下一步是什么？

有人能够想象一个没有移动应用的企业，即使他们根本不需要它们。甚至我曾经和一个 "移动应用生成器 "的客户合作，他们提供简单的移动应用，包括商店的名称、联系人、促销活动、用户粘性积分、营业时间和地址。做一个原生应用程序的唯一好处是，你可以点击地址，谷歌地图就会打开，并提供路线。这的确是突破性的。

然后，每个人都注意到，创建和维护移动APP实际上花费了一大笔钱。很多公司放弃了他们专门的移动团队，因为人们发现，你所需要做的只是打开一个网站，为智能手机扩展。而不是从头开始建立一个完整的应用程序! 然后，根据趋势稳定阶段，我们经历了："嗯，混合型怎么样？" - "不，回到原生"--"那么，你毕竟是为了一个新的、混合化的混合体回来的？"......

我真的很感兴趣，PWA的趋势是否会在这里稳定下来，或者我们是否会有另一个钟摆式的摆动。我有一种感觉，"一个应用程序政策 "将与我们保持更长的时间，但我不太确定PWA是否是我们能想出的解决这个问题的最佳方案。

只是提醒一下，谷歌提出了可信网络活动（TWA），他们试图将其作为一个标准。这仍然是一个新鲜的话题，但我感觉它很快就会枯萎，我没有看到前端开发者、经理或公司对它有任何兴趣。苹果不太可能提出他们自己的 "标准"，因为他们有一个原始的iOS，而且他们不得不承认原生应用已经成为过去。

13.4 未来可能出现的性能问题

我把最令人惊讶的留到最后，你看到WebAssembly的结果了吗？在我看来，WebAssembly确实是少数公司用来做优化的解决方案之一，像Facebook或Gmail这样的巨头。事实证明我完全错了。46%的受访者预测WebAssembly会越来越受欢迎，老实说，我很震惊！我不知道该怎么办。 也许我生活在这样一个世界里，当你使用了前端功能而碰壁时，WA是最后的选择，因为它很难写，而且很难维护。当所有的方法都用过了，但解决方案还是太慢，那时候你才会去用WebAssembly。

我们都知道，应用程序的性能需要不断提高，压力越来越大。现在的Web应用是否已经复杂到由于性能问题导致其他什么都做不了吗？这种对WebAssembly兴趣的增加是否应该是普遍性能问题的第一个预兆吗？我会在2022年持续关注这个话题。

参考资料

[1] The State of Octoverse: octoverse.github.com/

[2] Core Web Vitals: web.dev/vitals/

标签: 2022年国内外前端发展态势
上一篇： 【微信小程序】【分包】实现分包，脱离2048kb/2M的限制 下一篇： 怎么微信浏览器里 打开APP

本文地址： https://niwoxuexi.com/blog/wechat/article/2039

版权声明：本篇文章，如非注明，皆为博主 wechat 原创。转载需注明本文链接并保证链接可用。