graphql-jit VS uBlock

In the end like all performance questions you'll have to measure it. Persisted queries, and even more extreme approaches, like a GraphQL JIT (https://github.com/zalando-incubator/graphql-jit) can remove a lot of the overhead.

We faced something similar. To improve GraphQL performance, we use graphql-jit. We turned off all other tracing that datadog turns on by default. Then, we then wrote a custom tracer to connect graphql-jit to dd-trace. Hopefully this same pattern works for you!

GraphQL JIT – GraphQL execution using a JIT compiler\ (0 comments)

https://github.com/zalando-incubator/graphql-jit#compile-a-q...

so I guess the difference is instead of having totally generic functions that parse the query every time, instead you can call a factory function up front to get a specialised function for a particular query

and V8 JIT can make that faster

JS has always been special & excellent because it allows multiphase programming. That one coild just add more code has been unique versus the world of statuc languages, where maybe youcd have some tool to generate stubs for Thrift or gRPC, then compule that in to your program. Which works ok, if and only if you know ahead of time what schemas you might need. Im these cases, you have to give up on stub code & start using more interprtted systems.

The advantages in js have been colossal, often an easy order of magnitude win to compile selectors & queries & other fast inner loop bits into jit compiled code versus having userland interpretters. Some of thd rete engines enjoy this. Just today there's graphql-jit. https://github.com/zalando-incubator/graphql-jit/blob/main/s...

Everything you say is full of doubt & scorn & skepticism. I just cant imagine living im such a world where each system had to know fully well ahead of time each type of data it might want to interact with, might have to have that precompiled & baked in. Thatcs a shitty miserable world that looks like the hell JS plucked us out of, by being a flexible, dynamic language that could load in routines & change it's behavior over time. Screw that dark hell world.

By using useParserCache we make sure to parse every unique operation only once. By using useValidationCache we make sure to validate every unique operation only once. By using useGraphQLJit we replace the default execute function with a just-in-time implementation.

One thing to understand is that, if you are using Node.js graphql-js would typically be the underlying implementation of all libraries and ultimately everything would get converted to JS/TS objects typically an AST ultimately making all these as abstractions on top of the existing way to define schemas. Note that the implementation can differ a bit in other languages or even within Node.js if you are using other ways of implementation like graphql-jit

Could you provide more context? the GraphQLJit plugin is a lightweight wrapper around graphql-jit. Could you share your previous datadog/graphql setup? Would love to dig in and find a proper solution!

Customizable runtime. Use custom GraphQL implementation such as graphql-jit or rolling our own for performance and cutting-edge features.

Check out uBlock Origin's per site switches [1]

[1]: https://github.com/gorhill/uBlock/wiki/Per-site-switches#no-...

If ads, in particular on YouTube, are the problem, anything Chromium-based is probably only going to get worse and worse (see [1] and [2]). So that basically leaves you with Firefox and Safari.

I work for Mozilla (speaking for myself, of course), so I'll leave you to guess which I'd recommend :P

[1] https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b...

[2] https://arstechnica.com/gadgets/2023/09/googles-widely-oppos...

https://github.com/gorhill/uBlock

Or if on mobile, it is well worth it to look up adblock options for the browser you use.

What are the compelling advantages of Chrome nowadays?

Chrome is working to limit the capabilities of ad blockers:

https://www.malwarebytes.com/blog/news/2023/11/chrome-pushes...

Whereas a compelling advantage of Firefox is that uBlock Origin works best in Firefox:

https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b...

Advertising networks have often been vectors for malware. Using an ad blocker is an important security measure. Even the FBI recommends ad blockers:

https://www.malwarebytes.com/malvertising

https://theconversation.com/spyware-can-infect-your-phone-or...

https://www.ic3.gov/Media/Y2022/PSA221221?=8324278624

> It allows for 30,000 dynamic rules

That is not what we mean by dynamic filters. From https://developer.chrome.com/blog/improvements-to-content-fi...

> However, to support more frequent updates and user-defined rules, extensions can add rules dynamically too, without their developers having to upload a new version of the extension to the Chrome Web Store.

What Chrome is talking about is the ability to specify rules at runtime. What critics of Manifest V3 are talking about is not the ability to dynamically add rules (although that can be an issue), it is the ability to add dynamic rules -- ie rules that analyze and rewrite requests in the style of the blockingWebRequest permission.

It's a little deceptive to claim that the concerns here are outdated and to point to vague terminology that sounds like it's correcting the problem, but on actual inspection turns out to be entirely separate functionality from what the GP was talking about.

> Giving this ability to extensions can slow down the browser for the user. These ads can still be blocked through other means.

This is the debate; most of the adblocking community disagrees with this assertion. uBO maintains a list of some common features that are already not possible to support in Chrome ( https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b... ) and has written about features that are not able to be supported via Chrome's current V3 API ( https://github.com/uBlockOrigin/uBOL-home/wiki/Frequently-as... ). Of particular note are filtering for large media elements (I use this a lot on mobile Firefox, it's great for reducing page size), and top-level filtering of domains/fonts.

> "Its happened before"

> That's not an argument

It's a subheading to "2. Browser engine monopoly". The subsection's purpose is describing how bad things were during the IE monopoly to reinforce that it's something to be avoided.

> in fact you could counter-argue that IE left a lot of technical debt

That would be agreeing with the article, unless I understand what you mean.

> On top of that, the internet was very different back then.

In a way that now makes it harder for truly new competing engines to pop up due to increased complexity of the web.

> I'm still not convinced, why would I change my browser?

The points made in the article are:

* Increased privacy, opposed to willingly giving your data to an ad-tech company

* Helps avoid a browser engine monopoly which would effectively let Google dictate web standards

* It’s fast and has a nice user interface

Onto which I'd add:

* Content blockers work best on Firefox (https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b...), doubly so when Manifest V3 rolls out

* Allows more customization of interface and home page

* UX improvements, like the clutter-free reader mode, aren't vetoed to protect search revenue as with Chrome (https://news.ycombinator.com/item?id=37675467)

Advertising networks are vectors for malware:

https://www.cisecurity.org/insights/blog/malvertising

https://www.malwarebytes.com/malvertising

https://theconversation.com/spyware-can-infect-your-phone-or...

So if you're concerned about security then you want the browser with the best ad blocker.

uBlock Origin works best in Firefox:

https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b...