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

41–50 of 99 posts

Re: Fastest Front End Tooling for Humans and AI

#44

Post by notnullorvoid »

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.

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.

Re: Fastest Front End Tooling for Humans and AI

#45

Post by steveklabnik »

fullstackchris wrote: post #42

anyone have any insight as to why microsoft chose go? I feel like with rust it could have been even faster!

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.

Re: Fastest Front End Tooling for Humans and AI

#46

Post by conartist6 »

notnullorvoid wrote: post #44
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.

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.

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

Re: Fastest Front End Tooling for Humans and AI

#49

Post by agos »

Exoristos wrote: post #35

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.

ESLint on medium/big projects can be pretty slow and if you use type aware rules it opts out of caching

Re: Fastest Front End Tooling for Humans and AI

#50

Post by squidsoup »

yurishimo wrote: post #12
fsmedberg wrote: post #5

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.

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…

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