Aplikacja jednostronicowa: zalety i wady [zamknięte]

Czytałem o SPA i jego zaletach. Uważam, że większość z nich nie jest przekonująca. Istnieją 3 zalety, które budzą moje wątpliwości.

Pytanie: Czy możesz działać jako rzecznik SPA i udowodnić, że mylę się co do pierwszych trzech stwierdzeń?

                              === ADVANTAGES ===

1. SPA jest bardzo dobre dla bardzo responsywnych stron:

Renderowanie po stronie serwera jest trudne do wdrożenia dla wszystkich stanów pośrednich - małe stany widoku nie odwzorowują dobrze adresów URL.

Aplikacje jednostronicowe wyróżniają się tym, że potrafią przerysować dowolną część interfejsu użytkownika bez konieczności pobierania pliku HTML w obie strony. Osiąga się to poprzez oddzielenie danych od prezentacji danych poprzez posiadanie warstwy modelu, która obsługuje dane i warstwy widoku, która odczytuje z modeli.

Co jest złego w utrzymywaniu warstwy modelu dla non-SPA? Czy SPA jest jedyną kompatybilną architekturą z MVC po stronie klienta?

2. Dzięki SPA nie musimy używać dodatkowych zapytań do serwera, aby pobierać strony.

Hah i ile stron użytkownik może pobrać podczas odwiedzania Twojej witryny? Dwa trzy? Zamiast tego pojawiają się inne problemy z bezpieczeństwem i musisz oddzielić swoją stronę logowania, stronę administratora itp. Na osobne strony. Z kolei koliduje z architekturą SPA.

3.Czy mogą być jakieś inne zalety? Nie słyszę o niczym innym ...

                            === DISADVANTAGES ===

1. Klient musi włączyć javascript.
2. Tylko jeden punkt wejścia do witryny.
3. Bezpieczeństwo.

PS Pracowałem nad projektami SPA i nie-SPA. Zadaję te pytania, ponieważ muszę pogłębić swoje zrozumienie. Nie ma sensu szkodzić zwolennikom SPA. Nie proś mnie o więcej informacji na temat SPA. Chcę tylko usłyszeć twoje przemyślenia na ten temat.

Spójrzmy na jedną z najpopularniejszych stron SPA, GMail.

1. SPA jest bardzo dobre dla bardzo responsywnych stron:

Renderowanie po stronie serwera nie jest tak trudne, jak kiedyś przy użyciu prostych technik, takich jak utrzymywanie # skrótu w adresie URL, a ostatnio HTML5pushState . Przy takim podejściu dokładny stan aplikacji internetowej jest osadzony w adresie URL strony. Podobnie jak w Gmailu za każdym razem, gdy otwierasz pocztę, do adresu URL dodawany jest specjalny tag skrótu. Po skopiowaniu i wklejeniu do innego okna przeglądarki można otworzyć dokładnie tę samą pocztę (pod warunkiem, że mogą się uwierzytelnić). To podejście odwzorowuje bezpośrednio na bardziej tradycyjny ciąg zapytania, różnica polega jedynie na wykonaniu. Dzięki HTML5 pushState () możesz wyeliminować #hashi używać całkowicie klasycznych adresów URL, które można rozpoznać na serwerze przy pierwszym żądaniu, a następnie załadować za pośrednictwem ajax przy kolejnych żądaniach.

2. Dzięki SPA nie musimy używać dodatkowych zapytań do serwera, aby pobierać strony.

Liczba stron pobranych przez użytkownika podczas wizyty na mojej stronie internetowej? naprawdę, ile e-maili czyta niektórzy, gdy otworzy swoje konto pocztowe. Czytam> 50 za jednym zamachem. teraz struktura maili jest prawie taka sama. jeśli użyjesz schematu renderowania po stronie serwera, serwer wyrenderuje go na każde żądanie (typowy przypadek). - obawy związane z bezpieczeństwem - nie powinieneś / nie powinnaś przechowywać oddzielnych stron dla administratorów / logowania, które całkowicie zależą od struktury twojej witryny. weź na przykład paytm.com, również utworzenie strony internetowej SPA nie oznacza, że ​​otwierasz wszystkie punkty końcowe dla wszystkich Użytkownicy Mam na myśli, że używam auth formularzy na mojej stronie spa. - w prawdopodobnie najczęściej używanym frameworku SPA Angular JS programista może załadować całą świątynię html ze strony internetowej, dzięki czemu można to zrobić w zależności od poziomu uwierzytelnienia użytkowników. wstępne ładowanie HTML dla wszystkich typów uwierzytelniania nie jest

