Browsersphere

All the nonsense aside, now that it seems like multi-process architectures are beginning to surface in the world of web browser development, I thought it would be a good idea to dig in to the feature a bit and, at the very least, provide links to some useful information for those who are interested in what multi-process architectures mean for web browsers.

One of the more notable features included in the unveiling of Google’s Chrome was what Google refers to as “Crash Control.”  This feature allows for a “Windows Task Manager” type of interface for managing web browser processes.  Aside from providing the interface for explicit management of the running (or dying) processes, it is also meant to shield tabs within the same running instance of the browser chrome (for lack of a better word) from any issues arising in other concurrently running tabs.  In essence, when you accidentally load a web page in one tab that was developed using Microsoft Word, you don’t have to worry about the severe code bloat of the page bringing your other tabs to a screeching halt.  Or if the JavaScript of one page goes off into la-la land, you won’t necessarily lose any of the other non-offending tabs.

Months after this feature was unveiled in Chrome, it was announced as a feature of Maxthon under the name “The Isolator:”

Maxthon 2.5.1…includes a feature called The Isolator that separates the functions of each Web tab from all other tabs and other parts of the browser. The Isolator protects other tabs from also becoming frozen because a single unresponsive tab is monopolizing a computer’s resources.

Though it certainly wasn’t the first implementation (despite what MaxthonGuy might want you to believe), The Isolator is one of the first official implementations of a multi-process architecture among the web browsers that actually show up on the Browsersphere radar.  Unlike Chrome’s “Crash Control,” though, The Isolator is still considered to be “in advanced beta.”

Other than the press release, I wasn’t able to find much on Maxthon’s actual implementation.  On the other hand, there has been plenty of coverage on Chrome’s implementation.  Marc Chung, for example, does an excellent job of explaining Chrome’s process model.  He even goes so far as to show you how you can control the type of process model used by Chrome at launch time.  He also points to another interesting article from Chromium Blog that explains why Chrome uses the multi-process architecture and why the architecture is more relevant today than it was when web browsers were first created, and refers to a publication from which Chrome’s process model was derived.

Though the multi-process architecture has been heralded by many web users, it isn’t without its downsides.  Google Chrome Memory Usage – Good and Bad explains the trade-offs of separating tabs into their own distinct processes, including the following:

While the multi-process model provides clear robustness and performance benefits, it can also be a setback in terms of using the absolute smallest amount of memory. Since each tab is its own “sandboxed” process, tabs cannot share information easily. Any data structures needed for general rendering of web pages must be replicated to each tab.

For more information on Chrome’s implementation of the multi-process architecture from both a developer’s and end user’s perspective, I recommend checking out the following links:

• Chromium Developer Documentation – Process Models
• Developers and Webmasters: Task Manager
• Crash Control (Video)
• How can my web page open a new tab in a separate process?

And finally, here are some other multi-process-related links related to web browsers other than Maxthon and Chrome:

• The Firefox Process Model
• Download Stainless for Mac – Multi-process web browser
• Evidence tabs will get more attention in future Firefox releases
• Google Chrome vs. Internet Explorer 8 (note the mention that IE8 Beta 2 may have beaten Chrome to the punch, albeit with a slightly different approach to the overall architecture)
• IE8 and Loosely-Coupled IE (LCIE)
• Making Firefox More Robust (interestingly enough, this is from the author of the aforelinked publication, Charlie Reis)

Tags: Architecture, Charlie Reis, Chrome, Chromium Blog, Crash Control, Firefox, Google Chrome, IE8, Maxthon, MaxthonGuy, Multi-process, Performance, Stainless, The Isolator

I always get a kick out of reading the Maxthon Blog because some of the claims made about either Maxthon or its competitor web browsers are so outlandish.  This time around, a press release was posted claiming the following:

Maxthon’s engineers redesigned the browser’s framework so that each tab associated with a Web site works independent of each other. With that new architecture, if a tab becomes unresponsive for any reason, the other tabs and the browser are unaffected. The computer user can continue to browse normally and can refresh, reopen, or close the tab that is creating problems.

“Basically, our technology separates the tab and the browser,” said Jeff Chen, CEO of Maxthon. “That [sic] why the tab’s problem will not affect the browser’s performance, and so the browser can be a better environment to run Web application in tabs.

“As far as I know, no other major browser has such a feature,” Chen said.

I can understand making a claim like that last one in a press release, since you’re trying to set yourself apart from the competition.  Plus, Jeff Chen said “as far as I know,” which at least keeps the claim from being matter-of-fact.  However, I think it’s pretty inexcusable to make such matter-of-fact claims directly on your product’s blog when common knowledge suggests the opposite.

Before posting the aforelinked press release, the following was posted to the Maxthon Blog:

“…other browsers without [Maxthon's new feature] The Isolator – which would be, let’s see…. All of them. – can’t protect their tabs the way Max does.”

When an astute (or at least, non-delusional) commenter mentioned Google Chrome as a browser already supporting this feature, MaxthonGuy, the persona behind the madness that is Maxthon Blog, had this to say:

“Chrome does have a feature, Crash Control, that has a purpose similar to that of The Isolator. But the two technologies work differently, and Crash Control can’t save you from the Flash-inspired crashes that The Isolator blocks.”

So I guess if a feature has been implemented differently, then it doesn’t actually exist in any other browser.  Using that logic, I suppose Internet Explorer was the first web browser to support tabbed browsing.  But don’t worry, Firefox and Safari fans, your browsers were, too – despite what Opera or NetCaptor might have to say about it!

I just had to get this absurdity out of the way before I post a more in-depth look at multi-process architectures in web browsers.

Tags: Architecture, Chrome, Crash Control, Features, History, Maxthon, Maxthon Blog, MaxthonGuy, Multi-process, NetCaptor, Tabs, The Isolator