12 ms·

Why are most browsers developed in C++?

66 points by marpalmin 13y ago

hga 13y ago
Be sure and go down to the "Ask 'when' before 'why'" answer.
thethimble 13y ago
Interesting. With the recent influx of Go rewrites, I wonder if anyone would consider writing a browser in Go just as an experiment.
- stevoski 13y ago
  Has Go got a good UI library?
  - tdees40 13y ago
    It does not, and this needs to change before Go becomes viable for applications like this.
- azakai 13y ago
  GC pauses might be an issue with Go (they don't matter that much in a Go server app, but in a client app like a browser things are very different).
- marpalmin 13y ago
  I had the same doubt.
- redcircle 13y ago
  I rewrote quite a bit of the Chromium browser in Go, achieving a 10x reduction in lines of code (I stopped this project before I could reliably evaluate performance). Since Chromium uses a multi-process model, this was pretty easy: I implemented the Chromium IPC protocol in Go (I wrote a Chromium utility to emit a JSON description of the IPC protocol), and then told the privileged and unprivileged Chromium processes to use my Go subprocess rather than the original logic. My Go logic ran on both Windows and Mac OS X.
  - touristtam 13y ago
    Mind sharing if you have the code public ? :)
    - redcircle 13y ago
      Belongs to my employer :( Also, when I said 'quite a bit', I was thinking about the data-plumbing logic --- not UI and WebKit logic. It doesn't really make sense to rewrite WebKit.
joshmoz 13y ago
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: https://github.com/mozilla/servo https://github.com/mozilla/servo
fdej 13y ago
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. 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.
rossjudson 13y ago
There are a lot of poor or outdated answers to the question (arguing a lack of accelerated graphics, for example). 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. JIT compilation technology on the JVM (and elsewhere) these days is pulling within 20-50% of static C/C++ code. 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. By far the most important reason to choose a modern VM environment is security. Except in a vanishingly small number of cases, everything should always 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. 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. 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 much is done there that doesn't need to be. With a massive native code base it's just a huge problem to verify everything. 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. And around the corner, environments like the JVM can auto-vectorize on the fly (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7116452 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7116452), knocking down yet another performance-parity barrier.
- kintamanimatt 13y ago
  Performance doesn't just include CPU time, but also memory footprint. You might eat a similar amount of processor time, but you're not going to have a similar memory footprint with any kind of GC'd language, and if the GC happens to be a stop the world GC, you're likely to see pauses in the browser that will irritate the user. Before the inevitable "memory is cheap" argument is made, I'd rather have my client app be a good neighbor. Having a GC'd process on a client munch through memory like it's infinite is just bad manners and makes some bad assumptions. (On the flip side, a GC'd process that tries to be a good neighbor by freeing memory aggressively becomes a bad neighbor in terms of CPU time, which has additional consequences in terms of battery life.) The JVM, for example, tends to only run its GC when it needs to. It is a horrible neighbor in this respect because it just takes all the memory it needs and only runs its GC when it really, really has to. This is one of the reasons it's relatively fast, but as a consequence puts a lot of pressure on the system. In such a scenario it's possible other processes will OOM and be killed, or the system will start swapping memory pages, or other processes will have to run their GC more aggressively (as V8 does in low memory conditions) which puts even more pressure on the system. All this adds up to very selfish apps that bog down a system and can become virtually unusable. These selfish apps are also unsuitable for use in poorer parts of the world where incomes are lower and additional memory is potentially unaffordable. I think it's probably okay to take the attitude that memory is cheap when you control the environment and you're paying for the memory, but in any other circumstance, shipping software that gluttonously gobbles memory is probably unacceptable and the #1 reason why C++ makes good sense as a language choice for writing a browser.
