Pospiesz się po stronie klienta w tworzeniu stron internetowych

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?

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.

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

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.

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.

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 .

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.

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.

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.