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

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

Strona główna Aktualnoś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, i zastąpienia go wziętą z projektu Chromium odmianą WebKita. Z wiadomości prasowej bije oczywiście entuzjazm, a zmiana przedstawiana jest w samych superlatywach. Hakon Wium Lie, dyrektor techniczny Opery, już zapowiedział, że deweloperzy z jego firmy będą teraz pracowali nad ulepszeniami WebKita (rozwijanego też przez Google i Apple). Jak na to patrzą jednak inni ludzie związani z webowymi technologiami? Czy decyzja Opery nie zaszkodzi całemu WWW?

Jednym z pierwszych, którzy skomentowali decyzję o porzuceniu przez Operę prac nad własnym silnikiem był Robert O'Callahan z Mozilli. Dla niego to smutny dzień dla całego Webu – szczególnie, że uważał operowy silnik Presto za znakomitą technologię, w szczególności chwaląc zapewniany przez Presto poziom wsparcia dla standardów WWW. Teraz wpływ Opery na rozwój webowych standardów ma dramatycznie zmaleć, szczególnie gdyby norweski producent chciał zrobić coś inaczej niż Apple i Google.

Dla O'Callahana decyzja Opery oznacza też, że prace prowadzone w Mozilli staną się jeszcze ważniejsze, i jeszcze trudniejsze. Monokultura WebKitu na urządzeniach mobilnych będzie bardzo trudna do przełamania, coraz trudniej będzie promować programowanie „na standardy”, gdy wszyscy będą programowani „pod WebKit”. A to, że WebKit jest opensource'owym silnikiem niczego tak naprawdę nie zmienia – mało kto, poza programistami z Mountain View i Cupertino może podejmować decyzje dotyczące jego rozwoju, nie mówiąc już o tym, że usterki WebKita staną się nowym „standardem”, do którego dostosować się będą musieli Mozilla i Microsoft – producenci pozostałych na scenie silników.

Na drugim biegunie znaleźć można opinie zupełnie odmienne. John Resig, twórca jQuery, najpopularniejszej dziś biblioteki JavaScriptu, twierdzi że WebKit (wspólny framework do implementacji zgodnych ze standardami komponentów przeglądarek) jest dokładnie tym samym co jQuery (wspólny framework do implementowania zgodnych ze standardami DOM doświadczeń na stronach WWW). Jego zdaniem, kultywowane są cztery mity, przez które decyzja Opery wyglą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.

Kto ma rację? Złośliwi czasem mówią, że jQuery to IE7 webowych frameworków, autor tej notki też wcale nie jest zachwycony proliferacją biblioteki Johna Resiga, mając znacznie lepsze doświadczenia np. z Prototype czy dojo. Nie można też zapomnieć o jednej kwestii – Presto znacznie wydajniej niż inne silniki działa na słabych urządzeniach, nawet takich, które nie miały porządnej wersji kompilatora GCC (i trzeba było używać jakichś egzotycznych kompilatorów). Może w Zachodniej Europie czy USA nie ma to większego znaczenia (wszyscy już chodzą z wielordzeniowymi smartfonami w kieszeniach), ale rynki wschodzące, takie jak Chiny, Afryka, Indie, kraje Ameryki Południowej to już inna sprawa, tam wciąż większość urządzeń mobilnych nie jest w stanie uruchomić mobilnego Firefoksa, nie mówiąc już o Chrome.

Podsumowując – jest jak w naturze. Uboższe ekosystemy są bardziej podatne na choroby, a utratę Presto trudno ocenić inaczej, jak zubożenie webowego ekosystemu. Pierwsze konsekwencje triumfu WebKitu odczujemy pewnie dopiero za kilka lat, ale mogą to być konsekwencje równie długofalowe, jak niegdyś efekt upowszechnienia się Internet Explorera 6 z jego niezgodną ze standardami obsługą CSS czy ActiveX-em.

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.