W Google Chrome ten mechanizm działa od dawna - poszczególne zakładki i wtyczki są uruchamiane w oddzielnych procesach systemowych. Dzięki temu jeśli którakolwiek z nich ulegnie awarii (np. zawiesi się z powodu błędu strony), to użytkownik nie musi restartować aplikacji i tracić wszystkich otwartych stron - wyłącza się jedynie ta, która się zawiesiła.
Takiego rozwiązania nie znajdziemy w Firefoksie czy Safari - efekt jest taki, że jeśli któraś z otwartych w tych przeglądarkach kart zawiesi się, to wyłączana jest cała aplikacja i użytkownik trafi wszystkie otwarte zakładki. Oczywiście, zwykle da się je później odtworzyć - ale mimo wszystko rozwiązanie znane z Chrome jest dużo wygodniejsze. Dodajmy, że poszczególne zakładki w oddzielnych procesach uruchamia również Internet Explorer Microsoftu - problem w tym, że w przypadku tej przeglądarki mimo takiego rozwiązania zdarza się, iż zawieszenie jednej z uruchomionych kart powoduje wyłączenie całej przeglądarki (aczkolwiek nie jest to regułą).
Koncepcja ta na tyle przypadła do gustu autorom projektu WebKit, że postanowili wprowadzić podobny mechanizm do WebKit2 (szykowanej właśnie kolejnej wersji "silnika"). Z informacji przedstawionych przez serwis Daringfireball.net wynika, że w tym przypadku separowanie procesów pójdzie nawet dalej - oddzielane będą nie tylko poszczególne zakładki, ale również moduły obsługujące różne typy zawartości serwisów WWW (JavaScript, HTML itd.). A dzięki temu, że to rozwiązanie zostanie wprowadzone bezpośrednio do WebKita, to bez większych problemów będzie można wprowadzić go do każdej przeglądarki wykorzystującej ów "silnik". Czyli również Safari Apple'a (zarówno dla Mac OS X, jak i iPhone OS), Maxthona czy mobilnej przeglądarki wykorzystywanej w systemie Android lub Symbian S60.
Dodajmy, że w projekt WebKit (zainicjowany i wciąż nadzorowany przez Apple) zaangażowane są obecnie m.in. Google, Nokia, KDE oraz RIM (producent urządzeń Blackberry).
Daniel Cieślak