gte910h 13y ago
Most browsers are developed in C++ because for the timeframe in which the projects started, C++ was the performant answer
- RogerL 13y ago
  It still is. Consider, not just PC based browsers, but the one on your phone. Every JIT compile costs watts, not just time. There's a relatively large push to go back to C++ because of this (power usage). 20% reduced performance may not be noticable as far as user interaction goes, but it is sure noticed in terms of "my battery just died!". It's nice to have a common code base. C++ across multiple platforms reduces my cost, even if I have to pay for good programmer that understand the use of things like smart pointers.
  - gte910h 13y ago
    The browser in my phone is part Objective C and part C++, as part of the project descended from Konqueror, via WebKit. I'd contend the C++ parts are C++ for legacy reasons, aka, "It was the performant solution at the time KHTML was written". Very little mobile phone software these days is written in cross platform C++, of that it's mostly games. Most iPhone software is still written in Objective C, most Android software is still written in Java. For cross platform code, I'd say Xamarin or Unity C#, or Adobe's product line both are still beating out C++, even counting the games. Chrome is about 40% C++, and is now the default browser for android. C#/Xamarin would probably be what I'd standardize on if going for a true cross platform non-game app. Javascript/Unity3D or C+/Unity3D would probably be what I standardized on for games, with Futile being looked at hard for 2D games. Companies with a huge existing codebase (e.g. EA) likely find porting an existent engine cheaper than writing a new one, and will of course stick with their historical C++
    - Arelius 13y ago
      > Most iPhone software is still written in Objective C. Objective C shares many of the advantages of C/C++. > I'd say Xamarin or Unity C# Speaking of Unity, while much of the game specific code is written in C#. As far as CPU time, the vast majority of execution is spent in C++ code. Similarly on the Web, there is more Javascript code that runs in the browser than browser code. But most of the CPU time is spent in Browser C++.
pnp 13y ago
There was a browser written in Java in the past: http://en.wikipedia.org/wiki/HotJava http://en.wikipedia.org/wiki/HotJava
- specialist 13y ago
  I rank discontinuing HotJava as one of Sun's biggest missed opportunities. The stackexchange commenter moans about graphics performance in Java. I helped write the Magician OpenGL bindings for Java in the '90s (the Java API side was all me, which Sven of JOGL basically copied). My VRML browser was just as fast (fps) as the available VRML browsers written in C/C++. With JDK 1.1. Nowadays, Java and OpenGL go together like peas and carrots. Exhibit A is MineCraft. A good buddy of mine does all his projects in Java and OpenGL. The latest is the awesome 2D skeletal animator called Spine at http://esotericsoftware.com http://esotericsoftware.com. I couldn't imagine him doing it on top of any other stack.
  - eropple 13y ago
    > My VRML browser was just as fast (fps) as the available VRML browsers written in C/C++. With JDK 1.1. With respect, I find your claims dubious. I would certainly buy that your top framerate was competitive. I also expect that your framerate was significantly more stuttery and inconsistent due to garbage collection (or else written in such a devolved form of Java that you really might as well write C++ anyway). The problem is not Java's execution speed. It's that garbage collection is the death of responsiveness. > Nowadays, Java and OpenGL go together like peas and carrots. Exhibit A is MineCraft. Minecraft's performance characteristics are pretty bad for the fairly trivial rendering work being done. (It's improved, but it's still not great.) And writing code with LWJGL/JOAL is gross relative to similar code in C++--I have done both. You don't get anything for tying yourself to the JVM except, in a weird and mostly self-destructive way, the 'freedom' from understanding your object lifetimes and deterministic destruction. I've used libgdx and XNA/MonoGame extensively and have gone back to C++ because both are fairly limited in their usefulness. libgdx helps by hiding a lot of nasty API issues--and Mario and company are super good at what they do--but what it gives you is generally taken away by the limitations of the JVM in a client context (limited platform support, the infuriating Dalvik/Hotspot divide, That Frigging GC Again...). Writing up some pretty minor glue code between windowing, input, audio, and graphics isn't that bad. And, perhaps more importantly, you'll actually understand how it works. (I've spent the week fighting with OpenAL. I'm glad I did. I've learned a lot and can recognize the failure cases and can do something about them.) > A good buddy of mine does all his projects in Java and OpenGL. The latest is the awesome 2D skeletal animator called Spine at http://esotericsoftware.com http://esotericsoftware.com. I couldn't imagine him doing it on top of any other stack. Spine's pretty impressive, but there's not much in it you couldn't do with ease with Cocoa/Obj-C[++] or Qt or even WPF and .NET. It's also a misleading example, though, because tooling generally has much looser latency requirements than user software and so the severe weaknesses of JVM client applications are less readily apparent than in an application that needs to hit 60fps all day every day.
