Czy renderowanie interfejsu użytkownika po stronie klienta za pomocą Javascript jest dobrym pomysłem?

Question

"Klasyczne" podejście do tworzenia stron internetowych było od jakiegoś czasu cienkim klientem i grubym serwerem: serwer generuje HTML i wypycha go do przeglądarki, aby tylko renderować. Ale przy obecnych przeglądarkach (a także ze względu na dostępność dobrych bibliotek i frameworków) Javascript działa teraz. Twórcy stron internetowych mogą teraz założyć, że ich kod JavaScript będzie działał i przestanie się martwić.

To z pewnością otworzyło nowe możliwości rozwoju sieci. Aplikacje mogą teraz składać się głównie z treści HTML zwróconych z serwera i renderowanych przez przeglądarkę z pewną manipulacją interfejsu użytkownika wykonywaną po stronie klienta. Klient może nawet wysyłać zapytania do serwera o nowe dane w celu aktualizacji części interfejsu. Ale czy możemy pójść w drugą stronę? Aplikację można z pewnością zaprojektować jako serwer, który pluje tylko najbardziej minimalistycznym JSONem sklejonym z grubym klientem Javascript odpowiedzialnym za budowanie i kontrolowanie całego interfejsu użytkownika. Tak, to podejście może poważnie przełamać adresy URL w takim stopniu, że ludzie nie mogą już wysyłać wskaźników, ale z pewnością można to zaplanować (a dla niektórych aplikacji, takich jak poczta elektroniczna i czytniki kanałów, nie ma nawet materia).

Co myślisz? Czy kiedykolwiek próbowałeś tego podejścia? Czy rzeczy stają się zbyt wolne? Czy współczesne przeglądarki są w stanie poradzić sobie z taką ilością kodu Javascript? Czy istnieją znaczne różnice między implementacjami przeglądarek, które wciąż gryzą niewykształcony programista nawet z najnowszymi bibliotekami? Jakiego rodzaju aplikacje są według Ciebie odpowiednie? Czy rzeczywiście nadaje się do czegokolwiek, co jest?

Answer 1

Jestem na końcu budowy tego rodzaju aplikacji. Jest to GUI ExtJS na szczycie usług internetowych Zend Framework JSON-RPC, implementując portal gadżetowy podobny do iGoogle.

Zalety:

• Bardzo czuły UI, ExtJS daje wspaniałe wrażenia użytkownika.
• Bardzo przewidywalna komunikacja klient-serwer. Wszystko jest jsonem (łatwe do debugowania). W interfejsie API istnieje standardowa obsługa błędów (przynajmniej tak ją zaprojektowałem).
• Front-end jest wymienny. Mógłbym napisać aplikację C++ na samym zapleczu serwera. Oddzielenie front-end i back-end na linii klient-serwer oznacza, że ​​są one łatwiejsze do testowania niezależnie.
• Żyjesz i oddychasz javascript, co jest wspaniałe, jeśli Ci się podoba.

Wady:

• Trzeba żyć i oddychać JavaScript, który zasysa jeśli go nienawidzą. W naszym przypadku oznaczało to znaczne przekwalifikowanie zespołu programistów, ponieważ byliśmy obciążeni PHP.
• Wszystko żyje w jednym długowiecznym DOM, więc musisz trzymać się palców z zarządzaniem pamięcią i upewniając się, że rzeczy są porządnie oczyszczone. Ponadto ładowanie zbyt wielu interfejsów sprawia, że ​​IE go "ow, ow, rani mój mózg".
• Nie ma uruchomionego szybkiego zapytania, aby pobrać opcję w trakcie generowania interfejsu użytkownika. Ograniczenia projektu dotyczące życia na kliencie są początkowo zniechęcające. Przyzwyczajasz się do tego, ale to trochę przeszkoda.
• Ładowanie całego tego javascript oznacza, że ​​użytkownicy potrzebują szybkich połączeń i nowoczesnych przeglądarek.

Powodem, dla którego to zrobiliśmy, było zapewnienie lepszego komfortu użytkowania. Użytkownicy oczekują komputerów typu "desktop" i nie można ich dostarczyć w ramach obiegu serwera. Dostarczamy to teraz, ale nie można zaprzeczyć, że z takim podejściem wiążą się duże wyzwania. Ogólnie jestem zadowolony.

Update (wrzesień 2013):

Mimo korzystania z tej architektury i wciąż myśli, że to prawo architektura jeśli budujemy prawdziwej aplikacji internetowych (nie tylko strona internetowa z pewnych cech dynamicznych). Nasz zespół i produkt jest teraz znacznie większy (zbliża się do 500 000 linii kodu), ale architektura została skalowana bez problemu. Obecnie istnieje wiele naprawdę dobrych, skalowalnych frameworków javascript (kątowych, ember, ...), więc łatwiej jest zaadaptować ten sposób pracy.

Ponieważ @rwoo zapytał pewne wyzwania, które wciąż mamy:

