Farm: Fast vite compatible build tool written in Rust

So, I decided to try this for a real-world project and compare the results. This is for a full production build with no cache, taking the best of three runs each.

Vite:

    2166 modules transformed.
    built in 28.21s

Farm:

    [ Farm ] Build completed in 13350ms FULL EXTREME! Resources emitted to ./dist.
    [ Farm ] Public directory resources copied successfully.

So that is 28.21s vs. 13.35s, or a 53% decrease in build times. This is certainly neat, but I'm not sure whether it is worth the dependency on a new player.

I have mixed feelings about this project. It appears the author primarily aimed to rewrite Vite in Rust and then found justifications for doing so. From my experience, Vite is already sufficiently fast for most needs. Adopting a new and potentially unstable project for marginal performance improvements doesn't seem justifiable.

Serious question: does anyone here work for a BigCo who uses Chinese software like this in production? Do your InfoSec teams sign off on it?

What's the risk of downloading what's supposed to be a release binary of this off GitHub, where the release binary includes something nefarious not found in the open codebase, that steals your company's source code when you use it to compile?

In today's geopolitical climate, how does anyone trust non-Western projects?

So, we have rspack, turbopack and now Farm, all written in Rust.

There is also Vite, of course , which is already quite fast and very popular.

What's the differentiator between those?

Why aren’t we comparing to ESBuild?

I love how they compare the loading times by making the bars in the graph render as slowly as their benchmark measurement. Really delivers the message why the faster compilation time is worth it, instead of just showing a static graph with numbers.

Note in the benchmark, it is comparing a React JSX project using @vitejs/plugin-react (Babel based) instead of @vitejs/plugin-react-swc (SWC based).

I made the exact same point two years ago when Turbopack came up with a similar benchmark: https://github.com/yyx990803/vite-vs-next-turbo-hmr/discussi...

The point is if we want to compare bundler performance, we should keep all the non-architectural variables consistent across all implementations. Otherwise we are not comparing apples to apples.

PR submitted to update the benchmark: https://github.com/farm-fe/performance-compare/pull/11

A WeChat link under "community".

Without wanting to make this specifically anti-chinese, I really wonder whether that makes it better or worse than only having the Discord link.

I find Discord as a community platform already quite questionable. Now add to that the simple fact of fragmenting your community into two... I'm not convinced.

I’ll have to look at this over the weekend. I’m very excited to see improvements in dev UX in the JS ecosystem. I’d have a very hard time adopting this in prod tho, being so new.

Are any large projects using it? Corporation sponsors?

For the current farm, in order to be more compatible with the front-end ecosystem, we have chosen to be compatible with the vite hook and options. But in fact, the biggest performance problem lies in the communication problem between js and rust. For example, if a vite plug-in uses a hook to obtain the entire resource pot, the entire communication will consume more than 10 times the time, so the future path of farm should be if we Avoid these problems and create farm rust plugins

I would love to use it as a test but there is too much of a commitment in that it is not a drop in replacement for vite nor is there anything in the way of a doc or help for "migrate from vite to farm".

I stopped at "create" - I rather "install and convert" in a branch to try stuff out.

Where does money come from in Farm Inc.?

> This page crashed. > > Error creating WebGL context.

I'm sorry, but WebGL probably shouldnt be a requirement for your front page to display any content at all. I disable it for privacy hardening and switch browsers to opt-in. Additionally, low-power clients may struggle with rendering and sink battery in mobile devices.

The docs work fine, if anyone else runs into this and wants to read about the project.

https://www.farmfe.org/docs/why-farm

Is it like a drop in replacement? I’m working with a semi-legacy codebase that takes over a minute to compile and copy with YALC, so if this can squash that time to something more reasonable I’ll be extremely happy.

The scrolling is jumping around like crazy on iOS

Do I need a different npm package for this on ARM Macs vs my colleagues on Windows boxes?

Can someone with expertise in frontend development help me understand the proliferation of similar tools in the field?

What specific optimizations do these tools offer that others can't, and why can't the slower tools simply adopt these optimizations in future updates?

Is this a result of a lack of consensus within the community, leading to the creation of new forked tools, or is there a larger strategic context that I'm missing?

Is it copyrighted to a fake company? I'm not seeing a "Farm, Inc" in EDGAR search.

Any tool that wants to replace esbuild for me will have to write as good, or better, release notes. The cost of broken tooling and bad change logs (in other words, bad versions) are many orders of magnitude more expensive than the cost of staying on esbuild.

It looks promising, just a side a note: pink on white background was really hard to read, especially on phone screens.

idk if its just me but their website is falling apart on mobile

I would rather have V8 JIT improvements and code caches, than the whole RIIR.

Maybe instead of using nodejs, use Go, Spring, Quarkus, Micronaut, ASP.NET, Axiom...