Pospiesz się po stronie klienta w tworzeniu stron internetowych

10

W ciągu ostatnich kilku miesięcy zauważyłem duże podekscytowanie skryptami po stronie klienta w tworzeniu stron internetowych. Ale podczas gdy technologie po stronie serwera są dojrzałe, stabilne i dobrze akceptowane przez programistów zaplecza, technologie po stronie klienta są niedojrzałe (tj. W porównaniu do dużego frameworku po stronie serwera) i nie są lubiane przez wielu długoletnich programistów. Niemniej jednak obecnie wszyscy pracują nad rozwojem po stronie klienta. Osobiście oczekuję, że te duże frameworki po stronie serwera znikną za około 2-5 lat, obserwując obecny trend.

Dlaczego to jest takie? W jaki sposób nowe i „rozproszone” oprogramowanie po stronie klienta w HTML5 / JS może być lepsze od dużych i dobrze przemyślanych rozwiązań po stronie serwera?

Bruno Schäpper
źródło
4
Czy masz jakieś źródła, by zweryfikować swoje założenia? JavaScript jest prawie tak stary jak sam Internet i nie widzę, aby programowanie po stronie serwera nigdzie się zbliżało.
tdammers
1
Aby wyjaśnić, moje założenia są ograniczone do interfejsu. Widzę przesunięcie w stronę klienta, w logice interfejsu użytkownika, renderowaniu i tym podobnych. Oczywiście po stronie serwera nigdy nie zniknie, ale zostanie zredukowany do interfejsu API REST (lub SOAP).
Bruno Schäpper
3
Ta zmiana przychodzi i odchodzi. Zwykle tworzenie front-endów staje się bardziej popularne, gdy wprowadzane są nowe fajne technologie (Shockwave, Flash, JavaFX, Flex) lub duże nowe frameworki js próbują „przejąć świat” (motools, jquery itp.)
Andrzej Bobak
1
@VainFellowman: Naprawdę nie chcesz używać SOAP w skrypcie po stronie klienta. Jest o wiele za dużo narzutów, parsowanie go jest uciążliwe, a ty nie wygrywasz zbyt wiele, ponieważ JavaScript z jego dynamiczną dyscypliną pisania i tak nie będzie w stanie w dużym stopniu wykorzystać informacji o typie SOAP.
tdammers
1
@tdammers Nie chcę, naprawdę nie. Nie widzę sensu w używaniu SOAP przez HTTP. REST nadaje się do prawie wszystkiego.
Bruno Schäpper

Odpowiedzi:

7

To prawda:

Pospiesz się po stronie klienta w tworzeniu stron internetowych

Ale nie ogranicza się do strony klienta, jest to ruch pełnego stosu.

Wiem, że to może być zaskakujące. Wysłuchaj mnie

Dlaczego to jest takie? W jaki sposób nowe i „rozproszone” oprogramowanie po stronie klienta w HTML5 / JS może być lepsze od dużych i dobrze przemyślanych rozwiązań po stronie serwera?

Po pierwsze, oba są dobrze przemyślane.

Po drugie, ponieważ jest lepiej.

Dobre pytanie.

Ale „lepszy” jest subiektywny, więc odpowiedź na twoje pytanie brzmi: co konkretnie jest lepsze?

Ponownie odwiedź pytanie:

Jak „rozproszone” tworzenie po stronie klienta w HTML5 / JS może być lepsze od dużych rozwiązań po stronie serwera?

Because small is nimble.
And big is clunky.

To jest elastyczność.

To nie wydaje się wielka sprawa. Czy to? Elastyczność.

Jednak elastyczność leży u podstaw wszystkiego. Jedna poprawa elastyczności - poprawia wszystko.

Konserwowalność. Rozciągliwość. Skalowalność Modułowość. Użyteczność UX.

I jest szybszy do wdrożenia. To jest rzeczywistość. Szybciej i lepiej.

This is why Windows 8 made JS a first-class citizen.

HTML5 - JS, nie jest modą i nie zniknie. Widzimy tylko zalążki technologii, która będzie się rozwijać, aby zapewnić treści obliczeniowe i interakcje tabletom. Tabletki

Smartfony były najszybszą adopcją środków masowego przekazu od czasu telewizji w latach pięćdziesiątych. Teraz nie tylko mamy smartfony - ale także tablety.

