Is Brave actually a good browser now? Did they rewrite it or something? Last time I looked it was a janky JavaScript mess.
Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%
91–100 of 289 posts
Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%
#92Earlier quoted context omitted.
> They won't be installed if you just depend on React. Please correct me if I am wrong, here's my understanding. "npm install installs both dependencies and dev-dependencies unless NODE_ENV is set to production."
It does not recursively install dev-dependencies.
> It does not recursively install dev-dependencies.
So, these ~100 [direct] dev dependencies are installed by anyone who does `npm install react`, right?
Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%
#93Does Brave actually block ads now? Or does it still replace them with ads for scanmy cryptocurrency?
> Or does it still replace them with ads for scanmy cryptocurrency? Brave never did that. Brave blocks third-party ads & trackers by default. (disclaimer: I lead privacy and adblocking at Brave)
I definitely tried out brave several years ago and legit got lots of crypto ads. I really don’t know how you are getting upvoted for lying about this.
Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%
#94Earlier quoted context omitted.
It does not recursively install dev-dependencies.
> It does not recursively install dev-dependencies. So, these ~100 [direct] dev dependencies are installed by anyone who does `npm install react`, right?
No. They’re only installed if you git clone react and npm install inside your clone.
They are only installed for the topmost package (the one you are working on), npm does not recurse through all your dependencies and install their devDependencies.
Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%
#95Earlier quoted context omitted.
> The popular Javascript React framework has 15K direct and 2K indirect dependencies - https://deps.dev/npm/react/19.2.3 You’re looking at the number of dependents . The React package has no dependencies. Asides: > Do you read the source of every single package before doing a `brew update` or `npm update`? Yes, some combination of doing that or delegating it to trusted parties is required. (The difficulty should info…
> You’re looking at the number of dependents. The React package has no dependencies. Indeed. My apologies for misinterpreting the link that I posted. Consider "devDependencies" here https://github.com/facebook/react/blob/main/package.json As far as I know, these 100+ dev dependencies are installed by default. Yes, you can probably avoid it, but it will likely break something during the build process, and most people…
> And do what?
Keep on keepin on
Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%
#96Brave's adblocking engine is a neat example of open source and the ease of sharing lbraries in Rust. It uses Servo crates (also used by Firefox) to parse CSS and evaluate selectors, and is then itself published as a crate on crates.io where it can be pulled in by others who may want to use it.
And yet Rust ecosystem practically killed runtime library sharing, didn't it? With this mentality that every program is not a building block of larger system to be used by maintainers but a final product, and is statically linked with concrete dependency versions specified at development time. And then even multiple worker processes of same app can't share common code in memory like this lib, or ui toolkit, multimedia decoders, etc., right?
PS. Actually I'll risk to share my (I'm new to Rust) thoughts about it: https://shatsky.github.io/notes/2025-12-22_runtime-code-shar...
Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%
#97Earlier quoted context omitted.
Advocates of the C approach often gloss over the increased maintenance burden, especially when it comes to security issues. In essence, you’re signing up to maintain a limited fork & watch for CVEs separately from upstream. So it's ultimately a trade off rather than a strictly superior solution. Also, nothing in Rust prevents you from doing the same thing. In fact, I would argue that Cargo makes this process easier.
But that's what Linux distros are for, package maintainers watch the CVEs for you, and all you have to do is "apt upgrade"
In theory yes, but in practice I don't think you could build something like Servo very easily like that. Servo is a browser, but it's also purposefully designed to be a browser-developer's toolkit. It is very modular, and lots of pieces (like the aforementioned CSS selector library) are broken out into separate packages that anyone can then use in other projects. And Servo isn't alone in this.
However, when you install Servo, you just install a single artefact. You don't need to juggle different versions of these different packages to make sure they're all compatible with each other, because the Servo team have already done that and compiled the result as a single static binary.
This creates a lot of flexibility. If the Servo maintainers think they need to make a breaking change somewhere, they can just do that without breaking things for other people. They depend internally on the newer version, but other projects can still continue using the older version, and end-users and distros don't need to worry about how best to package the two incompatible versions and how to make sure that the right ones are installed, because it's all statically built.
And it's like this all the way down. The regex crate is a fairly standard package in the ecosystem for working with regexes, and most people will just depend on it directly if they need that functionality. But again, it's not just a regex library, but a toolkit made up of the parts needed to build a regex library, and if you only need some of those parts (maybe fast substring matching, or a regex parser without the implementation), then those are available. They're all maintained by the same person, but split up in a way that makes the package very flexible for others to take exactly what they need.
In theory, all this is possible with traditional distro packages, but in practice, you almost never actually see this level of modularity because of all the complexity it brings. With Rust, an application can easily lock its dependencies, and only upgrade on its own time when needed (or when security updates are needed). But with the traditional model, the developers of an application can't really rely on the exact versions of dependencies being installed - instead, they need to trust that the distro maintainers have put together compatible versions of everything, and that the result works. And when something goes wrong, the developers also need to figure out which versions exactly were involved, and whether the problem exists only with a certain combination of dependencies, or is a general application problem.
All this means that it's unlikely that Servo would exist in its current form if it were packaged and distributed under the traditional package manager system, because that would create so much more work for everyone involved.
Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%
#98Is that 45 MiB per-tab? People are laughing it off, but since each tab is a process these days..
Each tab can be a dozen or more processes nowadays, thanks to site isolation.
Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%
#99Brave's adblocking engine is a neat example of open source and the ease of sharing lbraries in Rust. It uses Servo crates (also used by Firefox) to parse CSS and evaluate selectors, and is then itself published as a crate on crates.io where it can be pulled in by others who may want to use it.
And yet Rust ecosystem practically killed runtime library sharing, didn't it? With this mentality that every program is not a building block of larger system to be used by maintainers but a final product, and is statically linked with concrete dependency versions specified at development time. And then even multiple worker processes of same app can't share common code in memory like this lib, or ui toolkit, multimedi…
if I recall correctly Rust does not support any form of dynamic linking or library loading.
Most of the community I’ve interacted with are big on either embedding a scripting engine or WASM. Lots of momentum on WASM based plugins for stuff.
It’s a weakness for both Rust and Go if I recall correctly
Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%
#100Brave's adblocking engine is a neat example of open source and the ease of sharing lbraries in Rust. It uses Servo crates (also used by Firefox) to parse CSS and evaluate selectors, and is then itself published as a crate on crates.io where it can be pulled in by others who may want to use it.
And yet Rust ecosystem practically killed runtime library sharing, didn't it? With this mentality that every program is not a building block of larger system to be used by maintainers but a final product, and is statically linked with concrete dependency versions specified at development time. And then even multiple worker processes of same app can't share common code in memory like this lib, or ui toolkit, multimedi…
Dynamic libraries are a dumpster fire with how they are implemented right now, and I'd really prefer everything to be statically linked. But ideally, I'd like to see exploration of a hybrid solution, where library code is tagged inside a binary, so if the OS detects that multiple applications are using the same version of a library, it's not duplicated in RAM. Such a design would also allow for libraries to be updated if absolutely necessary, either by runtime or some kind of package manager.