GoldenApp.eu

Aplikacje internetowe coraz częściej zastępują tradycyjne strony WWW. Tony AJAX-owych i ARIA-wych odnośników prowadzących w kosmos i treść niedostępna bez JS – tak obecnie wygląda typowa aplikacja WWW. Jednak czy na pewno tak wyglądać powinna? Ostatnimi czasy znów modny stał się temat Progressive enhancement (pojawiło się też kilka dobrych artykułów, np. Jake’a Archibalda), który w dobitny sposób pokazuje w jaki sposób można stworzyć dostępne i użyteczne aplikacje; nawet dla tych, którzy z różnych powodów nie mogą w pełni użyć jej możliwości (błędy w interpretacji JS i inne tego typu dziwne sprawy).

Oczywiście za chwilę podniosą się głosy oburzenia, że przecież prawdziwe aplikacje WWW bez JS prawa istnieć nie mają, tudzież nie mają sensu. Dobrze – a teraz pokażcie mi te „prawdziwe aplikacje WWW”. GMail, czytniki RSS, gry w HTML5 i WebGL… Prawdę powiedziawszy mało jest przykładów rzeczy, które koniecznie potrzebują JS (a taki GMail bez niego też przecież może – i z powodzeniem próbuje – zasysać maile z serwera). A twierdzenie, że Twój serwis internetowy wyświetlający wiadomości sportowe jest tak zaawansowanym webappem, że bez JS się nie obejdzie (bo masz reklamy odświeżające się AJAX-owo co 3 sekundy) jest tak naprawdę przejawem lenistwa. Naprawdę – czy stworzenie linku typu <a href="news1.html">News nr 1</a> jest aż tak skomplikowane i musisz je zastąpić przez <a href="#" onclick="ladujMiTuWTejChwiliNewsa('1')">News nr 1</a>? A co robi Twój super-hiper JS-owy link? Wysyła żądanie do serwera. A co robi zwykły link? Wysyła żądanie do serwera. I do tego reaguje na środkowy klawisz myszy i działa gdy padnie Twój mega CDN, z którego zasysasz wszystkie 100+ plików JS. Przecież każdy link w AJAX-ie odwołuje się do jakiegoś zasobu na serwerze (no bo ta baza danych gdzieś jest, nie?). Hashbangi to zło (i wszyscy to wiedzą), mamy History API a userzy chcą poprawnych URI – więc im je daj a nie owijaj w bawełnę. Twój AJAX i tak robi dokładnie to samo co nie-JS-owy link.

I tak, w swojej mega grze, gdzie eksplodują miliardy fajerwerków w każdej sekundzie możesz sobie wymagać obsługi JS z setkami dziwnych API, takich jak Vibration API. Ale do kurki wodnej: żeby przeczytać newsa o zjełczałym maśle w ultramarynowym pojemniku śniadaniowym prezesa międzynarodowej korporacji nie potrzebuję obsługi grafiki 6D w swojej przeglądarce…

Po tym krótkim (albo i nie – zależy od punktu czytania) wstępie przejdźmy do meritum. Nie na darmo rzuciłem hasłem PE i piekliłem się na działanie zaawansowanych webappów. Otóż ostatnio natknąłem się na ciekawe ogłoszenie, dzięki któremu trafiłem na stronę twórcy aplikacji internetowych. Postanowiłem więc sprawdzić czy webmaster zna tych kilka ładnych haseł jak PE czy ARIA. A oto co odkryłem:

