IMHO it's pretty simple: low-level performance. Even 25% slower than the output of a good C++ compiler means a browser goes from first to last place in many benchmarks. People expect the page to scroll at 60 FPS and that rules out GC pauses longer than 16 ms. Browsers are a mature market and unless the proposed replacement has the performance of C++ it's not worth the risk. Horizontally scaling server software has greater flexibility for performance; hence the explosion of languages on the server side while the client side is largely confined to languages developed in the 80s.<p>Parallelism may be the key to disruption here however; if a new browser can scale better to the multi-core present and future it may be worth taking a small hit over C++ in the sequential case. That's Servo's bet (although Rust strives for C++-level performance even in the single-threaded case).
Web browsers must be some of the most demanding applications to develop: they have to do very many different things; they must be very efficient; they must be very reliable; requirements change very rapidly.<p>If claims made by certain language X apologists are to be believed, one can infer that language X should permit developing a web browser in shorter time than C++, with performance within say 20% of C++ (or even superior to C++, depending on X and the apologist), with fewer bugs, and with a more maintainable codebase as the result. Actually delivering such a web browser would be a rather more convincing argument than empty talk or even glorified Fibonacci programs. Hence, I'm very much looking forward to future progress by the Rust guys.
There are a lot of poor or outdated answers to the question (arguing a lack of accelerated graphics, for example).<p>The number one reason current browsers are implemented in C++ is momentum. A browser has a lot of parts that do a lot of things; they're big code bases.<p>JIT compilation technology on the JVM (and elsewhere) these days is pulling within 20-50% of static C/C++ code.<p>If you were coding from scratch these days, would you start with C/C++? I doubt it, especially when you know you can get most of the same performance with other platforms.<p>By far the most important reason to choose a modern VM environment is security. Except in a vanishingly small number of cases, everything should <i>always</i> be bounds checked. The "native" part of a browser should be as small as possible, with a highly constrained and thoroughly checked API. Take away manual memory allocation and use after free goes away. Take away pointers and buffer overflows go away. You want as much of the browser code as possible to be running in a managed environment.<p>In my opinion every line of native code carries risks that don't exist in managed environments. Yes, properly written C code won't exhibit those problems -- but it seems to be extraordinarily difficult to do that. Security flaws are still being found in browsers, decades later.<p>And yes, security flaws exist in systems like the JVM. Those mostly come from native code as well, but some of them are because of the design. The JVM's "native part" is just too big. Too <i>much</i> is done there that doesn't need to be.<p>With a massive native code base it's just a huge problem to verify everything.<p>So Rust and Go are quite interesting. It's critically important that these languages remove "unsafe" features from something like C/C++, and lose almost nothing in the process.<p>And around the corner, environments like the JVM can auto-vectorize on the fly (<a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7116452" rel="nofollow">http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7116452</a>), knocking down yet another performance-parity barrier.
They all have roots going back to a time when C/C++ were the "it languages" for UI and systems development. Java was nowhere near ready for that sort of thing; Mozilla tried anyway, but Rhino is the only thing from that project that really took off. No other language even came close: Tcl/Tk had the UI part, but its performance wasn't up to par, and most other languages either didn't have the performance, or didn't have the UI capabilities, or called out to Tk to get the UI capabilities and thus inherited Tk's problems.<p>Mozilla tried the low-level guts/high-level UI approach anyway, using JavaScript because they had to implement an engine for it anyway. But it took them a few tries to really get it right, and its false starts in this category remain infamous to this day. The others stuck with C/C++ for everything because it's what worked at the time, and continue because it works for them.<p>Mozilla's at it again with Rust, though, and that looks like it could be an interesting project.
The Rust language is being designed to be ideal for use in building a Web rendering engine. Mozilla's rust-based engine experiment is called Servo:<p><a href="https://github.com/mozilla/servo" rel="nofollow">https://github.com/mozilla/servo</a>
There was a browser written in Java in the past:<p><a href="http://en.wikipedia.org/wiki/HotJava" rel="nofollow">http://en.wikipedia.org/wiki/HotJava</a>
Why a C like language? Power. Browsers are CPU and memory hogs, and C is simply the best way of squeezing out more performance.<p>Why an OO language? Well, while OO is overused, a HTML document looks a lot like a bunch of objects, doesn't it?
Why not? What other high performance languages were out there (besides C) when these browsers were created? New browsers can be written in different languages (for example Rust).