Czy istnieje jakieś solidne uzasadnienie, dlaczego witryny nie powinny być rozwijane z funkcją ajax, która ładuje główne części każdej części (zakładając, że elementy takie jak nagłówek, nawigacja itp. Pozostają takie same)?

Z pewnością wymagałoby to mniejszej ilości zasobów, ponieważ serwer nie musiałby wyświetlać treści wyświetlanych na każdej stronie, z korzyścią zarówno dla hosta, jak i użytkownika końcowego.

Odpowiedz na pytanie, biorąc pod uwagę:

• Zachowanie javascript w witrynach pogarsza się w każdym przypadku z wdziękiem

• W przypadku mojego pytania mówię o nowych witrynach, w których takie zachowanie można by wdrożyć od samego początku, więc technicznie nie kosztuje to żadnych pieniędzy - nie wracamy do produktu gotowego do wdrożenia.

Jeśli zawartość można uzyskać bez włączonej obsługi JavaScript, pytanie nie ma sensu. To nie jest „całkowicie Ajaxified”, jeśli możesz dostać się do treści w inny sposób. Naprawdę, pytasz: „czy można poprawić wrażenia mojego użytkownika dzięki Ajax?”. Odpowiedź brzmi oczywiście „tak”.

edytować

Kiedy Google wyszedł z propozycją przeszukiwania Ajax, został uznany za naprawdę zły pomysł . To ciekawa lektura.

Najpierw pierwsze

Profesjonaliści

• AJAX umożliwia korzystanie ze wspólnej strony „podstawowej” i po prostu ładowanie obszarów zawartości, co może skrócić czas ładowania użytkowników, ponieważ duża część strony jest już załadowana.
• Może pozwolić na trochę słodyczy, takich jak zanikanie i zwijanie obszaru zawartości.

Wady

• Nie działa dobrze, jeśli strona zostanie pobrana.
• Może zadzierać z urządzeniami niepełnosprawnymi.
• Przeglądarki z wyłączonym javascriptem nie będą w ogóle mogły korzystać z treści, chyba że zostanie zastosowana również wersja inna niż javascript.
• Dużo więcej pracy (czy naprawdę trzeba to powiedzieć?).

Teraz twoje pytanie

Zakładając, że twoja strona z wdziękiem ulega degradacji dla osób bez Javascript, to, jak dobrze się to okaże, zależy od tego, jak to się robi. Na przykład, jeśli po prostu wyświetlisz nieoczekiwany link do wersji innej niż javascript, niedogodnością dla tych przeglądających będzie kliknięcie innego linku. Z drugiej strony, jeśli istnieje „główna strona” noscript, która korzystałaby z tradycyjnych linków, działałaby lepiej dla większości użytkowników, ale nadal nie ma wsparcia dla osób korzystających z urządzeń niepełnosprawnych, na przykład, gdy użytkownik przychodzi do określonej „strony” z link itp.

Podsumowując, w świecie coraz szybszego połączenia internetowego tak naprawdę nie uzasadnia odcięcia niewielkiej ilości plików (założymy, że cały JavaScript, CSS i obrazy mogą i będą buforowane, pozostawiając po prostu sama strona „podstawowa” do zapisywania bajtów) dla wad, które może dać, a mianowicie dodatkowa trudność (choć nie zawsze jest to wyzwanie) i brak wsparcia dla niektórych użytkowników.

Podsumowując, powiedziałbym, że to zależy od ciebie, prawdopodobnie zadziałałoby całkiem nieźle, a dla zdecydowanej większości użytkowników prawdopodobnie zobaczą stronę zgodnie z przeznaczeniem, ale osobiście powiedziałbym, że nie przeszkadza, ponieważ tak niewielka poprawa rozmiaru pliku nie jest trudna.

