Having done concurrency in Java and Rust, my experience is that Rust's concurrency primitives are an order of magnitude better than Java's. I haven't tested C#'s.

The cool thing about rust is that it forces you to use thread safety primitives. It's called fearless concurrency

No, that's not what I'm talking about. C# and Java have nothing like the Send and Sync traits, and they don't have & and &mut.

> A famous one is HotJava.

"Final release: Late 2004; 20 years ago"

I guess I should've specified "not completely and utterly dead"? ;D

(Also, the size and complexity of a browser at that point in time was arguably still a whole lot less than a modern one)

It was also a mess :)

All the major browsers came out when Windows XP had substantial market share.

So browser vendors couldn't rely on the platform to provide up-to-date SSL support. Or MP3 support. Or MPEG-4 support. Or PDF support. This established the norm that browsers would ship their own video support, their own SSL support, and so on.

And Google realised they like the power this gives them - if Google wants to replace HTTP with QUIC or introduce a new video DRM standard, or a new video codec like VP9 - they don't need the cooperation of anyone outside of Google.

If Chrome bundles DRM support (allowing it to play Netflix), and its own HTTP/2 stack for speed - are you going to release a browser that's slower and doesn't play Netflix? Doesn't sound like a recipe for big market share.

Many of these components have been made part of the ecosystem long after they were introduced in Firefox. Also, the more platform-specific you go for each component, the more you're going to introduce subtle incompatibilities between Firefox running on different versions of Windows or in Firefox for Windows vs. macOS vs. Linux. Also, for a very, very long time, Microsoft had an extremely poor record in terms of security fixes. So what happens when you rely on a Microsoft http library and Microsoft takes a year or two to release a 0-day?

There are benefits to this approach, of course, but the costs would have been consequential.

Browsers are using new http features much earlier than they're available in the system libraries. Browsers supported http2 and 3 before they were standardised enough to include in systems. .net http client still can't even tell you about http2 early hints as far as I understand it.

It's going to be the same for crypto and compression. Systems don't ship with brotli for example. The battle tested implementations come to the browsers first in many cases - or at least they're battle tested at the point anyone starts including them in .net or Java.

> Why would you need to reinvent networking layer instead of just sending http requests via matrue, battle tested lib available in your programming ecosystem e.g from MSFT?

Because modern browsers are essentially cross-compatible OSes.