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

71–80 of 99 posts

Re: Fastest Front End Tooling for Humans and AI

#71

Post by TheAlexLichter »

lelandfe wrote: post #59
TheAlexLichter wrote: post #57

Earlier quoted context omitted.

The good part is that the new tools do replace the old ones, while being compatible. The pattern is: * Rolldown is compatible to Rollup's API and can use most Rollup plugins * Oxlint supports JS plugins and is ESLint compatibel (can run ESLint rules easily) * Oxfmt plans to support Prettier plugins, in turn using the power of the ecosystem * and so on... So you get better performance and can still work with your favo…

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

Re: Fastest Front End Tooling for Humans and AI

#72

Post by dcre »

philipwhiuk wrote: post #65
dcre wrote: post #56

Earlier quoted context omitted.

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.

I only use it for typechecking locally and in CI. I don’t have it generating code. Of course, what is generating my code is esbuild and soon Rolldown, so same issue maybe. If CVEs in tsgo’s deps are a big risk to run locally, I would say I have much bigger problems than that — a hundred programs I run on my machine have this problem.

Re: Fastest Front End Tooling for Humans and AI

#73

Post by dcre »

lelandfe wrote: post #59
TheAlexLichter wrote: post #57

Earlier quoted context omitted.

The good part is that the new tools do replace the old ones, while being compatible. The pattern is: * Rolldown is compatible to Rollup's API and can use most Rollup plugins * Oxlint supports JS plugins and is ESLint compatibel (can run ESLint rules easily) * Oxfmt plans to support Prettier plugins, in turn using the power of the ecosystem * and so on... So you get better performance and can still work with your favo…

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.

Re: Fastest Front End Tooling for Humans and AI

#74

Post by johnfn »

austin-cheney wrote: post #40
johnfn wrote: post #30

Earlier quoted context omitted.

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.

Perfect example of what I am talking about. People want faster software... until they are confronted by challenging decisions. JavaScript can be very fast. JavaScript, in the browser, reports a page load of about 0.06 seconds for my large personal SPA and that includes state restoration. That is determined by using: performance.getEntries()[0].duration in the browser. When conflicts arise people most frequently becom…

> When conflicts arise people most frequently become emotional and complain about the situation than make any decision towards resolution one way or the other. That is a psychological problem called cognitive conservatism[1]. About the half the time that emotional output is some form of deflection, such as hostility. Cognitive conservatism is only allowed to exist when there is insufficient pressure on the thought leaders to impose a resolution.

Please consider that it is your own behavior which leads to these responses. When you are getting repeated "hostile" reactions from everyone you try to state your case to, instead of insisting that everyone else is wrong, it might be wise to look inwards and ask yourself if you are the problem.

It is interesting that you claim that the only reason you can think of that people disagree with you that they are emotional. Have you considered that you might be wrong?

Re: Fastest Front End Tooling for Humans and AI

#75

Post by simonw »

philipwhiuk wrote: post #62
simonw wrote: post #37

Earlier quoted context omitted.

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

That should be a few dozen lines of vanilla JavaScript.

Re: Fastest Front End Tooling for Humans and AI

#76

Post by conartist6 »

TheAlexLichter wrote: post #57
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…

The good part is that the new tools do replace the old ones, while being compatible. The pattern is: * Rolldown is compatible to Rollup's API and can use most Rollup plugins * Oxlint supports JS plugins and is ESLint compatibel (can run ESLint rules easily) * Oxfmt plans to support Prettier plugins, in turn using the power of the ecosystem * and so on... So you get better performance and can still work with your favo…

So you really think everyone in JS should have to learn Rust or else be excluded from sharing in the ownership of their critical infra..?

Re: Fastest Front End Tooling for Humans and AI

#79

Post by notnullorvoid »

TheAlexLichter wrote: post #57
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…

The good part is that the new tools do replace the old ones, while being compatible. The pattern is: * Rolldown is compatible to Rollup's API and can use most Rollup plugins * Oxlint supports JS plugins and is ESLint compatibel (can run ESLint rules easily) * Oxfmt plans to support Prettier plugins, in turn using the power of the ecosystem * and so on... So you get better performance and can still work with your favo…

As far as I'm aware oxlint only supports plugins for non type aware rules, and type aware rules themselves aren't fully stable because it relies on a fork of tsgo.

Re: Fastest Front End Tooling for Humans and AI

#80

Post by kevlened »

sibeliuss wrote: post #67
sunaookami wrote: post #27

Oxfmt!? I just switched from ESLint and Prettier to Biome!

Biome missed the bus by not getting mixed language formatting in soon enough. Oxfmt got it, and then won.

> Oxfmt got it, and then won.

This doesn't align with the data.

  - 650k npm downloads for oxfmt this week [0]
  - 4.3m npm downloads for biome this week [1]

  - 19.1k gh stars for oxfmt [2]
  - 23.7k gh stars for biome [3]
  - gap widening in favor of biome [4]

  [0] https://www.npmjs.com/package/oxfmt
  [1] https://www.npmjs.com/package/@biomejs/biome
  [2] https://github.com/oxc-project/oxc
  [3] https://github.com/biomejs/biome
  [4] https://www.star-history.com/#oxc-project/oxc&biomejs/biome&type=date&legend=top-left
Post reply on HN