Farm: Fast vite compatible build tool written in Rust

Original Article ↗ Hacker News Discussion ↗

Performance & Benchmarks

  • Farm positions itself as a Vite-compatible, Rust-based build tool with faster builds, especially on large projects.
  • Reported benchmarks and one user test show roughly 2× faster production builds vs Vite (e.g., ~28s → ~13s for a ~2,100‑module app).
  • Some see a 50% build-time reduction as a big win for CI and feedback loops; others view it as a marginal gain not worth adopting a new tool.
  • Farm’s dev-time advantage is tied to “partial bundling” (somewhere between full bundling and Vite’s ESM-based dev server), aiming to keep large apps fast on cold start and HMR.

Comparisons to Existing Tools

  • Frequently compared to Vite, esbuild, Rspack/Rsbuild, Turbopack, Parcel, Bun, Deno, and the emerging Rust-based Rolldown (Rollup rewrite).
  • Vite currently uses esbuild in dev and Rollup for production; its maintainers plan to replace both with Rolldown.
  • Some argue esbuild alone is “enough” unless you need advanced plugin ecosystems.
  • Others note Farm and similar tools often reuse SWC and other Rust components rather than reinventing everything.

Tooling Ecosystem & Proliferation

  • Several commenters ask why so many near-duplicate frontend build tools exist.
  • A recurring answer: moving from single-threaded JS to multi-threaded compiled languages (Rust/Go) requires rewrites, so new tools appear instead of evolving old ones.
  • There is concern that Rust-based JS tooling (parsers, bundlers, transpilers) is broad in scope but under-resourced, and not always as battle-tested as JS predecessors.

Maturity, Adoption & Migration

  • Skepticism about using Farm in production due to its youth; questions about large users and sponsors, with no clear big-name adopters mentioned.
  • Some want “drop-in” replacement behavior and auto-migration from Vite configs; existing docs for “migrate from Vite” are considered too thin.
  • Farm aims for Vite hook/option compatibility but notes JS↔Rust plugin communication is a performance bottleneck; future direction is a Rust-native plugin system.

Platform, Binaries & Config

  • NPM package is expected to be cross-platform; lockfiles should be identical across ARM Macs and Windows.
  • Rust native binaries raise general questions of distribution but no concrete problems reported.

Website & DX Concerns

  • Multiple reports of broken/jumpy mobile scrolling and layout issues; one user hits a WebGL-related crash on the homepage (docs still work).
  • Some consider this a bad look for a frontend tooling project, especially around error boundaries and WebGL use.

Security, Origin & “Farm Inc.”

  • Confusion and concern about “Farm Inc.”: users can’t find a corresponding legal entity in US/China registries.
  • Project members later say Farm is not a company and that “Inc.” is a mistake.
  • GitHub indicates a Chinese origin; some participants express geopolitical/information-security concerns about using Chinese-developed tooling, while others note similar risks apply to “Western” OSS.
  • The repository layout and multiple proxy crates are called “weirdly convoluted” by one reader, but implications are left as speculation.

General Frontend Frustrations

  • Broader complaints about JS tooling: dependency bloat, rapid churn, fragile plugin ecosystems, and slow builds compared to large C++ projects.
  • Some see slow builds as an accidental “soft limit” on dependency sprawl; others emphasize that modern JS dev should have a fast feedback loop and that heavy build steps are themselves a smell.