• na żądanie wczytywania kodu js okazuje się być trudniejsze problemem niż przewidywano. Ważne jest, aby ta część była właściwa w twojej architekturze.
• Musieliśmy zintegrować automatyczną walidację jshint w hakowaniu przed popełnieniem błędu w subversion, ponieważ js jest zbyt tolerancyjna na błędy składniowe i często nie zauważasz tego, dopóki produkt nie dotrze do klienta.
• Ponieważ baza danych znajduje się na drugim końcu żądania usługi sieciowej, musisz dokładnie zaprojektować interfejs API usług internetowych, aby uzyskać niską wydajność z powodu oczekiwania na zbyt wiele żądań XHR. Jest to rozwiązalne, ale trudne, a z czasem nie jest łatwiejsze.
• O ile odpowiednie problemy z ramą dla różnych przeglądarek są zminimalizowane, nie znikają całkowicie, co oznacza, że ​​trzeba przetestować we wszystkich przeglądarkach, we wszystkich wersjach. Jest to tak duża praca, że ​​trzeba ją zautomatyzować za pomocą czegoś podobnego do selenu, a jak się okazuje, jest to trudniejsze w przypadku interfejsu użytkownika renderowanego po stronie klienta niż interfejsu renderowanego po stronie serwera.

Answer 2

Narzędzia takie jak Google GWT rób to, co opisujesz - renderuj znaczną część strony klienta w javascript. Niektóre z gruboziarnistych układów nadal są zużyte za pomocą HTML, ale interesujące bity są wykonywane dynamicznie po stronie klienta.

Ale GWT używa wygenerowanego javascript, a nie odręcznego. Robienie tego ręcznie jest bolesne.

Answer 3

ExtJS, YUI, dojo ... Ramki że w zasadzie oferują rękę w realizacji aplikacji, takich jak ta, którą opisujesz

My (w miejscu pracy) użył takiego podejścia z powodzeniem od wielu wielu dużych & małych aplikacjach skalę ... Na ogół oparcie większości aplikacji na ExtJS + jQuery, w niektórych przypadkach na dojo (Zend Framework (jeśli w ogóle interesujesz się światem PHP) zapewnij wygodną integrację z elementami dojo)

Jeśli nie jest nadużywane i używane tylko ze względu na jego użycie lub wpływ na czynnik chłodu - to niesamowite narzędzie.

Przy prawidłowym projekcie nie jest ani ciężki ani powolny, jak podejście jako takie.

Answer 4

Zrobiłem to ręcznie. To był rodzaj bólu, ale jest trochę pozytywów. Jest to odpowiednie tylko w przypadku bogatych aplikacji internetowych, w których wycofanie ma niewielki sens. Myślę, że zobaczymy coraz więcej aplikacji wymagających JavaScript, zwłaszcza po pojawieniu się frameworków takich jak Cappuccino Atlas.

Answer 5

Myślę, że to jest okropne. Trudno się rozwijać. Trudne do debugowania. Trudno uzyskać funkcjonalność, jakiej potrzebujesz. Wolę, aby aplikacje internetowe były tak proste, jak to tylko możliwe, i chodzę do zwykłych aplikacji GUI, gdy potrzebuję czegoś bardziej złożonego.

Answer 6

Twoje twierdzenie, że twórcy stron internetowych mogą teraz "założyć, że ich kod JavaScript działa", jest trudne do zaakceptowania. Z mojego doświadczenia wynika, że ​​Javascript jest prawie zawsze czarną dziurą ssącą cały czas i energię, którą można jej dostarczyć. Ramy takie jak Prototype i Script.aculo.us znacznie poprawiły jakość, ale nie są jeszcze tak stwardniałe, jak twoje pytanie.

Dwa główne problemy to jeden, obsługa przeglądarki i dwa to czas rozwoju. Korzystasz z aplikacji, której nie możesz kontrolować, aby obsłużyć większość obciążenia pracą aplikacji. Fakt, że może to być zepsute nawet najmniejszą aktualizacją przeglądarki, dotyczyłoby mnie. Generowanie strony serwera HTML w dużym stopniu ogranicza to ryzyko. Opracowanie bogatego interfejsu JavaScript jest czasochłonne, trudne do debugowania i równie trudne do przetestowania w szerokiej gamie dostępnych przeglądarek.

Podczas gdy te obawy są prawdziwe, nie można zignorować faktu, że można uzyskać fantastyczne doznania użytkownika za pośrednictwem skryptu JavaScript po stronie klienta. Ramy, o których wspomniałem wcześniej, ujawniają funkcjonalność, o której nawet nie śniło się rok lub dwa lata, iw rezultacie w dużej mierze opłacają się z góry wysoką cenę programowania (a czasami znacznie się skracają, gdy ramy są skutecznie wdrażane).