3. Czy mogą być jakieś inne zalety? Nie słyszę o niczym innym ...

• w tych dniach możesz bezpiecznie założyć, że klient będzie miał przeglądarki obsługujące javascript.
• tylko jeden punkt wejścia na stronę. Jak wspomniałem wcześniej, utrzymanie stanu jest możliwe, możesz mieć dowolną liczbę punktów wejścia, jak chcesz, ale na pewno powinieneś mieć jeden.
• nawet w użytkownikach SPA widzi tylko to, co ma odpowiednie prawa. nie musisz wstrzykiwać wszystkiego na raz. ładowanie szablonów HTML diff i asynchronii javascript jest również ważną częścią SPA.

Zalety, które mogę wymyślić, to:

1. renderowanie HTML oczywiście zajmuje trochę zasobów, teraz robi to każdy użytkownik odwiedzający Twoją witrynę. nie tylko renderowanie głównych logiki jest teraz wykonywane po stronie klienta zamiast po stronie serwera.
2. problemy z datą i czasem - po prostu daję klientowi czas UTC jest wstępnie ustawionym formatem i nawet nie dbam o strefy czasowe, na które pozwalam javascript obsługiwać. jest to wielka zaleta w przypadku, gdy musiałem zgadywać strefy czasowe na podstawie lokalizacji uzyskanej z adresu IP użytkownika.
3. dla mnie stan jest ładniej utrzymywany w SPA, ponieważ po ustawieniu zmiennej wiesz, że ona tam będzie. daje to poczucie tworzenia aplikacji, a nie strony internetowej. pomaga to zwykle w tworzeniu stron takich jak foodpanda, flipkart, amazon. ponieważ jeśli nie używasz stanu po stronie klienta, korzystasz z drogich sesji.
4. strony internetowe z pewnością są bardzo responsywne - wezmę ekstremalny przykład dla tej próby zrobienia kalkulatora na stronie internetowej innej niż SPA (wiem, że to dziwne).

Aktualizacje z komentarzy

Wydaje się, że nikt nie wspominał o gniazdach i długim odpytywaniu. Jeśli wylogujesz się z innego klienta, powiedz, aplikacja mobilna, Twoja przeglądarka również powinna się wylogować. Jeśli nie korzystasz ze SPA, musisz ponownie utworzyć połączenie przez gniazdo za każdym razem, gdy nastąpi przekierowanie. Powinno to również działać z wszelkimi aktualizacjami danych, takimi jak powiadomienia, aktualizacja profilu itp

Alternatywna perspektywa: czy oprócz Twojej witryny Twój projekt będzie obejmował natywną aplikację mobilną? Jeśli tak, najprawdopodobniej będziesz podawać surowe dane do tej natywnej aplikacji z serwera (tj. JSON) i przetwarzać po stronie klienta, aby je wyrenderować, prawda? Dzięki temu stwierdzeniu JUŻ JUŻ robisz model renderowania po stronie klienta. Teraz pojawia się pytanie, dlaczego nie powinieneś używać tego samego modelu w wersji internetowej projektu? Trochę bez zastanowienia. Następnie pojawia się pytanie, czy chcesz renderować strony po stronie serwera tylko w celu uzyskania korzyści SEO i wygody udostępniania / zaksięgowywania adresów URL

Jestem pragmatykiem, więc spróbuję spojrzeć na to pod kątem kosztów i korzyści.

Zauważ, że w przypadku wszelkich wad, które daję, uznaję, że można je rozwiązać. Dlatego nie uważam niczego za czarno-białe, ale raczej koszty i korzyści.

Zalety

