Golang如果作为前端语言与Javascript相比会怎样

Golang如果作为前端语言与Javascript相比会怎样 尽管Go是一门强大的后端语言，但其PWA/前端库确实不多。考虑到WASM的存在，以及Go拥有GopherJS和Yew，我很想看看Go与JS相比会如何。另外，如果Go能原生运行在浏览器中，它会比JS更快吗？

Ivan Malopinsky

将11种语言编译为JavaScript

一些将不同语言编译为JavaScript的基准测试。

7 回复

此外，我想知道 Go 语言是否有类似 Phoenix Liveview 那样的纯后端 Web 应用框架。

更多关于Golang如果作为前端语言与Javascript相比会怎样的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


是的，C和Rust也可以使用，但我就是喜欢Go语言那种Python式的风格以及它“开箱即用”的特性。Rust看起来太难了，而C语言就像布加迪：速度极快，但在处理空值、内存等方面需要大量的维护工作。

// 代码块示例
func main() {
    fmt.Println("hello world")
}

嗯，在这方面我不会抱太大希望，主要是因为WASM编程比传统编程复杂得多，即使我们谈论的是JavaScript，并且即使要做小事也需要付出巨大的努力。我想这就是它目前没有广泛普及的原因。

PythonGuyWhoLovesGo: 考虑到WASM的存在，并且Go拥有GopherJS和Yew，我很好奇Go与JS相比会如何。另外，如果Go是浏览器原生支持的，它会比JS更快吗？

在我看来，很难将服务器端语言与浏览器端语言进行比较。但是，在从API或数据库获取数据时，我更喜欢使用Javascript / AJAX，以减少页面闪烁，因为在使用新数据更新时，整个页面不必重新渲染/重新加载。我看不到使用Go代替Javascript能带来任何速度提升。只是减少了闪烁……

SSR（服务器端渲染）和CSR（客户端渲染）各有其优势。但它们的混合体SSG（静态站点生成）可能更有益。这意味着Go在构建时从模板渲染HTML，而所有动态内容由AJAX（Javascript）提供。

免责声明：我还没有测试过WASM，但据我理解，它的初始加载速度会较慢。

除了Go的WASM体积过大这一目前严重的缺点外，我希望WASM能在任何可能的情况下完全取代JavaScript。为什么？主要是由于：

  1. 类型约束
  2. 代码剥离（只打包我需要的代码）
  3. 尽可能重用我的Go库
  4. PWA兼容性（离线和在线模式）

在我看来，JavaScript框架/库如果不借助另一个衍生库来完成编译工作，就无法实现代码剥离（因此在其发展成熟期附近，常被抱怨库或框架臃肿庞大）。

我讨厌JavaScript及其衍生品吗？不。然而，如果客户端渲染能使用单一编程语言重用我的服务器端渲染库代码，我肯定会采用它。

我可以预见下一个演变是服务器端仅提供API，而客户端负责用户界面渲染和操作，特别是考虑到当前的地缘政治原因和战争局势 =（；以及端到端加密的要求（例如Bitwarden）。

供参考：我将于下个月开始全面探索WASM，计划将我的Hugo主题模块升级为完整的客户端渲染前端库。

geosoft1:

WASM 编程比传统方式复杂得多。

我认为是一些 JS 工作组的成员（那些有优越感的人）在阻碍改进。这不仅影响了 WASM；甚至 JavaScript 也受到了影响 [这个 Stage 3 时间库提案（Temporal 文档）完全让我措手不及，大吃一惊。仍然是实验性的提案？！你在开玩笑吗？]。

此外，很明显最初的意图是取代 JS。然而，这会引发 JS 社区内的技术政治动荡，因此它被改为补充性质。如你所知，一旦政治介入，一切都会变得昂贵而缓慢。

如果 Autodesk 能够将 AutoCAD（综述：2018 年 Google I/O 大会上的 AutoCAD Web 应用 | AutoCAD 博客 | Autodesk）带到云端而无需太多更改（https://web.autocad.com/login），见鬼，我对这项投资深信不疑。

此外，我们并不局限于 Go。C、Rust 或其他合适的编程语言都可以通过 WASM 加入进来。

从技术角度来看，Go语言通过WebAssembly（WASM）或GopherJS（将Go编译为JavaScript）确实能在浏览器中运行，但与JavaScript相比，它在前端开发中存在一些关键差异和限制。以下是对比分析：

  1. 性能方面：Go通过WASM运行时，计算密集型任务（如加密、图像处理）可能比JavaScript更快，因为WASM是接近原生性能的二进制格式。然而，对于DOM操作和事件处理，Go需要经过WASM与JavaScript的桥接，这会带来额外开销，通常比纯JavaScript慢。例如，使用syscall/js包调用DOM API时，性能会受桥接影响。

    // Go/WASM示例：简单的DOM操作
package main

import "syscall/js"

func main() {
    doc := js.Global().Get("document")
    body := doc.Call("getElementById", "app")
    body.Set("innerHTML", "Hello from Go/WASM!")
}

  2. 生态系统和库：JavaScript拥有React、Vue等成熟的前端框架和大量UI库，而Go的前端生态相对匮乏。GopherJS或WASM支持的库有限，例如缺少完整的组件化框架。虽然Yew（Rust框架）有时被误认为Go工具，但Go本身没有类似的前端框架。

  3. 开发体验：Go的静态类型和编译特性有助于大型应用维护，但浏览器调试困难。WASM调试工具不如JavaScript的DevTools成熟，且编译后的文件体积较大（Go运行时包含在WASM中），影响页面加载速度。

  4. 原生运行可能性：如果Go能像JavaScript一样原生集成到浏览器中（无需WASM），理论上性能会显著提升，因为消除了桥接开销。但目前没有浏览器厂商支持此功能，而JavaScript经过JIT优化，在典型Web任务中已足够快。

  5. 基准测试参考：在您提到的基准测试中，Go通过GopherJS编译为JavaScript时，性能通常低于原生JavaScript，因为转换层增加了开销。而Go/WASM在数值计算中可能领先，但综合Web场景下JavaScript仍占优。

总结：Go在前端领域更适合特定场景（如需要Go后端逻辑复用的计算模块），但整体上JavaScript在性能平衡、生态和工具链方面更胜一筹。除非浏览器原生支持Go，否则它难以替代JavaScript。

回到顶部