Millennium 13y ago
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. 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. Mozilla's at it again with Rust, though, and that looks like it could be an interesting project.
pcwalton 13y ago
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. 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).
- dustingetz 13y ago
  In 2013 I don't think it has anything 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 want to use Scala and need 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.
  - Arelius 13y ago
    > You can surely write a better browser from scratch in a language like Haskell. This isn't something quite as self-evident as you make it.
  - cwzwarich 13y ago
    Having written web browsers / browser engines and compilers for functional languages, I don't think you could do this with anything that exists today. And if you did it, the result would not be idiomatic Haskell; it would just have one huge monad threaded through the entire thing with no pure portion. You would also probably have to drop down to unsafe manual memory management for performance reasons.
shmerl 13y ago
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).
marpalmin 13y ago
Maybe a more interesting question is: Would you use C/C++ to develop a browser today?
- shmerl 13y ago
  Probably yes, if it's C++11 and UI is in Qt/QML for example.
- oscargrouch 13y ago
  how about to try a OS agnostic multiprocess architecture with IPC and/or shared mem, embeding a script language like javascript, with gpu acelleration, and video streaming in other language, that could have the same performance as c/c++ ?? Developers should be language/technology agnostic and just use the right tool for a given problem/solution, the same way you use a screwdriver for screws and a fork to eat..
- zxcdw 13y ago
  A browser ought to compete against Firefox and Chrome? Do managed languages come even close in resource usage(CPU and RAM) and consistent performance at projects at that scale?
deleted 13y ago
[deleted]
halayli 13y ago
low level performance and control with a lot of abstraction features.
AsymetricCom 13y ago
Because what else would you write it in?
wisty 13y ago
Why a C like language? Power. Browsers are CPU and memory hogs, and C is simply the best way of squeezing out more performance. Why an OO language? Well, while OO is overused, a HTML document looks a lot like a bunch of objects, doesn't it?

66 points by marpalmin 13y ago

hga 13y ago

Be sure and go down to the "Ask 'when' before 'why'" answer.

Interesting. With the recent influx of Go rewrites, I wonder if anyone would consider writing a browser in Go just as an experiment.

stevoski 13y ago
Has Go got a good UI library?
- tdees40 13y ago
  It does not, and this needs to change before Go becomes viable for applications like this.
