[deleted]
Fastest Front End Tooling for Humans and AI
11–20 of 99 posts
Re: Fastest Front End Tooling for Humans and AI
#12I'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.
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.
Re: Fastest Front End Tooling for Humans and AI
#13This 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.
Re: Fastest Front End Tooling for Humans and AI
#14Any 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.
Re: Fastest Front End Tooling for Humans and AI
#15I'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.
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.
Re: Fastest Front End Tooling for Humans and AI
#16Any 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.
Re: Fastest Front End Tooling for Humans and AI
#17It'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 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.
Re: Fastest Front End Tooling for Humans and AI
#18It'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…
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.
Re: Fastest Front End Tooling for Humans and AI
#19You can omit tsc with : https://oxc.rs/docs/guide/usage/linter/type-aware.html#type-..., so one less script to run in paralell
Re: Fastest Front End Tooling for Humans and AI
#20I'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 deb…
It's about raw performance. The tools mentioned mostly optimize for fast parsing, fast compilation/transpilation, etc.