采纳
KotestKotest（原名 KotlinTest）是 Kotlin 生态中的一个独立测试工具，它在我们的团队各式各样的 Kotlin 实现（原生、 JVM 或 JavaScript）中越来越受到关注。Kotest 的主要优点是它提供了丰富的测试风格来搭建测试套件，其中还有一套全面的匹配器，可以帮助你使用优雅的内部领域专用语言（DSL）编写表达式测试用例。Kotest 除了支持基于属性的测试 之外，我们团队也看好它可靠的 IntelliJ 插件和支持社区。我们的许多开发者将它列为首选并推荐那些仍在 Kotlin 中使用 JUnit 的开发者考虑切换到 Kotest。 React QueryReact Query 通常被描述为 React 缺失的数据获取库。获取，缓存，同步和更新服务器状态是许多 React 应用程序常见的需求，尽管这些需求易于理解，但众所周知，正确地实现这些需求非常困难。React Query 提供了一种基于 hooks 的更直接的方式。它与现有的基于 promise 机制的异步数据获取库协同工作，如 axios、Fetch 和 GraphQL。作为应用程序开发人员，你只需要传递一个解析数据的函数，其余的事情可以留给框架完成。该工具开箱即用，但也可以按需进行配置。它的开发者工具也能帮助刚接触此框架的开发人员理解其工作原理，遗憾的是，其开发者工具尚不支持 React Native。对于 React Native，你可以使用第三方开发者工具插件 Flipper。基于我们的经验，React Query 的第三版为我们的客户提供了生产环境所需的稳定性。
试验
Camunda
自从我们上次提到 Camunda 以来，我们已经看到了我们的许多团队和客户在使用该平台，使其在适合引入工作流引擎的领域里，成为我们的首选工作流引擎之一。Camunda 提供的工作流和决策引擎可以作为库集成到用户的 Java 代码中。这使得测试、版本化和重构工作流变得更容易，缓解了其他低代码工作流引擎的一些缺点。我们甚至已经看到 Camunda 在具有高性能要求的环境中被使用。一些团队还很喜欢它可以很容易与 Spring Boot 做集成及它漂亮的用户界面。
Jetpack Media3现如今安卓拥有多个媒体 API：Jetpack Media（也被称为 MediaCompat ），Jetpack Media2 和 ExoPlayer。然而，这些库都是分别开发的，它们的目的不同但是功能重叠。这就导致安卓开发者在编码的时候不仅需要斟酌类库的选型，当使用的特性来自于多个库的时候，还需要编写适配器或者兼容代码。Jetpack Media3 是从现有 API 中选取通用的功能——包括 UI、播放和媒体会话处理，然后将它们合并和改进成一个新的 API。ExoPlayer 的播放器界面也进行了更新、增强和简化，被用作 Media3 的通用播放器界面。在早期访问阶段之后， Media3 目前仍处于早期开发版本。虽然它的第一个正式版本即将发布，但我们已经在应用程序中使用 Media3 得到了积极的体验。
Svelte在 Web 组件框架中，Svelte 通过将反应性从浏览器中转移到编译器中而脱颖而出。Svelte 不是通过使用虚拟 DOM 和浏览器优化技巧来优化 DOM 更新，而是将你的代码编译成无框架的 JavaScript 代码，像做外科手术一样更新 DOM。除了运行时的性能优势之外，这也让 Svelte 在不牺牲开发者功能的情况下优化浏览器必须下载的代码量；此外，事实证明，由于在浏览器中执行的代码较少，它对移动网络应用的性能和电池需求更加友好。除了性能优势之外，我们团队还欣赏它友好的学习曲线和来自于编写更少代码 的维护优势。Svelte 本身只是组件框架，但 SvelteKit 增加了可以构建完整 Web 应用程序的功能。
评估
Astro令人难以置信的是，即使到了2022年，开发者社区仍在持续推出有趣的，用于构建 web 应用程序的新框架，Astro 就是最新推出的开源，多页面响应的应用程序框架，它可以在服务器上渲染页面并尽可能减少通过网络发送的 JavaScript 数量。Astro 看起来非常适合那些从多种渠道获取资源的内容型网站。我们喜欢 Astro 的一点是，尽管 Astro 鼓励只发送 HTML，但它仍然支持——在适当的时候——选择用您选用的前端 JavaScript 框架编写的活动组件。它通过 island architecture 做到这一点。岛屿是单个页面中的交互区域，仅在需要时才下载必要的 JavaScript。Astro 是相对较新的技术并且看起来支持日益增加的开发者及代码生态系统。它的发展值得关注。
Carbon Aware SDK当我们着眼于减少一款应用程序的碳足迹——运行软件间接导致的二氧化碳排放——时，注意力通常被导向让软件更加高效上。思路很明确：更高效的软件只需要更少的电力和服务器，从而减少发电与制造服务器所带来的碳排放。另一个策略是使应用程序具有碳意识。这是因为同样的工作负载并不总是具有相同的碳足迹。例如：在较冷气候的数据中心运行时，用于空调的电力需求会减少；或者，在能够使用更多的可再生能源（更多的阳光，更强的风力）时，碳基来源的电力需求会减少。借助 Carbon Aware SDK，软件工程师们可以查询数据源来发现对于给定的工作负载而言碳密集度更低的选项，然后将它移动到不同的位置或是在不同的时间运行它。这对那些对于时间和延迟都不敏感的大型工作负载来说是有意义的，例如训练机器学习模型。虽然这个 SDK 和可获取的数据源还不是很全面，但是我们相信是时候开始探索如何能让我们的系统具有碳意识了。
跨设备 SDK随着智能设备持续融入我们的生活，我们开始看到跨越多个设备的新用例出现。典型的例子是我们在手机上开始阅读一则文本但是更喜欢在平板电脑上读完它。其它例子包括在笔记本电脑上绘制骑行路线，然后把数据传输到自行车电脑上以便于导航，或是使用移动手机作为网络摄像头。这些使用场景需要非常特定类型的功能，例如发现附近设备、安全通信以及多设备会话。Apple 不久前已经开始将此类功能引入到它自己的 SDK 中了，现在 Google 也发布了其 跨设备 SDK 的首个预览版本。尽管该预览版本有一些限制——例如，仅支持手机与平板，并且一次仅支持两个设备——但是这项技术还是令人兴奋，在其推出后我们可以随着时间的推移而采用它。
暂缓
Carbon我们看到了一些对 Carbon 编程语言产生的兴趣。这一点也不令人惊讶：它有 Google 的背书，而且它被展现为 C 的天生继承者。在我们看来，C 不会以足够快的速度被取代，正如在过去几十年的时间里软件工程师们所表现的那样，写出安全且没有错误的 C 代码是一件极其困难且耗时的事情。虽然 Carbon 是一个有意思的概念，它专注于从 C 移植，但是在没有一个可工作的编译器的情况下，很明显它离可以使用还有很长的路要走，而且如果你想从 C 移植，也有其他现代的编程语言可以作为不错的选择。现在谈 Carbon 是否会成为 C 的天生继承者还太早了，不过，以今天的视角来看，我们推荐项目组去关注一下 Rust 和 Go 而不是等着 Carbon 的到来而推迟移植项目。
以上是本期技术雷达语言和框架象限中的部分条目，请点击下方链接，获取更多内容或查看完整版技术雷达。
https://www.thoughtworks.com/zh-cn/radar
