get rid of both Oxfmt and Oxlint and use biome OP
Fastest Front End Tooling for Humans and AI
31–40 of 99 posts
Re: Fastest Front End Tooling for Humans and AI
#32This 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.
It seems like all you have to do is paste 2-3 prompts
Re: Fastest Front End Tooling for Humans and AI
#33It'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…
So, what's your counterproposal?
Each of these tools provides real value.
* Bundlers drastically improve runtime performance, but it's tricky to figure out what to bundle where and how.
* Linting tools and type-safety checkers detect bugs before they happen, but they can be arbitrarily complex, and benefit from type annotations. (TypeScript won the type-annotation war in the marketplace against other competing type annotations, including Meta's Flow and Google's Closure Compiler.)
* Code formatters automatically ensure consistent formatting.
* Package installers are really important and a hugely complex problem in a performance-sensitive and security-sensitive area. (Managing dependency conflicts/diamonds, caching, platform-specific builds…)
As long as developers benefit from using bundlers, linters, type checkers, code formatters, and package installers, and as long as it's possible to make these tools faster and/or better, someone's going to try.
And here you are, incredulous that anyone thinks this is OK…? Because we should just … not use these tools? Not make them faster? Not improve their DX? Standardize on one and then staunchly refuse to improve it…?
Re: Fastest Front End Tooling for Humans and AI
#34The 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…
We'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.
Are 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.
Re: Fastest Front End Tooling for Humans and AI
#35All 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.
Re: Fastest Front End Tooling for Humans and AI
#36It'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…
So, what's your counterproposal? Each of these tools provides real value. * Bundlers drastically improve runtime performance, but it's tricky to figure out what to bundle where and how. * Linting tools and type-safety checkers detect bugs before they happen, but they can be arbitrarily complex, and benefit from type annotations. (TypeScript won the type-annotation war in the marketplace against other competing type a…
I'm being a little coy because I do have a very detailed proposal.
In want the JS toolchain to stay written in JS but I want to unify the design and architecture of all those tools you mentioned so that they can all use a common syntax tree format and so can share data, e.g. between the linter and the formatter or the bundler and the type checker.
Re: Fastest Front End Tooling for Humans and AI
#37Any 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 emplo…
I 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.
I take it you've never suggested to a front-end dev that maybe their contact form doesn't need a 1MB+ of JavaScript framework and could just be HTML that submits to a backend.
Re: Fastest Front End Tooling for Humans and AI
#38Oxfmt!? I just switched from ESLint and Prettier to Biome!
I really liked biome but it kept murdering my .vue files
Re: Fastest Front End Tooling for Humans and AI
#39Very 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.
Re: Fastest Front End Tooling for Humans and AI
#40Earlier quoted context omitted.
Then 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 i…
It 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.
Perfect example of what I am talking about.
People want faster software... until they are confronted by challenging decisions. JavaScript can be very fast. JavaScript, in the browser, reports a page load of about 0.06 seconds for my large personal SPA and that includes state restoration. That is determined by using: performance.getEntries()[0].duration in the browser.
When conflicts arise people most frequently become emotional and complain about the situation than make any decision towards resolution one way or the other. That is a psychological problem called cognitive conservatism[1]. About the half the time that emotional output is some form of deflection, such as hostility. Cognitive conservatism is only allowed to exist when there is insufficient pressure on the thought leaders to impose a resolution.
Its okay to say you don't really want to be faster.
[1] https://en.wikipedia.org/wiki/Conservatism_(belief_revision)
See also cognitive complexity: https://en.wikipedia.org/wiki/Cognitive_complexity#In_psycho...