• Łatwiejsze śledzenie stanu - nie trzeba używać plików cookie, przesyłania formularzy, pamięci lokalnej, pamięci sesji itp., Aby zapamiętać stan między 2 ładowaniami stron.
• Zawartość płyty kotła, która znajduje się na każdej stronie (nagłówek, stopka, logo, baner praw autorskich itp.), Ładuje się tylko raz na typową sesję przeglądarki.
• Brak opóźnień związanych z przełączaniem „stron”.

Niedogodności

• Monitorowanie wydajności - nierozerwalnie związane: większość rozwiązań do monitorowania wydajności na poziomie przeglądarki widziałem skupianie się wyłącznie na czasie ładowania strony, takim jak czas do pierwszego bajtu, czas na zbudowanie DOM, objazd w obie strony dla HTML, zdarzenie onload itp. Aktualizowanie strony ładowanie po AJAX nie będzie mierzone. Istnieją rozwiązania, które pozwalają instrumentować kod w celu rejestrowania wyraźnych miar, takich jak kliknięcie łącza, uruchomienie timera, a następnie zakończenie timera po wyrenderowaniu wyników AJAX i wysłanie tej opinii. Na przykład New Relic obsługuje tę funkcję. Korzystając ze SPA, przywiązałeś się tylko do kilku możliwych narzędzi.
• Testy bezpieczeństwa / penetracji - związane ręce: Zautomatyzowane skanowanie bezpieczeństwa może mieć trudności z wykryciem linków, gdy cała strona jest budowana dynamicznie przez środowisko SPA. Prawdopodobnie istnieją rozwiązania tego problemu, ale ponownie ograniczyłeś się.
• Pakowanie: łatwo jest znaleźć się w sytuacji, gdy pobierasz cały kod potrzebny dla całej witryny przy pierwszym ładowaniu strony, co może być bardzo trudne w przypadku połączeń o niskiej przepustowości. Możesz spakować pliki JavaScript i CSS, aby próbować ładować bardziej naturalne fragmenty podczas podróży, ale teraz musisz zachować to mapowanie i uważać na niezamierzone pliki, które zostaną wciągnięte przez niezrealizowane zależności (właśnie mi się przydarzyło). Znów, do rozwiązania, ale z kosztem.
• Refaktoryzacja Wielkiego Wybuchu: Jeśli chcesz dokonać poważnej zmiany w architekturze, np. Przejść z jednej struktury do drugiej, aby zminimalizować ryzyko, pożądane jest wprowadzanie zmian stopniowych. Oznacza to, że zacznij korzystać z nowego, migruj na niektórych zasadach, takich jak na stronę, na funkcję itp., A następnie usuń stary po. W tradycyjnej aplikacji wielostronicowej możesz przełączyć jedną stronę z Angular na React, a następnie przełączyć inną stronę w następnym sprincie. W SPA wszystko jest albo nic. Jeśli chcesz zmienić, musisz zmienić całą aplikację za jednym razem.
• Złożoność nawigacji: istnieją narzędzia, które pomagają w utrzymaniu kontekstu nawigacyjnego w SPA, takich jak history.js, Angular 2, z których większość opiera się na frameworku URL (#) lub nowszym interfejsie API historii. Jeśli każda strona była oddzielną stroną, nie potrzebujesz jej żadnej.
• Złożoność wymyślania kodu: strony internetowe uważamy naturalnie za strony. Aplikacja wielostronicowa zwykle dzieli kod na strony, co ułatwia utrzymanie.

Znów uznaję, że każdy z tych problemów można rozwiązać za pewną cenę. Ale przychodzi moment, w którym spędzasz cały swój czas na rozwiązywaniu problemów, których mógłbyś przede wszystkim uniknąć. Wraca do korzyści i tego, jak ważne są dla Ciebie.

Niedogodności

1. Klient musi włączyć javascript. Tak, to wyraźna wada SPA. W moim przypadku wiem, że mogę oczekiwać od moich użytkowników włączonej obsługi JavaScript. Jeśli nie możesz, nie możesz zrobić SPA, kropka. To tak, jakby próbować wdrożyć aplikację .NET na komputerze bez zainstalowanego .NET Framework.

2. Tylko jeden punkt wejścia do witryny. Rozwiązuję ten problem za pomocą SammyJS . 2-3 dni pracy, aby prawidłowo skonfigurować routing, a ludzie będą mogli tworzyć precyzyjne zakładki w Twojej aplikacji, które działają poprawnie. Twój serwer będzie musiał ujawnić tylko jeden punkt końcowy - punkt końcowy „daj mi HTML + CSS + JS dla tej aplikacji” (pomyśl o tym jako o lokalizacji pobierania / aktualizacji dla wstępnie skompilowanej aplikacji) - a skrypt JavaScript po stronie klienta napisze obsłużyć faktyczny wpis do aplikacji.

3. Bezpieczeństwo.Ten problem nie jest unikalny w przypadku SPA, musisz mieć do czynienia z bezpieczeństwem dokładnie w ten sam sposób, gdy masz „staroświecką” aplikację klient-serwer (model HATEOAS wykorzystujący hipertekst do łączenia stron). Po prostu użytkownik wysyła żądania, a nie JavaScript, a wyniki są w formacie HTML zamiast JSON lub innego formatu danych. W aplikacji innej niż SPA musisz zabezpieczyć poszczególne strony na serwerze, podczas gdy w aplikacji SPA musisz zabezpieczyć punkty końcowe danych. (A jeśli nie chcesz, aby Twój klient miał dostęp do całego kodu, musisz również podzielić JavaScript do pobrania na osobne obszary. Po prostu powiązuję to z moim systemem routingu opartym na SammyJS, aby przeglądarka tylko żądała rzeczy, o których klient wie, że powinien mieć dostęp, na podstawie początkowego obciążenia ról użytkownika,

Zalety

1. Główną zaletą architektoniczną SPA (o której rzadko się wspomina) w wielu przypadkach jest ogromne zmniejszenie „chattiness” Twojej aplikacji. Jeśli odpowiednio zaprojektujesz, aby obsługiwał większość przetwarzania na kliencie (w końcu cały punkt), wówczas liczba żądań do serwera (czytaj „możliwości wystąpienia błędów 503, które niszczą twoje wrażenia użytkownika”) jest znacznie zmniejszona. W rzeczywistości SPA umożliwia przetwarzanie całkowicie offline, co w niektórych sytuacjach jest ogromne .

2. Wydajność jest z pewnością lepsza przy renderowaniu po stronie klienta, jeśli zrobisz to dobrze, ale nie jest to najbardziej przekonujący powód do zbudowania SPA. (W końcu prędkości sieci się poprawiają). Nie uzasadniaj tego SPA na tej podstawie.

3. Elastyczność projektowania interfejsu użytkownika to chyba kolejna ważna zaleta, którą znalazłem. Po zdefiniowaniu mojego interfejsu API (z SDK w JavaScript) mogłem całkowicie przepisać mój interfejs bez wpływu na serwer oprócz niektórych plików zasobów statycznych. Spróbuj to zrobić za pomocą tradycyjnej aplikacji MVC! :) (Staje się to cenne, gdy masz martwe wdrożenia i spójność wersji interfejsu API).

Podsumowując: jeśli potrzebujesz przetwarzania offline (lub przynajmniej chcesz, aby Twoi klienci mogli przetrwać sporadyczne awarie serwerów) - znacznie zmniejszając własne koszty sprzętu - i możesz założyć JavaScript i nowoczesne przeglądarki, to potrzebujesz SPA. W innych przypadkach jest to raczej kompromis.

Jedną z głównych wad SPA - SEO. Dopiero niedawno Google i Bing rozpoczęły indeksowanie stron opartych na Ajaxie, wykonując JavaScript podczas indeksowania, a nadal w wielu przypadkach strony są indeksowane nieprawidłowo.

Tworząc SPA, będziesz musiał poradzić sobie z problemami SEO, prawdopodobnie po renderowaniu całej witryny i tworzeniu statycznych migawek HTML na użytek robota. Będzie to wymagało solidnych inwestycji w odpowiednią infrastrukturę.

Aktualizacja 19.06.16:

Od czasu, gdy napisałem tę odpowiedź jakiś czas temu, zyskuję znacznie więcej doświadczenia z aplikacjami Single Page (czyli AngularJS 1.x) - więc mam więcej informacji do przekazania.

Moim zdaniem główną wadą aplikacji SPA jest SEO, przez co ograniczają się one do rodzaju aplikacji „deski rozdzielczej”. Poza tym buforowanie będzie znacznie trudniejsze niż w przypadku klasycznych rozwiązań. Na przykład w ASP.NET buforowanie jest niezwykle łatwe - wystarczy włączyć OutputCaching i jesteś dobry: cała strona HTML będzie buforowana zgodnie z adresem URL (lub dowolnymi innymi parametrami). Jednak w SPA musisz samodzielnie obsługiwać buforowanie (przy użyciu niektórych rozwiązań, takich jak pamięć podręczna drugiego poziomu, buforowanie szablonów itp.).

Chciałbym uzasadnić, że SPA jest najlepsze dla aplikacji opartych na danych. Gmail to oczywiście wszystko o danych, a zatem dobry kandydat do SPA.

Ale jeśli twoja strona jest głównie do wyświetlania, na przykład strona z warunkami usługi, wtedy SPA jest całkowicie przesadzone.

Myślę, że najlepszym miejscem jest strona zawierająca zarówno strony w stylu SPA, jak i statyczne / MVC, w zależności od konkretnej strony.

Na przykład w jednej witrynie, którą tworzę, użytkownik ląduje na standardowej stronie indeksu MVC. Ale kiedy przechodzą do właściwej aplikacji, wywołuje SPA. Kolejną zaletą tego jest to, że czas ładowania SPA nie jest na stronie głównej, ale na stronie aplikacji. Czas ładowania strony głównej może rozpraszać uwagę użytkowników witryny po raz pierwszy.

Ten scenariusz przypomina trochę użycie Flasha. Po kilku latach doświadczeń liczba witryn Flash tylko spadła do zera z powodu współczynnika obciążenia. Ale jako składnik strony jest nadal używany.

Dla takich firm jak Google, Amazon itp., Których serwery działają z maksymalną wydajnością w trybie 24/7, zmniejszenie ruchu oznacza prawdziwe pieniądze - mniej sprzętu, mniej energii, mniej konserwacji. Przeniesienie wykorzystania procesora z serwera na klienta się opłaca, a SPA świecą. Zalety zdecydowanie przewyższają wady. Tak więc SPA czy nie SPA zależy w dużej mierze od przypadku użycia.

Wystarczy wspomnieć o innym, prawdopodobnie nie tak oczywistym (dla twórców stron internetowych) przypadku użycia dla SPA: obecnie szukam sposobu na implementację GUI w systemach wbudowanych, a architektura oparta na przeglądarce wydaje mi się atrakcyjna. Tradycyjnie nie było wielu możliwości tworzenia interfejsów użytkownika w systemach wbudowanych - Java, Qt, wx, itp. Lub w komercyjnych strukturach komercyjnych. Kilka lat temu Adobe próbował wejść na rynek z lampą błyskową, ale wydaje się, że nie odnosi tak dużego sukcesu.

Obecnie, ponieważ „systemy wbudowane” są tak samo wydajne jak komputery mainframe kilka lat temu, możliwy jest oparty na przeglądarce interfejs użytkownika podłączony do jednostki sterującej za pośrednictwem REST. Zaletą jest ogromna paleta narzędzi do interfejsu użytkownika bez żadnych kosztów. (np. Qt wymaga 20-30 $ za sprzedaną jednostkę na opłaty licencyjne plus 3000-4000 $ na programistę)

W przypadku takiej architektury SPA oferuje wiele zalet - np. Bardziej znane podejście programistyczne dla programistów aplikacji komputerowych, ograniczony dostęp do serwera (często w przemyśle samochodowym interfejs użytkownika i mętliki systemowe są oddzielnym sprzętem, w którym część systemowa ma system operacyjny RT).

Ponieważ jedynym klientem jest wbudowana przeglądarka, wspomniane wady, takie jak dostępność JS, logowanie po stronie serwera, bezpieczeństwo już się nie liczą.

2. Dzięki SPA nie musimy używać dodatkowych zapytań do serwera, aby pobierać strony.

Nadal muszę się dużo nauczyć, ale odkąd zacząłem uczyć się o SPA, uwielbiam je.

Ten konkretny punkt może mieć ogromną różnicę.

W wielu aplikacjach internetowych, które nie są SPA, zobaczysz, że nadal będą pobierać i dodawać treści do stron wysyłających żądania ajax. Myślę więc, że SPA wykracza poza rozważanie: co jeśli zawartość, która będzie pobierana i wyświetlana za pomocą ajax, to cała strona? a nie tylko niewielka część strony?

Pozwól, że przedstawię scenariusz. Weź pod uwagę, że masz 2 strony:

1. strona z listą produktów
2. strona, aby wyświetlić szczegóły konkretnego produktu

Weź pod uwagę, że jesteś na stronie listy. Następnie kliknij produkt, aby wyświetlić szczegóły. Aplikacja po stronie klienta wywoła 2 żądania ajax:

1. prośba o uzyskanie obiektu Json ze szczegółami produktu
2. prośba o szablon HTML, w którym zostaną wstawione szczegóły produktu

Następnie aplikacja po stronie klienta wstawi dane do szablonu HTML i wyświetli je.

Następnie wróć do listy (nie jest to wymagane!) I otworzysz inny produkt. Tym razem będzie tylko prośba o uzyskanie szczegółowych informacji o produkcie. Szablon HTML będzie taki sam, więc nie musisz pobierać ponownie.

Możesz powiedzieć, że w non-SPA, kiedy otwierasz szczegóły produktu, składasz tylko 1 wniosek, aw tym scenariuszu zrobiliśmy 2. Tak. Ale zyskujesz z ogólnej perspektywy, gdy poruszasz się po wielu stronach, liczba żądań będzie niższa. Dane przesyłane między klientem a serwerem również będą niższe, ponieważ szablony HTML będą ponownie używane. Ponadto nie trzeba pobierać przy każdym żądaniu wszystkich plików css, obrazów, plików javascript, które są obecne na wszystkich stronach.

Rozważmy również, że językiem po stronie serwera jest Java. Jeśli przeanalizujesz 2 wspomniane przeze mnie żądania, 1 pobierzesz dane (nie musisz ładować żadnego pliku widoku i wywołać silnik renderowania widoku) oraz inne pliki do pobrania i statyczny szablon HTML, abyś mógł mieć serwer HTTP, który może pobierać bezpośrednio, bez konieczności wywoływania serwera aplikacji Java, żadne obliczenia nie są wykonywane!

Wreszcie duże firmy korzystają ze SPA: Facebook, GMail, Amazon. Nie grają, mają najlepszych inżynierów studiujących to wszystko. Jeśli więc nie widzisz zalet, możesz początkowo im zaufać i mieć nadzieję, że odkryjesz je później.

Ważne jest jednak stosowanie dobrych wzorców projektowych SPA. Możesz użyć frameworka takiego jak AngularJS. Nie próbuj wdrażać SPA bez stosowania dobrych wzorców projektowych, ponieważ możesz skończyć z bałaganem.

Wady : Z technicznego punktu widzenia projektowanie i początkowy rozwój SPA jest złożony i można go uniknąć. Inne powody nie korzystania z tego SPA to:

• a) Bezpieczeństwo: Aplikacja do obsługi pojedynczych stron jest mniej bezpieczna w porównaniu do tradycyjnych stron z powodu skryptów cross site scripting (XSS).
• b) Wyciek pamięci: wyciek pamięci w JavaScript może nawet spowodować spowolnienie potężnego komputera. Ponieważ tradycyjne strony internetowe zachęcają do nawigacji między stronami, wszelkie wycieki pamięci spowodowane przez poprzednią stronę są prawie czyszczone, pozostawiając mniej pozostałości.
• c) Klient musi włączyć JavaScript, aby uruchomić SPA, ale w aplikacji wielostronicowej JavaScript można całkowicie uniknąć.
• d) SPA osiąga optymalny rozmiar, powoduje długi czas oczekiwania. Np .: Praca w Gmailu przy wolniejszym połączeniu.