Już w fazie rozwoju w Mozilli i Windows system operacyjny, który będzie działał na przyszłych urządzeniach na ich rynkach -> HTML / JS.

Pozostało wiele rozwiązań i innowacji.

Pojawia się pełen stos JS oparty na elastyczności.

Mam nadzieję że to pomogło.

Jack Stone
źródło
1
Świetna odpowiedź! Ale frameworki po stronie serwera obiecują te same korzyści, prawda?
Bruno Schäpper,
1
Tak, Sir, frameworki po stronie serwera obiecują te same korzyści, tak. Należy wiedzieć, że pojawiające się nieoczekiwanie dodatkowe korzyści pojawiają się w pojawiającej się technologii. Jest na najniższym poziomie (c) w IO. Wątki czekają. W JS ma wywołanie zwrotne. To nie czeka Tak więc istnieje optymalizacja IO na najniższym poziomie. Ta realizacja została teraz spokojnie przyjęta w dużej mierze przez Microsoft. Dlatego ich systemem operacyjnym jest JS. Ostatni punkt: optymalizacja i optymalizacja meta - na wszystkich poziomach. Ponieważ język jest elastyczny. Prosta, niewidoczna rzecz. Nieznany. Mam nadzieję, że to pomaga.
Jack Stone
1
Zdecydowałem się przyjąć tę odpowiedź, ponieważ jest ona najbardziej kompletna. Wszystkie pozostałe mają dobre strony, ale jest to najbardziej rozstrzygające. Dziękuję wszystkim!
Bruno Schäpper
9

Ta historia zawsze miała dwie strony; zarówno kod po stronie serwera, jak i kod po stronie klienta mają swoje zalety i wady.

Zalety skryptów po stronie klienta obejmują:

  • Może być bardziej responsywny, możliwe są rozległe zmiany bez objazdów serwera.
  • Kod działa na kliencie, zmniejszając zużycie zasobów na serwerze.
  • Rozdzielenie logiki od prezentacji staje się fizyczne.
  • Czasami łatwiej jest zrównoważyć obciążenie, szczególnie jeśli używane jest uwierzytelnianie na żądanie.

Ale skrypt po stronie serwera ma również wiele zalet:

  • Kontrolujesz maszynę, na której działa kod.
  • Niemal wszystko jest możliwe - jeśli twój serwer to potrafi, to i twój skrypt.
  • Użytkownicy nie mogą modyfikować skryptu przed jego uruchomieniem.
  • Użytkownicy nie mogą używać programów blokujących skrypty, aby uniemożliwić uruchomienie skryptu.
  • Użytkownicy nie widzą, co robi skrypt, mogą tylko obserwować dane wyjściowe.
  • Kod będzie działał niezawodnie z każdym klientem, jaki możesz sobie wyobrazić, w tym czytnikami ekranu, tekstowymi przeglądarkami internetowymi, pająkami wyszukiwarek, skrobakami, akumulatorami, botami IRC, maszynami klasy wyższej, przeglądarkami blokującymi skrypty, jak go nazwiesz.
  • Wtyczki użytkownika są mniej podatne na uszkodzenie.

W przypadku wysoce dynamicznych aplikacji internetowych podejście zorientowane na klienta zawsze było popularnym wyborem, ponieważ jest to jedyny sposób na zapewnienie przyzwoitego wrażenia użytkownika na pulpicie: bez skryptów po stronie klienta każda akcja użytkownika wymaga rundy trip, co oznacza co najmniej pół sekundy opóźnienia, zwykle więcej. Ale w przypadku witryny informacyjnej, która jest po prostu zbiorem statycznych stron obsługiwanych z bazy danych (powiedzmy, wikipedia), przewaga jest znikoma, a zalety skryptów po stronie serwera są wciąż przytłaczające.

Zaobserwowany szum pochodzi z kombinacji dwóch najnowszych osiągnięć:

  1. HTML5 i jego korona powiązanych technologii. Trwało to zbyt długo, ale teraz w końcu mamy standard, który zawiera wszystko, czego potrzebujesz, aby tworzyć dynamiczne aplikacje internetowe typu desktop bez gromadzenia włamań i przeglądarek głównego nurtu, które odpowiednio je wdrażają.
  2. Dostępna moc przetwarzania. Dzisiejsze podstawowe komputery stacjonarne są tak samo wydajne jak podstawowy serwer WWW, telefony komórkowe klasy klienta to praktycznie komputery stacjonarne 2005, a nowoczesne implementacje javascript są wystarczająco wydajne, aby przechylić równowagę wydajności: do tej pory zasoby po stronie klienta są tańsze niż serwer zasoby.

