It seems like most of common web browsers (Firefox, Chrome, Safari) are developed using C++. Whys is that so?

  • 28
    Firefox is written in C++ and Javascript, not just C++. Commented Jan 31, 2011 at 18:22
  • 1
    This question is likely to have a few pat answers, assuming that it's accurate (note Jesse's comment on Firefox, and there's a lot of browsers besides those three and IE). I don't think it's a productive one. Commented Jan 31, 2011 at 18:25
  • 1
    Is this the correct group for this question? Commented Jan 31, 2011 at 18:31
  • 6
    @Jesse isn't the js interpreter written in C++? That would kinda make it all C++, no? (I might be wrong..)
    – cambraca
    Commented Jan 31, 2011 at 23:42
  • 5
    @cambraca, with that logic, everything is assembly code! Commented Feb 1, 2011 at 0:22

14 Answers 14


Another way to ask the question is what kind of support does a browser need? The short list is:

  • Support for parsing (needed to make sense of [X]HTML, CSS, and [ECMA/Java]Script)
  • Tree walking/interpreting features (part of parsing and building UI)
  • Support for accelerated graphics
  • Fast networking
  • For the more advanced browsers: control over processes and isolating memory between pages
  • Must work on all supported platforms

Most languages have some sort of parsing support. You have parser generators for C, C++, C#, Java, etc. However, C and C++ have quite a few years head start on the rest of the alternatives so the algorithms and implementations are more mature. Accessing accelerated graphics in Java is a no go, unless you have some native extensions to make it work. WPF on C# provides access to accelerated graphics, but it is too new to have a serious browser built with the technology.

Networking is actually the least of the reasons to choose C++ over Java or C#. The reason is that communication is many times slower than the rest of the processing that goes on to display the page. The raw speed of the wire is the limiting factor. Both Java and C# have non-blocking IO support, as does C++. So there really is no clear winner in this area.

Why not Java? Have you ever tried to build a UI with Java? It feels cumbersome and slow compared to anything else out there, because it is. No accelerated graphics is also a big negative here. Java's sandboxing is really good, and can help improve the security of a browser if it is used correctly, but it is a pain to configure and make work. Not to mention the graphics format support lags behind most modern browsers.

Why not C#? If your only target is Windows, C# might actually make a good representation. The problem comes when you want to support anything else. Mono hasn't caught up enough to be considered cross platform enough for this task--particularly with accelerated graphics support and WPF. Who knows how long that will take to change.

Why not C? There's a C compiler for just about every platform out there (including embedded devices). However, there's a lot that C does not do for you that you will have to be extra vigilant about. You have access to all the lowest levels of the APIs, but the majority of C developers don't do GUIs. Even the C GUI libraries are written in an object oriented manner. As soon as you start talking UI, an object oriented language starts making better sense.

Why not Objective C? If your only target is Apple, it makes a lot of sense. However, most developers don't know Objective-C, and the only reason to learn it is to work on NeXT or Apple boxes. Sure you can use any C library with Objective-C, and there are compilers for many platforms, but finding people to work on it will be a touch more difficult. Who knows? Maybe Apple can turn this perceived deficiency around.

Why C++? There's a C++ compiler for just about every platform out there. Almost every GUI library has a C++ interface, sometimes it's better and sometimes it's just different. For example, Microsoft's ATL is a lot better than win32 C function calls or even the MFC library. There's C++ wrappers for GTK on Unix, and I'd be surprised if someone didn't have a C++ wrapper around Apple's Objective-C GUI library. Process management is easier within C++ than Java or C# (those details are abstracted away for you). It's perceived speed comes more from hardware acceleration than it does raw performance. C++ does take care of more things for you than raw C (such as bounded strings), but still gives you freedom to tweak things. Not to mention a number of libraries needed to render web pages are also written in C or C++.

