Farm: Fast vite compatible build tool written in Rust

Original Article ↗ Hacker News Discussion ↗

A new Rust-based JavaScript build tool called Farm is drawing interest for promising much faster builds and Vite compatibility, but many developers question whether its performance gains justify adopting a young, unproven system. Commenters compare it with existing tools like Vite, esbuild, Rollup, rspack, Bun, and upcoming Rust rewrites such as Rolldown, highlighting broader fatigue with constant frontend tooling churn and complex plugin ecosystems. Concerns also surface around Farm’s rough edges — from its mobile-unfriendly website and incomplete migration tooling to uncertainty about its Chinese origins, legal status, and long‑term maintenance and security.

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.