azakai 13y ago
GC pauses might be an issue with Go (they don't matter that much in a Go server app, but in a client app like a browser things are very different).
marpalmin 13y ago
I had the same doubt.
redcircle 13y ago
I rewrote quite a bit of the Chromium browser in Go, achieving a 10x reduction in lines of code (I stopped this project before I could reliably evaluate performance). Since Chromium uses a multi-process model, this was pretty easy: I implemented the Chromium IPC protocol in Go (I wrote a Chromium utility to emit a JSON description of the IPC protocol), and then told the privileged and unprivileged Chromium processes to use my Go subprocess rather than the original logic. My Go logic ran on both Windows and Mac OS X.
- touristtam 13y ago
  Mind sharing if you have the code public ? :)
  - redcircle 13y ago
    Belongs to my employer :( Also, when I said 'quite a bit', I was thinking about the data-plumbing logic --- not UI and WebKit logic. It doesn't really make sense to rewrite WebKit.

joshmoz 13y ago

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: https://github.com/mozilla/servo https://github.com/mozilla/servo

fdej 13y ago

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

rossjudson 13y ago

There are a lot of poor or outdated answers to the question (arguing a lack of accelerated graphics, for example). 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. JIT compilation technology on the JVM (and elsewhere) these days is pulling within 20-50% of static C/C++ code. 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. By far the most important reason to choose a modern VM environment is security. Except in a vanishingly small number of cases, everything should always 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. 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. 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 much is done there that doesn't need to be. With a massive native code base it's just a huge problem to verify everything. 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. And around the corner, environments like the JVM can auto-vectorize on the fly (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7116452 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7116452), knocking down yet another performance-parity barrier.

kintamanimatt 13y ago
Performance doesn't just include CPU time, but also memory footprint. You might eat a similar amount of processor time, but you're not going to have a similar memory footprint with any kind of GC'd language, and if the GC happens to be a stop the world GC, you're likely to see pauses in the browser that will irritate the user. Before the inevitable "memory is cheap" argument is made, I'd rather have my client app be a good neighbor. Having a GC'd process on a client munch through memory like it's infinite is just bad manners and makes some bad assumptions. (On the flip side, a GC'd process that tries to be a good neighbor by freeing memory aggressively becomes a bad neighbor in terms of CPU time, which has additional consequences in terms of battery life.) The JVM, for example, tends to only run its GC when it needs to. It is a horrible neighbor in this respect because it just takes all the memory it needs and only runs its GC when it really, really has to. This is one of the reasons it's relatively fast, but as a consequence puts a lot of pressure on the system. In such a scenario it's possible other processes will OOM and be killed, or the system will start swapping memory pages, or other processes will have to run their GC more aggressively (as V8 does in low memory conditions) which puts even more pressure on the system. All this adds up to very selfish apps that bog down a system and can become virtually unusable. These selfish apps are also unsuitable for use in poorer parts of the world where incomes are lower and additional memory is potentially unaffordable. I think it's probably okay to take the attitude that memory is cheap when you control the environment and you're paying for the memory, but in any other circumstance, shipping software that gluttonously gobbles memory is probably unacceptable and the #1 reason why C++ makes good sense as a language choice for writing a browser.

gte910h 13y ago

Most browsers are developed in C++ because for the timeframe in which the projects started, C++ was the performant answer

RogerL 13y ago
It still is. Consider, not just PC based browsers, but the one on your phone. Every JIT compile costs watts, not just time. There's a relatively large push to go back to C++ because of this (power usage). 20% reduced performance may not be noticable as far as user interaction goes, but it is sure noticed in terms of "my battery just died!". It's nice to have a common code base. C++ across multiple platforms reduces my cost, even if I have to pay for good programmer that understand the use of things like smart pointers.
- gte910h 13y ago
  The browser in my phone is part Objective C and part C++, as part of the project descended from Konqueror, via WebKit. I'd contend the C++ parts are C++ for legacy reasons, aka, "It was the performant solution at the time KHTML was written". Very little mobile phone software these days is written in cross platform C++, of that it's mostly games. Most iPhone software is still written in Objective C, most Android software is still written in Java. For cross platform code, I'd say Xamarin or Unity C#, or Adobe's product line both are still beating out C++, even counting the games. Chrome is about 40% C++, and is now the default browser for android. C#/Xamarin would probably be what I'd standardize on if going for a true cross platform non-game app. Javascript/Unity3D or C+/Unity3D would probably be what I standardized on for games, with Futile being looked at hard for 2D games. Companies with a huge existing codebase (e.g. EA) likely find porting an existent engine cheaper than writing a new one, and will of course stick with their historical C++
  - Arelius 13y ago
    > Most iPhone software is still written in Objective C. Objective C shares many of the advantages of C/C++. > I'd say Xamarin or Unity C# Speaking of Unity, while much of the game specific code is written in C#. As far as CPU time, the vast majority of execution is spent in C++ code. Similarly on the Web, there is more Javascript code that runs in the browser than browser code. But most of the CPU time is spent in Browser C++.

pnp 13y ago

There was a browser written in Java in the past: http://en.wikipedia.org/wiki/HotJava http://en.wikipedia.org/wiki/HotJava

