Progresywne ulepszanie a aplikacje jednostronicowe

33

Właśnie wróciłem z konferencji w Bostonie o nazwie An Event Apart .

Bardzo popularnym tematem wśród prelegentów była idea stopniowego ulepszania - treść witryny powinna być umieszczona w kodzie HTML, a JavaScript powinien być używany tylko w celu poprawy zachowania.

Argumenty, które mówcy podali dla stopniowego ulepszania, były bardzo przekonujące. Jest to nie tylko solidny wzór do obsługi starszych przeglądarek i urządzeń w sieci o niskiej przepustowości, ale HTML zawodzi znacznie bardziej wdzięcznie niż JavaScript (tzn. Znaczniki, które nie są obsługiwane, są po prostu ignorowane, a jeśli przeglądarka zgłasza wyjątek podczas wykonywania twojego skrypt - jesteś wąż).

Jeremy Keith wygłosił szczególnie wnikliwą rozmowę na ten temat.

Ale co z aplikacjami internetowymi na jednej stronie, takimi jak Backbone i Angular? Cały projekt tych frameworków wydaje się popychać programistę do przenoszenia treści poza HTML i do czegoś w rodzaju interfejsu API JSON.

Nie wydaje mi się, aby żelować te dwa wzorce projektowe: progresywne ulepszenie w porównaniu z aplikacjami internetowymi na jednej stronie. Czy zdarzają się sytuacje, w których jedno jest lepsze od drugiego? Czy też nie są to nawet technologie antagonistyczne i brakuje mi czegoś tutaj w moim modelu mentalnym?

SeanPlusPlus
źródło
Mają dwa różne przypadki użycia. Tak, nakładanie się serwera jest bardzo duże.
BobDalgleish
5
Myślę, że można śmiało powiedzieć, że wymagania dotyczące przeglądarki dla aplikacji jednostronicowych są z założenia bardziej rygorystyczne niż dla „zwykłych” aplikacji internetowych.
Robert Harvey
3
powinieneś poprosić Jeremy'ego Keitha, aby dał ci przykład z rzeczywistego świata, w którym progresywne ulepszanie jest naprawdę warte wysiłku zadowolenia 1-10% wszystkich internautów i zapytaj dane innych 90% użytkowników, czy faktycznie zależy im na stopniowym ulepszaniu lub czy są zadowoleni jeśli mogą odwiedzić witrynę z IE 5.0 lub bez javascript
kirie
1
Jeśli osoby, które wyłączają JS / obrazy / itp., Nie znajdują się w głównym docelowym systemie demograficznym, nie ma żadnego uzasadnionego powodu biznesowego, aby kontynuować Progressive Enhancement.
Graham
1
Wsparcie dla „urządzeń w sieci o niskiej przepustowości” jest w rzeczywistości argumentem za SPA, a nie przeciw! W SPA składasz tylko jedną dużą prośbę, a bez JS masz ją za każdym razem!
Dmitri Zaitsev

Odpowiedzi:

21

Wydaje mi się, że aplikacje jednostronicowe wytyczają linię w piasku stopniowego ulepszania. Tam, gdzie wcześniej próbowaliśmy obejść fakt, że implementacje i funkcje różnią się w różnych przeglądarkach od dziesięcioleci, SPA zakładają, że istnieje pewna podstawa, którą możemy zasadnie zgodzić się, że większość odwiedzających daną witrynę spełni. Nie sądzę, żeby te dwie były ze sobą sprzeczne. Nadal możesz stopniowo ulepszać po rozpoczęciu SPA, na przykład zaczynając od <video>tagu, a następnie nakładając na to swój własny bogaty w funkcje odtwarzacz.

Są też goście z wyłączonymi skryptami, ale wiedzą, w co się pakują. Nie rozumiem, dlaczego programiści powinni pochylać się nad tymi gośćmi, oprócz notatki „Potrzebujesz skryptów dla tej witryny”. Jeśli na to pozwolimy, to dlaczego nie zaspokoić również użytkowników z wyłączonym CSS? A co z wyłączonymi obrazami? Są to podstawowe technologie sieciowe. Nie powinni oczekiwać, że będą mieli w pełni funkcjonalne środowisko internetowe, kiedy będą zbierać i wybierać elementy.

