随着编译到 JavaScript 语言的日益普及，对于熟悉 Java 虚拟机（JVM）语言并希望开发 Web 应用程序但不想掌握复杂的 JavaScript 开发技术栈的开发人员来说，他们有了越来越多的 JavaScript 替代方案可选择。最近发布的对使用 GWT、TeaVM、JSweet、CheerpJ、Vaadin Flow 框架搭建的应用程序性能和有效负载特性的分析表明，与原生 JavaScript Web 应用程序相比，它们的性能差距正在缩小。
Java 开发人员 Renato Athaydes 最近对 JVM 替代方案和 JavaScript 进行了比较。作为比较参照物的目标应用程序是一个简单的计数器，它使用 React JavaScript 前端库实现：
这个计数器应用程序分别使用 GWT 、 TeaVM 、 JSweet 、 CheerpJ 和 Vaadin Flow 五种 Java 框架实现。这五种 Java 替代方案和原生 JavaScript 应用程序之间的比较遵循了一种简单的方法论：使用 Java 或框架提供的最基本的工具创建计数器应用程序，然后测量应用程序的大小和性能。应用程序大小通过浏览器的网络（Network）选项卡获取（计算所有类型的资源，避免偏向依赖大量非 JavaScript 资源的框架）。利用谷歌 Chrome 内置的 Lighthouse 审计工具来衡量性能。 LightHouse 的性能分数根据六个加权指标进行评估，这六个指标按照重要程度排序为：可交互时间、速度指标，首次内容绘制，首次 CPU 空闲，首次有效绘制和预计输入延迟时间。
根据 Lighthouse 的报告，JSweet 和 TeaVM 在首次内容绘制（First Contentful Paint，FCP）测量上击败了原生 JavaScript React 应用程序。谷歌报告表明，首次内容绘制是“测量从请求页面到浏览器渲染 DOM 第一个比特位的时间。这对用户来说是一个重要的里程碑，因为它提供了页面实际加载的反馈”。虽然大多数框架都获得了 LightHouse 评定为良好的全局性能分数（> 90，最高为 100），但是与其他框架相比，CheerPJ 性能表现不佳。
在很大程度上，我们可以通过生成的 JavaScript 大小来解释 Java 框架排名结果：
Java 框架按照生成 JavaScript 大小从小到大的顺序排列，和上述按照性能排列顺序相同。能得出这样的结果是意料之中的，因为浏览器解析生成 JavaScript 的时间与大小成正比，与性能成反比。
该项研究不包括 J2CL ，J2CL 是谷歌最近推出的 Java 到 JavaScript 转换器。此外，该研究依托于一个简单的 Web 应用程序。虽然测评结果不能推广到大型 Web 应用程序，但它仍然可以用于分析该项研究中涉及的 Java 框架之间的差异。
例如，CheerPJ 的大尺寸和糟糕的性能可以用这样一个事实来解释：它不是一个真正的 Java 到 JavaScript 的转换器，因为它将完整的 Java 运行时发送给了浏览器。从好的方面来说，CheerPJ 允许开发人员使用已编译且包含 Swing 应用程序的 jar，无需插件直接在浏览器中运行。
GWT（2006 年发布）是一种成熟的开源技术，谷歌广告就使用了 GWT。 GWT 附带了一系列用于界面构建的小部件和面板。
TeaVM 声称是 Java 字节码的前置编译器，它可以在浏览器中运行 JavaScript 和 WebAssembly 。 TeaVM 不需要源代码，只需要编译后的类文件，而且不要求源代码是 Java 编写的，因此 TeaVM 可以编译 Kotlin 和 Scala 。
Jsweet 自称是 Java 到 TypeScript／JavaScript 的转换器，具有 1000 多个 Java 可用的 JavaScript 库。 Jsweet 声称允许开发人员使用 JavaScript 访问使用 Java 生成的 API／对象，而无需额外的工具或运行时。然而，Jsweet 并不能完全模拟 Java。在某种程度上，可能需要修改现有的 Java 应用程序，特别是那些使用 Java 特定 API 编写的应用程序，如用于用户界面的 Swing。
Vaadin Flow 是一组用于使用 Java 构建 Web 应用程序的组件和工具。 Vaadin Flow 提供了内置的 Spring 支持，支持 WebSocket 的自动服务器端到客户端通信。 Web 应用程序可以用纯 Java 编写，也可以用 Java 和 HTML 混合编写。 Vaadin 的组件自称是移动优先的 Web 组件，可针对 UX、性能及可访问性进行微调。但是，Vaddin Flows 会向浏览器发送一个压缩后大小超过“300k（不管应用程序大小）”的客户端引擎。后者解释了 Vaadin Flow 性能曲线的表现。
该研究方法论的灵感来源于 InfoQ之前报道的博文“前端框架的实现比较“。
查看英文原文： Writing Web Applications in Java - a Study of Alternatives
评论