Poza powyższymi, innymi ograniczeniami architektonicznymi są utrata danych nawigacyjnych, brak dziennika historii nawigacji w przeglądarce oraz trudności w zautomatyzowanym testowaniu funkcjonalnym z użyciem selenu.

Ten link wyjaśnia zalety i wady aplikacji pojedynczej strony.

W moim rozwoju odkryłem dwie wyraźne zalety korzystania ze SPA. Nie oznacza to, że w tradycyjnej aplikacji internetowej nie można osiągnąć następujących celów, ponieważ widzę dodatkowe korzyści bez wprowadzania dodatkowych wad.

• Potencjał dla mniejszej liczby żądań serwera, ponieważ renderowanie nowej zawartości nie zawsze jest lub nigdy nie jest żądaniem serwera HTTP o nową stronę HTML. Mówię jednak o potencjale, ponieważ nowe treści mogą z łatwością wymagać wywołania Ajax w celu pobrania danych, ale dane te mogą być stopniowo lżejsze niż same plus znaczniki zapewniające korzyści netto.

• Zdolność do utrzymania „stanu”. Mówiąc najprościej, ustaw zmienną przy wejściu do aplikacji, a będzie ona dostępna dla innych komponentów przez cały czas użytkowania, bez przekazywania jej lub ustawiania lokalnego wzorca przechowywania. Jednak inteligentne zarządzanie tą umiejętnością ma kluczowe znaczenie dla zachowania porządku na najwyższym poziomie.

