前端是否厌倦了新趋势，并寻求稳定？
过去两年挺不容易的，在全球范围内引发了许多变化。自从我们的生活逐渐"搬到了线上"，IT行业也顺势参与了数字转型。前端开发也在从技术探索再到落地实践等各个方面发生了很多变化。因此，我们尽可能的将前端2020年和2022年的数据并排呈现，以便更好地进行比较。
最著名的前端开发笑话“新的一天，新的框架”似乎已经过时了。当然，新的框架和库确实出现了，但在某些领域，朝着潮流创新的竞赛慢慢让位于成熟和稳定。
共计3703份问卷,其他:84份,其中问卷分布如下:
我们也鼓励您积极参与结果分析！如果我们对前端人员有所了解的话，那就是每个人都有自己的意见，很少把它们留给自己——这很好，因为它推动了整个行业的发展。每个图表和表格都有一个“共享”按钮，以防您想与朋友开始讨论或只共享报告的一个特定数据点。
最后，向所有3703名填写该调查的前端人员表示衷心的感谢——没有你，就没有报告！
"高达56%的受访者表示远程工作，其中只有5%在办公室工作。大规模远程工作的概念如此新颖，以至于2020年的调查甚至没有测量这个数据点。
今年，一些从事前端开发的人在“其他”选项中共享的职位包括：
这应该不足为奇：但它总是很好地提醒我们，前端是一个非常容易上手的技术领域，即使在没有太多前端背景的情况下，这种情况很常见。
这个统计数据显示了一个有趣的二元性。在拥有大量前端团队的公司工作的前端工程师几乎与在少数人团队或单独工作的公司一样多。
这些公司的开发经验和期望相差很大。大公司在前端平台团队的同时，还将更重视开发人员体验。辅导也更常见。在较小的地方，每个开发人员的责任更大，获得反馈的选项更少。
50%的前端工程师在拥有10名或以上前端开发人员的公司工作，27%的工程师在拥有50名或以上前端开发人员的公司工作，这一统计数据也可能是团队为大型前端团队构建工具的有趣提示。这些地方似乎越来越多。
只有18%的填写调查的人说他们在非技术占主导地位的公司工作。82%的人认为自己在软件开发公司、开发机构或者技术占据主导地位的公司工作。很难说这项调查是否涉及到在更传统的公司工作的人，或者是否真的有更多的工程师在软件作为业务核心的地方工作。
无论如何，值得记住的是，调查结果绝大多数来自技术型公司。
组件驱动开发也受到大多数开发人员的欢迎，考虑到React、Vue、Svelte甚至Web组件的流行，这一点很有意义（如今年的独立成功案例——Wordle）。
渐进式Web应用程序(PWA)也越来越流行，开发人员热衷于使用相同的核心代码库充分利用跨平台开发。我们还看到像开放网络倡导组织(OpenWebAdvocacy,简称OWA)这样的组织推动苹果拥抱开放网络。这绝对是一个值得效仿的空间。
无头CMS(headlessCMS)也在进步，采用率更高，并更多地集成到框架中。对于我来说，Nuxt3已经发布了新的Prismic、Strapi、Sanity、Storyblock和Directus模块，可以零配置或者极少需要额外的配置即可使用。
我还注意到另一个趋势，这是没有明确提到这项调查。边缘渲染最初由CloudFlare及其worker平台驱动。调查中的大多数部署目标都发布或实现了自己的serverless或edgefunctions，这并不是偶然的，用户很快就会采用这些功能。Nuxt3、Remix或Sveltekit等框架正朝着这个方向发展，直接在CDN级别实现按需渲染。随着服务器呈现的应用程序在减少延迟和降低成本方面的相应收益，我预测这将成为2023年的一个重点。
"无论您如何看待Redux和Lodash，前端开发人员（自愿或不自愿）肯定会使用它们。在喜欢和不喜欢的解决方案中，他们都名列前三，这让我想知道，为什么人们会使用他们不喜欢的解决方案。我有几个理论。"--AndrzejWysoczański(SoftwareHouse前端负责人)
根据我的经验，Redux被软件公司及其客户广泛使用，因为它适用于需要复杂状态管理的大型项目。然而，Redux的入门门槛相当高。如果开发人员从头开始学习Redux，并且这对他们来说是全新的，那么他们最初可能并不喜欢它。但是，他们必须学习，也要学习，因为近20%的受访者希望在未来掌握Redux，尽管这很难。或者，人们可能意识到，为了在前端开发中获得一份好工作，有Redux经验对他们的简历很有好处。
就Lodash而言，我唯一合乎逻辑的解释是，我们的受访者必须在进入项目时就有这些解决方案，他们使用这些解决方案是出于必要，而不是出于乐趣。
似乎前端用户从Moment走向Date-FNS，这是一个好迹象。我感到震惊的是，超过40%的人仍然在他们的项目中使用Moment，无论他们的情绪如何。这个库已经失去了支持，甚至它的官方网站上也有创作者的留言说，如果你正在考虑使用Moment，你可能应该寻找替代品。幸运的是，只有5%的受访者渴望了解未来的Moment，所以这个库很可能走向衰落。
"设计系统空间非常零散。没有一个单一的设计系统超过市场的24%。这是React的一大不同之处，React占据了大部分前端市场。我认为这可以简单地解释为，因为一家公司对设计系统的选择大多是“艺术”的，没有两个人有完全相同的设计品味。"--OlivierTassinari(MUI首席执行官兼MaterialUI联合创始人)
作为一个侧面观察，结果中可能存在偏差。调查提出“MaterialUI/MUI”作为一个预定义的答案，我很高兴看到我们是领先的选择，然而，对于大多数人来说，MaterialUI是Material设计的同义词。因此，不清楚受访者是否从设计（设计系统）或代码角度（Material设计ReactUI库/框架）选择了这个答案。
”哇哦，看看SCSS，加油！如果一个孩子是在SASS被释放的那天出生的，他们今天就已经到了可以学习开车的年纪了。这对于任何软件工具来说都是难以置信的长寿，尤其是在前端开发工具快速发展的世界中。"
"近一半的受访者表示，他们不仅使用SASS，而且它是我的最爱，这让我难以置信，我碰巧也同意，因为它也是我的最爱。"
哇哦，没想到StyledComponents占据了这么高的比例！这让我印象深刻的是，问题只是关于样式化工具的使用，但是StyledComponents几乎也意味着React的使用。因此，看到这一大占比，尤其是结合了Emotion、Chakra以及VanillaExtract，我想这一切主要是在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这样的阻塞资源来说尤为重要），人们似乎无论如何都喜欢将工具的选择带来一个很好的性能优势。
很高兴看到像VanillaExtract这样的工具试图在样式中提供各种现代开发人员人机工程学，并且非常专注于确保良好的性能是默认行为。这通常意味着“提取(extracting)”“vanilla”CSS，如果你遵循他们的命名双关语。
所有这些都让我想到，如果我们能看到数据，比如说，流量排名前5000的网站的风格选择，结果会是什么。或者在互联网上发布的最后5000个网站上做出的选择。或者GitHub上开发最活跃的5000个网站。这会相似吗？很难说他们是否会完全不同。但我想到了WordPress发布的令人震惊的数据：43%的互联网用户。这并不是说你不能建立一个基于JavaScript框架的WordPress网站，有些人是这样做的，但我相信这些WordPress网站中有一小部分是这样的。那么他们在做什么？他们是Sass的大用户吗？难道你不认为它们中有相当一部分是普通的CSS，仅仅因为WordPress本身不提供任何内置的样式工具吗？或者，这些站点中的大多数并不是真正由开发人员构建的，而只是自助部署？
"很高兴看到前端调查涵盖了这个主题。您可以看到，越来越多的人开始对使用在线代码编辑器进行一些工作感兴趣，这非常令人兴奋。云开发只会继续增长，我希望看到更多的程序员和公司将他们的开发环境从本地转移到Cloud。"--IvesvanHoorne(CodeSandbox联合创始人)
这项调查证实了我们在CodeSandbox上已经注意到的情况。我们看到越来越多的人将他们的开发转移到网上，这也表明人们对云开发的普遍兴趣有所提高。仅在过去一年里，人们就创建了超过1200万个沙盒，占我们创建的沙盒总数的一半！
我对未来感到非常兴奋，因为我相信Cloud将使软件开发更容易访问和协作。我很高兴看到前端开发人员的回答反映了这种兴趣。至于我在这里对未来的期望，转向云开发可能比我们所有人想象的要快得多......
我们都可能同意，TypeScript受到了开发人员的普遍欢迎，业界在未来几年不会放弃这项技术。这是怎么发生的？在网上讨论中，人们经常称赞TypeScript在错误发生之前就阻止了整个类别的错误。这反过来又使开发更快，应用程序更可靠。
我不想在这里争论，但既然你们问我是什么让这么多开发人员喜欢TypeScript，我想说的是，TS让Web开发方式比以前少了很多令人沮丧的地方。在经历了太多年的Web开发之后，前端开发人员不想重复多次在代码编辑器和浏览器之间来回切换的经历，以猜测为什么“undefinedisnotafunction”。毕竟，“雪是白的(陈述一般事实)”类型的错误通常是由诸如变量拼写错误或参数放置错误之类的小错误引起的。
然后TypeScript拯救了我们，由微软推出，并在所有主要IDE中得到支持。现在，在前端编写代码感觉更加受控和简单。就我个人而言，我还喜欢在编写使用数据结构的代码之前设计数据结构，这为整个开发过程增添了额外的乐趣。
TypeScript不仅试图赢得开发者的心，而且还努力成为前端行业标准，不仅仅是针对Angular项目。可以肯定的是，完全不使用TypeScript的新商业项目已经很少了，在未来几年里，找到它们只会更加困难。如果你比较一下关于使用TypeScript和公司类型的问题，很明显，科技行业在他们的软件项目中自信地朝着TypeScript迈进。
以下为本次调查问卷中,各主要公司类型中对于TS的使用情况:
最后但并非最不重要的一点是，在2022年3月，当微软宣布在JavaScript中引入TypeScript的类型语法时，我们可以实时观察到“JavaScript将变成类似TypeScript的东西”的答案变得比以往任何时候都更为现实。这意味着浏览器可以理解TS，但不支持类型检查。然而，目前，前端社区对该提案表示冷遇，我认为它没有机会以当前形式被纳入ECMA标准。这也意味着JS不会很快变形为TS的克隆体，但肯定有什么东西在传播。
"越来越多的大公司不怕用SSG切换到无头CMS。Jamstack解决方案不再是一种新的尖端技术，对他们来说似乎不再是实验性的。"--SamuelSnopko(Storyblock的DevRel负责人)
我认为这项新的比赛将在接下来的几个月里带来一些令人兴奋的惊喜，而领先的三位是Next.js，Gatsby，和Nuxt.js将需要发展得更快！
最重要的功能将是增量生成，这将很快成为每个框架的必备功能。这使得小的更改更快、更容易–无需重新生成整个网站，只需更新需要更新的部分。此外，我预计本地化和个性化策略将大幅提升，这将成为框架的内部部分。
"我注意到的第一件事是，越来越多的人正在从他们自己的服务器上的传统主机转移，结果与2020年相比下降了8个百分点。
另一种选择是将前端托管转移到云提供商，综合结果为64%！AmazonWebServices仍然以45%的回复率位居榜首，考虑到AWS是市场上最大的云服务提供商之一，这并不奇怪。
GCP(GoogleCloudPlatform)和Azure在今年的结果中处于次要地位，均落后于AWS，各获得约13%的选票。亚马逊肯定在做一些不同的事情，我真的很想知道，如果Azure进一步推动Azure静态Web应用，结果会有所不同吗？
对于我来说，看到像Vercel和Netlify这样的服务越来越多地被采用，这也很有趣。多年来，这些公司通过提供前沿的服务，包括为开发者提供免费服务，证明了他们在游戏中处于领先地位。反过来，这为任何愿意学习和使用其服务来主持其项目的人创造了一个较低的进入壁垒。
我还认为CloudflarePages应该为自己感到自豪。该解决方案对调查来说相对较新，但近4%的受访者选择CP作为他们的首选托管选项。此外，甚至Cloudflare的工作人员也经常出现在“其他”部分。这只意味着前端开发人员愿意尝试并采用新的服务来部署serverless应用。
大多数前端人员（80%的受访者回答“是”）将CI添加到他们的工作流程中。我相信这是个好消息，它表明人们将软件开发生命周期的所有阶段都结合到了他们的工作流中。
就个别解决方案而言，GitHubActions在本次调查中占据首位，2022年超过56%，而2020年为35%。这表明，更多的前端用户在日常生活中转向GitHubActions。也许是因为GitHub在你想到CI的时候，极力主张将动作作为首选。加入微软的影响可能是多年来微软受到更多爱的原因之一。
从我个人的经验来看，这些结果似乎确实是真的。我过去使用CircleCI和TravisCI，但现在当我需要设置CI时，我默认使用GitHub操作。
我们还可以在“其他”选项中看到更多的解决方案（不包括在调查的集合答案中）。我说的是Teamcity、ClickDeploy、Envoyer等服务是CI的首选选项。对我来说，这意味着有一些小众提供商，你可能没有听说过，但他们仍然必须是稳定和可靠的，因为开发者确实选择他们作为CI的首选。
"如今，微前端受到了各种公司的欢迎。除其他外，Netflix、PayPal和美国运通已在其一些系统中实施了这种架构方法。我相信这是微前端成熟的正确途径。采用这种架构的大公司只会为社区提供更快的反馈循环，突出最佳实践和反模式。"
"此外，业界对微前端的讨论也越来越多。我所见过的几乎每一次前端会议都至少有一位发言者、一个小组或一个案例研究报告。"--LucaMezzalira(AWS首席解决方案架构师)
该社区开始拥有更成熟的工具，如用于客户端渲染应用程序的Single-SPA或模块联邦(ModuleFederation)，但我们仍在寻找服务端渲染的“方法”。
这里仍有很长的路要走。例如，如何使用"蜡烛版本"(canaryrelease)或蓝绿部署在生产中部署微前端？或者，在使用Preact或React18等服务端渲染框架时，如何利用部分混合？
尽管如此，与两年前相比，微前端确实取得了进步，上述结果清楚地证明了这一点。我认为在未来几年，更多的组织将采用这种方法，新的工具和模式将与前端社区共享并由其创建。我很高兴看到微前端的未来。
"从历史上看，我（和我周围的其他人）只需要这些API来获得更高级、更像本地应用程序的体验。因此，结果相当令人惊讶，尤其是42%的使用过WebSocket的受访者，而我估计只有不到5%的人会真正有需求。我想知道选择WebAssembly背后的主要动机是什么：性能、使用JavaScript以外的其他语言的可能性、缺乏更好的选择？"--JayPhelps(NetflixWeb平台,WebAssembly社区小组成员和RxJS核心团队成员)
我有一些理论。最简单的解释是，仍然存在某种抽样错误，或者我和受访者对问题的解释不一定是内联的。开发人员是否在生产网站上以商业层面使用了给定的技术，或者他们只是在“无法工作”的情况下对其进行了私人编码实验。这将有助于弥补我的期望和结果之间的差异。
然而，我认为真正的原因是多方面的，包括浏览器技术实际上比以往任何时候都更频繁地使用。即使在不一定需要实时性的情况下也可以使用WebSocket，像Firebase这样的平台一如既往地流行。各种技术的相对使用顺序似乎也是合理的。
FileSystemAccessAPI仍然很新（例如Firefox尚不支持），因此我想知道有多少使用它的网站仍在倒退到旧版本。
我个人很欣赏WebAssembly。它还很年轻，需要一些改进（尤其是浏览器中的客户端），但WebAssembly是第一个真正标准化的字节码。这对于许多用例来说都是一个吸引人的特性，不仅在浏览器中，而且在服务器端或离线应用程序中。由于WebAssembly是一个编译目标，即虚拟化机器代码，因此它不打算以与x64或ARM相同的方式手动编写。这意味着大多数开发人员都是从其他高级语言编译到WebAssembly的。
我很想知道这种语言的流行程度。我希望前三个是C/C++、Rust和AssemblyScript，Golang在WebAssembly社区中的流行程度也很高，因此值得一提。
从长远来看，工具应该使WebAssembly成为大多数开发人员实际上不需要关心的实现细节。就像iOS开发人员通常不关心编译到ARM一样。但标准化和社区发展是一个缓慢的过程，所以我认为我们离这一现实还有十多年的距离。
"VisualStudioCode一直是桌面代码编辑器的领导者。在前端开发方面，该团队一直在做很多改进，以加快开发速度并跨平台工作。在GitHub上使用VS代码的能力也扰乱了在线编辑器之战，如果你不知道，可以在GitHub中按“.”，它会为你在线启动VS代码。没有人想到它也会进入这个市场，在发布codespaces之后。"--SantoshYadav(谷歌开发者专家，Auth0大使。)
当涉及到桌面编辑器时，要想从VS代码中夺走桂冠，需要付出一些认真的努力。开发人员一直在为VS代码创建一些令人惊叹的扩展，与其他代码编辑器（如WebStorm）相比，这些扩展具有明显的优势。
对于在线代码编辑器，我对StackBlitz所做的事情感到非常惊讶。特别是引入Web容器，这样就可以在浏览器中运行NodeJs，这真是太棒了！CodeSandbox多年来一直是领导者之一，但我可以看到Stackblitz的激烈竞争。你可以在Web容器之后使用Stackblitz做很多事情，尤其是在线运行npm脚本。我喜欢CodeSandbox上提供的部署选项–您只需点击按钮即可在Netlify或Vercel上部署，这很酷。
我认为在线代码编辑器的使用只会从这里增加。现在，许多公司正在走向完全远程化，在线编辑是降低成本的一个很好的选择。你不需要投资高端笔记本电脑——CodeSandbox或StackBlitz可以帮你。每个开发人员都知道设置本地开发环境是多么的痛苦，在线代码编辑器可以在几分钟内完成。
对于版本控制，GitHub是许多开发人员的明确选择，难怪GitHub多年来推出的各种功能令人惊讶：GitHubAction、CodeSpaces、VSCodeOnline、新的GitHub代码搜索、人工智能副驾驶……我可以继续讲述所有这些功能如何使开发人员的日常生活更轻松。GitHub操作消除了开源开发者对外部提供者的依赖，他们获得了免费的开源构建。
Gitlab和Bitbucket提供了许多企业迫切需要的自托管选项的优势。但尽管如此，GitHub是开源开发者的家园，它只会增长，TheStateofOctoverse[1]就是一个明确的指标。
"我从事软件测试工作已经近十年了，测试前端应用程序一直是质量保证人员最常用的活动之一。但是开发者呢？这份报告给我讲了一个令人惊讶的故事。"--DawidDylowicz公司（OnfidoQA负责人）
对我来说，最令人震惊的结果是测试责任从测试人员转移到开发人员。事实证明，在88%的情况下，开发人员至少和QAs一样参与测试。
作为测试工程负责人，我的核心职责之一是鼓励我们的质量保证人员成为教练，帮助开发人员参与测试。因此，我很高兴看到我自己的经验反映在调查中，显示其他团队在这方面也取得了巨大进展。
作为《软件测试周刊》的策展人，我注意到很多测试人员和开发人员选择JavaScript进行测试。如今，更多的人写像Cypress和Playwright这样的工具，而不是Selenium。因此，我并不惊讶地看到，近一半的受访者已经试用过Cypress。除了Jest，它是最流行的测试工具。这表明人们对更健壮的测试越来越感兴趣，并青睐具有良好DX（开发人员体验）和使用与开发相同语言的工具。
"对于项目管理，69%的受访者使用Scrum或Kanban。52%的Scrum比33%的Kanban更常见，17%的受访者同时使用两者。三分之二的前端开发人员在完成项目时使用这两种方法之一。"
"单元测试在前端工程师中很普遍，近75%的受访者编写了此类测试。整合测试和端到端测试也很常见，大约一半的受访者编写了这些测试。"--GergelyOrosz(ThePragmaticEngineer创始人)
CodeReview在行业内很常见，80%的受访者表示他们遵循这种做法。有趣的是，CodeReview在哪里不太可能成为一种实践？对于那些不进行CodeReview的人来说，前端工程团队的规模与工程师是否进行CodeReview之间有着密切的联系：
以上大部分内容都不足为奇：工程师越多，CodeReview不仅在发现问题方面，而且在更好地传播知识方面带来的价值就越大。
CI/CD在行业内广泛存在。令人好奇的是，大约有四分之一的工程师不使用CI/CD。
"没有编写单元测试、没有CI/CD和没有进行CodeReview是相互关联的。"
这是本次调查中更有趣的发现之一。不做两个编写单元测试、CI/CD和CodeReview的工程师可能不会同时做这三个。
这一发现并不令人惊讶，因为这三种工具是相互关联的。当没有自动测试运行时，CI/CD就没有什么意义了。大多数CodeReview工具无缝集成到CI/CD工具中。
尽管如此，这一发现表明，通过引入单元测试和设置CI/CD，CodeReview可能会随之而来。或者，也许是另一种方式：希望进行CodeReview的工程师倾向于编写测试，并将建立CI/CD。
以下是本次调查调查问卷参与者提出的工程实践。如果您还没有尝试其他方法，不妨参考以下建议：
这就是我们最初的想法！然而，当我们看到剩下的选项并注意到以下几点时，我们松了一口气：
这让我们非常高兴，因为所有这些元素（响应性、性能和用户体验）对搜索引擎优化也很重要。
随着谷歌（和其他搜索引擎）在让互联网成为一个伟大的地方方面施加了很大的压力，用户处于其中心位置。因此，到2022年，搜索引擎优化的发展将远远超过一堆HTML标签和内容。重要的是，它不仅适用于网站，也适用于PWA和移动应用程序！
对于初学者来说，就是响应式。对于大多数在不同设备上工作的项目来说，这是必须的。最近，一些平台（推特）开始暗示AMP（另一种搜索引擎优化友好的网络应用移动版本）的退役。这使得RWD更加重要。
说到性能，这显然包括很多方面。从搜索引擎优化的角度来看，这一切都是关于页面速度的，不仅是速度，而且是页面体验。2020年11月，谷歌增加了三个新的页面体验信号，构成了他们所说的CoreWebVitals[2]。这些在20216月左右成为谷歌排名算法：最大内容绘制（LCP）、第一输入延迟（FID）和累积布局偏移（CLS）。以上三项是每一个前端最应该重视的指标。
接下来是用户体验，这是一个非常广泛的主题。然而，有一件事是肯定的：许多SEO已经使用SXO这个词来表示典型的搜索引擎优化必须包括用户体验。
那么，搜索体验优化就是将谷歌（和其他搜索引擎）的技术优化与为用户打造最佳网站相结合。在我们的应用程序生态系统中，有什么能更好地以用户期望、行为和成功的方式为用户服务？
但这也有另一个非常显著的优点。满意的用户=保留（或返回）用户。
好的用户体验会影响转化率，有助于留住用户，或者让他们想要获得更多体验。所有这些通常意味着更好的盈利，这是大多数商业应用程序的重心。
令我震惊的是，“总是”的答案竟然低至17%！这让我认为，前端开发人员仍然是被动的，而不是积极主动地实现可访问性。我在过去几年中看到的是，工程师们现在正在积极地运行自动化可访问性工具，作为其CI/CD的一部分，这无疑有助于提高工程师和软件团队其他关键成员的技能。
令我惊讶的是，可访问性没有用户响应性、性能或用户体验那么重要。我有一种感觉，由于公司产品的可访问性差，现在可能会对公司产生法律影响，我预计这一情况在未来会改变。
我希望在接下来的几年里，我们能看到像安全性一样的可访问性，我们将在设计软件产品时考虑到可访问性。与过去几年中安全至关重要的情况类似。
"用户体验往往是出现问题后的最后考虑。因为功能是第一位的，所以适应这些功能的用户界面是第二位的。因此，用户体验是一项昂贵而及时的工作，只有在大型专业公司才能做到。"
"虽然大多数受访者仍然倾向于使用自己的设计系统和样式，如SCSS，但用户体验需求仍然往往落在程序员身上，他们只需要获得一个功能来实现，而没有任何故事板或用户流示例。"--阿德里安·特瓦罗格(“Development&Design”创作者)
测试在编码中是如此重要的一项任务，以至于没有人能够再想象不经过适当测试就可以发布某些内容。这同样适用于用户体验测试，在我的选择中，它应该是写入CI/CD工作流的另一个元素。
有时，由于CTR失败，用户无法完成任务。但是，由于没有涉及用户体验测试，任务本身经常充满了未被发现的错误。
我得出的结论是，现如今前端开发普遍给予了测试和审查更多的考虑，尤其是在代码方面，这些同样的考虑应该应用于用户界面和用户体验，因为它们对任何系统的成功都至关重要。
不幸的是，我对可访问性的结果并不感到惊讶。至少我们对自己诚实。承认我们的缺点是改善缺点的第一步！希望这些结果能给我们敲响警钟，提醒我们自己，对于大量用户（包括使用辅助技术的用户和未使用辅助技术的用户）来说，可访问性是用户体验的重要前提。事实上，对于一些用户来说，他们对你开发的应用程序有任何“体验”的唯一方式就是考虑可访问性，因此我们最好采取相应的行动。
"前端可能正在进入稳定阶段"--马雷克·加伊达(SoftwareHouseCTO)
sin（x）/x函数图
看起来，前端开发正在进入一个更加"稳定"的阶段。一些问题，如可访问性或服务端渲染，已经不再需要讨论了。然而，几年前，前端还处于这条道路的起点，方法反映了完全不同的愿景、想法和方法。IT界的每个人都知道"每天都有新的前端框架"的笑话。但现在这种情况少了，我们正处于罪孽功能放缓和扁平化的阶段，稳定的过程开始了。
让我们来分析一下我从调查问卷的回复中可以挑出的一些趋势稳定的例子。
早在2020年，20%的受访者预测了微前端的死亡，而现在看来，它们并没有消失。微前端仍然有边界的意见，我想知道未来的妥协会是什么样子。LucaMezzalira在他的"Micro-frontend"一书中提出了12种不同的微前端概念，这意味着解决方案本身仍在内部结晶。我怀疑投票支持微前端的人与投票反对的人所支持的概念是不同的。
服务端渲染已经严重扁平化了（60%VS5%），但我很惊讶这就是稳定轴的落脚点。历史课：页面最初是在后端渲染的。然后人们说："这有点傻，在互联网上转来转去，慢得令人难以置信，应该由前端的浏览器来做"。然后反对派说。"好吧，但它还是有点慢，也许我们应该回到后端去？"对方的回应是："嘿，在服务器上做一点，在客户端做一点，怎么样？"所以我们基本上又回到了原点，这正是20年前的工作方式。但是这一次，我们在多年的新经验、实验和内部改变后，能够修改这个方法。
我的猜测是，领域驱动的设计是下一个目标。9年前的想法是将业务逻辑与技术问题（路由、数据库、性能、优化等）分开。有描述应用程序的代码，也有工程和技术的代码。每个人都为这个想法而疯狂，但几乎没有人能够做到这一点。概念是正确的，只是时机不对--矛盾的是，我们没有足够成熟的技术来执行这项任务。目前，这种技术正在发生转变，如果有人大声支持DDD，他们可能是对的。我们终于有了将理论转化为实践的工具，并将业务逻辑与技术部分真正分开。上面列表中的一些解决方案，如无头CMS，正是这样做的。
早在史前时代，曾经有一个巨大的、统一的应用程序。当新的人进入项目时，他们被告知做什么和怎么做，没有讨论和选择。
现在，如果你想在你的前端团队中建立责任感和所有权，确保开发人员对技术和工程问题有很多发言权。这不是关于应用程序的功能，而是关于它将如何被构建。公司终于开始在事情的决策上给予开发者更多的自主权，而不是在他们头上做重要的决定。不仅仅是因为前端程序员赚了很多钱。人们对自己的工作越有发言权，就越有主人翁意识。
在问题中包括的趋势中，我们已经有了组件驱动开发，GraphQL，微前端和网络组件--所有的应用程序都以这样的方式划分，软件团队中的每个人都可以在自己的部分工作，而这些部分以后将被纳入一个更大的整体。但每个开发人员都对自己的领域负责，并决定如何完成。这100%符合更广泛的开发者自主权的概念，有无数的问题解决选项。
然后，每个人都注意到，创建和维护移动APP实际上花费了一大笔钱。很多公司放弃了他们专门的移动团队，因为人们发现，你所需要做的只是打开一个网站，为智能手机扩展。而不是从头开始建立一个完整的应用程序!然后，根据趋势稳定阶段，我们经历了："嗯，混合型怎么样？"-"不，回到原生"--"那么，你毕竟是为了一个新的、混合化的混合体回来的？"......
只是提醒一下，谷歌提出了可信网络活动（TWA），他们试图将其作为一个标准。这仍然是一个新鲜的话题，但我感觉它很快就会枯萎，我没有看到前端开发者、经理或公司对它有任何兴趣。苹果不太可能提出他们自己的"标准"，因为他们有一个原始的iOS，而且他们不得不承认原生应用已经成为过去。
我把最令人惊讶的留到最后，你看到WebAssembly的结果了吗？在我看来，WebAssembly确实是少数公司用来做优化的解决方案之一，像Facebook或Gmail这样的巨头。事实证明我完全错了。46%的受访者预测WebAssembly会越来越受欢迎，老实说，我很震惊！我不知道该怎么办。也许我生活在这样一个世界里，当你使用了前端功能而碰壁时，WA是最后的选择，因为它很难写，而且很难维护。当所有的方法都用过了，但解决方案还是太慢，那时候你才会去用WebAssembly。