All nontrivial systems programs converge on an operating system. By which I mean the kernel, not the desktop environment. Google's Chrome is, I think, the closest a browser has gotten to being an OS kernel. This is an interesting development because if browsers have to replicate much of the same behavior as an OS kernel, then functionality can move from the actual OS kernel up into the browser. OS kernels may then become leaner as more applications are run inside the browser instead of natively on the OS kernel.
Which is close to a micro-kernel architecture, except in a form I don't think anyone anticipated 10 years ago.
Where the desktop environment lies may change, too. Will browsers start co-opting that as well, or is it still best to run that directly on top of the OS kernel? I think so, but I'm going on intuition, not experiment or practice.
Most modern browsers (especially FF3) are trying to do an operating system's job — scheduling logically independent processes, micro-managing memory allocations, mapping virtual memory, providing an internal windowing system, providing an internal GUI scripting system.
Chrome does none of these things. It parries them off to the real operating system, where they belong.
PS: I don't think browsers are a true kernel but they are getting a lot closer. I am going to wait a few months for chrome to work the major bugs out and then try it.
That is exactly what Chrome is not. It's not a monolithic process, with a large pool of green threads being scheduled to run on native threads using runtime trickery.
Instead it's just a bunch of shared-nothing exec-ed processes that are scheduled by the OS kernel, have their mallocs handled directly by the OS libc, and have their address space mapped and reclaimed by the OS kernel's VMM.
Yes, they are still scheduled by the OS kernel, but they are also being controlled by my own scheduling algorithms. I call this scheduling, because it's the same problem as OS level scheduling. And if I have to do it, I imagine Chrome has to do it. In this scenario, if you want to understand the runtime behavior of the threads, you must consider both OS kernel level decisions and my scheduling decisions.
I would also be surprised if there was no Chrome memory management inbetween malloc and the OS kernel.
"Web content has evolved to contain significant amounts of active code that run within the browser, making many web sites more like applications than documents. This evolution has changed the role of the browser into an operating system rather than a simple document renderer. Unlike current browsers, Chromium is built like an operating system to run these applications in a safe and robust way, using multiple OS processes to isolate web sites from each other and from the browser itself."
Emphasis mine.
For instance, on OS X, the Command-Control-D shortcut to auto-define any word you're overing over. Or the universal spell-check. Things that make things easier for developers and users alike.
I think a part of it is the operating system in question. Some really do stay out of your way, and it makes the browser in question something of importance. Others are much more pervasive.
I said on another thread that I couldn't imagine using a desktop mail app until I got my Mac, because it wasn't until Mail that I had something that really felt like a part of the system. And from what I know of fellow Mac-using students, they all feel the same way. I know a lot of Windows students who use Meebo as their default chat. Linux users almost all use Pidgin or Kopete. Mac users almost always stick with iChat. On Windows, where Meebo is more accessible than downloading something new, the web will be used more often. With more well-rounded platforms, though, the web isn't seen as being quite so pervasive.