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?
źródło
Odpowiedzi:
To prawda:
Ale nie ogranicza się do strony klienta, jest to ruch pełnego stosu.
Wiem, że to może być zaskakujące. Wysłuchaj mnie
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:
To jest elastyczność.
To nie wydaje się wielka sprawa. Czy to? Elastyczność.
Konserwowalność. Rozciągliwość. Skalowalność Modułowość. Użyteczność UX.
I jest szybszy do wdrożenia. To jest rzeczywistość. Szybciej i lepiej.
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.
źródło
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ą:
Ale skrypt po stronie serwera ma również wiele zalet:
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ęć:
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ś.
źródło
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.
źródło
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:
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.
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.
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.
Oznacza to mniej prac rozwojowych, kontroli jakości, dokumentacji ...
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.
źródło
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 .
źródło
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 frameworks
te zniknęły. Zawsze znajdą się firmy, które mogą sobie na nie pozwolić i wykorzystają swoje znaczące zalety.źródło
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.
źródło
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.
źródło