Aby upewnić się, że nie ucieknę bez analogii samochodu, nie powinienem oczekiwać, że mój samochód będzie działał, jeśli zdecyduję, że nie lubię niektórych funkcji. Mogłem powiedzieć inżynierom budowlanym: „Wyłączyłem światła przednie, więc pamiętajcie o instalowaniu lamp ulicznych co 125 stóp wszędzie, gdzie mogę odwiedzić”. Bez reflektorów mój samochód działałby dużo czasu, ale w niektórych miejscach nie będę mógł odwiedzić.

Collin Allen
źródło
3
I don't see why developers should bend over backwards for those visitors. Jeśli Twoja umowa określa, że ​​musisz udostępnić dostępną wersję swojej strony internetowej, korzystanie ze SPA może być trudniejsze. A co z SEO?
Simon Bergot
7
@Simon: Można zrobić SPA dostępny także (patrz np stackoverflow.com/questions/15318661/... ). Podobnie w przypadku SEO (jeśli SEO ma znaczenie, które zależy od aplikacji).
sleske
2
Niektóre z twoich analogii są trochę słabe. Wyłączenie Javascript ma cel bezpieczeństwa; trudno byłoby argumentować, że dodanie reflektorów do opieki czyni ją mniej bezpieczną.
Robert Harvey
1
To prawda, że ​​wyłączenie skryptów ma zalety bezpieczeństwa. Ale dla większości odwiedzających dodatkowe bezpieczeństwo, jakie daje wybór, nie jest tego warte. Bez skryptów Facebook odmawia pracy, przerwy na LinkedIn, przerwy na Pinterest, Instagram ładuje pustą stronę itp. Jeśli wymagają tego główni gracze, Twoje SPA też może.
Collin Allen
Znając tylko FB i LinkedIn, nie ma żadnego dobrego powodu, aby te strony się zepsuły bez JS, z wyjątkiem umieszczenia programistów, którzy nie chcą wkładać wysiłku w stworzenie akceptowalnie funkcjonującej witryny (lub zmuszać użytkowników do akceptowania mniej bezpiecznych praktyk przeglądania, które mogą skorzystać z ich zysków). Jeśli byłyby to pełne aplikacje internetowe, takie jak Plunker, możesz mieć rację, ale większość „aplikacji internetowych” to tylko „aplikacje” w tym sensie, że są zbudowane na jakimś frameworku. Pod względem użytkowania są to po prostu strony internetowe z większą ilością dzwonków i gwizdków niż kiedyś.
Dissident Rage,
6

SPA jest najbardziej korzystne, jeśli tworzysz aplikację, która nie pasuje do klasycznego modelu stron żądania / odpowiedzi. Istnieje ostatnio trend, w którym zwykłe strony internetowe są pisane jako SPA, nawet jeśli pasują do cyklu zapytań / odpowiedzi w sieci, IMHO robią głupie wysiłki. To, co robią takie strony internetowe, to słabe przebudowywanie przeglądarki internetowej o wiele więcej błędów i mniej funkcji.

Idea stopniowego ulepszania i SPA nie wyklucza się wzajemnie w przypadku tych głupich, jednostronicowych stron z aplikacjami. Potrzebujesz po prostu javascript do przeprowadzenia negocjacji treści (tj. Nagłówka Accept), aby otrzymali zasób JSON, który JavaScript w SPA może się wyrenderować zamiast wstępnie renderowanych stron HTML. Problemy z tego rodzaju SPA stron internetowych są oczywiste, musisz mieć zduplikowaną implementację renderowania strony zarówno na serwerze, jak i na kliencie.

Dla prawdziwych aplikacji internetowych, tj. Takich, które naprawdę muszą być SPA, ponieważ nie pasują do standardowego wzorca żądania / odpowiedzi; stopniowe ulepszanie jest znacznie trudniejsze dla prawdziwych aplikacji, ponieważ tak naprawdę używają one przeglądarki jako platformy technologicznej do przenośnego pisania aplikacji. Język skryptowy jest istotną częścią prawdziwej aplikacji internetowej, a nie tylko taką, którą można opcjonalnie ulepszyć. Niektóre techniki ulepszeń progresywnych nadal mogą jednak działać (np. Zastąpienie wideo / audio Flash tagiem <video>/ <audio>), ale prawdziwe aplikacje internetowe będą wymagały javascript jako podstawy.