• Wszystko musi być zgodnie z prawem, prawda? Zatem od razu wita nas ładny komunikat o cookies. Chociaż można by się spierać czy zmniejszony przycisk z tekstem „Nie wyrażam zgody” nie jest przypadkiem przekazem podprogowym – a w tym momencie świadoma zgoda użytkownika staje pod znakiem zapytania…
• Dziwną rzecz ujrzałem włączając narzędzia developera. Później jeszcze do niej wrócę.
• Piękne błędy 404.
• Linki w menu nie zmieniają adresu strony. Zapowiada się dobrze skonstruowana strona, prawda?
• Logo też jest nieklikalne. A strona główna intuicyjnie kryje się pod opcją „Oferta” w menu.
• Przejdźmy do kodu. Walidatory (zarówno HTML, jak i CSS) nie mają zastrzeżeń.
• Natomiast ja mam – jak zawsze 😉 Ale najpierw pochwalę: na html znajduje się atrybut lang, wskazujący na język strony.
• Autor strasznie się nie umie zdecydować czy tak naprawdę pisze w XHTML i umieszcza dodatkowy slash, czy w HTML i go olewa.
• DOCTYPE z HTML5… i tyle. Nie ma ani jednego nowego znacznika.
• Autor bardzo dba o SEO:

  <meta name="robots" content="all">
  	<meta name="revisit-after" content="7 days">

  Szkoda, że zapomniał o istnieniu takich plików jak robots.txt i sitemap.xml.

• <meta name="keywords" lang="en" content="goldenapp,golden app,applications,internet,php,mysql,sql,query,html,html5,css,jquery,animations,cheap,secured,mateusz,bartocha,programmer,scripts,complex,templates,stable,protect,repair,clear,code">
  	<meta name="keywords" lang="pl" content="goldenapp,golden app,aplikacje,internetowe,php,mysql,sql,query,html,html5,css,jquery,animacje,tanie,bezpieczne,zabezpieczone,programista,zlecenie,mateusz,bartocha,programowanie,projektowanie,skrypty,firmowe,rozbudowane,serwisy,szablony,stabilne,chronione,naprawa,przejrzyste,kod">

  Bardzo dobry pomysł. Polecam stworzyć wersje słów kluczowych dla każdego z języków kongresowych. I koniecznie nie można zapomnieć o podobnym zabiegu dla meta[name=description].

• Oczywiście jQuery wczytywany w nagłówku. A powinien być pod koniec body.
• Co ciekawe strona dziwnie się skaluje, natomiast brakuje meta[name=viewport].

• <div id="resizable_loader"><img src="./public/img/loader.gif" alt="loading.."></div>

  To cudo pokazuje się przy wejściu na stronę. Nie muszę chyba mówić, że przy wyłączonym JS widzimy tylko ten wkurwiający ładny GIF. Bo w końcu to superhiper appka z WebGL.

• Na stronie co prawda są nagłówki, ale ani nie wyglądają na nagłówki, ani nie są po kolei. A w kodzie pierwsza jest… stopka. Bo w końcu każda książka zaczyna się od rozwiązania akcji.

• <span class="small">12 748</span>

  Magiczna liczba strony – nigdzie nie jest napisane co ona robi i co oznacza. Ot, jest sobie taka w stopce i sterczy.

• Jak na moje oko, jest tutaj porządny divitis.
• Oto przykładowy link z menu:

  <li onclick='load("#offer1")'>Oferta</li>

  Podstawowy problem z linkiem w menu jest taki, że nie jest linkiem. I w żaden sposób nie działa bez JS (oraz wtedy, gdy jest przestój w przesyle i JS z odpowiednią funkcją jeszcze nie doszedł). Nie dodaje też #offer1 do adresu (jak robi każda porządna one-page site). O History API nie ma nawet co marzyć. Autor nawet nie odrobił lekcji i nie poczytał nieśmiertelnego artu porneLa o onclick. A wystarczyło dać normalny link do kotwicy.

• Później jest kilka div.text_box i każdemu (ok, prawie każdemu) nadano dodatkowo atrybut style, wyśrodkowujący tekst. Bo przecież klasy nie służą do tego. Wydaje mi się, że kto jak kto, ale twórca webappów powinien znać przynajmniej zarys OOCSS.
• Nie ma tu akapitów – imituje je podwójne przełamanie linii (i czasami nagłówki). Natomiast nagłówki imituje b.

