本文翻译者系奇舞团前端工程师
原文标题：State of Frontend 2022
原文作者：Aleksandra Dbrowska
原文地址：tsh.io/state-of-fr…
前端是否厌恶了新趋势，并寻求安稳？
一、简介
曩昔两年挺不简略的，在全球范围内引发了许多改动。自从咱们的日子逐步”搬到了线上”，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年成果的故事是结构的鼓起。开发人员好像越来越期望元结构能够更快、更有信心肠作业。查询显现，受访者越来越或许注重以下最佳实践（例如功用和最终用户体会），这彻底解说了这种向元结构开展的趋势。”– Sbastien 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 Wysoczaski(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.js | 43.6% |
| 没用到任何结构或库 | 35% |
| Gatsby | 22.7% |
| Nuxt.js | 9.8% |
| 其他 | 7.3% |
| Hugo | 5.6% |
| Vuepress | 3.6% |
我以为这项新的竞赛将在接下来的几个月里带来一些令人兴奋的惊喜，而领先的三位是Next.js，Gatsby，和Nuxt.js将需求开展得更快 ！
6.3 您最喜爱运用以下哪种SSG？
| SSG类型 | 得票率 |
|---|---|
| 没用到任何结构或库 | 37.7% |
| Next.js | 36.9% |
| Gatsby | 8.4% |
| 其他 | 6% |
| Nuxt.js | 5.8% |
| Hugo | 2.4% |
| Vuepress | 1.2% |
最重要的功用将是增量生成，这将很快成为每个结构的必备功用。这使得小的更改更快、更简略–无需重新生成整个网站，只需更新需求更新的部分。此外，我估量本地化和个性化策略将大幅提升，这将成为结构的内部部分。
七、 宿主
7.1 布置相关，大规划迁移到云端是否意味着传统保管的终结？
“我注意到的榜首件事是，越来越多的人正在从他们自己的服务器上的传统主机搬运，成果与2020年比较下降了8个百分点。
就我个人而言，我以为这是注定要发生的，我不以为”咱们正在从传统的保管”是一件坏事。开发人员正在寻求优化他们的时刻和生产力，假如他们能够找到一种办法来完结初始设置所需的大部分作业，他们将选用这些服务。这便是我在这儿看到的状况，我以为从长远来看，更多的人会离开它，但它会停止存在吗？不，我不这么以为，一些体系依然需求十分定制的保管，他们或许无法从供给商那里取得，所以他们挑选自己制作。跟着云保管的开展，迁移将继续发生。”– Gift Egwuenu(Cloudflare开发者)
7.2 您最常将运用程序布置到哪里？
| 云端挑选 | 得票率 |
|---|---|
| Amazon Web Services | 45% |
| 个人机器 | 36.2% |
| Vercel | 25.4% |
| Netlify | 25.2% |
| Google 云渠道 | 13.6% |
| Azure | 13.1% |
| 其他 | 7% |
| Cloudflare Pages | 3.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 Actions | 56.5% |
| Jenkins | 31.6% |
| Gitlab CI | 30.7% |
| Circle CI | 17% |
| Azure DevOps/Pipelines | 16.5% |
| Bitbucket Pipelines | 13.4% |
| Travis CI | 8.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-SPA | 35.9% |
| Web Components | 24.3% |
| 模块联邦 | 22.5% |
| 其他 | 12.4% |
| Bit | 3.2% |
| Systemjs | 1.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 API | 42.1% |
| Clipboard API | 35.6% |
| Geolocation API | 31.1% |
| 没用任何 | 24.8% |
| File System Access API | 21.5% |
| Fullscreen API | 14.5% |
| WebGL | 14% |
| WebRTC API | 11.4% |
| WebAssembly | 10.4% |
| 其他 | 1.7% |
| WebHID API | 0.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 Code | 74.4% |
| JetBrains IDE (WebStorm) | 18.8% |
| Vim | 3.3% |
| Sublime | 1.4% |
| 其他 | 1.1% |
| Atom | 1% |
| Brackets | 0.1% |
当触及到桌面修改器时，要想从VS代码中夺走桂冠，需求支付一些认真的努力。开发人员一直在为VS代码创立一些令人惊叹的扩展，与其他代码修改器（如WebStorm）比较，这些扩展具有显着的优势。
10.4 在线代码修改器
关于在线代码修改器，我对StackBlitz所做的作业感到十分惊奇。特别是引进Web容器，这样就能够在浏览器中运转NodeJs，这真是太棒了！CodeSandbox多年来一直是领导者之一，但我能够看到Stackblitz的激烈竞争。你能够在Web容器之后运用Stackblitz做许多作业，尤其是在线运转npm脚本。我喜爱CodeSandbox上供给的布置选项–您只需点击按钮即可在Netlify或Vercel上布置，这很酷。
10.5 你最喜爱的在线代码修改器是什么？
| online IDE | 得票率 |
|---|---|
| 没有任何喜爱的 | 41.5% |
| CodeSandbox | 34.8% |
| StackBlitz | 15.1% |
| Replit | 4.3% |
| 其他 | 4.3% |
我以为在线代码修改器的运用只会从这儿添加。现在，许多公司正在走向彻底长途化，在线修改是降低成本的一个很好的挑选。你不需求出资高端笔记本电脑——CodeSandbox或StackBlitz能够帮你。每个开发人员都知道设置本地开发环境是多么的苦楚，在线代码修改器能够在几分钟内完结。
10.6 版本操控供给程序
关于版本操控，GitHub是许多开发人员的明确挑选，难怪GitHub多年来推出的各种功用令人惊奇：GitHub Action、CodeSpaces、VS Code Online、新的GitHub代码搜索、人工智能副驾驶……我能够继续讲述全部这些功用怎么使开发人员的日常日子更轻松。GitHub操作消除了开源开发者对外部供给者的依托，他们取得了免费的开源构建。
10.7 你最喜爱的版本操控供给商是什么？
| vcs | 得票率 |
|---|---|
| GitHub | 75.8% |
| Gitlab | 14.6% |
| BitBucket | 6.3% |
| 没有 | 2.1% |
| 其他 | 1% |
| Perforce | 0.2% |
Gitlab和Bitbucket供给了许多企业迫切需求的自保管选项的优势。但虽然如此，GitHub是开源开发者的家乡，它只会添加，The State of Octoverse[1]便是一个明确的方针。
十一、 测验
11.1 测验状况中的惊喜：前端开发人员从未进行过更多的测验！
“我从事软件测验作业现已近十年了，测验前端运用程序一直是质量保证人员最常用的活动之一。可是开发者呢？这份陈述给我讲了一个令人惊奇的故事。”–Dawid Dylowicz公司（Onfido QA担任人）
11.2 谁担任您的软件开发团队中的测验？
| 测验人员 | 得票率 |
|---|---|
| 开发者和QA | 43.4% |
| 只要开发者自己 | 24.5% |
| 大多时分依托开发者 | 20.3% |
| 大多时分依托QA同学 | 9.5% |
| 只要QA | 2.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 在曩昔一年中，您是否运用了以下测验东西？
| 测验东西 | 占比 |
|---|---|
| Jest | 80.1% |
| Testing Library | 49% |
| Cypress | 47.9% |
| Mocha | 21.4% |
| 其他 | 11.1% |
| Super Test | 5.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 Review | 79.8% |
| CI & CD | 73.9% |
| Versioning | 62.9% |
| Scrum | 52.9% |
| Git Flow | 41.8% |
| kanban | 33.8% |
| Containerization | 32.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% |
| GraphQL | 42.4% | 34.7% | 9.1% | 13.8% |
| 无头CMS | 39.4% | 30.8% | 4.8% | 25.1% |
| JAMStack | 26.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 Components | 45.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函数图
看起来，前端开发正在进入一个愈加 “安稳 “的阶段。一些问题，如可拜访性或服务端烘托，现已不再需求谈论了。可是，几年前，前端还处于这条路途的起点，办法反映了彻底不同的愿景、主意和办法。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/