Sprawdź http://gawker.com/ - ta strona prawie całkowicie się ładuje po fakcie. Używają „hashbangs” ( http://mydomain.com/#!some_section) do określenia, która strona zawartości powinna zostać załadowana, główna nawigacja pozostaje niezmieniona.

Sprawdź http://mtrpcic.net/2011/02/fragment-uris-theyre-not-as-bad-as-you-think-really/, aby zapoznać się z krótkim przewodnikiem na temat koncepcji Gawkera.

Są plusy i minusy, musisz wziąć pod uwagę wyszukiwarki (patrz http://code.google.com/web/ajaxcrawling/docs/getting-started.html ), osoby z wyłączoną obsługą javascript i przeprowadzić wiele testów.

Biorąc to wszystko pod uwagę, największym argumentem przeciwko nim jest prawdopodobnie to, że gdy użytkownik czeka na załadowanie strony, a następnie musi czekać na kolejne ładowanie, może być niecierpliwy. Moim zdaniem najlepszą praktyką jest załadowanie strony głównej, nawigacji i głównej zawartości w jednym przebiegu (na żądanie) i zapisanie AJAX na niepotrzebne zdarzenia. Działa to z ideą stopniowego ulepszania i łączy najlepsze z obu podejść.

Ponieważ to chyba nie jest konieczne.
Ładowanie podstawowych dokumentów HTML jest proste i działa. Wprowadzenie do Ajax dodaje całą kolejną warstwę dla przeglądarek, kodu i obsługi JavaScript, zaplecza, dziwnych adresów URL z hashbangiem i tak dalej. Czasami może to być uzasadnione, a czasem nie. Może zaoszczędzić ci trochę zasobów serwera (może), ale czy to wystarczy, aby zrównoważyć utrzymanie? Musisz ocenić ten projekt.

Jako przykład, kiedy Twitter otrzymał najnowszą przeprojektowanie, przyjęli podejście, że nie jest to po prostu strona internetowa, ale aplikacja, a całość jest w dużej mierze oparta na Ajaxie, chociaż większość tego, co robi być obsługiwany przez regularne żądania stron. Jednym z największych problemów, który wciąż się zdarza, choć teraz znacznie mniej, jest przybycie i przywitanie go pustą stroną, ponieważ coś w Ajaxie zawiodło.

W praktyce dużo pracy zajmuje stworzenie strony „w pełni AJAX”, szczególnie dla dużych stron internetowych, które są bardzo skomplikowane. Niektóre strony internetowe, które próbują tego dokonać, to Google i Facebook, ale nawet one nie robią tego idealnie.

Typowe problemy to nawigacja (tj. Do przodu i do tyłu) oraz zakładki, ale istnieje wiele innych błędów, z którymi wielu programistów wolałoby się nie zmagać. I w gruncie rzeczy oznacza to utworzenie dwóch wersji strony internetowej, aby były kompatybilne z Javascriptem i użytkownikami innymi niż javascript (i poprawki dla wszystkich przeglądarek ze słabą obsługą AJAX).

Tak, powinno być, jednak powinno być na odwrót.

Wspólne części strony należy wysyłać przez HTTP. Następnie mała kontrolka ajax (lub nawet lepsze websockets) ładuje zawartość dynamiczną asynchronicznie.

Oczywiście najpierw musisz wykryć, czy javascript jest włączony (przez cookie) i użyj tej metody tylko wtedy, gdy jest włączony.

Potrzebujesz więc normalnej pełnej trasy HTTP, a następnie trasy do gniazd sieciowych. Wymaga to powielania kodu, chyba że użyjesz narzędzia takiego jak node.js

Większość ludzi „uważa”, że po prostu nie jest to warte dodatkowego wysiłku. A czasem tak nie jest.

Na marginesie, wiele osób źle ocenia strony. W rzeczywistości decydują, że nie potrzebujesz wersji innej niż javascript i potrzebujesz tych wszystkich dziwnych adresów URL mieszania hash i uszkodzonych przycisków do przodu / do tyłu. Prawidłowe wykonanie ajax wymaga historii HTML5 (IE9 go nie ma). Wymaga także od programisty ukończenia wersji witryny.

Ponieważ oświadczyłeś, że z wdziękiem obniży się dla odwiedzających z wyłączonym Javascriptem, widzę tylko dwa prawdziwe problemy (i jeden możliwy problem), które mogą się pojawić.

Zła dla dostępności

Czytniki ekranu i inne technologie wspomagające są często wyrzucane przez dynamiczne zmiany DOM. Przetwarzają i czytają stronę w sposób liniowy, a zmiana zawartości strony po jej załadowaniu może nie być obsługiwana poprawnie.

Mogą istnieć techniki obejścia tego, ale nie przyjrzałem się temu zbyt dokładnie.

Zwiększona złożoność

Utrzymanie tego rodzaju strony może być trudne. Na przykład: jeśli utworzyłeś nowy układ i zmieniłeś ID obszaru treści, który zamieniasz na swoje łącza AJAX, może to zepsuć twój schemat nawigacji w dość kłopotliwy sposób.

Tego rodzaju zachowanie AJAX skomplikowałoby również każdą analizę ruchu, którą wykonujesz; Google Analytics nie zarejestruje poprawnie tych obciążeń AJAX bez ręcznego połączenia z pageTracker._trackPageview('this_page');.

Zwiększenie złożoności działania strony podnosi także poprzeczkę dla nowych programistów; każdy pracujący w witrynie prawdopodobnie musiałby zostać poinformowany o tym, jak to zachowanie wpływa na ładowanie strony.

Możliwe: wolniejsze ładowanie strony podczas pierwszej wizyty

W zależności od struktury rzeczy strona pobierająca kod AJAX będzie mogła zostać uruchomiona dopiero po pełnym załadowaniu dokumentu. Tak więc dopiero po tym, jak odwiedzający pobrał całą stronę, a następnie Javascript (jeśli był to plik zewnętrzny), a ich przeglądarka renderowała go i pobierała zawartość za pośrednictwem AJAX, czy zobaczyłaby zawartość strony.

Każde kolejne kliknięcie linku byłoby szybsze, ale pobranie pierwszej strony odwiedzanej przez użytkownika zajęłoby dłużej niż wersja statyczna.

Powodem, dla którego oznaczyłem to jako możliwy problem, jest to, że zawsze możesz wysłać pierwszą stronę statycznie (ponieważ będziesz mieć wersję statyczną jako rezerwową), a następnie użyć AJAX do kolejnych linków.

Co do tego, co jest warte, nie wydaje mi się to okropnym pomysłem - szczególnie w przypadku zastosowań wrażliwych na przepustowość, takich jak strony mobilne. Trzeba jednak dokładnie rozważyć wady, aby upewnić się, że było warto w twoim przypadku.

Posiadanie elementów ajax na stronie jest w porządku, gdy masz małą bazę użytkowników, ale gdy masz większy ruch; chcesz zastosować bardziej statyczne podejście, aby zmniejszyć nadużycie zasobów.

Na przykład: powiedz, że 200 osób próbuje uzyskać dostęp do strony na sekundę. Masz około 7 zapytań do bazy danych dla wywołań ajax; czyli 1400 baz danych wywołuje sekundę, która może zepsuć witrynę.

Witryna, która musi być zaprojektowana pod kątem większego ruchu, powinna mieć statyczne strony skierowane na zewnątrz, dla treści, które mogą być wyświetlane w sposób statyczny. Osiąga się to poprzez użycie skryptu po stronie serwera, który uruchamia się co sekundę, w celu przebudowania strony statycznej, która jest pobierana dla użytkownika końcowego, a tym samym zmniejszono obciążenie z 1400 wywołań bazy danych na sekundę do 7.

Jest to podejście SOA do budowania stron internetowych.