9 ms·
Fastest Front End Tooling for Humans and AI
- sunaookami 7mo agoOxfmt!? I just switched from ESLint and Prettier to Biome!
- nimonian 7mo agoI really liked biome but it kept murdering my .vue files
- h4ch1 7mo agodprint ftw, works very well with Svelte as far as I've seen. Biome and oxc* never worked properly with Svelte, but I haven't tried them since the past 9 or so months when I switched to dprint from prettier.
- sibeliuss 7mo agoBiome missed the bus by not getting mixed language formatting in soon enough. Oxfmt got it, and then won.
- kevlened 7mo ago> Oxfmt got it, and then won. This doesn't align with the data. - 650k npm downloads for oxfmt this week [0] - 4.3m npm downloads for biome this week [1] - 19.1k gh stars for oxfmt [2] - 23.7k gh stars for biome [3] - gap widening in favor of biome [4] [0] https://www.npmjs.com/package/oxfmt [1] https://www.npmjs.com/package/@biomejs/biome [2] https://github.com/oxc-project/oxc [3] https://github.com/biomejs/biome [4] https://www.star-history.com/#oxc-project/oxc&biomejs/biome&type=date&legend=top-left
- EvgheniDem 7mo agoThe bit about strict guardrails helping LLMs write better code matches what we have been seeing. We ran the same task in loose vs strict lint configurations and the output quality difference was noticeable. What was surprising is that it wasn't just about catching errors after generation. The model seemed to anticipate the constraints and generated cleaner code from the start. My working theory is that strict, typed configs give the model a cleaner context to reason from, almost like telling it what good code looks like before it starts. The piece I still haven't solved: even with perfect guardrails per file, models frequently lose track of cross-file invariants. You can have every individual component lint-clean and still end up with a codebase that silently breaks when components interact. That seems like the next layer of the problem.
- takeaura25 7mo agoWe've been building our frontend with AI assistance and the bottleneck has shifted from writing code to reviewing it. Faster tooling helps, but I wonder if the next big gain is in tighter feedback loops — seeing your changes live as the AI generates them, rather than waiting for a full build cycle.
- simonbw 7mo agoAre your frontend builds actually so slow that you're not seeing them live? I've gotten used to most frontend builds being single digit seconds or less for what feels like a decade now.
- EvgheniDem 7mo agoNot build speed, the human review cycle. When the AI generates a component, I still need to read through it manually to make sure it does what I intended, handles edge cases, and fits the existing patterns. That takes 8-12 minutes per component regardless of how fast the build is. The slow part is not the computer. It is me reading AI-generated code line by line before I trust it enough to ship.
- EvgheniDem 7mo agoExactly this. And what makes it compound is that you can not build muscle memory for patterns you have already reviewed. Same prompt, different output every time, so every generation is a fresh read even if you have seen similar code before. The feedback loop angle is interesting. Real-time linting during generation rather than after could help catch issues earlier, but I think the deeper problem is the non-determinism. Even with instant feedback, if the output changes on each run you are still starting from scratch each time. Have you found anything that actually reduces the review time per component, or is it mostly about finding issues faster?
- newzino 7mo ago[flagged]
- sublinear 7mo agoI'm confused by this, but also curious what we mean by "fastest". In my experience, the bottleneck has always been backend dev and testing. I was hoping "tooling" meant faster testing, not yet another layer of frontend dev. Frontend dev is pretty fast even when done completely by hand for the last decade or so. I have and have also seen others livecode on 15 minute calls with stakeholders or QA to mock some UI or debug. I've seen people deliver the final results from that meeting just a couple of hours later. I say this as in, that's what's going to prod minus some very specific edge case bugs that might even get argued away and never fixed. Not trying to be defensive of pure human coding skills, but sometimes I wonder if we've rolled back expectations in the past few years. All this recent stuff seems even more complicated and more error prone, and frontend is already those things.
- whstl 7mo agoIt's about raw performance. The tools mentioned mostly optimize for fast parsing, fast compilation/transpilation, etc.
- fsmedberg 7mo agoI'm very surprised the article doesn't mention Bun. Bun is significantly faster than Vite & Rolldown, if it's simply speed one is aiming for. More importantly Bun allows for simplicity. Install Bun, you get Bundler included and TypeScript just works, and it's blazing fast.
- canadiantim 7mo agoBun can replace vite?
- netghost 7mo agoBun ships with lots of tools built in. It has support for bundling js, html, etc for the browser. I suspect that if you want the best results or to hit all the edge cases you'd still want vite, but bun probably covers most needs.
- TheAlexLichter 7mo agoNot really.
- yurishimo 7mo agoIMO Bun and Vite are best suited for slightly different things. Not to say that there isn't a lot of overlap, but if you don't need many of the features Bun provides, it can be a bit overkill. Personally, I write a lot of Vue, so using a "first party" environment has a lot of advantages for me. Perhaps if you are a React developer, the swap might be even more straightforward. I also think it's important to take into consideration the other two packages mentioned in this post (oxlint & oxfmt) because they are first class citizens in Vite (and soon to be Vite+). Bun might be a _technically_ faster dev server, but if your other tools are still slow, that might be a moot point. Also, Typescript also "just works" in Vite as well. I have a project on work that is using `.ts` files without even an `tsconfig` file in the project. https://vite.dev/guide/features#typescript https://vite.dev/guide/features#typescript
- squidsoup 7mo ago
- conartist6 7mo agoIt's funny to me that people should look at this situation and say "this is OK". The upshot of all these projects to make JS tools faster is a fractured ecosystem. Who if given the choice would honestly want to try to maintain Javascript tools written in a mixture of Rust and Go? Already we've seemingly committed to having a big schism in the middle. And the new tools don't replace the old ones, so to own your tools you'll need to make Rust, Go, and JS all work together using a mix of clean modern technology and shims into horribly legacy technology. We have to maintain everything, old and new, because it's all still critical, engineers have to learn everything, old and new, because it's all still critical. All I really see is an explosion of complexity.
- riskable 7mo ago> All I really see is an explosion of complexity. I thought this was the point of all development in the JavaScript/web ecosystem?
- co_king_5 7mo ago[dead]
- CodingJeebus 7mo ago> We have to maintain everything, old and new, because it's all still critical, engineers have to learn everything, old and new, because it's all still critical. I completely agree but maintenance is a maintainer problem, not the consumer or user of the package, at least according to the average user of open source nowadays. One of two things are come out of this: either the wheels start falling off once the community can no longer maintain this fractured tooling as you point out, or companies are going to pick up the slack and start stewarding it (likely looking for opportunities to capture tooling and profit along the way). Neither outcome looks particularly appealing.
- NewsaHackO 7mo agoYes, this just sounds like the run-of-the-mill specialization issue that is affecting every industry (and has been affecting every industry before AI). Web devs learn Javascript/Typescript/frameworks, "middleware" developers learn Rust/Go/C++/etc. to build the web development frameworks, lower-level devs build that, etc. There shouldn’t be a strict need for someone who wants to make websites or web technology to learn Rust or Go unless they want to break into web framework development or WASM stuff. But again, this is just over-specialization that has been happening since forever (or at least since the Industrial revolution).
- dejli 7mo agoIt looks more functional i like it.
- deleted 7mo ago[deleted]
- gaoshan 7mo agoThis smells of "I like to solve puzzles and fiddle with things" and reminds of hours spent satisfyingly tweaking my very specific and custom setups for various things technical. I, too, like to fiddle with optimizations and tool configuration puzzles but I need to get things done and get them done now. It doesn't seem fast, it seems cumbersome and inconsistent.
- ssgodderidge 7mo ago> It doesn't seem fast, it seems cumbersome and inconsistent I think the point of this project is to provide an opinionated set of templates aimed at shipping instead of tinkering, right? "Don't tinker with the backend frameworks, just use this and focus on building the business logic."
- conradkay 7mo agoIt seems like all you have to do is paste 2-3 prompts
- austin-cheney 7mo agoAny method for front end tooling is potentially the fastest. It always comes to what you measure and how you measure it. If you don't have any measures at all then your favorite method is always the fastest no matter what, because you live in a world without evidence. Even after consideration of measurements radical performance improvements are most typically the result of the code's organization and techniques employed than the language its written in. But, of course, that cannot be validated without evidence from comparison of measurements. The tragic part of all this is that everybody already knows this, but most front end developers do not measure things and may become hostile when measurements do occur that contradict their favorite techniques.
- codingdave 7mo agoI have yet to meet a front-end dev that gets hostile when you show them how their code can be improved. On the contrary, the folks I have worked with are thrilled to improve their craft. Unless of course you are not showing them improvements and are instead just shitting on their work. Yes, people do get hostile to that approach.
- austin-cheney 7mo agoThen you and I are talking to different people. Fortunately, I don't work in JavaScript for employment any more. As a frame of reference just the mere mention that a site could be 50-200x faster by dumping React creates conflicts of interests for impacted developers and the results are typically not immediately welcoming. That isn't shitting on anybody's work, especially if you provide guidance for improvement, but if a large group of developers cannot function without React their perception of "shitting on their work" will be less objective.
- johnfn 7mo agoIt doesn't surprise me that you got a lot of people upset at you. "Dumping React" is not a viable strategy for the large majority of organizations. This would be like saying that you could improve performance by rewriting the backend into Rust.
- bingobongodev 7mo agoYou can omit tsc with : https://oxc.rs/docs/guide/usage/linter/type-aware.html#type-checking-diagnostics https://oxc.rs/docs/guide/usage/linter/type-aware.html#type-..., so one less script to run in paralell
- _pdp_ 7mo agoThis is a good list. Bookmarked.
- the_harpia_io 7mo ago[flagged]
- insin 7mo agoAny plans to create a combined server + web app template using @hono/vite-dev-server for local development, with both sides of auth preconfigured, with the server serving up the built web app in production? I've used this setup for my last few projects and it's so painless, and with recent versions of Node.js which can strip TypeScript types I don't even need a build step for the server code. Edit: oops, I didn't see nkzw-tech/fate-template, which has something like this, but running client and server separately instead
- vivzkestrel 7mo agoget rid of both Oxfmt and Oxlint and use biome OP
- elxr 7mo agoFor what reason?
- vivzkestrel 7mo agobecause it is a single tool that does lint, formatting and checking sort order. you really dont need 3 libraries in its place
- loevborg 7mo agowhat are the pros and cons of oxlint vs biome?
- vivzkestrel 7mo agobiome does the work of all 3 of those libraries for starters
- Exoristos 7mo agoAll y'all need more RAM in your development laptops. Maybe. At least, I've never been bothered by the performance of standard tooling like prettier, ESLint, and npm.
- e10jc 7mo agoVery cool list but why no mention of biome? I’ve been using that on a recent project and it’s been pretty great. Also bun test instead of vitest.
- huksley 7mo agoOne nitpick is Claude Code on the web does not do linting by default, so you need to run lint for its changes manually.
- fullstackchris 7mo agoanyone have any insight as to why microsoft chose go? I feel like with rust it could have been even faster!
- steveklabnik 7mo agoThey said at the time that Go let them keep the overall structure of the code, that is, they weren't trying to do a re-implementation from scratch, more of a port, and so the port was more straightforward with Go.
- Narretz 7mo agoKinda crazy that ts-node is still the recommendation when it hasn't been updated since 2023. And likewise crazy that no other lib has emerged that has typescript compilation and typechecking. Of course if it works, don't fix it, but typescript has evolved quite a bit since 2023.
- dcre 7mo agoI like tsx for this, and it's actively maintained. The author may not know about it. https://github.com/privatenumber/tsx https://github.com/privatenumber/tsx
- TheAlexLichter 7mo agoLove that fact that you don't need anything ts-node/tsx like if you have erasable syntax only. Other than that, there is https://github.com/oxc-project/oxc-node https://github.com/oxc-project/oxc-node too.
- 1necornbuilder 7mo ago[dead]
- philipwhiuk 7mo agoCan't wait for the first crypto-attack on a front-end JS library that's caused by a Go package vuln. God knows how `pnpm audit` will handle Go-module dependencies. (I opened an issue against typescript-go to flag this https://github.com/microsoft/typescript-go/issues/2825 https://github.com/microsoft/typescript-go/issues/2825 )