Komentarze do: Projekt aplikacji po stronie klienta

Autor: Kamil Brenk

Kamil Brenk — Fri, 06 Aug 2010 20:21:27 +0000

Bezużyteczne i wkurzające, jednak potwierdza, że JavaScript częściowo działa w przeglądarkach mobilnych. Więc gdyby ktoś budował prostą stronę na telefon to mógłby użyć JavaScript, ale nie polecałbym dołączanie biblioteki do jedynie kilkukrotnego wykorzystania metody bind czy live.

Czasem warto się pomęczyć trochę więcej, napisać prostą obsługę zdarzeń w „czystym” JS i nie katować klienta biblioteką ważącą prawie 50 KB ;>

Btw. obsługa zdarzeń jest tutaj przykładem, to tyczy się każdej funkcjonalności. Tak jak jednak napisałeś wcześniej, wszystko z umiarem – jeśli tej funkcjonalności jest za dużo i dochodzi operowanie na modelu DOM czy coś jeszcze to dopiero wtedy warto zastanowić się nad użyciem frameworka :D

Autor: eRIZ

eRIZ — Thu, 05 Aug 2010 22:32:09 +0000

Nie zgodzę się jednak co do telefonów. Opera Mini obsługuje JavaScript, a przynajmniej niewielką część funkcjonalności. Przykładowo: zdarzenie onfocus dodane do pola input zadziała na telefonie, jednak będzie wymagało odświeżenia strony. Jest to dość uporczywe i męczące (dużo serwisów dodaje zdarzenia na polach formularzy, menu rozwijanych), jednak działa.

Też korzystam z OMini, ale to, co przytoczyłeś, to jest praktycznie… bezużyteczne? ;)

Autor: Kamil Brenk

Kamil Brenk — Thu, 05 Aug 2010 19:44:27 +0000

eRIZ, dziękuję za komentarz :-)

W zdaniu, które zacytowałeś chodziło mi właśnie o sytuację, gdy potrzebujemy tylko minimalnej obsługi JavaScript, a w związku z tym nie ma co zaprzęgać do tego frameworków. Niektóre rzeczy są stosunkowo proste w wykonaniu i warto zwolnić trochę łącza. Oczywiście w przypadku konieczności zaimplementowania szerszej funkcjonalności w JS to framework jest wręcz niezbędny, by nie wymyślać koła na nowo oraz by skrócić czas pracy.

Nie zgodzę się jednak co do telefonów. Opera Mini obsługuje JavaScript, a przynajmniej niewielką część funkcjonalności. Przykładowo: zdarzenie onfocus dodane do pola input zadziała na telefonie, jednak będzie wymagało odświeżenia strony. Jest to dość uporczywe i męczące (dużo serwisów dodaje zdarzenia na polach formularzy, menu rozwijanych), jednak działa.

Autor: eRIZ

eRIZ — Thu, 05 Aug 2010 17:55:32 +0000

Niemniej jednak nie wszędzie można dawać jquery, czasem lepiej zastosować kilka prostych funkcji. Mowa tutaj chociażby o telefonach – nie ma tam miejsca na cache, a każdy kolejny MB kosztuje (Simplus = 5zł za 50 MB)

No tak, tylko że komórkowe przeglądarki za bardzo z tego nie skorzystają. ;)

Poza tym, popadamy tu w skrajność – zajdzie potrzeba ulepszenia serwisu, to i tak przyjdzie doczepić kolejnego frameworka. Czysty JS owszem, ale do czasu. Jeśli liczba linijek zaczyna przekraczać pewne dopuszczalne maksimum, olewam klepanie koła na nowo.

W PHP jest sens nieraz napisania wszystkiego na czysto, bez fw, ale we front-endzie już nie. Chociażby ze względu na różnice w implementacji pewnych funkcji przez przeglądarki.

Autor: Kamil Brenk

Kamil Brenk — Fri, 30 Jul 2010 09:31:12 +0000

@Tomasz: generalnie się z tym zgodzę, teraz tak wielu developerów używa bibliotek z CDN, że większość użytkowników ma pewnie dany obiekt w buforze (przynajmniej te popularne, jak jquery). A nawet jeśli nie to pobranie pliku z serwerów krawędziowych CDN jest dużo szybsze niż z normalnego serwera.

Niemniej jednak nie wszędzie można dawać jquery, czasem lepiej zastosować kilka prostych funkcji. Mowa tutaj chociażby o telefonach – nie ma tam miejsca na cache, a każdy kolejny MB kosztuje (Simplus = 5zł za 50 MB)

Autor: Tomasz Kowalczyk

Tomasz Kowalczyk — Fri, 30 Jul 2010 08:46:16 +0000

„Czasem warto poświęcić kilkanaście minut i napisać własną klasę do tworzenia obiektów Ajaksa (XHR), niż specjalnie zaprzęgać do tego jQuery, Prototype i inne wynalazki.”

Narzekasz też wcześniej na ilość danych jakie trzeba będzie pobrać – zapomniałeś o jednym – CDN. Umieszczając na stronie linki zamiast do siebie, do serwisów hostujących te pliki masz bardzo dużą szansę, że ktoś wczyta skrypt z cache, a ty masz nieporównywalnie większe możliwości niż w przypadku własnego rozwiązania.

Autor: Kamil Brenk

Kamil Brenk — Thu, 29 Jul 2010 23:11:15 +0000

Ale jestem głupi, wcześniej coś mi się pomyliło :D jQuery bowiem posiada metodę do takiego zarządzania zdarzeniami - live. Jakby tego było mało, czasem używam tej metody i nie jest mi obca.

Autor: Michal Wachowski

Michal Wachowski — Thu, 29 Jul 2010 22:37:44 +0000

No i zapomniał bym o dość ważnym efekcie bombelkowania – dzięki niemu, można sprawdzać czy zdarzenie, wywołane przez dany element pochodzi z danego kontenera czy nie i zależności od wyniku – odpowiednio obsłużyć.

Np. w sytuacji gdy mam kilkanaście kontenerów

1
2
3
4

Przy kliknięciu na link rel=”remove” nie szukam linka wywołującego zdarzenie, a kontenera w którym się znajduje.
No i, obsługę zdarzenia daję na dokument, nie na każdy kontener z osobna :)

Autor: Michal Wachowski

Michal Wachowski — Thu, 29 Jul 2010 22:32:23 +0000

W prototype.js nie ma problemu z właśnie takim przechwytywaniem zdarzeń.
Ot po prostu zamiast

1	$('id').observe('click'', function(evt) { ... });

pisze się

1	document.observe('click', function(evt) { ... });

Zaś w funkcji reagującej na zdarzenie:

1
2
3
4
5

var target = evt.findElement('cssSelector');
if(target) {
evt.stop();
...
}

:) Czyżby kolejna przewaga nad jBadziew? :D

Autor: Kamil Brenk

Kamil Brenk — Thu, 29 Jul 2010 11:20:16 +0000

@sokzzuka: wiem o czym mowa, jednak w dobie frameworków nie chciałoby mi się pisać mechanizmu do przechwytywania zdarzeń, jestem na to za leniwy.

Zamiast tego wolę z wykorzystaniem jQuery przypinać zdarzenia do określonych elementów, wykonywać konkretne akcje, po czym blokować dalsze działania przeglądarki (preventDefault).