Opera na WebKicie: pierwsze reakcje webowej społeczności

W dziedzinie technologii webowych wiadomością tygodnia,jeśli nie miesiąca, jest na pewno zapowiedź porzucenia przez OperęSoftware swojego własnego silnika renderującego i skryptowego, izastąpienia go wziętą z projektu Chromium odmianą WebKita. Zwiadomości prasowej bije oczywiście entuzjazm, a zmianaprzedstawiana jest w samych superlatywach. Hakon Wium Lie, dyrektortechniczny Opery, już zapowiedział, że deweloperzy z jego firmybędą teraz pracowali nad ulepszeniami WebKita (rozwijanego teżprzez Google i Apple). Jak na to patrzą jednak inni ludzie związaniz webowymi technologiami? Czy decyzja Opery nie zaszkodzi całemuWWW?Jednym z pierwszych, którzy skomentowalidecyzję o porzuceniu przez Operę prac nad własnymsilnikiem był Robert O'Callahan z Mozilli. Dla niego to smutnydzień dla całego Webu –szczególnie, że uważał operowy silnik Presto za znakomitątechnologię, w szczególności chwaląc zapewniany przez Prestopoziom wsparcia dla standardów WWW. Teraz wpływ Opery na rozwójwebowych standardów ma dramatycznie zmaleć, szczególniegdyby norweski producent chciał zrobić coś inaczej niżApple i Google.Dla O'Callahana decyzja Operyoznacza też, że prace prowadzone w Mozilli staną się jeszczeważniejsze, i jeszcze trudniejsze. Monokultura WebKitu naurządzeniach mobilnych będzie bardzo trudna do przełamania, coraztrudniej będzie promować programowanie „na standardy”, gdywszyscy będą programowani „pod WebKit”. A to, że WebKit jestopensource'owym silnikiem niczego tak naprawdę nie zmienia – małokto, poza programistami z Mountain View i Cupertino może podejmowaćdecyzje dotyczące jego rozwoju, nie mówiąc już o tym, że usterkiWebKita staną się nowym „standardem”, do któregodostosować się będą musieli Mozilla i Microsoft –producenci pozostałych na scenie silników.Na drugim biegunie znaleźć możnaopinie zupełnie odmienne. John Resig, twórca jQuery,najpopularniejszej dziś biblioteki JavaScriptu, twierdzi że WebKit(wspólny framework do implementacji zgodnych ze standardamikomponentów przeglądarek) jest dokładnie tym samym co jQuery(wspólny framework do implementowania zgodnych ze standardami DOMdoświadczeń na stronach WWW). Jegozdaniem, kultywowane są cztery mity, przez które decyzja Operywygląda na znacznie straszniejszą, niż jest w rzeczywistości: Przejście Opery na WebKit skończy się stagnacją silników renderujących – tymczasem przecież KDE stworzyło KHTML, z którego Apple stworzyło WebKit, z którego Google stworzyło WebKit/Chromium, a nikt (?) nie może zaprzeczyć, że Chrome/Chromium jest lepszą przeglądarką niż Safari, które jest lepszą przeglądarką niż Konqueror. Według Resiga, utalentowani ludzie Opery też mogą wprowadzić wiele wymaganych przez ich przeglądarkę elementów do WebKitu, a z czasem elementy te mogą trafić do innych przeglądarek. Przejście Opery na WebKit sprawi, że silnik ten stanie się de facto standardem – jednak według Resiga, WebKit już jest standardem, podobnie jak standardem stało się jQuery (i jest to czymś dla Resiga wspaniałym). A błędy i tak będą naprawiane – każdy z producentów może przecież usuwać usterki we własnym forku kodu silnika. Przejście Opery na WebKit zaszkodzi jej możliwościom wpływania na standardy – Resig uważa, że większym problemem w tej kwestii dla Opery jest przejście Anne van Kesterena, ich człowieka od webowych standardów, do Mozilli. Opera jest małym graczem, zmiana silnika w IE czy Firefoksie byłaby większym problemem – Resig wierzy, że wcześniej czy później i tak do tego dojdzie. Mozilla i Microsoft będą odczuwały coraz większą presję, by zmienić silniki swoich przeglądarek, choćby tylko po to, by móc nadążyć za WebKitem, standardem na platformach mobilnych. W tej sytuacji jest to tylko decyzja biznesowa – jeśli twoi programiści muszą poświęcić znaczną część swojego czasu na implementowanie standardów, które implementują też wszyscy inni, to znaczy to, że uniemożliwiłeś im zajęcie się czymś, co pozwoliłoby się od innych odróżnić. Pozytywnym przykładem ma być tu Chrome, którego deweloperzy uwolnieni od rozwijania własnego silnika renderującego mogli zmiażdżyć wszystkich wydajnością przeglądarki.[img=doubts]Kto ma rację? Złośliwi czasemmówią, że jQuery to IE7 webowych frameworków,autor tej notki też wcale nie jest zachwyconyproliferacją biblioteki Johna Resiga, mając znacznie lepszedoświadczenia np. z Prototype czy dojo. Nie można też zapomnieć ojednej kwestii – Presto znacznie wydajniej niż inne silnikidziała na słabych urządzeniach, nawet takich, które nie miałyporządnej wersji kompilatora GCC (i trzeba było używać jakichśegzotycznych kompilatorów). Może w Zachodniej Europie czy USA niema to większego znaczenia (wszyscy już chodzą z wielordzeniowymismartfonami w kieszeniach), ale rynki wschodzące, takie jak Chiny,Afryka, Indie, kraje Ameryki Południowej to już inna sprawa, tamwciąż większość urządzeń mobilnych nie jest w stanieuruchomić mobilnego Firefoksa, nie mówiąc już o Chrome.Podsumowując – jest jak wnaturze. Uboższe ekosystemy są bardziej podatne na choroby, autratę Presto trudno ocenić inaczej, jak zubożenie webowegoekosystemu. Pierwsze konsekwencje triumfu WebKitu odczujemy pewniedopiero za kilka lat, ale mogą to być konsekwencje równiedługofalowe, jak niegdyś efekt upowszechnienia się InternetExplorera 6 z jego niezgodną ze standardami obsługą CSS czyActiveX-em.