Lie Ryan
źródło
+1, ale nie zawsze łatwo jest zdecydować, czy coś „naprawdę” wymaga SPA. Na przykład aplikacje biznesowe, które w większości wprowadzają dane, z szerokim zakresem złożoności formularzy. Jeśli większość formularzy jest prosta, SPA nie jest „prawdziwie” wymagane, więc nadal istnieje napięcie między rozwiązaniami SPA a rozwiązaniami innymi niż SPA.
sinelaw
@sinelaw: Większość aplikacji biznesowych na ogół nie powinna być SPA. Istnieje kilka wyjątków, np. Arkusz kalkulacyjny, Przetwarzanie tekstu, ale te są dziwne. Wskaźniki, że potrzebujesz SPA: jeśli chcesz przesyłać dane z serwera do klienta, nie tylko dla jednego lub dwóch powiadomień, ale jako kluczowy element aplikacji, np. Gra, śledzenie zapasów, czat; jeśli aplikacja nie ma rozsądnego pojęcia „strona” lub pojęcie „strona” zostało całkowicie zniekształcone w aplikacji, np. w aplikacjach pakietu Office. Aplikacje biznesowe, które działają głównie na formularzach, lepiej pozostają w wersji innej niż SPA.
Lie Ryan,
Zgodzić się. Kolejny wskaźnik dla SPA: jeśli opracowanie SPA jest tańsze niż opracowanie „klasycznej” strony internetowej. Aplikacje biznesowe skierowane do określonych odbiorców mogą czasem nakładać takie wymagania, jak „korzystać z nowoczesnej przeglądarki”, dzięki czemu progresywne ulepszanie niesie ze sobą niewiele korzyści.
sinelaw
@sinelaw: Budowa SPA prawie nigdy nie jest tańsza niż tworzenie stron wielostronicowych; zwłaszcza jeśli nie korzystasz ze starszych przeglądarek.
Lie Ryan
Jeśli Twój zespół składa się z ekspertów SPA z niewielkim doświadczeniem w projektach zorientowanych na serwer, będzie to tańsze.
sinelaw
2

Uważam, że aplikacje internetowe z jedną stroną i stopniowe ulepszanie są prawie antagonistami. Jeśli HTML jest obliczany na kliencie na podstawie danych pobranych z interfejsu API JSON, nie może on z łatwością ulec płynnej degradacji. Może jednak zaoferować bogatszy i przyjemniejszy interfejs użytkownika.

Możesz skonfigurować bota, który będzie indeksował twoją aplikację i zapisywał wersję statyczną. Tej techniki można używać do wyświetlania HTML w przeglądarkach bez javascript (używają go osoby niewidome lub boty wyszukiwarek). To inwestycja, więc naprawdę sprowadza się do twoich wymagań.

Czy tworzysz aplikację internetową do zarządzania zasobami ludzkimi dla konkretnego przedsiębiorstwa? Nie potrzebujesz pełnej wdzięku degradacji, a SPA może być łatwiejsze do zbudowania. Firma może wymusić użycie określonej przeglądarki, więc możesz mieć mniej testów do zrobienia.

Czy tworzysz publiczną stronę internetową dla powiązania z wymogami dostępności i potrzebami widoczności w wyszukiwarkach? Następnie rozważ zbudowanie kodu HTML na swoim serwerze. Lub stworzenie SPA ze statyczną wersją, w zależności od budżetu.

Simon Bergot
źródło
1

Myślę, że zależy to od tego, jak daleko chcesz posunąć się dzięki Progressive Enhancement - to raczej paradygmat projektowania niż twardy i szybki zestaw reguł.

Jeśli używasz frameworka SPA, myślę, że zezwolenie na Javascript jest oczywiste. Jednak JavaScript, który piszesz w celu ulepszenia swojej strony, musi być wystarczająco inteligentny, aby poradzić sobie z każdym HTMLem, który może stworzyć framework.