specialist 13y ago
I rank discontinuing HotJava as one of Sun's biggest missed opportunities. The stackexchange commenter moans about graphics performance in Java. I helped write the Magician OpenGL bindings for Java in the '90s (the Java API side was all me, which Sven of JOGL basically copied). My VRML browser was just as fast (fps) as the available VRML browsers written in C/C++. With JDK 1.1. Nowadays, Java and OpenGL go together like peas and carrots. Exhibit A is MineCraft. A good buddy of mine does all his projects in Java and OpenGL. The latest is the awesome 2D skeletal animator called Spine at http://esotericsoftware.com http://esotericsoftware.com. I couldn't imagine him doing it on top of any other stack.
- eropple 13y ago
  > My VRML browser was just as fast (fps) as the available VRML browsers written in C/C++. With JDK 1.1. With respect, I find your claims dubious. I would certainly buy that your top framerate was competitive. I also expect that your framerate was significantly more stuttery and inconsistent due to garbage collection (or else written in such a devolved form of Java that you really might as well write C++ anyway). The problem is not Java's execution speed. It's that garbage collection is the death of responsiveness. > Nowadays, Java and OpenGL go together like peas and carrots. Exhibit A is MineCraft. Minecraft's performance characteristics are pretty bad for the fairly trivial rendering work being done. (It's improved, but it's still not great.) And writing code with LWJGL/JOAL is gross relative to similar code in C++--I have done both. You don't get anything for tying yourself to the JVM except, in a weird and mostly self-destructive way, the 'freedom' from understanding your object lifetimes and deterministic destruction. I've used libgdx and XNA/MonoGame extensively and have gone back to C++ because both are fairly limited in their usefulness. libgdx helps by hiding a lot of nasty API issues--and Mario and company are super good at what they do--but what it gives you is generally taken away by the limitations of the JVM in a client context (limited platform support, the infuriating Dalvik/Hotspot divide, That Frigging GC Again...). Writing up some pretty minor glue code between windowing, input, audio, and graphics isn't that bad. And, perhaps more importantly, you'll actually understand how it works. (I've spent the week fighting with OpenAL. I'm glad I did. I've learned a lot and can recognize the failure cases and can do something about them.) > A good buddy of mine does all his projects in Java and OpenGL. The latest is the awesome 2D skeletal animator called Spine at http://esotericsoftware.com http://esotericsoftware.com. I couldn't imagine him doing it on top of any other stack. Spine's pretty impressive, but there's not much in it you couldn't do with ease with Cocoa/Obj-C[++] or Qt or even WPF and .NET. It's also a misleading example, though, because tooling generally has much looser latency requirements than user software and so the severe weaknesses of JVM client applications are less readily apparent than in an application that needs to hit 60fps all day every day.

Millennium 13y ago

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. 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. Mozilla's at it again with Rust, though, and that looks like it could be an interesting project.

pcwalton 13y ago

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

dustingetz 13y ago
In 2013 I don't think it has anything 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 want to use Scala and need 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.
- Arelius 13y ago
  > You can surely write a better browser from scratch in a language like Haskell. This isn't something quite as self-evident as you make it.
- cwzwarich 13y ago
  Having written web browsers / browser engines and compilers for functional languages, I don't think you could do this with anything that exists today. And if you did it, the result would not be idiomatic Haskell; it would just have one huge monad threaded through the entire thing with no pure portion. You would also probably have to drop down to unsafe manual memory management for performance reasons.

shmerl 13y ago

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

marpalmin 13y ago

Maybe a more interesting question is: Would you use C/C++ to develop a browser today?

shmerl 13y ago
Probably yes, if it's C++11 and UI is in Qt/QML for example.
oscargrouch 13y ago
how about to try a OS agnostic multiprocess architecture with IPC and/or shared mem, embeding a script language like javascript, with gpu acelleration, and video streaming in other language, that could have the same performance as c/c++ ?? Developers should be language/technology agnostic and just use the right tool for a given problem/solution, the same way you use a screwdriver for screws and a fork to eat..
zxcdw 13y ago
A browser ought to compete against Firefox and Chrome? Do managed languages come even close in resource usage(CPU and RAM) and consistent performance at projects at that scale?

deleted 13y ago

[deleted]

halayli 13y ago

low level performance and control with a lot of abstraction features.

AsymetricCom 13y ago

Because what else would you write it in?

wisty 13y ago

Why a C like language? Power. Browsers are CPU and memory hogs, and C is simply the best way of squeezing out more performance. Why an OO language? Well, while OO is overused, a HTML document looks a lot like a bunch of objects, doesn't it?