Poza wymaganiem JS (co nie jest szaloną rzeczą wymaganą od aplikacji internetowych), inne zauważone wady są moim zdaniem albo specyficzne dla SPA, albo można je złagodzić poprzez dobre nawyki i wzorce rozwoju.

Staraj się nie rozważać korzystania ze SPA bez uprzedniego zdefiniowania, w jaki sposób odniesiesz się do bezpieczeństwa i stabilności API po stronie serwera. Wtedy zobaczysz niektóre z prawdziwych zalet korzystania ze SPA. W szczególności, jeśli używasz serwera RESTful, który implementuje OAUTH 2.0 dla bezpieczeństwa, osiągniesz dwa zasadnicze rozdzielenie problemów, które mogą obniżyć koszty rozwoju i utrzymania.

1. Spowoduje to przeniesienie sesji (i jej bezpieczeństwa) do SPA i odciąży Twój serwer od całego tego narzutu.
2. Twoje interfejsy API są zarówno stabilne, jak i łatwe do rozszerzenia.

Wskazano na wcześniej, ale nie wyraźnie; Jeśli Twoim celem jest wdrożenie aplikacji na Androida i Apple, napisanie JavaScript SPA, które jest otoczone rodzimym połączeniem do obsługi ekranu w przeglądarce (Android lub Apple), eliminuje potrzebę utrzymywania zarówno bazy kodu Apple, jak i bazy kodu Android.

Rozumiem, że to starsze pytanie, ale chciałbym dodać kolejną wadę aplikacji do pojedynczej strony:

Jeśli budujesz interfejs API, który zwraca wyniki w języku danych (takim jak XML lub JSON), a nie w języku formatowania (takim jak HTML), umożliwiasz większą interoperacyjność aplikacji, na przykład w aplikacjach business-to-business (B2B). Taka interoperacyjność ma ogromne zalety, ale umożliwia pisanie oprogramowania w celu „wydobywania” (lub kradzieży) danych. Ta szczególna wada jest wspólna dla wszystkich interfejsów API, które używają języka danych, a nie ogólnie dla OSO (w rzeczywistości SPA, które prosi serwer o wstępnie renderowany HTML, pozwala tego uniknąć, ale kosztem złej separacji modelu / widoku). Ryzyko ujawnione przez tę wadę można ograniczyć za pomocą różnych środków, takich jak ograniczenie żądań i blokowanie połączeń itp.