Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Faster Alternative to Jq

micahkepe.com

Post reply on HN
Print view View original

81–90 of 281 posts

Re: A Faster Alternative to Jq

#81

Post by Koschi13 »

1a527dd5 wrote: post #43

I appreciate performance as much as the next person; but I see this endless battle to measure things in ns/us/ms as performative. Sure there are 0.000001% edge cases where that MIGHT be the next big bottleneck. I see the same thing repeated in various front end tooling too. They all claim to be _much_ faster than their counterpart. 9/10 whatever tooling you are using now will be perfectly fine. Example; I use grep a…

Maybe look at it from another perspective. Better performance == less CPU cycles wasted. Consider how many people use jq daily and think about how much energy could be saved by faster implementations. In times like this where energy is becoming more scarce we should think about things like this.

Re: A Faster Alternative to Jq

#82

Post by ffsm8 »

mikojan wrote: post #62
1a527dd5 wrote: post #43

I appreciate performance as much as the next person; but I see this endless battle to measure things in ns/us/ms as performative. Sure there are 0.000001% edge cases where that MIGHT be the next big bottleneck. I see the same thing repeated in various front end tooling too. They all claim to be _much_ faster than their counterpart. 9/10 whatever tooling you are using now will be perfectly fine. Example; I use grep a…

> I see the same thing repeated in various front end tooling too. They all claim to be _much_ faster than their counterpart. > > 9/10 whatever tooling you are using now will be perfectly fine Are you working in frontend? On non-trivial webapps? Because this is entirely wrong in my experience. Performance issues are the #1 complaint of everyone on the frontend team. Be that in compiling, testing or (to a lesser extend…

Uh, I've worked for a few years as a frontend dev, as in literal frontend dev - at that job my responsibility started at consuming and ended at feeding backend APIs, essentially.

From that I completely agree with your statement - however, you're not addressing the point he makes which kinda makes your statement completely unrelated to his point

99.99% of all performance issues in the frontend are caused by devs doing dumb shit at this point

The frameworks performance benefits are not going to meaningfully impact this issue anymore, hence no matter how performant yours is, that's still going to be their primary complaint across almost all complex rwcs

And the other issue is that we've decided that complex transpiling is the way to go in the frontend (typescript) - without that, all built time issues would magically go away too. But I guess that's another story.

It was a different story back when eg meteorjs was the default, but nowadays they're all fast enough to not be the source of the performance issues

Re: A Faster Alternative to Jq

#83

Post by gpvos »

Koschi13 wrote: post #81
1a527dd5 wrote: post #43

I appreciate performance as much as the next person; but I see this endless battle to measure things in ns/us/ms as performative. Sure there are 0.000001% edge cases where that MIGHT be the next big bottleneck. I see the same thing repeated in various front end tooling too. They all claim to be _much_ faster than their counterpart. 9/10 whatever tooling you are using now will be perfectly fine. Example; I use grep a…

Maybe look at it from another perspective. Better performance == less CPU cycles wasted. Consider how many people use jq daily and think about how much energy could be saved by faster implementations. In times like this where energy is becoming more scarce we should think about things like this.

I agree, but in this age of widespread LLM use, that's only marginal.

Re: A Faster Alternative to Jq

#84

Post by merlindru »

CodeCompost wrote: post #34
Bigpet wrote: post #3

When initially opening the page it had broken colors in light mode. For anyone else encountering it: switch to dark mode and then back to light mode to fix it.

I suspect the website is vibe-coded, like the tool itself.

this is a bad faith take. i think the website is really cool and doesn't reek of slop at all. what makes you think differently?

Re: A Faster Alternative to Jq

#86

Post by [deleted] »

mikojan wrote: post #62
1a527dd5 wrote: post #43

I appreciate performance as much as the next person; but I see this endless battle to measure things in ns/us/ms as performative. Sure there are 0.000001% edge cases where that MIGHT be the next big bottleneck. I see the same thing repeated in various front end tooling too. They all claim to be _much_ faster than their counterpart. 9/10 whatever tooling you are using now will be perfectly fine. Example; I use grep a…

> I see the same thing repeated in various front end tooling too. They all claim to be _much_ faster than their counterpart. > > 9/10 whatever tooling you are using now will be perfectly fine Are you working in frontend? On non-trivial webapps? Because this is entirely wrong in my experience. Performance issues are the #1 complaint of everyone on the frontend team. Be that in compiling, testing or (to a lesser extend…

[deleted]

Re: A Faster Alternative to Jq

#87

Post by lelandfe »

mikojan wrote: post #62
1a527dd5 wrote: post #43

I appreciate performance as much as the next person; but I see this endless battle to measure things in ns/us/ms as performative. Sure there are 0.000001% edge cases where that MIGHT be the next big bottleneck. I see the same thing repeated in various front end tooling too. They all claim to be _much_ faster than their counterpart. 9/10 whatever tooling you are using now will be perfectly fine. Example; I use grep a…

> I see the same thing repeated in various front end tooling too. They all claim to be _much_ faster than their counterpart. > > 9/10 whatever tooling you are using now will be perfectly fine Are you working in frontend? On non-trivial webapps? Because this is entirely wrong in my experience. Performance issues are the #1 complaint of everyone on the frontend team. Be that in compiling, testing or (to a lesser extend…

There are some really fast tools out there for compiling FE these days, and that's probably to what they refer. Testing is still a slog.

Re: A Faster Alternative to Jq

#88

Post by roland35 »

lemagedurage wrote: post #64
1a527dd5 wrote: post #43

I appreciate performance as much as the next person; but I see this endless battle to measure things in ns/us/ms as performative. Sure there are 0.000001% edge cases where that MIGHT be the next big bottleneck. I see the same thing repeated in various front end tooling too. They all claim to be _much_ faster than their counterpart. 9/10 whatever tooling you are using now will be perfectly fine. Example; I use grep a…

True. I feel like the main way a tool could differentiate from jq is having more intuitive syntax and many real world examples to show off the syntax.

For better or worse, Claude is my intuitive interface to jq. I don't use it frequently, and before I would have to look up the commands every time, and slowly iterate it down to what I needed.

Re: A Faster Alternative to Jq

#89

Post by luc4 »

Since the query compilation needs exponential time, I wonder how large the queries can be before jsongrep becomes slower than all the other tools. In that regard, I think the library could benefit from some functionality for query compilation at compile-time.

Re: A Faster Alternative to Jq

#90

Post by robmccoll »

bungle wrote: post #40
hackrmn wrote: post #32

Having used `jq` and `yq` (which followed from the former, in spirit), I have never had to complain about performance of the _latter_ which an order of magnitude (or several) _slower_ than the former. So if there's something faster than `jq`, it's laudable that the author of the faster tool accomplished such a goal, but in the broader context I'd say the performance benefit would be required by a niche slice of the u…

Integrating with server software, the performance is nice to have, as you can have say 100 kRPS requests coming in that need some jq-like logic. For CLI tool, like you said, the performance of any of them is ok, for most of the cases.

jq is probably faster than storage, the network, compression, or something else in your stack and not your bottleneck.
Post reply on HN