Po stronie klienta a po stronie serwera (który?)

Czytałem ostatnio kilka bardzo ciekawych artykułów na temat renderowania całego klienta vs. serwera.

Http://www.onebigfluke.com/2015/01/experimentally-verified-why-client-side.html

Http://www.quirksmode.org/blog/archives/2015/01/angular_and_tem.html

Http://tomdale.net/2015/02/youre-missing-the-point-of-server-side-rendered-javascript-apps/

Teraz byłem trochę fanem, Jeśli chodzi o stronę klienta, ale po Przeczytałem te artykuły, ku mojemu zdziwieniu zaczęły pojawiać się pewne punkty na korzyść renderowania po stronie serwera... Główne punkty to:

  • 1) możesz uaktualnić swój serwer, ale nie Urządzenie Użytkownika - oznacza to, no cóż, tak... To Ty masz kontrolę nad serwerem, więc jeśli jest on pod kontrolą, możesz zdecydować się na aktualizację/skalowanie. Nie możesz zmuszać użytkowników do uaktualniania swoich urządzeń.

  • 2) pierwsza farba vs. ostatnia farba - teraz w linku experimentally verified... powyżej pokazuje, kiedy użytkownicy po raz pierwszy zobaczą stronę (pierwszy paint) i kiedy użytkownicy mogą korzystać ze strony w 100% (ostatni paint). Teraz z tego, o czym mogę myśleć, gdy użytkownik widzi stronę, zajmuje ich mózgowi trochę czasu, aby przetworzyć sygnały z kory wzrokowej do kory czołowej, a następnie do kory przedtrzonowej, gdzie użytkownik faktycznie zaczyna klikać palcem, to jest oczywiście, jeśli html jest renderowany najpierw, więc mózg ma coś do przetworzenia podczas ładowania dzieje się w tle (Pliki js, oprawa itp.).

To, co naprawdę mnie przyciągnęło, to bit, w którym twitter donosił, że ludzie mają do 10 sekund czasu ładowania dla renderowania po stronie klienta, nikt nigdy nie powinien tego doświadczyć ! To coś w rodzaju powiedzenia: "cóż, jeśli nie masz wystarczająco dobrego urządzenia, przykro mi, będziesz musiał poczekać.".

Zastanawiałem się, czy nie ma dobrego sposobu na użycie zarówno silników szablonowych po stronie klienta, jak i serwera, które zarówno klient i serwer użyj tego samego silnika szablonu i kodu . W takim przypadku jest to tylko po to, aby dowiedzieć się, czy jest dobroczyńcą dostarczyć klientowi renderowaną stronę, czy pozwolić klientowi renderować ją samemu.

W każdym razie, podziel się swoimi przemyśleniami na temat moich powiedzeń i artykułów, Jeśli chcesz. Zamieniam się w słuch!

Author: Karl Morrison, 2015-03-26

2 answers

Zasadniczo jesteś lookign dla izomorficznej aplikacji internetowej , która ma ten sam kod dla frontend i backend.

Izomorficzny JavaScript

Aplikacje JavaScript, które działają zarówno po stronie klienta, jak i po stronie serwera. Izomorficzne frameworki JavaScript są kolejnym krokiem w ewolucji frameworków JavaScript. Te nowe biblioteki i frameworki rozwiązują problemy związane z tradycyjnymi frameworkami JavaScript.

I bet this guy wyjaśnia to znacznie lepiej niż ja.

Tutaj wpisz opis obrazka

Tak więc, gdy użytkownik przychodzi na stronę, serwer renderuje całą stronę z zawartością. Więc ładuje się szybciej i nie wymaga dodatkowych żądań ajax do ładowania danych, itp. Następnie, gdy użytkownik przechodzi do innej strony, używane są zwykłe techniki aplikacji jednostronicowych.

Więc, co mnie to obchodzi?
  • stare przeglądarki / słabe urządzenia / wyłączony Javascript
  • SEO
  • niektóre ładowanie strony ulepszenia

Stare przeglądarki / słabe urządzenia / wyłączony Javascript

Na przykład IE9 nie obsługuje API historii. Tak więc, dla starych przeglądarek (i jeśli użytkownik wyłącza javascript zbyt), oni po prostu poruszać się po stronach, tak jak zrobili to w starych dobrych czasach.

SEO

Google mówi obsługuje SPA ale SPA raczej nie pojawią się w najlepszych wynikach wyszukiwania google, prawda?

Prędkość strony

Jak stwierdzono, pierwszy strona ładuje się jednym żądaniem HTTP i to wszystko.

OK, więc

Istnieje wiele artykułów na ten temat:

Ale czy powinno mnie to obchodzić?

To zależy od ciebie, oczywiście.

Yeah, that ' s cool, but potrzeba dużo pracy, aby przepisać / dostosować istniejącą aplikację. A jeśli twój backend jest w PHP / Ruby / Python / Java / Whatever, mam dla ciebie złe wieści(niekoniecznie niemożliwe, ale bliskie).

To zależy od strony, możesz spróbować zebrać trochę statystyk i jeśli odsetek użytkowników ze starymi urządzeniami jest mały, nie warto się trudzić, więc dlaczego nie...

NIECH CIERPIĄ

Jeśli zależy Ci tylko na użytkownikach ze starymi urządzeniami, to daj spokój, jest to twój user problem jeśli używa IE8 przeglądania stron z iPodem Touch 2. Na przykład, Angular zmniejszył obsługę IE8 W 1.3 około rok temu, więc dlaczego nie miałbyś po prostu ostrzec użytkowników, że muszą uaktualnić;)

Zdrówko!
 16
Author: Alexander Mikhalchenko,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-03-03 15:01:29

Wszystkie rozmowy na ten temat pominęły jeden punkt. Bajtów wysłanych do klienta. Strony renderowane jako HTML na serwerze są o wiele mniejsze. Mniej przesyłanych bajtów jest lepsze dla wszystkich, zarówno serwera, jak i klienta. Widziałem koszty przepustowości w witrynach w chmurze, a nawet redukcja o 10% może być ogromną oszczędnością. Strony js po stronie klienta są zawsze grube.

 -2
Author: Experienced Programmer,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-04-22 17:19:37