W rzeczywistości nic się nie zmieniło pod względem tego, w czym dobre są podejścia skoncentrowane na serwerze i na kliencie; zmieniło się to, że zorientowanie na klienta jest teraz łatwiejsze i tańsze oraz działa lepiej niż kilka lat temu, co czyni go realnym wyborem dla znacznie większej liczby aplikacji niż kiedyś.

tdammers
źródło
twarde prawdy ... +1.
Jack Stone,
8

Strona serwera zawsze będzie w pobliżu. Nie możesz siedzieć po stronie klienta za wszystko. Na przykład nie chcesz używać projektu MVC Backbone.js dla mikrokontrolera przesyłającego parametry w czasie rzeczywistym z suwnicy produkcyjnej.

Nie wierz w szum.

lwm
źródło
Powiedz mi. Czy JS w Windows 8, hype? -1. Zgadzam się z pierwszym punktem, ale twój drugi punkt dotyczący szumu wymaga wyjaśnienia.
Jack Stone,
JS nie jest wyłączny po stronie klienta i nie był przez jakiś czas.
Erik Reppen 18.04.13
@ClintNash ya, właściwie. Ms umożliwiła j's tworzenie aplikacji win8 w celu zwiększenia potencjalnej liczby programistów dla ich platformy. Jest to odpowiedź dla osób decydujących się na naukę tych technologii zamiast technologii komputerowych. Ale jako rev, który już zna c # / wpf, nie widzę powodu, aby budować aplikację win8 z HTML / JS.
Andy
@ErikReppen to prawda, ale sam js nie wycina go na serwerze, potrzebujesz frameworku do wbudowania. Szczerze mówiąc, zaskakuje mnie chęć użycia skryptu na serwerze. Zrobiliśmy to już, to była klasyczna ASP i tak naprawdę nie mam ochoty powtarzać tego doświadczenia.
Andy
@Andy Na klasycznej ASP (w szczególności formularze internetowe) nie znajdziesz końca porozumienia z żadnym twórcą JS, który miał nieszczęście mieć dostęp do narzędzi, których zdecydowanie nie chcemy tam wracać. Jest to jednak najmniej zapamiętane narzędzie skryptowe po stronie serwera oparte na tagach i prawdopodobnie najbardziej gwałtownie pogardzane rozwiązanie typu cienki klient, które kiedykolwiek cieszyło się popularnością. Porównywanie tego do czegoś takiego jak Python i teraz JS po stronie serwera graniczy z mówieniem ludziom, żeby kupili konia.
Erik Reppen
6

W 2009 roku dokonałem zmiany z frameworku PHP po stronie serwera na rozwiązanie ExtJS po stronie klienta powiązane z usługami internetowymi po stronie serwera.

Powodem migracji były dla mnie:

  1. Większe bezpieczeństwo poprzez zmniejszenie liczby punktów końcowych i kodu na serwerze.
    Przechodząc do usług internetowych, weryfikujesz dane wejściowe na granicy usług internetowych i masz dokładniejszą kontrolę nad operacjami wejścia / wyjścia serwera. Nie ma warstwy interfejsu użytkownika po stronie serwera, która by zamrozić twoją architekturę bezpieczeństwa.
  2. Poprawiona wydajność z powodu mniejszej liczby objazdów serwera
    Zmiana architektury powoduje, że pobieranie danych może się zdarzać rzadziej, a dane mogą być buforowane lokalnie przy użyciu renderowania interfejsu użytkownika, który w ogóle nie wymaga obchodzenia w obie strony. W obie strony zabijają wydajność aplikacji internetowych.
  3. Poprawiona wydajność z powodu buforowania interfejsu
    użytkownika Warstwa interfejsu użytkownika może być całkowicie hostowana w sieci CDN. Zbudowałem nawet aplikacje sieciowe offline, wpychając kod interfejsu użytkownika do pamięci podręcznej aplikacji HTML5.
  4. Większa wierność interfejsu użytkownika (rozbudowana kontrola po stronie klienta)
  5. Zewnętrzni programiści mogą korzystać z tego samego interfejsu API, z którego korzysta mój własny interfejs, i mogę łatwo ponownie używać interfejsów API w modułach, jeśli mają wspólne funkcje.
    Oznacza to mniej prac rozwojowych, kontroli jakości, dokumentacji ...
  6. Lubię programować w JavaScript lepiej niż PHP, Python lub Java

