Why are most browsers developed in C++ [closed]

Question

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

Answer 1

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.

Answer 2

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).

Conclusion:

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.

Answer 3

Speed

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

Answer 4

Portability

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

Answer 5

(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.

Answer 6

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).

Answer 7

History

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."

Answer 8

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

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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.

Answer 14

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.