Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fastest Front End Tooling for Humans and AI

cpojer.net

Post reply on HN
Print view View original

61–70 of 99 posts

Re: Fastest Front End Tooling for Humans and AI

#61

Post by 9dev »

conartist6 wrote: post #36
dfabulich wrote: post #33

Earlier quoted context omitted.

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.

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.

Re: Fastest Front End Tooling for Humans and AI

#62

Post by philipwhiuk »

simonw wrote: post #37
codingdave wrote: post #16

Earlier quoted context omitted.

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.

Live-form validation? Auto-complete? Any of these ringing a bell?

It's almost like there are genuine UX improvements being done

Re: Fastest Front End Tooling for Humans and AI

#64

Post by philipwhiuk »

Can'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 )

Re: Fastest Front End Tooling for Humans and AI

#65

Post by philipwhiuk »

dcre wrote: post #56
conartist6 wrote: post #6

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…

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.

How do you plan to track CVEs flagged on tsgo's native dependencies.

Re: Fastest Front End Tooling for Humans and AI

#66

Post by conartist6 »

nicoburns wrote: post #60
conartist6 wrote: post #36

Earlier quoted context omitted.

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.

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.

Yeah, you are correct. But that means I have the benefit of ten years development in the web platform, as well as having hindsight on the earlier effort.

I would say the reason the perf costs feel bad there is that the abstraction was unsuccessful. Throughtput isn't all that big a deal for a parser at all if you only need to parse the parts of the code that have actually changed

Re: Fastest Front End Tooling for Humans and AI

#68

Post by EvgheniDem »

takeaura25 wrote: post #3
EvgheniDem wrote: post #2

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…

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.

Exactly 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?

Re: Fastest Front End Tooling for Humans and AI

#69

Post by EvgheniDem »

simonbw wrote: post #34
takeaura25 wrote: post #3

Earlier quoted context omitted.

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.

Not 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.

Re: Fastest Front End Tooling for Humans and AI

#70

Post by conartist6 »

9dev wrote: post #61
conartist6 wrote: post #36

Earlier quoted context omitted.

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.

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.

All I can say for sure is that the reason the old tools were slow was not that the JS runtime is impossible to build fast tools with.

And anyway, these new tools tend to have a "perf cliff" where you get all the speed of the new tool as long as you stay away from the JS integration API sued to support the "long tail" of uses cases. Once you fall off the cliff though, you're back to the old slow-JS cost regime...

Post reply on HN