r   e   k   l   a   m   a
r   e   k   l   a   m   a

WebKit nie dla Microsoftu i Mozilli: własny silnik renderujący nie do zastąpienia?

Strona główna Aktualności

Informacja o porzuceniu przez Operę Software rozwijanego przez kilkanaście lat silnika renderującego Presto i przejściu na WebKit zelektryzowała tak społeczność webdeweloperów jak i użytkowników tej norweskiej przeglądarki. Sama firma przedstawia oczywiście tę decyzję jako korzystną, zarówno z perspektywy biznesowej jak i technologicznej. Podobnie uważa też John Resig, twórca biblioteki JavaScriptu jQuery, którego zdaniem najlepiej by było, by wszyscy pozostali producenci przeglądarek, utrzymujący własne silniki renderujące, poszli w ślady Opery i przeszli na WebKit. A co na to sami zainteresowani?

Szanse na to, że Microsoft poszedłby za radą Johna Resiga wydawały się znikome. I faktycznie, jedyny komentarz, jaki uzyskaliśmy z biura prasowego Microsoftu w sprawie decyzji Opery Software i jej wpływu na rynek przeglądarek brzmiał: Microsoft jako spółka giełdowa nie komentuje decyzji konkurencji. Skupiamy się na zapewnieniu zgodności przeglądarki z przyjętymi standardami i w tym kierunku zdążają dziś nasze działania.

Nic dziwnego: posiadanie własnego silnika renderującego, dopasowanego do technologii „zaszytych” w Windows, to dla Microsoftu sprawa kluczowa. Trident w wersji 5.0 i 6.0 (IE9 i IE10) wykorzystywany jest dziś przecież nie tylko w tych przeglądarkach, ale też w wielu innych kluczowych dla Microsoftu aplikacjach – Outlooku, Enkarcie, Visual Studio, Windows Media Playerze czy Skype. Z Tridenta korzysta też wiele aplikacji firm trzecich, więc zastąpienie tego engine'u WebKitem byłoby poważnym kłopotem dla całego ekosystemu oprogramowania dla Windows.

A jak wygląda sprawa z Mozillą? Czy deklarowanemu celowi organizacji nie przysłużyłoby się porzucenie Gecko i przeniesienie Firefoksa na WebKit? Sprawą tą zajął się dyrektor techniczny Mozilli, Brendon Eich, wyjaśniając nie tylko techniczne aspekty takiej zmiany, ale też i kwestie związane z wartościami, którym producent Firefoksa służy.

Eich daje jasno do zrozumienia, że Mozilla to nie Opera – firma w której zmieniło się znacznie więcej, niż tylko silnik renderujący. W styczniu tego roku miał on dostać list od przyjaciela, sugerujący, że w firmie, której pracownicy byli współautorami kluczowych technologicznych innowacji dla WWW, zwalniani są starsi programiści, firma przechodzi restrukturyzację. Najwyraźniej były to zmiany przygotowujące grunt pod przejście na WebKit.

Tylko jaki to WebKit? Wbrew triumfalnym deklaracjom o jednym silniku, by wszystkie technologie webowe zgromadzić i we wspólnym kodzie związać, sytuacja w WebKicie jest daleka od jedności. WebKit podzielony jest nie tylko pod względem biznesowym – rozmaitymi potrzebami Google'a i Apple'a (do których dojdą teraz potrzeby Opery), ale też pod względem technicznym. Liczne forki, odmiany dla urządzeń mobilnych, odmienne modele wieloprocesowości, osiem stosowanych systemów kompilacji – Eich twierdzi, że jedynie dzięki dyplomatycznym talentom szefów projektów z konkurencyjnych firm, udaje się utrzymać wymianę kodu między odmianami WebKitu. Dla Mozilli jest tu zbyt wielu kucharzy, by z kuchni WebKitu dostać coś smacznego.

O wiele lepiej jest więc dla Mozilli wymyślić nowy, własny silnik, niż brać cudzy kod. Przełączenie Firefoksa z silnika Gecko na WebKit oznaczałoby rezygnację z języka XUL, a to oznaczałoby konieczność rezygnacji z tych wszystkich tysięcy rozszerzeń do Firefoksa. Oznaczałoby to też utratę modelu bezpieczeństwa stosowanego w Firefoksie, paska Awesome Bar i wielu innych komponentów Firefoksa, których ot tak przenieść na WebKit nie można.

Eich przyznaje, że gdyby był na miejscu decydentów Opery, pewnie podjąłby taką samą decyzję. Nastawiona na zysk firma, o niewielkim udziale w rynku desktopowych przeglądarek, nie jest w stanie rozwijać konkurencyjnego silnika renderującego. Jednak Mozilla to nie Opera, Mozilla to coś więcej niż spółka akcyjna, a udział Firefoksa w rynku jest na tyle duży, by móc sobie pozwolić na niezależność.

Jednak nawet z biznesowego punktu widzenia, decyzja Opery nie jest wolna od ryzyka. Zdaniem Eicha problem leży w tym, że porzucenie własnego silnika oznacza, że produkt może konkurować tylko na polu dystrybucji. Jednak innowacje w zakresie interfejsu są bardzo łatwe do sklonowania, a użytkownicy przechodzą między nimi bez mrugnięcia okiem. Tak oto w ciągu roku upadł w Chinach Maxthon, a zastąpiła go przeglądarka Qihoo – programy korzystające z cudzych technologii.

Zainteresowani przyszłością silników renderujących powinni koniecznie przeczytać wspomniany felieton Brendana Eicha: rozważa on tam kwestie wielowątkowego kodu, współbieżności, architektur wielordzeniowych i tego wszystkiego, co może w przyszłości zaoferować hardware. Bez względu na to, co miałaby przynieść przyszłość, to jedno jest pewne: Mozilla sobie z tym poradzi.

r   e   k   l   a   m   a
© dobreprogramy
r   e   k   l   a   m   a
r   e   k   l   a   m   a

Komentarze

r   e   k   l   a   m   a
r   e   k   l   a   m   a
Czy wiesz, że używamy cookies (ciasteczek)? Dowiedz się więcej o celu ich używania i zmianach ustawień.
Korzystając ze strony i asystenta pobierania wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.