Sądzę, że istnieją aplikacje dla interfejsu użytkownika z obsługą języka JavaScript, o ile decyzja o przejściu na tę trasę jest dobrze przemyślana. Nie dyskutowalibyśmy o tym na SO, gdyby nie fakt, że potencjał interfejsu użytkownika korzystający z tej strategii jest niesamowity. Aplikacje internetowe wykorzystujące dane internetowe są doskonałymi kandydatami (RSS, usługi REST). Aplikacje, które trafiają do bazy relacji lub złożonych usług sieciowych, będą musiały z konieczności utrzymywać ściślejsze sprzężenie z serwerem.

Moje 2 centy.

Answer 7

Jeśli dobrze rozumiem twoje pytanie, myślę, że odnosisz się do tego, jakiego rodzaju rozwoju używasz z czymś takim jak ExtJS. Z Ext nie można już pisać żadnego HTML, a raczej zaprojektować całą aplikację głównie za pomocą JavaScript, używając technik podobnych do aplikacji GUI dla programistów na pulpicie.

W większości przypadków nowoczesne zestawy narzędzi niemal wyeliminowały większość dziwactw przeglądarki. Chociaż z pewnością można czasami spotkać się z problemami z renderowaniem w różnych przeglądarkach, to nie jest to tak wielki problem, jak byłoby, gdybyś sam próbował napisać wszystkie JS. Prędkość powinna być akceptowalna nawet w IE6, chociaż ogólnie uzyskasz lepszą wydajność w najnowszej wersji Safari, Chrome lub Firefox. (Nie wiem wystarczająco dużo o IE7 lub 8, aby skomentować).

Podniesiono jednak prawidłowy punkt dotyczący adresów URL i ich udziału. Nawet poza przypadkiem udostępniania danych jest to ważne dla lokalizacji zakładek w aplikacji. Dostępne są techniki przechowywania stanu aplikacji i możliwość jej odtworzenia, ale o ile wiem, nadal nie jest to łatwe. Z tego powodu rozsądnie jest unikać bogatych aplikacji internetowych w sytuacjach, gdy nie są one konieczne. Prostsze aplikacje internetowe mogą być łatwiejsze do debugowania, testowania i konserwacji.

Mimo to istnieją sytuacje, w których bogate aplikacje internetowe mają wiele sensu. Na przykład wiele wewnętrznych aplikacji komputerowych dla przedsiębiorstw można przepisać, aby były bogatymi aplikacjami internetowymi. Mogą zapewnić podobny wygląd i sposób działania, widżety i wzorce interakcji jako aplikacje desktopowe, ułatwiając przejście do aplikacji internetowej. Zewnętrzne aplikacje, które wymagają manipulowania danymi (np. Czytniki e-mail/news, aplikacje księgowe itp.) Również mogą być doskonałym rozwiązaniem.

Answer 8

W przypadku wewnętrznych linii aplikacji biznesowych, w których można kontrolować pulpit, javascript ma sens.

W przypadku aplikacji zewnętrznych/publicznych, w których nie masz pojęcia, z której przeglądarki korzystają Twoi klienci, zachowaj spokój i używaj jej w jak najmniejszym stopniu.

Kiedy mówisz, że JavaScript po prostu działa teraz ze względu na frameworki, to nie jest do końca prawdą. IE 6 jest nadal szeroko rozpowszechniony, podobnie jak starsza wersja Safari. Nawet FF 2.x i 1.x w pewnym stopniu mają przyzwoity udział w rynku konsumenckim.

Oprócz tego, nie każdy ma szybki internet, co jest dość wymagające dla wielu z tych frameworków. Co więcej, chociaż większość bibliotek pracuje z IE 7, jest to pies dla większości operacji.

Jeśli chodzi o rozmiar biblioteki, mamy wiele formantów .net, które lubią wstrzykiwać do 1 MB javascript do klienta. Próbuję wysłać to babci.

Wreszcie telefony podnoszą użytkowników jako podstawowe urządzenie dostępu do internetu. Niestety, ich rozmiar pamięci podręcznej jest mały i, w większości przypadków, te fajne rzeczy javascript nie działają zbyt dobrze.

Answer 9

YUI Teatr ma film, który moim zdaniem jest bardzo istotne pytanie - gorąco polecam oglądanie go

High-performance JavaScript: Why Everything You've Been Taught Is Wrong

Tytuł jest nieco mylący, ale on rzeczywiście mówi o samych zagadnień ty Stoję twarzą w twarz.

Answer 10

Lubię wdrażać podejście hybrydowe. Kiedy strona jest najpierw żądana, powinna zostać wypełniona tak dużą ilością informacji, jak można to wywnioskować z adresu URL/Querystring/Post. A następnie wszelkie kolejne zmiany stanu mogą być wyszukiwane i aktualizowane za pomocą Ajax.

Wiele osób ma tendencję do podejścia polegającego na prostym ładowaniu strony, a następnie pozwalaniu javascriptowi/ajaxowi na ładowanie. Powoduje to, że klient czeka na załadowanie strony, a następnie klient czeka na załadowanie danych.

Znacznie lepiej pozwolić serwerowi na wykonanie początkowego ładowania danych i zapełnić wszystkie elementy interfejsu użytkownika.