• <h3>(X)HTML, CSS, JavaScript(wraz z jQuery), PHP, SQL.</h3>

  Jak dla mnie to jest lista a nie nagłówek, ale pewnie się nie znam.

• 4. jest liczebnikiem, ale porządkowym, zatem zdania typu „Od czwartego lat” nie mają dużego sensu.

• <a href="#" onclick='load("#offer1")'>Przejrzyj szczegóły mojej oferty by dowiedzieć sie więcej.</a>

  Pewien postęp – pojawił się link!

• <h2>Masz pomysł na coś wyjątkowego? Chcesz zaistnieć w internecie?</h2>
  						<h1>Możesz na mnie liczyć!</h1>

  h1 jako podtytuł dla h2 – ciekawy pomysł, nie powiem.

• <a href="http://framework.zend.com/" target="_blank">Zend Framework 2</a> lub <a href="http://kohanaframework.org/" target="_blank">Kohana 3</a>

  porneL jest najwyraźniej zupełnie nieznany autorowi.

• Kolejnym dowodem na to jest lista wsadzona w tabelkę. Powiało aplikacją na miarę GMaila.
• Lista wybranych projektów mogłaby być listą. Na razie jest zbiorem nic nie mówiących, niesemantycznych div. Na szczęście są nagłówki, które jakoś sprawę ratują. W HTML5 można ładnie wykorzystać section/article do tego.

• Technologia: HTML, CSS, jQuery<br><br>	
  								Adres www: <a href="http://footballgame.pl/" target="_blank">http://footballgame.pl</a>

  Wygląda jak wymarzona lista definicji.

• Obrazki do projektów też mają bardzo ładne alt – „IMG”. Dużo mówiące i opisowe. No i aż się prosi, by można je było powiększyć klikiem. Niestety, jesteśmy skazani na takie liliputy.

• Imię i nazwisko/nick: <input type="text" name="nick" value=""><br><br>

  Uwielbiam dostępne formularze. label jest podstawą – inaczej strona jest zupełnie bezużyteczna.

• Na tak ładnej stronie komunikaty błędów formularza w alert rażą.
• No i komunikat o poprawnym wysłaniu wiadomości w kodzie jednak trochę nie pasuje. Jak już tak jest, to powinien być ładnie potraktowany przez aria-hidden/hidden i usunięty przez display:none.
• A dane kontaktowe nadają się do address. I też przypominają dl. No i klikalne być powinny.

• <img src="./public/img/background-full.png" width="1200" height="800" onload="setTimeout('loader()', 800)" alt="background">

  W dzisiejszych czasach zrobiłbym to po prostu na background-size. No i do tego to onload. Każde on… w HTML to pogwałcenie zasady rozdziału aplikacji na warstwy. Do tego zastosowanie setTimeout tutaj mnie dziwi – czyżby grafika loadera była na sztywno wyłączona po określonym czasie? Zatem mamy do czynienia ze zwykłą atrapą. Nieładnie. Już pomijając string jako pierwszy parametr – wywołujemy sobie tym samym eval (czyli spada nam wydajność).