Ale nie pomylcie się, to, co dzieje się teraz, jest szumem. Zostanie zdmuchnięty i wiele aplikacji internetowych ponownie użyje architektury interfejsu użytkownika po stronie serwera.

Joeri Sebrechts
źródło
Co, hype? -1 Powodzenia, gdy Windows 8 czyni JS obywatelem pierwszej klasy. Tak, może architektura interfejsu użytkownika po stronie serwera napisana w node.js. Musimy się tego nauczyć, ponieważ nie blokuje.
Jack Stone,
Nie sądzę, że wrócimy wkrótce do rozwiązań typu gruby klient. Ale gdybym był obarczony ExtJS za jakikolwiek problem, który stał się bardziej skomplikowany niż kupowanie pre-fab web UI (tj. Wszystkie problemy niezależnie od pierwotnego planu), wiedziałbym, dlaczego alternatywa może wydawać się mniej niż idealna.
Erik Reppen
6

Innym czynnikiem napędzającym entuzjazm dla rozwiązań po stronie klienta jest wzrost aplikacji mobilnych. Jeśli utworzysz witrynę w dużym stopniu opartą na JavaScript i AJAX po stronie klienta, a także zbudujesz natywne aplikacje na iOS i Androida, istnieje duża szansa, że ​​wszyscy trzej mogą korzystać z tych samych usług REST, aby wykonywać wszystkie swoje operacje na danych .

Carson63000
źródło
Dobrze powiedziane ... +1.
Jack Stone,
Rzeczywiście bardzo dobra uwaga.
Bruno Schäpper
4

Przede wszystkim użytkownik nie widzi (a czasem nawet nie obchodzi) tego, co nie jest serwerem. Bez względu na to, jak dobrze napisany jest kod po stronie serwera, użytkownicy nie docenią aplikacji, jeśli część klienta nie zostanie wykonana dobrze. Czasami nawet ładny interfejs użytkownika jest ważniejszy niż funkcjonalność.

Duży i wydajny hosting serwerów jest dość drogi. Znacznie taniej jest zaimplementować niektóre elementy logiczne (oprócz sprawdzania poprawności) po stronie klienta. Możesz więc użyć mniejszego (a więc tańszego) hostingu serwerów, ponieważ nie byłby tak bardzo ładowany.

Z tego powodu, pomimo niestabilności, technologie po stronie klienta zyskują coraz większą popularność. Poza tym JS i HTML / CSS są obsługiwane przez (prawie) wszystkie nowoczesne przeglądarki.

Te dwie części aplikacji nie mogą istnieć osobno. Internet wydaje się nie opuszczać w najbliższej przyszłości.
Nie sądzę, żeby big server-side frameworkste zniknęły. Zawsze znajdą się firmy, które mogą sobie na nie pozwolić i wykorzystają swoje znaczące zalety.

superM
źródło
4

Tworzenie stron internetowych po stronie klienta jest ściśle powiązane z przeglądarkami internetowymi i ich zmianami w miarę upływu czasu. Podane przez Ciebie rozwiązanie może nie działać w ciągu kilku miesięcy z powodu istotnych zmian w silnikach renderujących strony w przeglądarkach internetowych. Niektóre przeglądarki są / były niezgodne ze standardami i dlatego wymagały jeszcze większego wysiłku ze strony programistów, aby osiągnąć oczekiwany wynik.

Istnieje kilka rozwiązań próbujących rozwiązać ten problem. Na przykład, jeśli używasz jquery, masz pewność, że Twój skrypt będzie działał w przeglądarkach obsługiwanych przez tę konkretną bibliotekę jquery. Ale tylko od autorów zależy, czy zapewnisz zgodność z niektórymi / większością / wszystkimi przeglądarkami. Pytanie brzmi, który zespół będzie cię lepiej wspierać. Czy będzie to zespół motools, zespół jquery, inny zespół? Jeśli nie obsługują one określonej przeglądarki internetowej, Twój projekt może nie działać w tej przeglądarce.

