[HN Gopher] Fastest Front End Tooling for Humans and AI
___________________________________________________________________
Fastest Front End Tooling for Humans and AI
Author : cpojer
Score : 97 points
Date : 2026-02-18 11:51 UTC (11 hours ago)
(HTM) web link (cpojer.net)
(TXT) w3m dump (cpojer.net)
| EvgheniDem wrote:
| The 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 wrote:
| 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.
| simonbw wrote:
| 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.
| sublinear wrote:
| I'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 wrote:
| It's about raw performance. The tools mentioned mostly optimize
| for fast parsing, fast compilation/transpilation, etc.
| fsmedberg wrote:
| I'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 wrote:
| Bun can replace vite?
| netghost wrote:
| Bun 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.
| yurishimo wrote:
| IMO 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
| squidsoup wrote:
| Worth mentioning that both oxfmt/oxc are in alpha. I would
| put money on them replacing prettier and eslint, but they're
| not ready for production yet.
| kevinfiol wrote:
| It's been a while since I've tried it, but post-1.0 release of
| Bun still seemed like beta software and I would get all sorts
| of hard to understand errors while building a simple CRUD app.
| My impression from the project is the maintainers were adding
| so many features that they were spread too thin. Hopefully it's
| a little more stable now.
| dcre wrote:
| Bun and Vite are not really analogous. Bun includes features
| that overlap with Vite but Vite does a lot more. (It goes
| without saying that Bun also does things Vite doesn't do
| because Bun is a whole JS runtime.)
| conartist6 wrote:
| It'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 wrote:
| > 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 wrote:
| In retrospect, the tolerance for excess complexity in the
| JS/npm/yarn/web framework ecosystem was an important
| precursor to the wanton overconsumption of today's LLM
| ecosystem.
| CodingJeebus wrote:
| > 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 wrote:
| Yes, 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).
| cod1r wrote:
| It's definitely an explosion of complexity but also something
| that AI can help manage. So :shrug: ...
|
| Based on current trends, I don't think people care about
| knowing how all the parts work (even before these powerful LLMs
| came along) as long as the job gets done and things get shipped
| and it mostly works.
| dfabulich wrote:
| 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...?
| conartist6 wrote:
| 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.
| notnullorvoid wrote:
| Yeah it's a shame that few people realize running 3 (or
| more) different programs that have separate parsing and AST
| is the bigger problem.
| conartist6 wrote:
| Not just because of perf (though the perf aspect is
| annoying) but because of how often the three will get out
| of sync and produce bizarre results
| nicoburns wrote:
| Hasn't that already been tried (10+ years ago) with
| projects like https://github.com/jquery/esprima ? Which
| have since seen usage dramatically reduced for performance
| reasons.
| 9dev wrote:
| You can rip fast builds from my cold, dead hands. I'm not
| looking back to JS-only tooling, and I was there since the
| gulp days.
| dcre wrote:
| I look at it and don't really have an issue with it. I have
| been using tsc, vite, eslint, and prettier for years. I am in
| the process of switching my projects to tsgo (which will soon
| be tsc anyway), oxlint, and oxfmt. It's not a big deal and it's
| well worth the 10x speed increase. It would be nice if there
| was one toolchain to rule them all, but that is just not the
| world we live in.
| TheAlexLichter wrote:
| The good part is that the new tools _do_ replace the old ones,
| while being compatible. The pattern is:
|
| * Rolldown is compatible to Rollup's API and can use most
| Rollup plugins * Oxlint supports JS plugins and is ESLint
| compatibel (can run ESLint rules easily) * Oxfmt plans to
| support Prettier plugins, in turn using the power of the
| ecosystem * and so on...
|
| So you get better performance and can _still_ work with your
| favorite plugins and extend tools "as before".
|
| Regarding the "mix of technology" or tooling fatigue: I get
| that. We have to install a lot of tools, even for a simple
| application. This is where Vite+[0] will shine, bringing the
| modern and powerful tools together, making them even easier to
| adopt and reducing the divide in the ecosystem.
|
| [0] https://viteplus.dev/
| lelandfe wrote:
| e: ahhh frick this is just stupid AI spam for this dude's
| project.
|
| Supports... some ESLint rules. It is not "easy" to add
| support to Oxlint for the rules it does not.
|
| The projects at my work that "switched" to it now use both
| Eslint and Oxlint. It sucks, but at least a subset of errors
| are caught much faster.
| dejli wrote:
| It looks more functional i like it.
| gaoshan wrote:
| This 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 wrote:
| > 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 wrote:
| It seems like all you have to do is paste 2-3 prompts
| austin-cheney wrote:
| Any 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 wrote:
| 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.
| austin-cheney wrote:
| 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 if a large group of developers cannot
| function without React their perception of "shitting on their
| work" will be less objective.
| johnfn wrote:
| 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.
| austin-cheney wrote:
| 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_re
| vision)
|
| See also cognitive complexity: https://en.wikipedia.org/w
| iki/Cognitive_complexity#In_psycho...
| agos wrote:
| Insinuating the person you're discussing with has a
| psychological problem is also not a great way to win
| minds
| austin-cheney wrote:
| I did no such thing. That you see such is an example of
| front end developers seeing everything through
| emotionally tinted glasses. If you want to talk numbers
| we can talk numbers, but it doesn't matter if the first
| matter is whether or your not the numbers offend you.
| simonw wrote:
| 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.
| philipwhiuk wrote:
| Live-form validation? Auto-complete? Any of these ringing a
| bell?
|
| It's almost like there are genuine UX improvements being
| done
| bingobongodev wrote:
| You can omit tsc with :
| https://oxc.rs/docs/guide/usage/linter/type-aware.html#type-...,
| so one less script to run in paralell
| _pdp_ wrote:
| This is a good list. Bookmarked.
| the_harpia_io wrote:
| the ecosystem fragmentation thing hit me pretty hard when i was
| trying to set up a consistent linting workflow across a mono-repo
| last year. half the team already using biome, half still on
| eslint+prettier, and adding any shared tooling meant either
| duplicating config or just picking a side and upsetting someone
|
| i get why the rust/go tools exist - the perf gains are
| measurable. but the cognitive overhead is real. new engineer
| joins, they now need 3 different mental models just to make a PR.
| not sure AI helps here either honestly, it just makes it easier
| to copy-paste configs you don't fully understand
| sunaookami wrote:
| Oxfmt!? I just switched from ESLint and Prettier to Biome!
| nimonian wrote:
| I really liked biome but it kept murdering my .vue files
| h4ch1 wrote:
| dprint 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.
| insin wrote:
| Any 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 wrote:
| get rid of both Oxfmt and Oxlint and use biome OP
| elxr wrote:
| For what reason?
| loevborg wrote:
| what are the pros and cons of oxlint vs biome?
| Exoristos wrote:
| All 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.
| squidsoup wrote:
| On a large codebase, eslint is quite slow.
| agos wrote:
| ESLint on medium/big projects can be pretty slow and if you use
| type aware rules it opts out of caching
| e10jc wrote:
| Very 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 wrote:
| One nitpick is Claude Code on the web does not do linting by
| default, so you need to run lint for its changes manually.
| fullstackchris wrote:
| anyone have any insight as to why microsoft chose go? I feel like
| with rust it could have been even faster!
| steveklabnik wrote:
| They 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 wrote:
| Kinda 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 wrote:
| I like tsx for this, and it's actively maintained. The author
| may not know about it. https://github.com/privatenumber/tsx
___________________________________________________________________
(page generated 2026-02-18 23:01 UTC)