菜单

语言 & 框架

采纳?

  • Arrow 的推广语是“Kotlin标准库的函数式伴侣”。事实证明,其所提供的现成可用的更高级别抽象的程序包非常有用,以至于我们的团队在使用 Kotlin 时,都将 Arrow 视为明智的默认选择。最近,为准备1.0版的发布,Arrow 团队进行了几处更改,包括添加了新模块,删除了一些旧模块,并将一些功能标记为过时。

    历史信息
  • jest-when 是一个轻量级的 JavaScript 库,为 Jest 提供匹配模拟函数入参的能力。Jest 是全栈测试的好工具,而 jest-when 则可以帮助检查模拟函数接收的参数是否符合期望,这样就能够为依赖较多的模块写出更健壮的单元测试。jest-when 易于使用,并支持多种匹配器。因此在需要匹配模拟函数入参时,我们会默认选择 jest-when。

    历史信息

试验?

  • 在需要用 Node.js 实现时,我们看到团队非常高兴能使用 Fastify。这个 web 框架提供了方便的请求-响应验证处理,支持 TypeScript,以及为团队提供更轻松的开发体验的插件生态系统。虽然它在Node.js生态中是个很好的选择,我们仍然坚持之前的建议:不要陷入Node 过载的场景中。

    历史信息
  • 随着单页面 JavaScript 应用越来越复杂,以可预测的方式进行状态管理就显得愈发重要。不可变性(Immutability)可以帮我们确保应用具有一致的表现,不幸的是,JavaScript 没有提供内置的具有深层不变性的数据结构(参见 ES 记录与元组提案)。Immer(在德语中是永远的意思)是一个极小的包,它可以让你用更加便利的方式处理不可变状态。它基于写时复制(copy-on-write)机制进行工作,具有最小化的 API,而且只操作普通的 JavaScript 对象和数组。这意味着其数据访问是无缝的,不需要做大规模重构就能把不可变性引入到现有代码库中。目前,我们的很多团队都在自己的 JavaScript 代码库中使用它,相对于 Immutable.js,我们更喜欢它一些,这就是把它移入“试验”中的原因。

    历史信息
  • Redux 已被移回试验环,因为我们不再将其视为 React 应用程序默认的状态管理方式。经验表明,在许多情况下 Redux 框架仍然具有一定的价值。但是与其他方法相比,Redux 会导致代码冗长难读。而引入 Redux Sagas 通常更会加剧这个问题。相对的,React 最新版本中的功能已经可以有效地管理状态,而无需引入其他框架。但需要着重强调的是,当简单的状态管理解决方案开始变得复杂时,仍然可以考虑使用 Redux,或者是 Facebook 最近发布的 Recoil

    历史信息
  • Rust 编程语言持续流行,并连续五年被开发人员们评为 Stack Overflow 的“最受喜爱”语言。我们当然也喜欢它。它是一种快速,安全且富有表现力的语言,随着它的生态系统发展,其实用性也不断提高。例如,Rust 开始用于数据科学和机器学习,并能显著提高性能。同时,用 Rust 编写的面向流的低延迟数据库 Materialize 也应运而生。

    历史信息
  • single-spa是个 JavaScript 框架,它把多个微前端集成为一个前端应用。虽然我们告诫提防微前端混乱,借口使用微前端来混合和匹配多个框架,但 single-spa 恰恰干的就是这个。我们明白存在一些正当的场景,比如在有必要集成多个框架时,你需要升级多个微前端中某个框架到新版本。single-spa 一直是我们团队在集成微前端时的默认框架选择,他们发现它可以跟 SystemJS 工作得很好,并且能管理单个依赖的不同版本。

    历史信息
  • Kotlin 的生态在持续生长,更多的类库开始充分利用 Kotlin 语言的特性,去换掉他们的 Java 替代品。Strikt 是一个可以让你以非常流畅的风格编写测试断言的断言库。它使用 Kotlin 的 blocks 和 lambdas,帮助你的测试不那么冗长,以保持可读性。Strikt 还支持创建自定义断言,这会让你的测试更特定于领域。

    历史信息
  • 在之前的雷达中,我们曾经提及多个状态管理的类库,但 XState 在其中显得与众不同。它是个简单的 JavaScript 和 TypeScript 框架,可以创建有限状态机并可视化为状态图。它可以跟最流行的响应式 JavaScript 框架(Vue.jsEmber.jsReact.js 以及 RxJS)集成,并基于 W3C 标准来创建有限状态机。另外一个值得留意的特性是它可以序列化状态机的定义。在其他的上下文中(尤其在编写游戏逻辑时)创建有限状态机时,我们发现一件很有帮助的事情,是 XState 对状态以及可能的转换的可视化能力,通过它的 visualizer 实现起来是如此容易。

    历史信息