For the time being, C++ does edge out the alternatives.

  • 4
    For non-Apple and non-NeXT platforms, there is the GNUStep collection. It's mostly compatible with Cocoa, and runs damn near everywhere.
    – greyfade
    Commented Jan 31, 2011 at 20:13
  • 5
    Remember that Java mustn't use Swing (which is a crappy library) for the GUI. For instance, we have Qt bindings.
    – Anto
    Commented Jan 31, 2011 at 20:16
  • 2
    According to my.opera.com/kilsmo/blog/2008/01/29/opera-is-not-based-on-qt Opera is not based on Qt
    – Anto
    Commented Jan 31, 2011 at 20:33
  • 2
    I never said Opera was based on Qt. I meant to imply that a non-free browser is really hard to sell when there are so many excellent free options. Commented Jan 31, 2011 at 21:00
  • 8
    Availability of parser generators isn't really that relevant — in all browsers HTML, XML, and JS parsers are hand-written, and CSS is in some.
    – gsnedders
    Commented Jul 31, 2013 at 16:29

I've decided to write a novel about this in hopes that people will gloss over it and upvote me. No, no, just kidding! I suffered over every word. Every word, I tell you!

Ask 'when' before 'why'

All major web browsers can trace their origins back to the 90s. Konqueror became Safari and Chrome; Netscape became Firefox; IE and Opera are still IE and Opera. These browsers all have a 15 year head start on incumbents.

I suggest you even try to name an acceptable cross-platform (Windows/Mac/Unix and even worse) language that was available in around 1995 when modern browsers originated. To build the core in anything but C/C++, you'd probably have had to build or buy and modify a compiler and platform libraries.

How about today? What are the alternatives?

Just for fun, let's think about the problem today. Yes, there are alternatives, but there are still major problems.

Language choice presents at least these problems:

  1. Knowledge problems - Hiring/training developers or attracting contributors
  2. Organizational/social problems - Language acceptance
  3. Language implementation: Speed, platform support, tooling
  4. Language power

1: Knowledge problems

Where do you get people who know the language or can learn it? This is an obstacle for languages like OCaml, F#, Haskell, Common Lisp and D that are fast and high-level enough to write a browser in nicely, but have few followers (In the 10k-100k range, maybe) even if you liberally count all the hobbyists and academics.

2: Social/Organizational problems

Corollary to the cargo-cult answer above:

  • An open source browser not using C, C++, C# or Java will supposedly have difficulty with contributors.
  • A proprietary browser not using C, C++, C# or Java will get project managers severely yelled at in most organizations.

3. Technical problems

Even in modern times, you need a fairly fast language for the computation intensive parts of rendering pages and running Javascript. You can choose to supplement that with a high-level language for building GUI elements, etc. (e.g. the Firefox approach of C++ and Javascript) but you have to have close integration between the languages; you can't just say "Okay, C# and Lua." You'll probably have to build and debug that bridge yourself unless you choose C or C++ as the base language.

Cross-platform development is another bag of worms. You could use C# or F# and cross your fingers on GTK# and Mono being alive and well in the future. You could try Common Lisp, Haskell, OCaml... Good luck getting everything working on Windows and Mac and Linux.

4. Language Power

After all of that, you have to build an enormous amount of functionality, so if you choose a low-level language you need an even huger army of coders than before. Note that no one has really built a browser from scratch in about fifteen years. That's partly because (surprise!) it's hard.

Specifically, having a Javascript interpreter is problem 3 (acquire one) or problem 4 (build one).


