12 ms·
Farm: Fast vite compatible build tool written in Rust
- pjmlp 2y agoI 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...
- deleted 2y ago[deleted]
- GiorgioG 2y ago[flagged]
- Yiin 2y agocare to elaborate?
- SOLAR_FIELDS 2y agoIm not OP but they are probably referring to the endless cycle of build tooling produced in the JS/TS ecosystem. Due to a multitude of reasons, the ecosystem produces a lot more tools in a much faster lifecycle than many other languages.
- xpe 2y agoJavaScript be crazy. So much success. So much pain. Tools. Tools. More tools, please.
- throwAGIway 2y agoPain? Every new tool brought less pain and more performance to me... Lately it's just a "npm install" and I'm migrated, no configuration needed.
- xpe 2y agoI'm talking about the pain at any point in time, p(t), over the long and complicated history of JavaScript. It looks like you are talking about the derivative of pain over time: dp/dt.
- throwAGIway 2y agoWell my pain got very significantly lower when I started to use React instead of jQuery and Ext.js, and then even lower with TypeScript. Since then the pain has been so low I ditched C# and switched to TS full-stack. Nothing I tried since then proved less painful. It's not as good as it was in the Delphi days but that's because of many different target platforms and device form factors, than the technology itself.
- xpe 2y agoI think we have much in common. Yes, I remember ExtJS. But not Delphi. Yes, I remember the innovation of React and how it was a huge step forward relative to jQuery. Roughly ten years ago, I used Clojure often, so I got to see the emergence of Om, then Reagent, and more. Somewhere along that time I saw Elm. Now, I see the innovation of Dioxus in the Rust + WebAssembly world. These developments were/are impressive. Part of fully appreciating them means embracing what they do better than JavaScript -- and many of these differences are incompatible with JavaScript's evolution. In a word, these other technologies are better largely because they have found a way to "break free". If I were to try to "make a point" it would be probably be this: JavaScript, at any point in time, has been both useful and painful. Along the way, it has evolved remarkably well. The pain has lessened. With the birth of TypeScript, the experience is even more improved. But nevertheless, even with all the improvements, in some ways we're still paying down the "tech debt" rooted in some early decisions. Some of the pain isn't necessarily around fundamental tech debt as much as community splintering. For example, I have a hunch, though I'm not an expert, that the Tower of Babel of JS tooling (such as bundling systems) may be resolved at some point. But I don't think this is likely until something else happens... I look forward to a future where WebAssembly affords a direct, first-class, interface to the browser and DOM that provides high-quality, zero-cost abstractions. As great as WebAssembly is, there is still a considerable kludge in terms of how data is moved around at the interface between JS and WebAssembly. When this happens, it will arguably be a tremendous achievement -- to decouple web applications from the unnecessary constraints of JavaScript's historical choices. I have a hope/prediction that stronger "competition" at the level of interfacing between the browser and the choice of language will spur better thinking and tooling. This gives me hope that the complexity of TS compilation + JS bundlers can give way to some elegant tooling, more along the lines of what the Rust community has achieved with Cargo.
- dgoldstein0 2y agoHello Battlestar Galactica fan
- deleted 2y ago[deleted]
- phildenhoff 2y agoI’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?
- throw156754228 2y agoDo I need a different npm package for this on ARM Macs vs my colleagues on Windows boxes?
- nailer 2y agoNo, npm packages usually ship with binaries for multiple platforms. Some of them will try and build something dynamically as well.
- throw156754228 2y agoSo the npm package lock file will be the same on all platforms?
- wayvey 2y agoYes
- hassannawaz 2y agoidk if its just me but their website is falling apart on mobile
- aniforprez 2y agoDidn't seem too bad. The header and some buttons on the main page are misaligned but the docs seem fine
- ethagnawl 2y agoI had the same experience. The page was jumping around and made it very difficult to read individual sections/bullets. I know it's tangential but it's not a great look for a FE tool.
- codetrotter 2y agoYep. Same for me. Was scrolling trying to read and it makes a big jump on its own for no reason. That’s a bad look in any case, and especially so when it’s the website for an FE tool. Using Safari on iOS.
- deleted 2y ago[deleted]
- the_duke 2y agoSo, 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?
- emmanueloga_ 2y agoDon't forget Bun (*) ... [1]. Bun's bundler is appealing since Bun packages a bunch of other tools you already need (test runner, runtime, fast npm replacement). Bun + Biome covers everything you need for a TS project (Biome lints and formats). -- * : I guess it is not written in Rust but still in the same category of tools. 1: https://bun.sh/docs/bundler https://bun.sh/docs/bundler
- noahtallen 2y agoAnd Deno! Which also has compilation tools and is written partly in Rust.
- emmanueloga_ 2y agoTrue, although it seems they deprecated their bundle command and even recommend using esbuild or rollup [1] (or an "unstable" module deno_emit). -- 1: https://docs.deno.com/runtime/manual/tools/bundler https://docs.deno.com/runtime/manual/tools/bundler
- brabel 2y agoYep that was a bummer for me, I was trying to start a little project where I wanted a bundler lib and started using Deno's... but quickly ran into some limitations and found out they've deprecated it and it's not even maintained anymore :( . I started using esbuild instead via its Typescript lib, but then noticed I was spending a lot of time working around the problems with the JS ecosystem (terrible file system watcher in node.js, lots of underpar libraries and as someone not intimate with every domain, it's nearly impossible to know which library may be well written and maintained without spending lots of time investigating, weird APIs, silent errors, I just can't believe some people can cope with all of this instead of just moving to a saner language).... and as esbuild is written in Go, I rewrote my code in Go and now it's much, much nicer to work on, much faster, can be shipped as a single binary etc. If there was a bundler written in Rust I might have chosen that, as despite not having anything against Go, the momentum seems to be strongly shifting to Rust (and even in the little Go I did, I already feel the pain of its error handling), and Rust definitely gives you better tools to write reliably applications.
- ccorcos 2y agoWhy aren’t we comparing to ESBuild?
- graypegg 2y agoVite uses ESBuild under the hood. https://github.com/farm-fe/performance-compare?tab=readme-ov-file#performance-compare https://github.com/farm-fe/performance-compare?tab=readme-ov... The production build metric here would be ESBuild + a small amount of overhead from vite. (The HMR/dev build side of things is handled by Rollup instead with Vite) IMO, Vite (ESBuild/Rollup) are fast enough. Farm will need to get some time being used + abused by OTHER people's real projects before I'll be considering it in order to save what seems like maybe 2 minutes a day.
- oefrha 2y ago> The production build metric here would be ESBuild + a small amount of overhead from vite. (The HMR/dev build side of things is handled by Rollup instead with Vite) That’s completely backwards. Vite only uses rollup for production, which is why production build is slower. https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuild https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuil... The plan is to replace both esbuild and rollup with Rust-based rolldown (fast, and supports rollup’s plugin architecture) eventually. See https://www.youtube.com/watch?v=hrdwQHoAp0M https://www.youtube.com/watch?v=hrdwQHoAp0M.
- evantbyrne 2y agoIs it copyrighted to a fake company? I'm not seeing a "Farm, Inc" in EDGAR search.
- m00x 2y agoNot every company is american
- codetrotter 2y agoThe main website is referring to two languages, English and Chinese. They have a WeChat group, and a QQ address. So I’m going to assume they are based in China. This Wikipedia article https://en.wikipedia.org/wiki/Incorporation_(business) https://en.wikipedia.org/wiki/Incorporation_(business) has a list of abbreviations used for incorporated businesses. For example in Norway we use “AS” (Aksjeselskap). In Germany GmbH (“Gesellschaft mit beschränkter Haftung”, limited liability company), and AG ("Aktiengesellschaft", business association with shares), are the most similar to the corporations in the US. In the UK they have a bunch of different ones. China uses WFOE (or WOFE), to refer to a Wholly Foreign Owned Enterprise (WFOE). This is the most popular form of business entity for foreign investors wanting to set up a company in China; it is a limited liability company. The article doesn’t mention what Chinese owned companies in China use as abbreviation. In fact, on the whole list as far as I can see it seems that only three countries use the abbreviation “Inc”: USA, Canada, and the Philippines. The article as a whole only mentions a few countries though, so I had a look elsewhere as well. Another website talks specifically about Chinese company structures. https://learn.sayari.com/understanding-chinese-corporate-structures/ https://learn.sayari.com/understanding-chinese-corporate-str... > In China, the limited liability company (LLC; in Chinese, 有限责任公司 or 有限公司) structure is generally for smaller and less restricted companies. Chinese LLCs may not have more than 50 shareholders > company limited by shares (股份有限公司 or 股份公司) structure is generally used by larger companies, including publicly traded companies (which must be companies limited by shares) > One-Person Limited Liability Company (一人有限责任公司) This type of corporation has similar rights and responsibilities to a standard LLC, but may only be established by a natural person. And quite a few different ones in addition to those, but none using “Inc” as abbreviation. Back to the topic of countries where Inc is used. 1. United States: The most prominent user of "Inc." for incorporated entities. 2. Canada: "Inc." is commonly used alongside "Ltd." (Limited). 3. Philippines: Companies frequently use "Inc." to indicate incorporation. 4. Australia: Although "Pty Ltd" (Proprietary Limited) is more common, "Inc." can also be used for non-profit organizations. 5. New Zealand: Similar to Australia, "Inc." is used for non-profit entities. 6. Japan: The term "Kabushiki Kaisha" (K.K.) is the standard, but "Inc." is sometimes seen in international contexts. 7. South Korea: The term "주식회사" (Jusikhoesa) is typical, but "Inc." is occasionally used for international recognition. 8. Taiwan: Companies might use "Inc." in English contexts, though the local term is "有限公司" (Youxian Gongsi). These countries utilize "Inc." to denote an incorporated company, often within international business contexts. Anyway. If they really are an incorporated company I think it would be helpful to mention what country they are incorporated in, and provide some kind of registration number that you can use for looking up details about the company. And conversely, if they are not an actual incorporated business then don’t pretend to be.
- ram_rar 2y agoCan 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?
- aaaaaaabbbbbb 2y agoI have recently written a broader exposition on frontend build tooling, perhaps it will be useful: https://sunsetglow.net/posts/frontend-build-systems.html https://sunsetglow.net/posts/frontend-build-systems.html. The performance gains in the recent past have mostly been due to moving away from single-threaded JavaScript to multi-threaded compiled languages. This requires a complete rewrite, so existing tools rarely take this step. We see this optimization in Farm alongside "partial bundling," which strikes a performance-optimal balance between full bundling (Webpack) and no bundling (Vite) in development. Vite abstracts over a preconfigured set of "lower-level" frontend build tools consisting of a mixture of older single-threaded JavaScript tools and newer multi-threaded compiled language tools. Vite can adopt the partial bundling of Farm, but dispensing with its remaining JavaScript tools is a major breaking update.
- snthpy 2y agoThank you for this. This looks like just what I was looking for!
- snthpy 2y agoBusy reading this and it's great so far. One comment, you've referenced "tree shaking" a few times without explaining what it is. I think I know but it might help others to explain that before your reference it.
- aaaaaaabbbbbb 2y agoThanks for the feedback! I struggled with the ordering since each section is somewhat mutually dependent; this is arranged more like a thematic history than a chronological one. Tree-shaking naturally fits under bundling, and I'm afraid that explaining it earlier will make tree-shaking's explanation itself contextless since without bundling there is nothing to tree shake. I can hyperlink those references to the tree-shaking section tomorrow so that there is an action for the confused.
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- tamimio 2y agoIt looks promising, just a side a note: pink on white background was really hard to read, especially on phone screens.
- deleted 2y ago[deleted]
- Too 2y agoI 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.
- hu3 2y agoIndeed! They probably took the idea from https://esbuild.github.io https://esbuild.github.io
- jensenbox 2y agoI 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.
- geon 2y agohttps://www.farmfe.org/docs/migration/from-vite https://www.farmfe.org/docs/migration/from-vite
- 9dev 2y agoThat’s not too helpful. If the transition is really as easy as they claim, a simple console utility to generate a farm.config.ts from my vite.config.ts would go a long way.
- brightwu 2y agoFarm'll develop a auto migration tool later
- 9dev 2y agoIm sure they will, it’s kind of a low hanging fruit. But with the fast pace the JS ecosystem has, network effects are key. So if they want to amass users quickly, making it as easy as possible to switch over could decide whether they can gain enough market share to stay relevant.
- kitsune_ 2y ago[flagged]
- deleted 2y ago[deleted]
- techpression 2y agoAny 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.
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- mirekrusin 2y agoWhere does money come from in Farm Inc.?
- antihero 2y agoIs 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.
- TikolaNesla 2y agoI 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.
- klabb3 2y agoAnother way to view it: slow builds is a poor man’s feature, that punishes you for bringing in too many deps. The JS ecosystem (speaking as an omnivore using many languages) suffers two big problems: 1. Tooling is too fragmented and complex and poorly designed. This includes even the standard tools and formats like npm and package.json. 2. There’s a weak culture of API stability. Leave a project for 3 months and there are new config files, plugin formats, etc. It’s improving slowly through standardization with things like ES modules. But it’s still a Wild West.
- skydhash 2y agoThat's my main gripe about JS ecosystem. Most of the times, I only need to compile a project (either live or as a static asset). You run "npm install" and the build tool (without any project dependencies) already come with 200 folders inside node_modules. And those byte-sized libraries! It always feels like an hackathon scene.
- 1oooqooq 2y agoit is. just because you pushed a hack to prodb doesn't mean it stops being a hack. but that's all that younger devs know. specially people from boot camps or the CS to startup pipeline.
- throwAGIway 2y agoI tried building a Rust project and it failed because it consumed my entire remaining 8 GB of disk space... Good old NPM. I tried running a Python project and the necessary apt-get pulled 2 GB of dependencies and conflicted with some of software I use, that's before running the pip install... Good old NPM.
- wiseowise 2y ago[flagged]
- mirekrusin 2y agoYour comment could be rephrased as: fn main() { println!("I really dislike trend of “written in X” in a headline. What difference does it make if a build tool is written in X? If X entails “fast, takes small amount of resources and reliable” - then just say so."); }
- Alifatisk 2y agoYour comment did not contribute with anything new, you just wrote what the comment above said in some code.
- handwarmers 2y agoThis thread sums up most reactions to "X, written in Rust" articles in recent times.
- pornel 2y agoLanguages have more characteristics than what can be reasonably included in a headline. "Fast to run, but slow to compile and needs very new compiler, and may have a big-ish executable, but OTOH it won't cause much problems with installation of dependencies - vite compatible build tool"
- wiseowise 2y agoNot sure what you’re implying. I’m an end user of a product, I couldn’t care less what time it takes to compile the final binary. Or this thing exists to attract enthusiastic Rust devs to contribute to the project?
- whstl 2y ago"Written in Rust" is often a shorthand for "having performance as a goal" when the tool is new and the target audience is mostly technical and made of early adopters, or people willing to try or contribute to new things. Perhaps you're not the target audience at the current time.
- FireInsight 2y ago> 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 https://www.farmfe.org/docs/why-farm
- chuckadams 2y agoMinus the bar charts, the site works fine with JS disabled. If WebGL takes the whole page with it when it crashes, that's kind of on the browser to fix. Having a hard time even seeing what WebGL is used for on that page though: there's a canvas tag in the menubar, but it doesn't seem to be used for anything.
- koito17 2y ago> If WebGL takes the whole page with it when it crashes, that's kind of on the browser to fix. On the contrary, it's on the Farm team to fix. It seems their front page has only one error boundary, which is why the chart component crashing takes the whole page down. This is fixed by simply wrapping the chart component in its own error boundary. That way React doesn't unmount practically the whole page when that component throws an error.
- chuckadams 2y agoOh, I thought you were talking about the actual browser process crashing. But seriously, are you saying that in React, a child component that throws an error during render will kill the parent's render too? That's wacky. I do Vue for a living, which doesn't behave anything like that. But anyway, the chart looks like regular DOM to me. The canvas is actually in the top navbar, but I don't see anything drawn on it.
- FireInsight 2y ago
- dangoodmanUT 2y agoThe scrolling is jumping around like crazy on iOS
- serial_dev 2y agoSome of the content is also unreachable on Android.
- 9dev 2y agoSo, 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.
- threecheese 2y agoA halving of build time, for even a medium volume project, could be a big cost reduction. If those builds were much longer than 30sec, compounding through a CI pipeline with many changes, leads to much shorter cycle times, faster time to prod, faster to find and fix defects, which translates to much more than just infra cost reduction benefits. I created a visualization once, of the release pipeline for a big project, showing the feedback loops that exist and the compounding effects of small improvements like that. It was eye opening for me, and everybody.
- kamikaz1k 2y agoBuild time isn’t the only benefit, but consider that the author is from ByteDance and how large their projects are. Another important callout is how in Vite, native ESM modules are used in dev which makes it very slow for large apps with thousands of modules. So cold start of dev can be important too. In practice HMR is mostly what you need and Vite has it covered. But slow tends to accumulate slow.
- c-hendricks 2y agoI kinda prefer how vite handles things in dev by not bundling files. I work remote to my server, and I'd much rather download the few changed files vs a multi-deca-megabyte file.
- deleted 2y ago[deleted]
- 2y ago
- solatic 2y agoSerious 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?
- castalian 2y agoYou can't trust "western" open source projects as well. It wouldn't be hard to just not mention China anywhere on the website or the sources so that most people would never know.
- imp0cat 2y agoWell this one specifically is listed under a fake company name which raises further questions. Is this just another attempt to conceal chinese spyware? See the discussion at https://news.ycombinator.com/item?id=40756408 https://news.ycombinator.com/item?id=40756408
- kveykva 2y agoTheir code base is also weirdly convoluted, with many crates and files just proxying over to others. I've read and written a lot rust, and haven't seen this style really. Could be nothing but its odd.
- phero_cnstrcts 2y agoI would consider western and non western equally bad.
- k4rli 2y agoThat's what the Chinese would say. West doesn't need to insert vulnerabilities for the basic stuff since they can already front/backdoor with GCP/AWS/alike.
- black_puppydog 2y agoA 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.
- erkelost 2y agoFor 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
- EvanYou 2y agoNote 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/discussions/8 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 https://github.com/farm-fe/performance-compare/pull/11