my
co robimy
blog
kariera
kontakt
poprzedni
Chroń dane!

Chroń dane!

Naszym aplikacjom zapewniamy najwyższe standardy bezpieczeństwa. Ochronimy dane osobowe Twoich Klientów i zabezpieczymy akcje promocyjne na Twoich stronach. Przeprowadzimy audyt bezpieczeństwa dla Twojego biznesu w sieci.
Bądź w kontakcie!

Bądź w kontakcie!

Dla naszych klientów przygotowaliśmy system do e-mail marketingu, który dodajemy do naszych realizacji. Bez abonamentu, bez opłat za wysyłkę poczty! Prosty w obsłudze, sprawny i skuteczny w działaniu. W pełni zintegrowany z pozostałymi naszymi produktami!
Zostań gwiazdą!

Zostań gwiazdą!

Potrafimy solidnie namieszać! Namieszamy też dla Ciebie.
Gwarantujemy, że dzięki nam, będzie o Tobie głośno, a Twoje produkty będą tematem niejednej dyskusji. Przekonaj się sam!
Bądź pierwszy!

Bądź pierwszy!

Z nami nie zginiesz. Kampanie oparte na dobrze dobranych słowach kluczowych oraz wysoka pozycja w wynikach wyszukiwania zapewni Ci dotarcie do grupy docelowej dla Twoich produktów!
następny
  • Szkielety:) AJAX
    data: 10 marca 2009 | autor: Filip Balicki | komentarzy: 1
    Pomimo użycia w tytule polskiej wersji, postanowiłem w dalszej części używać angielskiego słowa "Framework" - tak będzie czytelniej, a artykuł nie będzie sprawiał wrażenia pisanego w prosektorium.
    W dzisiejszym temacie mam zamiar "wyspowiadać się", dlaczego wybrałem Mootools.
    Nie będę przekonywał do samego Ajax-a - zakładam, że wiemy jakie są możliwości i ograniczenia wynikające z wyboru tej technologii.
    Podobnie, jeśli ktoś oczekuje nowego gracza na froncie "świętej wojny" pomiędzy Mootools, Dojo, jQuery oraz Prototype to może poczuć się zawiedziony.
    Najczęściej wykorzystywanym orężem w owej wojnie jest wydajność, mierzona za pomocą różnorakich klonów skryptu dostępnego pod adresem http://mootools.net/slickspeed/.
    By jednak uzyskać miarodajne wyniki, należy ów skrypt odpalić na różnych przeglądarkach - wtedy wyniki potrafią mocno zaskoczyć.

    I tak, przeprowadzając testy pod Windows Server 2003 dla przeglądarek IE 7, FF 3 oraz Opera 9.64 otrzymałem następujące wyniki (w milisekundach):
    FrameworkIE 7FF3Opera 9.64
    Mootools 1.23819456
    jQuery 1.2.62559764
    Prototype 1.61370182112
    YUI 2.5.2872225231
    Dojo 1.114067128


    "Hurra" krzykną zaciekli bojownicy jQuery patrząc na wyniki pod IE. "Hurra" będą im wtórować walczący w imię Mootools patrząc na wyniki pod FF3. "HA" - zakrzykną miłośnicy Dojo...

    Lecz kiedy już opadnie kurz bitewny można próbować wyciągać racjonalne wnioski:

    • Firmie Microsoft nie po drodze z przyjętymi standardami. Oznacza to konieczność implementacji różnych obejść. Bez względu na framework, IE zawsze będzie czerwoną latarnią - zwłaszcza wydajnościowo.

    • Prototype z definicji to taka biblioteka, gdzie "musi być wszystko". De facto to właśnie prototype.js wyznacza funkcjonalności, które szanujący się framework musi mieć. Kosztem tego zadania jest słaba wydajność.

    • Trzy wiodące frameworki (Mootools, jQuery, Dojo) wydajnościowo są porównywalne, bez względu na to co mówią ortodoksyjni "wyznawcy".


    Ostatni z powyższych punktów powoduje, że nie podam argumentów, "Dlaczego wybrać Mootools", ale raczej "Za co lubię Mootools". Wymienione cechy niekoniecznie muszą być cechami indywidualnymi, część z nich znajdzie się także w innych narzędziach. Niemniej jednak są w także w Mootools i chwała twórcom za to.

    1. Mootools jest modułowy. Podstawowa funkcjonalność, pozwalająca manipulować na elementach struktury DOM niezależnie od przeglądarki, jest zamknięta w jednym pliku "core". Natomiast "dodatki" będące już konkretnymi pomysłami na różne efekty dynamiczne na stronie, zawierają się w osobnym pliku "more". Co więcej, developer ma możliwość prostej manipulacji klasami, które mają zostać dołączone do "more" podczas ściągania. To, oraz możliwość wybrania kompresji plików, daje możliwość ograniczenia do minimum nadmiarowego kodu, który musi zostać przesłany do użytkownika.

    2. Kod jest czytelny i przejrzysty. Bez względu na bogactwo dokumentacji, prędzej czy później każdy developer musi "pogrzebać" w kodzie źródłowym. Na tym polu Mootools mogłoby wyznaczać standardy. Nawet skomplikowana funkcjonalność jest świetnie i przede wszystkim czytelnie oprogramowana.

    3. Nieinwazyjność, tzn. korzystając z Mootools, nadal można korzystać z funkcji natywnych JavaScript (chociaż w 99% przypadków będzie to bezzasadne).

    4. "Nachalność" rozwiązań ograniczona - tzn. jest pozostawiona dowolność rozwiązań, tam gdzie jest to możliwe. Np. Request.HTML daje możliwość wskazania elementu, do którego ma być "załadowany" rezultat, ale nic nie stoi na przeszkodzie, by obsłużyć też ten przypadek poprzez onSuccess.
      Innym przykładem może być sposób dołączania nowych elementów do struktury DOM. Można wywołać odpowiednią metodę na elemencie rodzica, ale też istnieje metoda analogiczne odpalana na dołączanym elemencie.
      Tym samym "przesiadając" się z innego frameworka, czy też "czystej" JavaScript, powinniśmy łatwo się odnaleźć.

    5. Stosunkowo niski poziom abstrakcji - oczywiście jak na framework Javascript. Mootools to nie ANSI C, ale jednak wymaga od programisty twórczego myślenia. Klasy i metody tego narzędzia stanowią raczej składowe rozwiązań - zbiór gotowych i kompletnych efektów jest mocno ograniczony (Dział Plugins). I wbrew pozorom to nie jest wada. O ile część frameworków jest rozpoznawalna na pierwszy rzut oka przy przeglądaniu strony, o tyle Mootools pozwala na zaskoczenie użytkownika.

    6. "Inteligentna" manipulacja atrybutami - framework z założenia powinien zapewniać niezależność od przeglądarek. Jeśli odpalamy jakąś metodę, dajmy na to "wygaszającą" element do pełnej przeźroczystości, spodziewamy się identycznego efektu zarówno na FF jak i na Safari. Mootools idzie o krok dalej - nie tylko konkretne metody są niezależne od przeglądarki. Jeśli jakiś atrybut jest bezpośrednio ustawiany dla wybranego elementu, kod zostanie przeanalizowany pod kontem nazwy tego atrybutu, czy przypadkiem w danej przeglądarce nie występuje on pod inną nazwą. I tak setStyle("opacity", 0.5) ustawi przeźroczystość na 50%, pomimo tego, że atrybut "opacity" nie występuje w IE, zaś odpowiadający mu filter: alpha wyrażany jest procentowo, a nie ułamkowo.




       By być uczciwym, należy także wspomnieć o tym, co należy zaliczyć "in minus" mówiąc o Mootools:

    1. Wersja 1.2 nie jest kompatybilna z 1.11 - niektóre metody działają w inny sposób w późniejszej wersji. Nie tylko ich składnia może się różnić, ale też ta sama metoda na tym samym zbiorze argumentów może dawać inne wyniki zależne od wersji.

    2. Sekcja "demo" na stronie mootools.net została mocno okrojona. Jest co prawda dodany link do poprzedniej wersji, ale często stanowi to pułapkę, gdyż metody w wersji 1.2 mogą już nie istnieć lub działać w odmienny sposób niż w wersji 1.11. Zrezygnowano także z bardzo wygodnego interface'u, który pozwalał przełączać się pomiędzy kodem js, css a html (Chociaż nadal jest na stronie umieszczona błędna informacja, że taka nawigacja jest możliwa). Oczywiście można próbować tłumaczyć, że demo sugeruje konkretne rozwiązania, a Mootools jest tak pomyślany by nie ograniczać programisty, ale umówmy się, argument ten jest nieco naciągany.



    Reasumując:
    Mootools jest jednym z najpopularniejszych frameworków do JavaScript. Wydaje się dobrze wyważać łatwość implementacji dynamicznych rozwiązań, a wspieranie i otwartość na własne rozwiązania. Natomiast nie ma potrzeby prowadzenia świętej wojny, który framework jest najlepszy: najlepszym wyborem jest ten framework, który znasz najlepiej.

komentarze

  • Janek napisał/a w środę, 18 marca 2009 o godzinie 15:16:56
    Dosyć oryginalna lista argumentów :) Ale muszę przyznać, że gdyby nie w miarę "żywotna" grupa dyskusyjna mootools, start z tym frameworkiem były dosyć trudny. Zwłaszcza jeśli ktoś nie miał wcześniej styczności z JavaScript. Ale jak już się załapie "o co biega", to jest super.

dodaj komentarz