Progresywne ulepszanie a aplikacje jednostronicowe

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?

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ć.

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.

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.

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.

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.

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.