评估?

  • 在几年前我们写到超越游戏的VR时,我们没有预见到 VR 解决方案会以多快以及多深的程度进入到除了视频游戏之外的领域。事后看来,我们当然看到了一些兴趣和采纳的增长,但人们对它的理解却比我们预期的要慢得多。原因之一可能是工具。UnityUnreal 是两个用于开发 VR 应用的成熟又强大的引擎。我们还特别提到 Godot。然而,这些引擎跟大多数 web 和企业团队熟悉的那些工具很不同。随着我们继续探索,我们意识到基于 web 的 VR 方案已经取得巨大进展,其中对 Babylon.js 我们有相当积极的经验。Babylon.js 是用 TypeScript 编写并在浏览器中渲染出它的应用,这为许多开发团队提供了熟悉的开发体验。此外,Babylon.js 也是开源软件,成熟而且资金充足,这让它足具吸引力。

    历史信息
  • 虽然 JavaScript 及其生态系统已经在 Web UI 领域占据了统治地位,但随着 WebAssembly 的出现,一些新的机遇之窗也正在打开。我们看到一个有趣的新选择 —— Blazor,它可以使用 C# 来构建交互式 Web UI。我们青睐这个开源框架,是因为它能让我们在浏览器中基于 WebAssembly 运行 C# 代码,从而利用 .NET 标准运行时环境和生态系统以及它的各种自定义库。此外,只要需要,它还可以在浏览器中与 JavaScript 代码进行双向互操作。

    历史信息
  • Flutter DriverFlutter应用的集成测试库。通过 Flutter Driver,你可以在真实设备或模拟器上测试和驱动测试套件。我们的团队一直在编写单元测试和 widget 测试,以确保 Flutter 应用的大部分业务功能已被实现。不过,对于测试实际用户交互方面,我们仍在评估。

    历史信息
  • 尽管我们是定义安全策略即代码的积极倡议者,但这个领域的工具一直很有限。如果你在使用 HashiCorp 产品(比如 Terraform 或者 Vault ),并且不介意为企业版本付费,那你就可以使用 HashiCorp Sentinel。事实上,Sentinel 是一门完整的编程语言,用来定义和实现基于上下文的策略决策。比如,在 Terraform 中,它可以用来在应用基础设施变更前,测试是否存在策略违规。在 Vault 中,Sentinel 可以用来定义对 API 的细粒度访问控制。这样的方法提供了类似高级编程语言提供的封装、可维护性、可读性和扩展性,自然相比较传统的声明式安全策略而言更具吸引力。Sentinel 和 Open Policy Agent 属于同一类型的工具,但它是专利所有,闭源,并且只能工作于 HashiCorp 产品中。

    历史信息
  • Hermes 是一个经过优化的 JavaScript 引擎,可在 Android 端快速启动 React Native 应用程序。JavaScript 引擎(例如 V8)具有即时(JIT)编译器,可在运行时对代码进行分析以生成优化的指令。而 Hermes 采用了另一种方法,将 JavaScript 代码提前编译(AOT)为优化的字节码。这样做的结果是,你可以获得更小的 APK 图片大小,更少的内存消耗和更快的启动时间。我们正在一些 React Native 应用中认真评估 Hermes,建议你也这样做。

    历史信息
  • 我们在使用 TypeScript 时,很喜欢强类型带来的安全性。但是,将数据带入类型系统(比如调用后端服务读取数据)时,可能会引发运行时错误。io-ts 可以解决这个问题。io-ts 的编码和解码函数,将编译时类型检查与运行时消费外部数据结合在一起。同时,io-ts 也可以用作自定义的类型守卫。我们认为这是一个绝妙的解决方案。

    历史信息
  • 过去我们讨论过在数据科学项目中应用好的工程实践改进 工具Kedro 是另一个很好的补充。它是用于数据科学项目的开发工作流框架,为构建生产用数据和机器学习管道带来了标准化的方法。我们很欣赏其对软件工程实践和良好设计的关注,它强调测试驱动开发、模块化、版本控制以及良好的代码实践,比如将凭证排除在代码库之外。

    历史信息
  • 自我们于2014年第一次提到 Web Components 以来,它已经取得了稳步的发展。作为 Polymer 项目的一部分,LitElement 是一个简单的库,你可以使用它创建轻量级 web 组件。它实际上只是一个基类,它减少了对许多常见引用文件的需要,并且使编写 Web 组件变得更加容易。我们已经在项目中使用它取得了早期的成功,并且很高兴看到这项技术的成熟。

    历史信息
  • Web 应用,特别是企业内部应用,通常分为两个部分。用户界面和小部分业务逻辑运行在浏览器中,而大部分业务逻辑、认证和持久化工作运行在服务器中。这两部分一般会通过在 HTTP 上传输 JSON 进行通讯。但请不要误认为这些端点(endpoint)是真正的 API,不,它们只是当应用要穿越两个运行环境时的实现细节而已。与此同时,它们也提供了一个合适的“接缝”,以便独立测试这些“零件”。当测试 JavaScript 部分时,可以通过像 Mountebank 这样的工具在网络层对其服务端进行打桩(stub)和模拟(mock)。还有一种方式是在浏览器中拦截各种请求。我们很喜欢这种由 Mock Service Worker 带来的方式,因为 Service Worker 是前端开发人员比较熟悉的抽象层。这种方法可以简化设置,并且执行得也更快。不过,由于这些测试没有测到真正的网络层,所以你还要实现一些端到端测试,才能得到一个健康的测试金字塔。

    历史信息
  • 越来越多正在使用 React 的团队,都开始重新评估他们对于状态管理的选项,这也是我们在重新考虑 Redux 时提到的。现在,React 的缔造者 Facebook,发布了 Recoil,一个用于管理状态的全新框架。它源自一个要应付大量数据的内部应用。即便现在对 Recoil 没有充分的实践经验,我们仍然能预见它的潜力和前景。API 简单易学,感觉像是惯用的 React。不像其他方法,Recoil 为应用间共享状态提供了一个有效而灵活的办法:它支持从派生数据和查询动态地创建状态,并在不损害代码分割的情况下,实现整个应用范围内的状态监控。

    历史信息
  • 现代机器学习模型非常复杂,并且需要大量标记训练数据集进行学习。Snorkel 始于斯坦福 AI 实验室,开发者们意识到手动标记数据非常昂贵,而且通常不可用。Snorkel 使我们可以通过创建标记函数的方式自动对训练数据进行标记。Snorkel 采用监督式学习技术来评估这些标记函数的准确性和相关性,然后重新赋权并组合输出标签,从而生成高质量的训练标签。由此,Snorkel 的创建者们推出了一个名为 Snorkel Flow 的商业平台。尽管 Snorkel 本身已不再被积极研发,但它在使用弱监督方法标记数据方面的思想仍具有重要意义。

    历史信息
  • Streamlit 是 Python 编写的开源应用框架,数据科学家用其来构建好看的数据可视化应用。Streamlit 专注于快速原型设计,并且支持各种不同的可视化库(包括 PlotlyBokeh),因此在Dash等竞品中脱颖而出。对于需要在实验周期中快速展示的数据科学家来说,Streamlit 是一个可靠的选择。我们在一些项目中使用它,并且只需要花费很少的工作量就能把多个交互式可视化放在一起。

    历史信息
  • 我们不断看到新的前端 JavaScript 框架出现,其中 Svelte 作为一个前途无量的新组件框架脱颖而出。与其他使用虚拟 DOM 的框架不同,Svelte 将代码编译为单纯的无框架 JavaScript 代码,这些代码可以直接操作更新 DOM。不过,它只是一个组件框架;如果你打算构建功能丰富的应用程序,可以考虑将 Sapper 与 Svelte 一起进行评估。

    历史信息
  • SWR 是用于获取远程数据的 React Hooks 库,它实现了 stale-while-revalidate HTTP缓存策略。SWR 首先从缓存(过时的)中返回数据,然后发送获取请求(再验证)并最终用更新的响应数据刷新数值。组件因此持续而且自动地获得一个数据流,先是过时的,然后是刷新过的。我们的开发者在使用 SWR 时获得了很好的开发体验,并且因为数据总是显示在屏幕上,从而显著提升用户体验。然而,我们提醒团队,只有当应用程序返回过时数据是合适的时候,才能使用 SWR 缓存策略。要注意,HTTP 通常要求缓存要用最新的响应返回给请求,只有在需要非常慎重的场景下,才会允许返回过时的响应数据。

    历史信息
  • Testing Library 是用于在众多框架(如ReactVueReact Native 以及 Angular)中测试应用程序的软件包集合。这组库通过鼓励测试用户行为,而非实现细节的方式(如在特定时间点中 UI 存在的元素),来帮助你以用户为中心的方式测试 UI 组件。这种思维方式的好处之一在于测试更加可靠,这也是我们所认为的主要区别。我们建议在任意框架中测试 Web 程序时,都使用该系列工具。尽管仅有 React Testing Library 和 Angular Testing Library 的直接使用经验,我们仍对 Testing Library 印象深刻。

    历史信息

暂缓?

    无法找到需要的信息?

    每期技术雷达中的条目都在试图反映我们在过去六个月中的技术洞见,或许你所搜索的内容已经在前几期中出现过。由于我们有太多想要谈论的内容,有时候不得不剔除一些长期没有发生变化的条目。技术雷达来自于我们的主观经验,而非全面的市场分析,所以你可能会找不到自己最在意的技术条目。

    新的,移进/移出 ,没有变化