Live data from Hacker News

Fastest Front End Tooling for Humans and AI

cpojer.net

91–99 of 99 posts

Re: Fastest Front End Tooling for Humans and AI

#91
post #87

Earlier quoted context omitted.

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

> […] the reason the old tools were slow was not that the JS runtime is impossible to build fast tools with. I don't have them at hand right now but there are various detailed write-ups from the maintainers of Vite, oxc, and more, that are addressing this specific argument to point out that indeed the JavaScript runtime was a hard limitation on the throughput they could achieve, making Rust a necessity to improve bui…

Why do you need high throughput though? Isn't that a metric of how fast a batch processing system is?

Why are we still treating batch processing as the controlling paradigm for tools that work on code. If we fully embraced incremental recomputation and shifted the focus to how to avoid re-doing the same work over and over, batch processing speed would become largely irrelevant as a metric

Re: Fastest Front End Tooling for Humans and AI

#92

Earlier quoted context omitted.

1) This is not what I said, no 2) With AI, languages and syntax matters even less nowadays. 3) There have been a good amount of contributors (e.g. for Oxc) that came out the JS world, so it isn't impossible 4) Realistically, the avg. web dev does not contribute to tooling internals, maximum custom rules or similar. The concepts are a bigger "hurdle" than the lang.

That still leaves you admitting that only a small fraction of the served community can really contribute. You'll need to keep all the best benefits of your work for the Plus users or else there would be no reason to buy Plus and no way to keep paying the few to do all the work for the many. You're stuck telling people what they can't have (and shouldn't want) while I'm now in a position to just give people what they…

> That still leaves you admitting that only a small fraction of the served community can really contribute.

Not really (see above).

> You'll need to keep all the best benefits of your work for the Plus users or else there would be no reason to buy Plus and no way to keep paying the few to do all the work for the many.

No, won't happen that way.

> You're stuck telling people what they can't have (and shouldn't want) while I'm now in a position to just give people what they want.

Didn't see any software of yours yet, only big talk so far sadly! Besides that, VoidZero will also be in a position to just give people what they want

Re: Fastest Front End Tooling for Humans and AI

#93

Earlier quoted context omitted.

Yeah, no. Real human here. Oxlint does support core rules out of the box but has support for JS plugins[0] as mentioned. If you don't rely on a custom parser (so svelte or vue component for example) things just work. Even react compiler rules[1]. [0] https://oxc.rs/docs/guide/usage/linter/js-plugins.html [1] https://github.com/TheAlexLichter/oxlint-react-compiler-rule...

So as long as you only need the pre-installed software it's a great device eh. I'm the PC to your game console here. Parser extension? Piece of cake for us. Heck just to showboat we actually extended our es6 parser from our es3 parser, and then implemented each later standard as an extension of the earlier one. We're able to run parsers for pretty much any programming language, and making them super easy to write. We…

As said in another comment: Curious to see what you are coming up! Talk is cheap

Re: Fastest Front End Tooling for Humans and AI

#94
post #51

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.

Love 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 too.

Re: Fastest Front End Tooling for Humans and AI

#95

Earlier quoted context omitted.

That still leaves you admitting that only a small fraction of the served community can really contribute. You'll need to keep all the best benefits of your work for the Plus users or else there would be no reason to buy Plus and no way to keep paying the few to do all the work for the many. You're stuck telling people what they can't have (and shouldn't want) while I'm now in a position to just give people what they…

> That still leaves you admitting that only a small fraction of the served community can really contribute. Not really (see above). > You'll need to keep all the best benefits of your work for the Plus users or else there would be no reason to buy Plus and no way to keep paying the few to do all the work for the many. No, won't happen that way. > You're stuck telling people what they can't have (and shouldn't want) w…

VoidZero is betting I'm just talk, ok, that's fair. But the way you say it makes me think that your evaluation of me is mostly on hearsay, because if you had actually tried to find out how serious I am I suspect you'd be less flippant. You're welcome in the Discord!

Re: Fastest Front End Tooling for Humans and AI

#96
post #73

Earlier quoted context omitted.

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.

Vite+ is not “this dude’s project”, it’s made by the team that makes all the tools discussed in this article.

[deleted]

Re: Fastest Front End Tooling for Humans and AI

#97

Earlier quoted context omitted.

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.

Yeah, no. Real human here. Oxlint does support core rules out of the box but has support for JS plugins[0] as mentioned. If you don't rely on a custom parser (so svelte or vue component for example) things just work. Even react compiler rules[1]. [0] https://oxc.rs/docs/guide/usage/linter/js-plugins.html [1] https://github.com/TheAlexLichter/oxlint-react-compiler-rule...

Definitely read AI tonality into the earlier comment, noticed it didn't call out your relationship to it, then saw that you had a comment history plugging it, and made assumptions.

My apologies. I'll follow through to the links next time.

Re: Fastest Front End Tooling for Humans and AI

#98

Earlier quoted context omitted.

Live-form validation? Auto-complete? Any of these ringing a bell? It's almost like there are genuine UX improvements being done

You know that pure HTML have it ? and if you need a more complex validation, a few lines of js does the magic. Same if you need live autocomplet.

Good point, HTML with no JavaScript at all has pretty good validation built in now. Try entering an incomplete email address on this demo page: https://tools.simonwillison.net/html-validation-demo

Re: Fastest Front End Tooling for Humans and AI

#99
post #85

Earlier quoted context omitted.

The success of an organization is very rarely dependent solely on website performance. Speed is just one dimension in a vast and multi-dimensional optimization space. Spending time improving performance means you are necessarily not spending time improving one of those other vectors. It is a question of priorities - and suggesting that others who say that other priorities are more important are "emotional" is failing…

Yes. Everything else matters too, but that is still not an excuse to throw away evidence. If you don’t want to be faster it’s okay.

I am not throwing away evidence. I am saying "You are correct that removing React would make most websites faster. It would also be a strategy that few places should pursue."
Post reply on HN