If you developed a three-platform (Windows/Mac/*nix) browser today (early 2011), what are some of the choices?

  • C: See (2). Everyone's going to clamor for C++. Have fun selecting a cross-platform toolkit or building one (1, 2, 3 and 4). See also (4); have fun building a stable, secure browser in it.
  • C++: Have fun selecting a cross-platform toolkit or building one (1, 2, 3 and 4). Have fun (4) building stable, secure browser in it.
  • C or C++ and HLL: Your best bet. Pick your poison on the dynamic language; See (1) and (2). Too many good languages, too few followers of each. (1, 2, 3 and 4) on toolkit.
  • Java: Second best bet, if you have to please middle management. See (4); building huge things in Java takes a lot more code than in anything else on this list but maybe C.
  • Scala: Beats Java on (4); (1) and (2) but it's catching on.
  • C and Javascript: As a special case, this is appealing because you already have to build or acquire and assimilate Javascript interpreter. (Hence Firefox.) (1, 2, 3 and 4) on toolkit; the Mozilla people built their own IIRC.
  • C#: Have fun on (3). You're probably stuck with GTK#, however good that is, or building your own layer and renderer above GTK# and Windows Forms.
  • Ruby/Python/Perl/Racket/Lua/Erlange etc.: You've got (3) on cross-platform widget libraries and speed. Moore's law is with you on (4); the growing demand on browsers is against you.
  • OCaml, Haskell, Common Lisp, Smalltalk: (1) and (2) in spades. No speed issues, probably, but (3) for cross-platform development, and you'll have to build your own everything or bridge to C/C++ libraries somehow.
  • Objective-C: (3) I'm not sure how cross-platform development would work out here.

If we see another major browser rise in the next few years, I would bet it will be written in C or C++ and a dynamic language (Like Firefox), whether open source or proprietary.

Edit (July 31, 2013): Commenters on Hacker News seem to be mentioning Rust and Go (not specifically in connection with my answer), which fall vaguely into the "miscellaneous fast" bucket. Trying to keep this list of languages egalitarian and up to date will be a losing battle, so instead I'm calling it a representative sample as of the time of writing and leaving it alone.

  • 4
    +1 for noting that WHEN a particular browser was first developed also plays a significant role.
    – Sparky
    Commented Jan 31, 2011 at 20:47
  • 3
    It's worth noting that while IE may not be cross-platform today, it certainly was at one time, and its current market share almost certainly derives (at least in part) from that cross-platform capability. Commented Jan 31, 2011 at 20:58
  • 2
    Note that IE was cross-platform once around IE4.
    – JasonFruit
    Commented Jan 31, 2011 at 21:01
  • 2
    +1 for when. That is the only reason. If someone started a browser project today they most likely wouldn't use C++
    – Henry
    Commented Jan 31, 2011 at 21:39
  • 4
    @Henry, unlikely that they would exclude using C++. The answer notes that C++ is still going to be part of the puzzle. Commented Jan 31, 2011 at 21:49


As ugly as it is, C++ is still what you use when you want a fast application and full control over the code.

This is why games, non-core parts (such as file importers) of Office, and more are still written in C++.

Edited to include response from MSalters

  • 3
    Other than games, I don't believe that these reasons are why those apps are written in C++. Though if you have first hand knowledge I'm happy to be proven wrong.
    – Henry
    Commented Jan 31, 2011 at 21:37
  • 2
    first hand knowledge? VS 2010, Office 2010 are both huge app suites yet they are extremely fast at what they do. While both have a rather large COM legacy, and MS heritage, performance is still the most important thing for users. Commented Jan 31, 2011 at 21:42
  • 8
    What else would office be written in? VB? C and C++ are the only options for Microsoft to write large apps in. Don't say C# please
    – Toby Allen
    Commented Jan 31, 2011 at 23:45
  • 4
    @Victor: I haven't seen the source for VS2010, so it may very well be written entirely in C#.
    – Ryan Hayes
    Commented Feb 1, 2011 at 0:05
  • 3
    If office is a C# app, why was the original Ribbon a MFC control, and we had to wait ages for a C# one to be developed? none of these huge apps will be rewritten in C#, they'll be wrapped in a WPF gui (like VS2010) and the bulk of the old code will be reused. Even MS doesn't have the resources to completely rewrite their biggest apps - not if they want to spend time adding features to them too.
    – gbjbaanb
    Commented Apr 11, 2011 at 23:14


I can only guess, but you are mentioning software products that target multiple platforms, and C++ can be compiled to any platform.

  • +10 - Other than raw performance, I think this is the REAL reason most browsers are in C++ with the exception of IE. Most browsers work on multiple platforms and there are few languages/frameworks that can perform at the same level AND be cross-platform compatible. Commented Jan 31, 2011 at 19:40
  • I thought this at first too, but for a GUI centric application like a web browser. Is C++ really that much more portable to other Operating systems than say Java?
    – JohnFx
    Commented Jan 31, 2011 at 21:44
  • 1
    Is a browser really that GUI centric? Commented Jan 31, 2011 at 22:34
  • @JohnFx - Correct, the GUI part is probably not that portable. But the core of e.g. a browser application is about handling HTML, creating DOM trees, parsing javascript and executing it fast enough. A well designed application can easily share the same core and have different UI code for each platform. And yes, C++ is much more portable than Java (but without GUI), because for C++ you only need a compiler targeting the CPU. For Java you need the full framework.
    – Pete
    Commented Feb 1, 2011 at 7:37
  • It was my understanding that most of the guts of HTML processing is done by a few core tools like WebKit. Perhaps it is because those are in C++ that the whole browsers are?
    – JohnFx
    Commented Feb 1, 2011 at 14:08

(I've been working on Firefox for about five years.)

The questioner is right that a lot of Firefox's code is C++, and in fact C++ is the majority if you count by lines of code (although that doesn't tell the whole story, since we have a lot of JavaScript, and JS is more concise than C++).

But in reality, Firefox is written in a lot of different languages:

  • C++
  • C (NSS, NSPR, various libraries we've imported)
  • x86 and ARM assembly
  • JavaScript
  • XUL (an HTML-like markup language) and CSS
  • Objective C (MacOS-only code)
  • Java (Android-only code)
  • Multiple custom interface-definition languages (XPIDL, IPDL)
  • WebIDL (another interface-definition language, but this one isn't custom, although the code generator is)
  • Python (code generators)

I sure am forgetting some.

This list is important because it hints at the incredible complexity that sits behind a web browser.

Yes, Firefox has a lot of C++ code, and yes, that has something to do with the fact that C++ was the best language for this sort of thing when Netscape was founded. But I also contend that there exists no better language today for a lot of what we do.

No other language has as strong an ecosystem of libraries (we rely heavily on external code). Few other languages give you full-stack control like C++ (we regularly tweak our custom heap allocator and do all sorts of memory-unsafe things to be faster or use less memory). Few other languages let you re-implement most of the standard library in a sane way (we have our own strings and collections implementations, tuned to our needs). Few other languages let you implement your own garbage collector. And so on.

Although C++ is the obvious choice for a lot of what we do, the people who suggest that we could write a browser in Java and write our own JVM if necessary are on to something. This is essentially what we do, but with JavaScript instead of Java. Of course, much of the browser isn't written in JavaScript. But a surprising amount is.

  • Are these memory-unsafe actions sources of security problems?
    – Demi
    Commented Dec 23, 2013 at 0:24

Well, you'd have to ask the developers of those products directly to get the answer, but I suspect it's a combination of familiarity (it's what those developers knew best), performance (compiling to a native binary as opposed to bytecode), and tools (compared to languages like C, C++ is full of nice labor-saving gadgets like the STL).



Each of the browsers has some history that influenced the choice of language.

For example, both Chrome and Safari are based on WebKit, which has its origins in the KDE project's KHTML part. KDE originally was created (in part) as a demonstration of the Qt GUI toolkit, so KDE is, overall, a C++ project. All new KDE projects were, at the time, written entirely in C++, so it was a logical choice for KHTML. It has since been ported to use other GUI toolkits.

Opera's Presto engine was written with performance and a small binary size in mind: C++ was the logical choice.

Microsoft's IE was written as a collection of ActiveX components, which could have been written in any language that has COM bindings, but was likely written in a subset of C++, because the majority of their codebase is already written in that language.

Netscape's Mozilla was written in C++ likely because portability was a major concern of theirs. C and C++ compilers are (virtually) ubiquitous, and so it was a logical choice.

There's no inherent technical reason for these choices. It just "seemed like a good idea at the time."


Networking in C and C++ is easy to optimize, since you don't have to use libraries if you don't want to. I suspect that C++ is the language of choice because it allows the advantages of C:

  • Speed
  • Optimization
  • A certain amount of portability
  • Compiled language, not interpreted

coupled with the advantages of OOP:

  • Extensibility
  • Easier visualization
  • Better library support for non-critical tasks such as string processing and data structures
  • Doesn't Java or C# has those advantages?
    – Nipuna
    Commented Jan 31, 2011 at 18:29
  • 5
    I have developed apps in both, and I'd say that for limited network functionality they are fine. However, I would not want to build anything that centered on the network portion as a browser does. I would want a lot more control over what was happening, and I would want a compiled language.
    – Michael K
    Commented Jan 31, 2011 at 18:32
  • Java and C# are also compiled. C# would have an advantage over Java when it comes to building the GUI--a critical part of any browser. Java would have an advantage with portability. Both Java and C# are recompiled on the target platform--for arguably better speed improvements. Commented Jan 31, 2011 at 19:35
  • 5
    No, they are interpreted. They compile to bytecode and run on a virtual machine. That VM does not have a one-to-one correspondence from it's instruction set to the native one.
    – Michael K
    Commented Jan 31, 2011 at 20:28
  • 1
    You couldn't have this more backwards! Networking; you could shell out to curl and the browser would be just as fast. The network CODE is not the slow bit. And what is sockets if it's not a library? String Processing; This is the core of any html browser, it's NOT non-critical and I can't think of a single language that has worse string handling than C++ other than C.
    – Henry
    Commented Jan 31, 2011 at 21:53

When the first lines of code for the first round of browsers were written, C# and Java did not exist. Nor did Ruby. Python may have been around, but it was still a tiny homebrew project at that point.

Basically, there really werent any other choices other than C++ that would allow one to build a browser that would be fast and run on many different platforms.

So why were they written in C++? Because that was the only language available that they could be written in.

  • 1
    Not sure what you mean by 'new round'. But FF and IE have code bases that go back to the mid 90s, and most new browsers use one of the rendering engines (for example, Chrome uses WebKit) Commented Jan 31, 2011 at 20:08
  • 2
    FF got rid of the legacy Netscape code (i.e. that mid 90s bloat) and implemented their own rendering engine. WebKit is also a comparatively new rendering engine (used by Chrome and Safari). IE still has legacy bloat which continues to weigh it down. So I'll disagree here. Commented Jan 31, 2011 at 20:18
  • 2
    According to wikipedia at least, both gecko and webkit started around 1998. C# wasnt around then, and java was new on the scene (and super sluggish and truly awful at gui's back then), so that wouldnt have been a feasable option. So I dont know what other languages would have been suitable. Maybe Pascal. Commented Jan 31, 2011 at 20:28
  • 1
    @Berin Loritsch: Yes, but at no point did they simply throw out all the existing code and start over (on everything) from the very beginning, which is pretty much what they'd have had to do to convert to another language. In addition, people who knew/know C++ well enough for their decision about FF to stick would be likely to switch to a different language anyway. Commented Jan 31, 2011 at 20:40
  • 2
    @Berin Loritsch Rubbish. FF is still based on Gecko (1997) and Webkit is based on khtml (1998).
    – Henry
    Commented Jan 31, 2011 at 21:46

Because the browsers (e.g., HotJava, obviously enough written in Java) written in other languages have never been achieved any substantial degree of market acceptance/penetration.

I can't say anything about the current iteration (or most recent--hasn't been updated in quite a while) of HotJava, but when I tried it, lack of market penetration seemed (at least to me) extremely easy to understand -- it was ugly, slow, and incompatible with quite a few web pages. Ultimately, it seemed to be based on a premise that never panned out: that the web would consist primarily of Java applets, with HTML as little more than a wrapper telling which applets to display where.

Part of it is probably also historical: most of the big web browsers have been around a long time. When they were first written, the landscape was much different: C++ was a "hot" new language, so it was being used for a lot of new development. Browsers have become some of the most heavily used software around, while many others from the time have faded into oblivion.

I think the displayed "attitude" of the language has an effect as well: C++ (like C before it) has always emphasized practicality and pragmatism. That basic attitude tends to attract programmers who are also pragmatic. Many other languages place a great deal more emphasis on things like elegance -- and in so doing, they attract programmers who think the same way. The problem with that is what I call the "Lisp effect". Symptoms include:

  1. Endless arguments over the most elegant implementation of the most trivial things.
  2. Inability to freeze features and finish something that can be shipped (even with flaws)
  3. Inability to compromise. Anybody who disagrees with me is not just wrong, but must be either stupid or evil.

There are more, but you get the general idea (and yes, I'm exaggerating to some degree--but only to a degree). Yes, some of the code you get will be astoundingly beautiful--but chances are that it's six months late, and mostly incompatible with every other piece of code in (what's supposed to be) the system, and by the time you receive it there's a pretty fair chance something else has changed enough that you can't use it at all.

There are also languages that would undoubtedly work just fine, but (rightly or wrongly) simply don't have (or at the crucial time, didn't have) the market share for anybody to have ever written a browser in them. Given the size and complexity of a complete browser, it takes a lot of people and quite a bit of time to develop one. With that kind of investment, many people get relatively conservative about things like development tools.

  • 1
    WRT point 3, I will definitely assert, without qualification, that writing network-facing software in the C family is either stupid or evil, because it entails either unknowingly (stupid) or knowingly (evil) working with a system widely known to introduce security holes that will cause harm to your users. It's morally equivalent to giving a soldier body armor with a target painted on it. Commented Jan 31, 2011 at 20:03
  • 9
    @Mason: Your display of exactly the bigotry in question is certainly appreciated. Commented Jan 31, 2011 at 20:10
  • 2
    @Mason: Nonsense. One security hole (that had already been fixed, but many sysadmins hadn't bothered to install updated code) isn't even close to proof that all code written in the same language "will cause harm" or anything of the sort. OpenBSD (for one example) has a considerably better security history than the Pascal-based version of MacOS even aspired to. Commented Jan 31, 2011 at 20:20
  • 5
    @Mason: No, you are. First, the Morris worm exploited a proram that used gets, which is a terrible function, but hardly unavoidable (and certainly not "fundamental" to the language, or anything like that). Second, C++ is not the same language as C in any case. Third, OpenBSD demonstrates quite nicely that secure software can and is written in C. There's no "underlying language flaw" that prevents writing solid, secure software in C. The tiny market share of OpenBSD indicates that security isn't a major concern for most people. Commented Jan 31, 2011 at 20:48
  • 6
    @Mason: the buffer overrun in gets is a simple consequence of the fact that you don't pass it the length of the buffer you're using. Nothing fundamental to the language about it -- you could do the same thing in Pascal (and I have). Writing software that's secure against an intelligent attacker isn't easy regardless of language. Based on experience in all three, it's a little easier in C than in Pascal, and a lot easier in C++ than in C. Commented Jan 31, 2011 at 21:17

Cargo-cult programming. The perception that "C++ is fast" is still out there, (despite poorly-thought-out language-level features like its badly broken object model that slow things down,) and people want their browsers to be fast, so they write in C++.

In a sane world, people writing network-facing software would be horrified at the mere thought of using a language that comes saddled with all of C's inherent security issues, and actually doing so would be an act of criminal negligence. (Just look at how many buffer overflow exploits have been found against various browsers in the last 15 years or so! How many millions of dollars of damage are these coders responsible for?)

There are other compiled languages capable of creating fast binaries. The problem is that they don't have the same exposure as the C family, and we all have to suffer for it.

Fun fact: By the time the Morris Worm hit the Internet in 1988, conclusively demonstrating the problems with writing OSes and network-facing software in C, (which have still not been solved to this day, because they're inherent flaws in the language,) Apple had been releasing the most advanced operating system the world had seen so far, for several years already, written in Pascal.

  • 15
    Huh? I liked the Mac OS just fine, but to call it the most advanced OS the world had seen is silly. It wasn't even in the same ball park as UNIX and VMS, let alone the IBM big iron systems: single user, no virtual memory, limited process management. To be sure it had a very nice windowing system, but even that was derivative from Xerox Parc, and a bunch of academic projects. I also think that much of the Mac OS was actually written in M68k assembly. The libraries used the Pascal function call standards because it was expected that Pascal would be the primary application language. Commented Jan 31, 2011 at 19:18
  • 5
    Pre-2000s Apple's operating systems weren't any more stable than the MS equivalent. When I was working two projects in the 90s, one with Mac OS and one with NT I had the same number of crashes and reboots required. Now they are all some sort of C based language. (Apple uses Objective-C for its current stuff). Security may be more difficult in C based languages, but using a different language doesn't make it suddenly more secure. Commented Jan 31, 2011 at 19:29
  • 13
    @Mason, the fact that the Mac didn't need those features at the time doesn't mean those are insignificant. You made an unqualified statement that the Apple OS was the most advanced in the world, but apparently what you really meant was that it had the most sophisticated user interface. That is a defensible statement, but rather less grand than what you wrote. Writing a usable GUI is hard. Writing a reliable paged memory system is hard. Saying that one is more significant then the other is silly. Consumer level computing as we know it now couldn't exist without both. Commented Jan 31, 2011 at 19:39
  • 5
    @Mason: your experience clearly differs (hugely) from anybody and everybody else's -- in many respects. :-) Commented Jan 31, 2011 at 20:27
  • 3
    @Mason: LOL at referring to pre-Mac OSX as "advanced". Apple OS was a constant source of crashes, not least because of its extremely rudimentary file system. Commented Jan 31, 2011 at 21:52

Access to system-level APIs

All browsers have to interface with the OS at some point, and most of the major OSes have well-established C and C++ APIs and libraries. It's usually easier to work with those APIs in C or C++ rather than write wrappers.


Control and Portability

most of the speed arguments can go either way, but in anything where you need precise control over how something gets done many of the higher level languages will rain on your parade. There are exceptions to this, but most of them are not cross-platform enough to count in something like a browser.


Legacy compatibility - can't throw away old code

It has nothing to do with the merits of C++ vs other languages. You can surely write a better browser from scratch in a language like Haskell; a project this important could even implement their own JVM if they needed to guarantee some performance characteristics. Like how Facebook wrote their own PHP compiler/optimizer.

A browser that breaks on non-standard markup is worse than useless. Legacy compat is so critical and so complex that a rewrite is just not an option. Lots of money and time is invested in battle-tested security etc, you can't just throw that investment away. Again, like how Facebook is still written in PHP.

  • I can understand why people might not upvote this... but downvoted? That's weird. Here's a +1 for you. Commented Nov 14, 2013 at 0:10
  • You have a (small) point, but your first sentence throws that away. Of course it does have to do with the merits of C++ vs other languages as well.
    – chtenb
    Commented Apr 27, 2014 at 10:38

Not the answer you're looking for? Browse other questions tagged or ask your own question.