Możesz także skorzystać z innych technik PE, takich jak wykorzystanie najnowszych funkcji CSS w najnowszej wersji przeglądarki lub degradacja HTML5 do HTML4.

philicomus
źródło
1
Częścią stopniowego ulepszania jest to, że podstawowa treść powinna być dostępna bez javascript. Nie jestem pewien, jak napisać SPA bez javascript.
Alan Shutko
@AlanShutko Być może z elementami iframe. Wiele stron, ale technicznie URL się nie zmienia ...;)
Izkata
1
Tak, myślę, że myślałem bardziej w kategoriach HTML 5 vs HTML 4 i takich rzeczy, jak CSS specyficzne dla przeglądarki (np. Możesz chcieć skorzystać z niedawno zaimplementowanej funkcji dostępnej tylko w najnowszej wersji Chrome, ale która obniża się do bardziej prymitywna kontrola w starszych przeglądarkach). Wykonanie bez javascript byłoby trudne w SPA, ale to tylko jedna część koncepcji stopniowego ulepszania.
philicomus
Progresywne ulepszanie może być tak proste, jak użycie css3, jeśli jest dostępne do zaokrąglania rogów. Podstawowy pomysł nie ma nic wspólnego z JavaScript.
Daniel Little
1

Stopniowe ulepszanie i aplikacja pojedynczej strony mogą współistnieć. Dwa najbardziej przekonujące argumenty, które słyszałem o tworzeniu aplikacji w ten sposób, to:

  • Odporność na awarie w sytuacjach, gdy pliki HTML są pobierane w całości, ale skrypty, do których się odwołują, nie pobierają się całkowicie dzięki łączności sieciowej, która spada i zanika (możliwe w sieciach komórkowych)
  • Potencjał do poprawy postrzeganej wydajności przy początkowym wczytywaniu strony (przez skrócenie czasu rozpoczęcia renderowania)

Renderowanie po stronie serwera (jest to dla użytkowników, nie tylko ze względu na SEO) i wyczyn to dwie techniki, które mogą pomóc w tworzeniu stopniowo ulepszanych aplikacji jednostronicowych z nowoczesnymi ramami JS po stronie klienta.

Niektóre frameworki JS po stronie klienta są łatwiejsze do pracy z renderowaniem po stronie serwera niż inne ( uważaj, niektóre rozwiązania renderowania po stronie serwera i kombinacje frameworków nie dają działających SPA, ponieważ strona renderowana na serwerze jest przeznaczona tylko do użytku w wyszukiwarkach, a nie do końca -users ).

W chwili pisania tego tekstu, React.js i Ember (wraz z nadchodzącym FastBoot) są tymi dwoma, o których wiem, że mają lub starają się, aby po stronie serwera uczynić z obywatela pierwszej klasy; renderowana strona po stronie serwera jest nadal działającym SPA, gdy jest analizowana w przeglądarce klienta.

Eliot Sykes
źródło
0

Jestem zdania, że ​​zmniejszone obciążenie strony jest prawdopodobnie całkiem dobre dla serwerów i sieci. Chciałbym zobaczyć więcej SPA używanych poprawnie.

Nie jestem jednak zdania, że ​​wymaga to dwóch rzeczy:

1) konfigurowanie wszystkich linków jako standardowych linków żądania / odpowiedzi przy początkowym ładowaniu, pozwól ramie / bibliotece SPA zastąpić je zaktualizowaną (interaktywną) wersją, gdy przeglądarka się załaduje, a silnik JS stwierdzi, że dostępna jest obsługa SPA. To naprawdę jest progresywne ulepszenie; JS jest ładowany na istniejącej stronie HTML, co jest lepsze dla wyszukiwarek, technologii wspomagających i starszych przeglądarek.

i

2) Serwer musi reagować na trasy takie jak / foo / bar / json i foo / bar, podając właściwy format; realistycznie, jeśli zawijasz wszystko w układach i częściach, aby uzyskać pierwszą stronę, powinieneś być w stanie uzyskać wszystko poprzez układy i częściowe dla drugiej i kolejnych stron.

Jest tu sporo pracy; co prawda, ale jeśli masz kontrolę nad pełnym stosem, równoważy obie technologie.

Crispen Smith
źródło