We replaced our React front end with Go and WebAssembly

Original Article ↗ Hacker News Discussion ↗

WebAssembly for Frontends

  • Many see this as a strong demonstration of WASM’s promise: bringing “any language” to the browser and enabling backend‑oriented teams to build rich UIs.
  • Others argue WASM is appropriate for niche, heavy client‑side computations (FFmpeg, game engines), but “absurd” for typical CRUD/DOM apps where JS/TS excel.
  • There’s relief that the app uses DOM elements, not canvas‑only rendering (which would harm accessibility).

Go + go-app Tradeoffs

  • go-app’s Go‑based virtual DOM is praised for compiler‑checked UI, editor completion, and reuse of Go logic, though some find the “HTML via Go function calls” style ugly versus template‑based approaches.
  • Go WASM currently produces large binaries (tens of MB uncompressed) due to its runtime and async model; new Go releases and alternatives (TinyGo, Zig, Rust) are discussed as ways to shrink output.
  • They replaced JSON with gob over WebSockets for performance; commenters note gob is not hardened against adversarial input and has caused perf/robustness issues elsewhere.

Bundle Size, Performance, and Architecture

  • 32MB (≈4MB compressed) is seen as huge compared to typical JS/WASM bundles, but some argue it’s acceptable for a professional app used all day, where caching amortizes cost.
  • Concerns remain about startup time, CPU/battery use, and multi‑tab initialization; suggestions include workers, chunked WASM loading, and (hypothetical) shared runtimes.
  • Some question why so much data crunching happens client‑side instead of pre‑aggregation on the backend; counterpoint is that pushing work to clients can control infrastructure costs.

Was React Really the Problem?

  • Several are unconvinced by the claim that “TypeScript/React didn’t scale” for a complex UI; they point to virtualized tables and standard browser techniques that can handle huge datasets.
  • Some who tried the new UI report basic UX rough edges, reading this as inexperience with frontend rather than a React limitation.
  • Others defend the decision as primarily about eliminating a duplicated React codebase and unifying logic in one language/ecosystem, not about React’s raw technical limits.

One Language Everywhere & Full‑Stack Debate

  • One camp strongly values single‑language stacks (Go everywhere, or TS everywhere) for small teams: easier cross‑editing, fewer context switches, and lower barriers for contributors.
  • Another camp argues front‑ and back‑end are effectively different disciplines with different concerns; forcing one language can hide real complexity and reduce use of best‑fit tools.
  • Large subthread debates “full‑stack”: some see full‑stack engineers as highly productive generalists; others view them as dabblers who underperform specialists, especially on UX or complex backend work.

Ecosystem, Tooling, and LLMs

  • Skeptics note hiring React devs is far easier than finding Go+WASM frontend developers.
  • Several argue LLMs make popular, stable stacks even more attractive, since models answer questions about mainstream tools far better than about niche frameworks.
  • Others say good developers can learn new stacks quickly and that teams should optimize for adaptability over narrow framework experience.

Accessibility & Maintainability Concerns

  • Because the UI uses real DOM elements, commenters believe screenreader access should be achievable, unlike canvas‑only UIs.
  • Some foresee long‑term maintenance pain: large binaries, esoteric stack, thin ecosystem, and dependence on a relatively young library. Others call it an interesting, valid experiment whose real success will only be clear over time.