• Jeśli loader jest atrapą tak czy siak, to po co w ogóle się pojawia? A jeśli się już pojawia, to niech będzie poprawnie zrobiony (czyli pojawia się tylko, gdy JS jest dostępny).
• Tyle na temat HTML. Teraz przejdźmy do CSS. Ciekawi mnie czemu domyślnie wszystko ma overflow:hidden?
• Autor jest strasznie szowinistyczny. Cienie boksów dostanie tylko webkit.
• W stylach istnieje straszna niekonsekwencja. Raz border-radius deklarowany jest bez vendor prefixów a w innym z nimi (łącznie z niedziałającym już -moz-border-radius).
• div.text_box (zawierające całą treść strony) są domyślnie ukryte (i to przez display:none), zatem dostępność leży totalnie. Wychodzi leniwość webmastera. To webapp, dude – tu można!
• Część stylów się powtarza i można by je połączyć (chodzi głównie o te dla nagłówków).
• Teraz czas na JS. Oprócz jQuery, na końcu includowane są 4 pliki JS. Łącznie – 5 requestów. Nie jest źle, ale mógłby być 1 (lub 2 requesty). Do tego minifikacja i hula. Tak samo można potraktować także CSS. Kto jak kto, ale autor webappów powinien o tym wiedzieć.
• Kod obsługujący formularz kontaktowy jest niestety zobfuskowany… Ale w dość prymitywny sposób, więc bez problemu można wyciągnąć prawdziwą treść (funkcja generująca string, który następnie puszczamy w eval – to kogoś jeszcze powstrzymuje?). Jeśli autor chciał zmniejszyć rozmiar, to powinien użyć uglify/GCC a nie czegoś takiego. No chyba, że chciał ukryć kod – wtedy przepraszam.
• Kod wygląda dobrze… Poza jednym, subtelnym szczegółem – istnieje w jQuery coś takiego jak form.serialize, przerabiający wszystkie pola formularza na dane strawne dla formularzy. Nie potrzeba wszystkich pól wymieniać po kolei. I niepokoi mnie skłonność do „ręcznej obfuskacji kodu” (zmienne typu a – sam jestem winny takiego postępowania i w części moich projektów wciąż odbija mi się to czkawką; no chyba, że to też zrobił obfuskator).
• Plik resizable.js też sobie rozkodowałem (jego kodu nie wrzucam – kto chce, może sobie sam spróbować odkodować). Okazał się głównym silniczkiem strony.
• Pełno funkcji globalnych. A powinien być ładny namespace.
• W kodzie znajduje się konstrukcja typu:

  $(function()
  	{
  		$(document).ready({
  			//tutaj magia
  		})
  	});

  Taka konstrukcja wskazuje na nieznajomość jQuery. Zgodnie z dokumentacją obydwie konstrukcje są swoimi aliasami.

• Przy przełączaniu treści wszystkie elementy są po kolei ukrywane przy pomocy ich identyfikatorów. Problem w tym, że wszystkie mają tę samą klasę, z której można tutaj skorzystać. Ale jak wiadomo id jest jednoznaczny i lepiej korzystać z niego – zawsze.
• Teraz najlepsze. Co zrobił autor zamiast użyć media queries i machnąć wszystko w kilku linijkach CSS + opcjonalnie respond.js dla starych IE (albo po prostu zastosować procenty)? Proste – na starcie pobiera style wszystkich elementów na stronie (body * – to już samo w sobie jest bardzo wydajne), po czym odpala funkcję resize (przy każdym zdarzeniu resize strony także odpala. Ale już np. przy orientationchange nie). Co robi ta funkcja? Leci w 3 (słownie: trzech) zagnieżdżonych pętlach po wszystkich elementach i zmienia ich style w zależności od aktualnej wielkości strony. Stąd takie dziwne (i totalnie bezużyteczne) skalowanie. Nie mówiąc już o wydajności takiego rozwiązania. Nigdy nie widziałem czegoś równie dziwnego w JS. Pomysł jest po prostu skrajnie debilny. Od samego początku (błędne założenie o „łatwym” rozwiązaniu problemu) aż po wykonanie (na pewno da się wydajniej). Szokło mnie – i to mocno.

Czy strona jest poprawnie wykonana? Absolutnie nie. Łamie wiele podstawowych zasad projektowania stron. Proste problemy są tutaj rozwiązane w fenomenalnie dziwny sposób. Dziwi mnie slogan o tworzeniu aplikacji internetowych na stronie osoby, która nie ogarnia w pełni nawet jQuery. W dobie wielowątkowych aplikacji JS to po prostu… bidnie. I tyle. Ale wygląda – a jak wiadomo pierwsze wrażenie jest najważniejsze. Niestety.