Dziudek's jogger

W celu uporządkowania kursu postanowiłem raz jeszcze opublikować wpisy, które już się ukazały, ale w zmienionej formie i rozszerzone o nowości jakie pojawiły się w finalnej wersji frameworka MooTools 1.2

MooTools jest podstawą do tworzenia złożonych skryptów/aplikacji opartych o JavaScript. Jakie korzyści zyskujemy dzięki wykorzystaniu gotowego frameworka takiego jak MooTools, jQuery czy Prototype ?

Przede wszystkim tworzymy kod zdecydowanie szybciej, a to głównie dzięki temu, że zamiast dbać o to by kod zadziałał w Internet Explorerze i pozostałych przeglądarkach skupiamy się na istocie działania skryptu/aplikacji. To MooTools dba o to by w wyniku wywołania metody addEvent dla Internet Explorera została wywołana metoda attachEvent, a w pozostałych przeglądarkach metoda addEventListener. Po prostu MooTools zapewnia nam kompatybilny z wieloma przeglądarkami interfejs programistyczny, który możemy wykorzystywać do realizacji swoich (często wyszukanych) pomysłów.

Oczywiście świat nie jest taki różowy jak by się mogło niektórym wydawać. W wyniku wykorzystania MooTools na danej stronie musimy wzbogacić naszą witrynę o dodatkowe kilobajty danych - na szczęście przy skrajnej kompresji (kompresja YUI + GZIP) rozmiar MooTools 1.2 bez pluginów oscyluje w granicach 18kB.

Przy czym można w optymalizacji posunąć się jeszcze dalej, ale o tym za chwilę. Inną o wiele poważniejszą wadą wszelkich gotowych bibliotek JS jest fakt, że są one po prostu wolniejsze od "czystego" JS. Nie muszę chyba nikogo przekonywać, że wywołanie:

document.getElementById("test");

Jest szybsze niż MooTools'owe:

$("test");

Choć oczywiście zapis jest krótszy. No ale takie są uroki gotowych rozwiązań. Dlatego w wypadku szczególnie czasochłonnych fragmentów kodu warto jednak stosować czysty JS w miejsce odpowiedników opartych o MooTools czy inne rozwiązania.

Wracając do optymalizacji rozmiaru pobieranych wraz ze stroną plików. Po pierwsze końcowy rozmiar możemy zmniejszyć poprzez nie zaznaczanie zbędnych elementów frameworka na stronach pozwalających pobrać skrypt: http://mootools.net/core i http://mootools.net/more.

Jak już pewnie niektórzy wiedzą strona pobierania pluginów została oddzielona od strony umożliwiającej pobranie samego frameworka - dlatego warto zapoznać się z zawartością obu stron pobierania.

Dalszą optymalizację rozmiaru osiągniemy poprzez wybór odpowiedniej techniki kompresji - YUI jest najskuteczniejszą metodą kompresji z dostępnych, a przy tym pozbawioną tak krytykowanej kiedyś funkcji eval, która w połączeniu ze skompresowanym kodem JS dawała bardzo dobre rezultaty kompresji (MooTools 1.11 skompresowany taką techniką miał rozmiar około 44kB wobec około 63kB otrzymanych przy użyciu YUI), jednak dekompresja skryptu nieraz powodowała zawieszenie przeglądarki lub po prostu brak odpowiedzi.

Do testowania skryptów lepiej oczywiście wykorzystać wersję bez kompresji - pozwoli to znaleźć szybko przyczynę błędów, gdyż bardzo często narzędzia takie jak Firebug nie wskazują na fragment naszego skryptu, ale na fragment kodu frameworka w którym wystąpił błąd (na przykład brak jakiegoś elementu do którego odwołuje się skrypt).

A co jeśli GZIP + YUI nam nie wystarcza ? Teoretycznie istnieje kolejna możliwość zoptymalizowania ilości pobieranych danych. Choć na razie jeszcze póki nie jest to powszechne nie jest to z pewnością tak skuteczne, ale w perspektywie przyszłości warto się taką możliwością zainteresować, chodzi mi o AJAX Libraries API od Google, którego działanie bazuje na cache'u przeglądarek - umieszczamy na stronie znacznik script odnoszący się do biblioteki MooTools umieszczonej na serwerach Google - dzięki temu gdy użytkownik odwiedzi kilka stron korzystających z takiego udogodnienia, to jego przeglądarka pobierze plik frameworka tylko raz - w pozostałych wypadkach nastąpi odczyt z cache'u przeglądarki. Wady ? Brak dostępności MooTools 1.2 (przynajmniej ja nie znalazłem w chwili pisania tego wpisu). Ale trzeba przyznać pomysł bardzo dobry, a przy okazji stwarza możliwość zbadania popularności różnych frameworków, oczywiście jeżeli metoda ta się spopularyzuje ;)

Jeszcze mała uwaga na temat dołączania plików MooTools i skryptów z nim związanych do stron. Osobiście polecam osadzanie skryptów w zewnętrznych plikach, tak by nie zaśmiecać kodu stron kodem JS - ja osobiście dołączam do stron z reguły dwa pliki:

<script type="text/javascript" src="mootools.js"></script>
<script type="text/javascript" src="engine.js"></script>

Polecam przy tym by plik mootools.js zawierał połączone pliki rdzenia frameworka i pluginów - po co dołączać trzy pliki zamiast dwóch :) W pliku engine.js mamy natomiast właściwy skrypt pisany w oparciu o MooTools - nie dołączam jego zawartości do pliku mootools.js z prostego powodu - trzeba zachować porządek i czytelność - framework to framework, a skrypt bazujący na frameworku to już coś osobnego.

Ważne jest też by pamiętać, że zapis:

<script type="text/javascript" src="engine.js"></script>
<script type="text/javascript" src="mootools.js"></script>

Jest z reguły niepoprawny i skończy się błędem (najczęściej) z powodu odwoływania się w kodzie skryptu to niezadeklarowanych obiektów.

Kończąc tą część wpisu, chciałbym jeszcze zwrócić uwagę na to, że najlepiej przy korzystaniu z MooTools wykorzystywać DOCTYPE XHTML. Dlaczego ? Niektóre elementy frameworka pracują poprawnie tylko z takim DOCTYPE, dlatego lepiej od razu się do tego faktu przyzwyczaić, albo zapamiętać go by później nie być zdziwionym gdy klasa Fx.Scroll czy Fx.Slide zacznie się zachowywać dziwnie (lub w ogóle nie będzie działać) na stronie zgodnej z HTML 4.01 Transitional ;)