Live data from Hacker News

Fastest Front End Tooling for Humans and AI

cpojer.net

21–30 of 99 posts

Re: Fastest Front End Tooling for Humans and AI

#21

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…

[flagged]

Re: Fastest Front End Tooling for Humans and AI

#22
post #13

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.

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

Re: Fastest Front End Tooling for Humans and AI

#23

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

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.

Re: Fastest Front End Tooling for Humans and AI

#24

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.

Bun can replace vite?

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.

Re: Fastest Front End Tooling for Humans and AI

#28

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…

> 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 communit…

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

Re: Fastest Front End Tooling for Humans and AI

#29
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

Re: Fastest Front End Tooling for Humans and AI

#30

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.

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.
Post reply on HN