This is a really good thing, and having been through this in other Google projects, a sincere congratulations to the folks who demonstrated the tenacity to keep pushing forward despite both I'm sure a lot of genuine hard questions being asked, and a lot of fud. This outcome will be good for users in the long run.
When the number of stakeholders exceeds some relatively small number N, it becomes very hard to distinguish good, tough, fair questions from FUD and obstructionism. I imagine the Chromium project easily exceeds that N.
Yes, absolutely. Also to be clear: people aren't implicitly at fault for asking questions rooted in fud. Caring is a good thing, and so is trusting your intuition, and speaking up. The challenge is working through it all quickly and collaboratively.
Oh indeed. Sometimes people repeat FUD just because they feel like they need to say something and they aren't well informed. Other times people do so because they are honestly concerned. Unless you know the person, it can be hard to differentiate.
1. Google strangles Firefox through advertising for Chrome as a better browser on their web properties, breaking Firefox on their web properties (the famous oopsies) and bundling the Chrome installer with installers for other software.
2. Google enjoys a browser monopoly and can dictate features as standards to support their data collection and advertising business.
3. Google thanks Mozilla from the bottom of their heart for developing Rust, so all is forgotten :-)
There’s also a slightly hidden reason: keeping Mozilla’s Firefox as a competitor lets you get away with being hammered by antitrust regulations (which Microsoft already had the experience with IE)
It's infuriating how Mozilla dropped the ball with Rust. Rust is successful, and Mozilla could have been the guardian behind the language. They gave away their biggest innovation in years. I installed Firefox on Windows Yesterday and walked through picking my culture-defining theme colors for the UI and then I made myself a stiff drink.
I really don't see how it could have gone any differently.
Mozilla is struggling. Firefox's market share is less than 3%, in the "also ran" category. Employing all the people in the Silicon Valley to maintain Rust is hugely expensive without an obvious return on financial investment.
By opening Rust up to the community, they ensured its popularity and longevity beyond what more corporate-focused languages (Go, Swift, or C#) can achieve. Relinquishing control is exactly what Rust needed to help its popularity.
Certainly not having a bunch of engineers employed specifically to develop and maintain Rust hurts, but Mozilla simply cannot afford it.
Successful programming languages tend to be bad for business: they generate support costs but little or no measurable income.
The only way to make them profitable is to use them as a lock-in tool for your platform (VB, .Net, SQL dialects...), but Mozilla never had anything to lock people in.
> Relinquishing control is exactly what Rust needed to help its popularity.
Maybe? But that's not why they did it. In the same year that their CEO took another massive payout they laid off tons of staff "because covid", an excuse that was obviously nonsense at the time but especially looks like nonsense when you realize that tech absolutely exploded during covid with record high valuations.
Mozilla absolutely could have afforded it. Easily.
Mozilla's CEO is an absolutely disaster and the company is never going to be able to recover from it.
I think its the best of both worlds. Mozilla gets to focus on Firefox while other companies contribute and grow the rust eco system. Having no real sponsor makes companies see Rust as less of a threat and more of an opportunity. Similar to Linux.
Google always had the ability to use Rust in any of its projects. However, I think Mozilla pissed away the biggest opportunity they had in a decade to lead something that will change an industry, and to influence (positively) the community around it. I certainly trust Mozilla over Google, though I'm still mad about that Mr. Robot extension.
Google has all the resources and hundreds of engineers to throw at Rust. They will definitely have undue influence on the language and its community now that it's in Chrome. I just hope it doesn't wind up looking like Kotlin.
It's sad that Mozilla's layoffs were that extensive, but it also gave more resilience to the language I think. There isn't a single stakeholder any more. Instead it's distributed among a bunch of big tech companies. Which brings its own issues, but it's not the end of the world.
Mozilla has also never really controlled Rust's development, it was their policy to treat it independently. The big tech companies also don't control it now. This might change in the future due to a weakened core team creating a vacuum that might be filled by the foundation, but the current status is that Rust is quite independent.
This isn't to say Google becoming the guardian is appealing; plenty of nose-holding to be had there too. But considering the absolute ineptitude and even hostility Mozilla has shown towards users over the past 1~2 decades, I'm glad they aren't the guardians to anything anymore.
Everything Mozilla touches dies an undeserving death, so I hope they continue to spiral further down into irrelevance and an eventual dissolution.
It also shows the poor management Mozilla has since they effectually cut-loose the Rust team and aren't investing too much in rewriting parts of FireFox in Rust.
Rust would've been a great USP for FireFox. They squandered it and now the competition is running with it. Both Google and Microsoft are all-in with Rust.
Rewriting in Rust is not necessarily a good idea for any given project, and Google is almost certainly not going to be proactively rewriting large amounts of Chrome in Rust any more than Mozilla is.
The reason is that bugs exist primarily in new code, not code that has been untouched for a long time. While you may solve some latent memory issues by rewriting in Rust, you're likely to introduce new regressions as well which may be much worse. It makes much more sense to focus on writing your new code in the safe language and gradually migrate things only when they would require a substantial rewrite anyway.
> The reason is that bugs exist primarily in new code, not code that has been untouched for a long time.
Think of WireGuard vs. OpenVPN. Sometimes when a lot of cruft and old habits have built up, there are significant advantages to starting fresh, with better ideas from the get go.
There are parts of mozilla that will need significant rewrites anyways, and writing parts of those in Rust could be a win if they can keep the interfaces clean.
Right, the finding from Google's Android team was that security bugs tend to be in new code, and so therefore choosing a safe language for new code is a much bigger win than rewriting stuff that you weren't going to change otherwise and which might be fine.
I hope they took into consideration a corollary: that new code often _exposes_ bugs in the old, by exercising untested code paths or just by breaking assumptions. When a bug arises this way, do you attribute it to the new code or the old?
A good takeaway is that the old code should not have exposed paths that didn't yet have a consumer. I frequently fall into the trap of making my code too general to support future use cases, and this usually ends up being rewritten when those use cases are actually implemented, or the code is just dead for the lifetime of the project.
> When a bug arises this way, do you attribute it to the new code or the old?
Rust has a hard rule here, if your code wasn't marked unsafe, but it can be (ab)used in a way which causes unsafety, then the code is wrong. If the code is marked unsafe, but the safety documentation misses a key requirement and as a result you can obey the documented safety rules and still get unsafe behaviour, that code or its documentation is still wrong.
Thus in Rust it's never OK to say "You were using it wrong" on APIs unless they explicitly say they're unsafe and provide documentation on how to use them safely knowing that. Rust's sort() and sort_unstable() are trickier than the equivalents in the C++ standard library because a silly or erroneous Ord implementation like claiming to be Greater even than yourself is (stupid but) safe in Rust and must not induce unsafety in the sort() methods. In C++ 20 if your ordering constraints are bogus, you've got Undefined Behaviour immediately.
Rust can't "correctly" sort six Ponies that all insist they're the Best Pony, but it can promise that attempting to sort them is safe.
Obviously legacy code in a language with no hard rule about what's required may be more fraught, most C++ ought to be labelled "unsafe" but chances are it does not adequately document all the constraints on parameters etc. for safe use.
I don't think this is necessarily wrong, but I wonder if there's a sampling bias here: the really good memory corruption bugs might tend to not be discovered for years, or have small variants that keep giving for years (because they're in legacy parts of the codebase, and the team lacks institutional knowledge to make comprehensive fixes).
(Put another way: I entirely believe that rewriting old components in Rust might introduce more bugs, but might still be a net win in terms of decreasing vulnerability researcher value: 100 silly panicking overflow bugs are preferable to one "oops, underflowed the pointer and now the attacker has arb R/W at an address of their choice" bug.)
> Scaling beyond 17k SLOC
[...]
> C++ full builds scale better than Rust
Chromium has millions of line of code not 17k, so, although the scaling test is fairly artificial, rust might get worse and worse as the project get bigger.
Paradoxically, the stupid include model of C++ allows to extract more parallelism form the build.
I wouldn't be surprised if C++ with modules has similar scalability behavior as rust though.
I believe you're 100% wrong. There are probably hundreds if not thousands of bugs in the old code. Just because they haven't been found yet doesn't mean they're not there.
If a handful of developers at SerenityOS can write a web browser (including Javascript and CSS support) from scratch in a year or so why can't Mozilla rewrite the FireFox engine in Rust?
> There are probably hundreds if not thousands of bugs in the old code. Just because they haven't been found yet doesn't mean they're not there.
Most definitely! But how many bugs were in the code that are no longer there? And how does the relative severity compare between new bugs and old bugs?
When considering a rewrite, the question isn't whether there are latent bugs, the question is whether fixing those bugs is worth the regressions that will likely be introduced (not to mention the cost).
Every project should have exactly zero (0) memory bugs. That's nigh impossible to achieve with large codebases written in C/C++ or some other unsafe language.
Chromium and FireFox are still busily fixing memory bugs twenty years after the code was written. It's a God-awful mess!
Right now they don't have a unique selling point (USP). Rust could've been that selling point but they instead focused on making divisive UI changes and adding subscriptions.
Also their crusade against taking money from Google is ill-conceived. There's simply no other source of revenue for a web browser (unless they start their own search engine, but that would be suicide since Google would immediately cut off their funding).
They should focus on building the best and most secure browser and then their market share will almost certainly improve.
The management team should've been fired along time ago. But they essentially hijacked Mozilla. All the trademarks and copyrights belong to the Mozilla Corporation, not the Foundation.
Management are filthy crooks, scum and carpetbaggers.
Microsoft and Apple are building pack-in browsers that users neither love nor hate. Brave is trying to sustain themselves on a comedy routine of a cryptocurrency, and Google is 30 seconds away from relapsing into web domination.
Relative to the rest of the circus, I'd say Mozilla is doing an okay job.
As a sidenote, I had the impression Brave was some cryptocurrency delusion too. They have a much more extensive list of privacy modifications than Firefox does. I was impressed on a 2nd look, and you opt-in to the crypto nonsense.
There are worse things than supporting cryptocurrency in your project, but Brave's implementation is downright nefarious. BAT was a funnel that led directly into the developers pockets, it didn't even pretend to be pro-community.
I don't trust Brave any more than I trust Google, since ultimately they're both funded by dwindling ad revenue.
While I don't disagree, there is nothing wrong with Apple and Microsoft making perfectly adequate, boring browsers. Eliciting strong emotions is an anti-feature, surely!
> Rust was developed by Mozilla specifically for use in writing a browser, so it’s very fitting that Chromium would finally begin to rely on this technology too. Thank you Mozilla for your huge contribution to the systems software industry. Rust has been an incredible proof that we should be able to expect a language to provide safety while also being performant.
Somewhere, the laid-off Mozilla Servo team just took a swig from their hip flask.
At this point I just internally assume that ‘general purpose’ C/C++ codebases that aren’t at least open to the idea of Rust are the “if your code has memory issues, you’re just an idiot, except for the times that my code has had memory issues” types of C developers.
More browser code being written in a language with fewer footguns is always cause for celebration
Or maybe it's because the tooling's lacking, the support in linux distributions is spotty, some architectures aren't supported, is complex to interoperate and integrate with build systems, or any of the above? There's plenty of reasons one may opt to not to, however valid you may think they are.
Rust is supported in all Debian release architectures. It kinds of has to, it is a build dependency of Firefox (and soon, Linux itself).
To be more than a FUD, you should specify which Linux distribution and which architecture. Yes, it was bad in Rust's early days, but not anymore. I speak this as someone who worked to improve Rust support in Linux distributions and across architectures.
It is fair to say Swift support in Linux distributions is spotty, as Swift is not packaged in Debian at all, and Swift upstream is developed against its own LLVM fork, which distributions are reluctant to package. I don't think it is fair to say the same to Rust. Rust upstream takes care to support LLVM releases, precisely so that it is easier to package by Linux distributions.
I said "spotty", not nonexistent. Many distributions patch around the lack of suitable support by vendoring all dependencies and locking their versions, making it hard to see the dependency graph from the package manager, scan for vulnerabilities, patch/fix a library across the entire distribution, etc etc.
Am I reading you correctly in saying that C and C++'s tooling is good compared to Rust?
My experience in both (10+ years for C and C++ at this point, 3+ for Rust) is the exact opposite; I can't remember the last time a C or C++ build system, test framework, documentation engine made me one tenth as happy and satisfied as `cargo` does.
Depends on what you mean by "good". C/C++ tooling is certainly more plentiful, better-supported, and available on more platforms, than Rust at this point. That's somewhat natural, considering how much older the ecosystem is.
It's not solely about compile times though. If you consider all the debugging time Rust saves you from, I'd guess Rust even with its slower compile time, comes out ahead in terms of productivity.
That is after all what this link is telling us. One of the main points made was "speed up development"
If it were solely about compile times that wouldn't be a major reason to use Rust here.
Only a sith deals in absolutes, it's not solely about _anything_.
I write multithreaded code every day, and I'm constantly pushing for us modernizing and cleaning up our c++ codebase. Mistakes happen, subtle bugs slip through, but probably 95% of the code I write and features I write don't benefit from the extra checks that rust provides. The 5% that _do_, that's a trade-off, and we need to decide whether it's worth it. In the long tail, yeah there's less bugs of various categories.
Is that worth the cost of the rewrite and the productivity hit for 95% of what I do (as someone who would genuinely benefit from having a borrow checked), the answer right now is probably not
That's not possible at all with the bare-metal languages.
I think many people do not understand that race conditions are a direct consequence of the complexity of our CPUs, memory etc. It is not the "flawed" programming language design that allowed them to sneak in but it is because the problem isn't fundamentally solvable.
Some languages try to minimize the surface area but it's not for free: there's always a trade-off attached to it. In that sense it is not anymore a bare-metal language.
You're thinking of data races, but, (safe) Rust doesn't have data races. You can't write them.
In C++ if you write a data race, that's Undefined Behaviour, game over. This difference might be astonishing, but it's a fundamental design choice.
The data race requires two things to coincide and in (safe) Rust they can't. You need mutation of a value which isn't synchronised with access to that value. In concurrent C or C++ it's trivial to do this by mistake, you now have a data race and so UB. But you can't write this in safe Rust.
Go compiles near instantly, having used Rust and Go for some time now, and shipped in both, Go is the clear winner if you value being able to iterate quickly.
Maybe? I found Go pretty stifling and ran into corners where I was faced with having to copy/paste a lot, write a code generator, or resort to ditching type safety. None of those options are very satisfying. I know generics are now there so maybe this has changed since I last used it. Good if so! 100kloc go program was fast to compile, but awful to modify.
It was amusing to me that often times the answer in Go to avoiding repeating yourself was creating a code generator though, because the language didn't have the native abilities in macros/generics/meta programming itself to do it.
Same! I’ve written reasonably large programs in both. Go definitely has a lower learning curve and there’s absolutely value in that and it’s faster compile times. In a team with mixed experience and backgrounds making web or network services? Maybe go is the right way to go. Not everyone wants or is willing to climb the rust learning curve.
I do think the quick iteration tapers off though the larger the code base gets due to the points I mentioned.
Yeah if you punt the complexity to run time you can burn run time cycles instead of compile time cycles. Make your user pay to run your code instead of your developers. Go is more anti-end-user than Rust.
As with most such things, there is considerable nuance to this question. If you're careful with your dependencies and optimizing for compile time, it can be quite good. For example, a clean release build of makepad studio on M1 Max is 8.81s.
There are also patterns that can really bloat compile time, especially heavy use of procedural macros to autogenerate code. Using serde to serialize big, complex data types can be a big compile time hit. Monomorphization can also be a problem, but fortunately careful use of boxing of dyn traits can help a lot with both code size and compile time (miniserde is an alternative to serde that's more optimized on these dimensions).
There's also continual and ongoing work to improve compile times. So overall I would say it's definitely a factor, but not necessarily a showstopper.
> you're careful with your dependencies and optimizing for compile time, it can be quite good.
The same can be said about c++.
On the other points, every rust project I've seen in the wild makes heavy heavy use of macros, and the majority of projects I've used have a dependency like serde or something. If you're willing to avoid procedural macros and large dependencies, you might as well just work in c++, avoid custom templates and enjoy wicked fast iteration times.
> So overall I would say it's definitely a factor, but not necessarily a showstopper.
I disagree, it is a showstopper for now. It might not be in the future but the situation right now is that comparable c++ and rust projects in my experience have been an order of magnitude in the difference in compile times. My work c++ codebase is a 30 minutes clean build on a 32 core machine with 96GB ram and an NVMe SSD. I can only imagine what an equivalent project would be in my rust if it were as large.
Another real world example, and actually quite relevant to the use case of the original article. Tint and naga are both shader compilers, primarily used for compiling WGSL into SPIR-V, MSL, and HLSL so shaders can be used portably. Tint is in C++ and takes 113.6s for a clean compile on M1 Max. Naga, in Rust, is 17s. That includes serde and a bunch of the usual community crates (quote, syn, thiserror, petgraph).
Admittedly Tint is more mature and sophisticated, but both serve the function I need them for.
There are a few things you can do to help it. The Bevy project has a section of their setup documentation that lists a few strategies[0]. In general though it can be relatively pretty slow.
Frankly it depends, just like in C++, how the code is written.
Rust, even more so than C++ code bases I've worked on and with, really tries to do lots of static typing and mono morphizing. If you work with large projects using boost and eigen, or other template libraries like them compile times are far from amazing. Compared to something like Qt where mostly its dynamic typing at work, and compile times were usually pretty reasonable.
It depends on C++ code is written, plus contrary to Rust, most C and C++ shops make heavy use of binary libraries, so they only get to compile what they actually need for the project.
You are basically saying that not abandoning c++ for Rust makes someone a bad developer. Sounds like suprematism to me. Not all programs are as critical and complex as web browsers. Not all code bases have the same security requirements, there are some legit use cases for trading performance or ease versus guaranteed memory safety.
And then even Rust is not a guarantee that an application has no vulnerabilities, as memory isn’t everything.
So please use rust if it make sense, but please also don’t force it upon every possible c++ software projects.
Please don't put C and C++ in the same boat. This are two different languages and while C++ is definitely far from perfect, at least there is a lot of contruct to manage memory in a safer way (smart pointers raii) and usage of void pointers and c-like arrays are heavily discouraged.
Obliviously if you can use Rust, it's even better but that's not always the case.
Empirically, if they're not the same boat, they're very similar boats. People made impassioned arguments for the plausibility of memory-safe C, too --- in fact, they still do. But look where the bugs come from, and there's a clear pattern.
I generally agree although the article is right about the integration mostly working for small API surfaces. Due to some big differences between the languages (e.g. no move constructors in Rust) doing Rust-C++ FFI is still painful, even with tools to help.
It must have been embarrassing to have had to write that. Anyway I would be embarrassed. "Our existing code is a whole mountain range of mud. We hope new code written in this new language will be less so."
Anyway it will be much slower to write bad code in it, with the compiler kvetching the whole time, so the rate of accumulation of bad code will necessarily be lower.
The same people who wrote the bad old code will be writing the new code. They may hope that it will be better code, but a big ball of mud is a big ball of mud, whatever the language.
I don't agree that the decisions at the time were reasonable. Coding in Google-dialect C++ was a spectacularly bad choice, evident even then. Each day they stick to it is another equally bad choice, well into thousands now.
The first sentence is literally not true, and easy to see just from looking at changes in who contributes over time. The number of contributors is not even the same order of magnitude from when it started.
Chrome was released 14 years ago, and they started writing it even earlier than that, so even trivial "passage of time" would tell you it was unlikely to be true - most developers are not working on the same codebase or even at the same company, they did 14 years ago. This was much more common in tech decades ago , but not anymore, and not been true for a long time.
So even if it was "bad old code" (which, i'll explain, is also nonsense), the same people aren't writing it.
As for "bad old code" -
Chrome was faster, safer, less janky, etc, than its contemporaries for many many years since inception.
So when you say "Coding in Google-dialect C++ was a spectacularly bad choice, evident even then", it just makes you look silly - it clearly was not. If it was such a bad choice, evident even then, the former would not have happened.
Overall - to look at clear success and basically say "they totally fucked everything up, and i wouldn't have done it, because i know better", is pretty arrogant. To then think that if there are bad design decisions, the main bad ones from decades ago are the programming language, is honestly the most hilariously arrogant thing i've read on HN in a while.
The article is an extended admission of series of bad decisions leading to problems so bad they feel they need to switch programming language to try to patch up after. If there were not fundamental problems they have failed to address adequately for years, none of this would even be under discussion.
It is face-saving to blame the programming language, but we should not be fooled. Canonically, the good craftsman does not blame the tool.
Pretty much nonsense, really. Given the herculean effort Google has put into Chromium to deal with these sorts of problems and the massive investment they've made in C++ it should not be taken lightly at all that they're choosing any other language for a project that has been using it for decades.
> Canonically, the good craftsman does not blame the tool.
Yeah that's so true, that's why we build our sky scrapers by bashing rocks into wood and walling it up with dried feces and dirt, right?
Hundreds of people are writing it even now, adding to that massive codebase. The people writing code in Rust will mostly be drawn from among those same people.
They might not be the ones who have been coding the bugs. If not, the new code will, perforce, not be less buggy. If they are the ones who have been coding the bugs, we should expect new bugs.
I am not a fan of the Google dialect of C++. That said, there is no dialect of C++ that would solve the issues they are running into and will continue running into if they use C++. Every major user of C++ regardless of organization or style guidelines has the exact same concerns with the language.
I never get memory usage errors in my C++ code. Many others, likewise.
It is probably true that Google staff, with their existing education and background, cannot achieve this, but other organizations do.
There is of course no possibility of Google recoding all of Chromium in modern C++ or Rust, so they will live with the bugs they have already coded. A new browser, such as Ladybird, could avoid Google's failings.
If you think Google should be embarassed to have written chrome, do you also believe that every other browser vendor should be even more embarassed to have written something less stable/performant/etc. than chrome?
I use firefox for ideological reasons, but there is no denying that it is the (slightly) worse choice from a pure tech perspective.
We may compare to the situation of American automobile manufacturers.
If we had no Toyota or Honda to compare to, one might then insist cars could not be reliable. One might even point to Jeep and Tesla and claim Ford and Chevy were exemplary, by comparison. But we happen to know cars can be better because we have better cars.
I fail to see how it would be embarrassing to improve their product. Is it embarrassing for automakers to release a new car with new technology that's better than their last car?
It is embarrassing to have released cars year after year with fundamental problems that have not been fixed, year after year. Or, it should be. American carmakers really should be embarrassed.
We do not know if next year's car will actually be notably, or even any, better than this year's. The article says they hope so, but obviously nobody knows. Probably there will be fewer of a class of bugs in the new code, but there might also be radically less code implementing needed features. We can only wait and see.
What do you mean by “fundamental problems.” I’m using chrome right now, it works great, and there’s no better browser.
I assure you they’re not embarrassed they didn’t write it in rust from the beginning and they’re not embarrassed to have written the best and most successful browser there is.
They are so very "not embarrassed" that they are embarking on a massive change in how they operate. Or, claim to be; we will need to wait and see if it really happens, and then, if it does happen, if it has any desirable outcome.
We can anyway be certain Google does not need unpaid help defending them.
To be clear your claim is that because Google chrome has some use of a programming language where the community leans left, people are going to meaningfully stop using chrome?
When Firefox added Rust, there were some forks, and threats of forks. Just how it goes. Turns out maintaining a fork of a browser is not exactly easy, and “we don’t like a language it’s written in” isn’t a fantastic way for people to decide to use your fork over the main project.
Maybe I’m missing some recent events but I’ve only heard or seen anything political in regard to state political leanings and especially “identity politics”.
Just feels weird to feel so strongly about that aspect of a programming language. If people held a principled view they’d be horrified of how militaries use anything and everything mainstream.
While that would be nice it is extremely hard for me to believe. Why would using Rust for small portions of the chromium codebase cause people to stop using chrome/blink?
I believe Google is putting too much effort into bringing interop between C++ and Rust. Why not simply rewrite the core of Chromium in Rust?
I mean, if a handful guys at SerenityOS can write a web browser from scratch in just a few years surely Google can muster enough manpower to rewrite Chromium in Rust in a couple of years?
Interop is wasteful since there's a large discrepancy between C++ and Rust code. Trying to plug the holes will lead to an inferior product at great cost.
SerenityOS's LadyBird browser is an impressive project, but it doesn't prove that you can rewrite something like Chromium in a few years.
It does prove you can get something working. But it will take many more years to actually get to feature parity given the long tail of web APIs. It will also take many more years to be competitive on performance with existing engines. And even if you use a memory-safe language you'll be introducing many other bugs along the way.
This doesn't diminish the LadyBird browser in any way! It can still be useful for many people in many ways.
Mind you that only a handful of developers worked on LadyBird and it has Javascript and CSS working.
LadyBird only needs video and WebRTC to be fully functional for day-to-day use by non-power users.
WebSockets and WebGL would be nice too, but that will take some time. Most other API's are cruft, such as WebUSB (a Google contraption that more or less ignores security).
Many of those web APIs are things Google forces down everyone’s throats to have something at least on paper resembling feature parity with native applications.
The Serenity browser wasn't much better than netsurf last time I checked, in fact it was in many ways worse so I don't think they really compare in any substance at this point. Why don't you do it if it is so easy?