Podniecenie, które wydaje się istnieć od dłuższego czasu. Widziałem to, gdy Shockwave i jego następca Flash zostały wprowadzone, nastąpił „wielki powrót” bogatych interfejsów użytkownika po dostarczeniu złożonych bibliotek js, najpierw z motools, a następnie z jquery (zacząłem używać ich w tej kolejności). Były Flex i JavaFX. Ale żaden z nich nie może uzyskać dużego udziału w rynku. Niektóre wymagają wtyczek, które z czasem często narażają użytkownika na luki w zabezpieczeniach, inne mogą nie działać po stronie klienta z powodu niektórych niestandardowych ustawień (np. JavaScript wyłączony w przeglądarce klienta).

Z drugiej strony rozwiązanie po stronie serwera jest zwykle pisane tylko raz. Nie musisz się martwić, że wszystko się nie powiedzie i będzie trzeba go przepisać, gdy pojawi się nowy Firefox / Chrome / IE / Opera. Nie musisz się również martwić, że klient spróbuje zmodyfikować twoją aplikację i / lub uszkodzić dane.

Andrzej Bobak
źródło
1
Czy to nie jest czysta wyobraźnia? Prawdopodobnie będziesz musiał zmienić ustawienia po stronie serwera, gdy zmieniają się klienci, ponieważ w pewnym momencie nie będziesz musiał generować HTML / JS / CSS.
Bruno Schäpper
1
I jeszcze jedno: „Tworzenie stron internetowych po stronie klienta jest ściśle powiązane z przeglądarkami internetowymi” - Technologie sieciowe są oficjalnymi standardami, o ile trzymasz się tego, wdrażasz standard, a nie łączysz swojej aplikacji z przeglądarką. Chociaż nie tak dawno temu tak naprawdę nie było prawdą, wydaje się, że tak jest w tej chwili.
Bruno Schäpper
Przede wszystkim przeczytaj, jak niektóre przeglądarki po prostu nie przestrzegają standardów (na przykład Internet Explorer). Z czasem wszystko się zmieniło, ale nawet z IE7 miałem okropne problemy z powodu własnego sposobu interpretacji tego, co napisałem. Przeczytaj także kilka artykułów na temat kompatybilności w różnych przeglądarkach. Ten problem nie istniałby, gdyby każdy dostawca przeglądarki internetowej przestrzegał standardów. Po drugie, jeśli zestaw danych się zmieni, musisz zmienić logikę biznesową, to oczywiste, ale kiedy zostanie wysłany nowy IE i musisz przepisać około 30% kodu, aby kod działał w nowej przeglądarce - coś jest nie tak
Andrzej Bobak
Oczywiście wiem, jak bolesne jest to, że wszystko działa w każdej przeglądarce. Ale ta praca musi być wykonana niezależnie od strony serwera lub klienta (ponieważ w końcu i tak musisz korzystać z przeglądarki). Z pewnością zgadzam się z twoją drugą kwestią. Jednak nie widzę 30% do przepisania. Być może potrzebne są pewne zmiany, ale wątpię, aby były tak złe, jak w dawnych czasach. Z drugiej strony musisz powtórzyć wszystko w oparciu o warstwę usług, jeśli chcesz zastąpić stos po stronie serwera. Jesteś więc bardzo ściśle powiązany z implementacją po stronie serwera. Prawdopodobnie z góry interfejsu użytkownika do modelu.
Bruno Schäpper
-1

Absolutnie zgódź się z twoimi sentymentami. Uważam również, że poza tym, co mówisz, zobaczymy dramatyczny spadek REST i ogromny wzrost liczby gniazd internetowych, głównie w związku z tym, jak widzimy, jak strony komunikują się z powrotem na swoje serwery. Vert.x, Node.js itp. Cała strona serwera, a także strona klienta, przechodzi na programowanie oparte na zdarzeniach. Java EE, PHP, Rails itp. Wszyscy muszą się dostosować, inaczej stracą bardzo szybko.

kodowanie
źródło
Bez wyjaśnienia odpowiedź ta może stać się bezużyteczna w przypadku, gdy ktoś inny przedstawi inną opinię. Na przykład, jeśli ktoś opublikuje takie stwierdzenie: „nie zobaczymy dramatycznego spadku REST i masowego wzrostu w gniazdach internetowych”, w jaki sposób ta odpowiedź pomoże czytelnikowi wybrać te odmienne opinie? Zastanów się, czy nie zmienić go w lepszy kształt
komnata,