6 powodów, dla których Aplikacje Internetowe to nie Srebrna kula, której szukasz – blog.

w ciągu ostatnich dwóch lat coraz częściej słyszałem o pojęciu Izomorficznych aplikacji internetowych. Również w tym czasie, zrobiłem trochę myślenia o technice. Mój wniosek jest taki, że izomorficzne Aplikacje Internetowe to coś, co nie dodałoby wartości dla mnie lub typowych organizacji, dla których pracuję. Kilka rzeczy doprowadziło mnie do tego wniosku.

ale zanim podam powody, najpierw podkreślę, że uważam, że biblioteki izomorficzne javascript (np. lodash.js) są super. Ponadto, myślę, że izolowane izomorficzne składniki mogą być cenne, na przykład na żywo zaktualizowany wskaźnik giełdowy.

powody, dla których nie wierzę, że aplikacje internetowe są cenne dla mnie lub organizacji, dla których pracuję, to:

• serwer WWW może być teraz napisany tylko w javascript
• izomorficzne aplikacje internetowe nigdy nie mogą być progresywnym ulepszeniem dla nietrywialnych aplikacji
• blokowanie vs nieblokujący przepływ danych
• czas do interakcji i niesamowita Dolina
• urządzenia mobilne zamarzają podczas parsowania javascript
• twoi najlepsi programiści są teraz zajęci nie wytwarzaniem wartości

chcę zacząć od definicji izomorficznych aplikacji internetowych. Izomorficzna aplikacja internetowa to aplikacja internetowa, w której kod aplikacji nie wie, gdzie jest uruchomiony. Zamiast tego ta wiedza jest przechowywana w kodzie infrastruktury i pozwala aplikacji jako całości działać zarówno po stronie klienta, jak i serwera.

web serwer może być teraz napisany tylko w javascript

jeśli kod klienta i Kod serwera są takie same (a Klient może dziś tylko interpretować javascript), wtedy jesteśmy ograniczeni do używania javascript tylko na serwerze. Lubię node.js bardzo, ale myślę, że lepiej być otwartym na alternatywy w przyszłości, w mojej perspektywie.

izomorficzne aplikacje internetowe nigdy nie mogą być progresywnym ulepszeniem dla nietrywialnych aplikacji

javascript po stronie Klienta ma dostęp do maszyny stanu w pamięci, która pozwala na drobnoziarnisty poziom interakcji z bardzo niskim opóźnieniem (sub milisekundy). To samo nie dotyczy maszyny stanu HTTP, która jest napędzana kliknięciami łącza i przesyłaniem formularzy.

dla mnie Progressive Enhancement ma zacząć się od linii bazowej, która jest dostępna dla wszystkich możliwych urządzeń / przeglądarek,od starych do obecnych do przyszłych. W praktyce oznacza to podstawę renderowania po stronie serwera. Krok ulepszenia to decyzja biznesowa o tym, gdzie ulepszyć witrynę/aplikację, aby zwiększyć wartość. Innymi słowy, ulepszenie odbywa się w kodzie aplikacji (specyficznym), a *nie* w kodzie infrastruktury (ogólnym), z wyjątkiem technik optymalizacji, takich jak pjax lub turbolinks.

sposobem dla Izomorficznych aplikacji internetowych na progresywne Ulepszanie jest wzięcie tej drobnoziarnistej maszyny stanu w pamięci i „przetłumaczenie” jej tak, aby używała tylko linków i formularzy. Jedyne przypadki, w których jest to możliwe, to kiedy nie potrzebujesz pełnego renderowania po stronie klienta, ale zamiast tego możesz polegać na wyżej wymienionych technikach optymalizacji i komponentach po stronie klienta w celu zwiększenia doświadczenia (np. komponent kalendarza dla pola wejściowego dla daty).

wariantem tego rozwiązania jest nie obsługa każdego stanu/przejścia po stronie klienta w maszynie stanu po stronie serwera. W tym przypadku powinna to być decyzja biznesowa, która musi zostać odzwierciedlona w kodzie aplikacji, dzięki czemu środowisko kodu aplikacji jest wrażliwe, co jest sprzeczne z ideą Izomorficznych aplikacji internetowych.

sposobem dla Izomorficznych aplikacji internetowych, aby uzyskać Progresywne ulepszenie, jest wzięcie tej drobnoziarnistej maszyny stanu w pamięci i „przetłumaczenie” jej, aby używała tylko linków i formularzy.

blokowanie vs nieblokujący przepływ danych

Sekwencja renderowania dla sieci po stronie serwera i sieci po stronie klienta jest inna: blokuje się po stronie serwera, a nie po stronie klienta.

wyobraź sobie, że musimy wykonać dwa żądania do niektórych Usług, aby wyświetlić widok. Możemy wykonać te żądania równolegle.

po stronie serwera, jeśli drugie żądanie zwróci pierwsze, może renderować tę część odpowiedzi, ale musi zablokować wysyłanie tych bajtów, dopóki pierwsze nie wyrenderuje i nie zwróci tej części odpowiedzi z powrotem do przeglądarki.

po stronie klienta to ograniczenie nie istnieje: obie odpowiedzi mogą być obsługiwane i renderowane niezależnie.

również, myślę, że powyższe reprezentuje najprostszy z przykładów. Wyobraź sobie, że masz drzewo komponentów, w którym główny komponent jest inteligentny (zobacz Komponenty prezentacyjne i kontenerowe, aby uzyskać wyjaśnienie inteligentnych/głupich komponentów), a następnie kilka poziomów głupich komponentów, a następnie co najmniej jeden komponent liścia, który jest inteligentny.

Infrastruktura następnie potrzebuje sposobu, aby upewnić się, że kontekst smart leaf nie zostanie utracony, tak że tracimy kontrolę nad wykonywaniem blokowania/nieblokowania, w zależności od trybu serwera/klienta. Jednym ze sposobów rozwiązania tego problemu może być wykonanie całego programu w wolnej monadzie, reprezentującej wykonanie jako dane do późniejszej interpretacji. Innym rozwiązaniem może być użycie jakiejś formy wzorca odwiedzającego i niech komponenty deklarują, jakich danych potrzebują (podobnie jak Tutorial: Handcrafting Izomorphic Redux Application (With Love)). Ta ostatnia jest prawdopodobnie najłatwiejsza. Chodzi mi o to, że problem różnych trybów blokowania jest prawdopodobnie znacznie bardziej skomplikowany, niż można sobie wyobrazić na początku.

alternatywną konstrukcją jest posiadanie reguły, która mówi „tylko komponent główny może być inteligentnym komponentem”, podobnie jak w przypadku monady IO w Haskell, zachowując czyste liście i mając tylko skutki uboczne na najwyższym poziomie. Myślę, że ten projekt jest dobry po stronie serwera, ale nie po stronie klienta: komponent po stronie Klienta powinien być w stanie załadować własne dane w przynajmniej niektórych scenariuszach, na przykład dotyczących komponentów związanych z mediami społecznościowymi. Posiadanie reguły, która nigdy nie pozwala na takie scenariusze, wydaje się bardzo bezproduktywne.

czas na interakcję i niesamowita Dolina

dzięki izomorficznemu podejściu do aplikacji Internetowych Użytkownik będzie widział na ekranie elementy graficzne, które wydają się być interaktywne, ale nie są. innymi słowy, czas między tym, kiedy przeglądarka wyrenderowała odpowiedź serwera, a tym, kiedy javascript jest pobierany, parsowany i wykonywany. Nazywa się to „niesamowitą Doliną” lub „wioską Potiomkina”.

zobacz ten tweet i odpowiedzi, aby uzyskać więcej szczegółów.

urządzenia mobilne zamrażają się podczas parsowania javascript

na „typowym” telefonie komórkowym otrzymujesz 1ms UI wątku na 1KB javascript, zgodnie z tym tweetem. Malte Ubl jest liderem technologicznym projektu AMP, więc podejrzewam, że wie, o czym mówi.

twoi najlepsi programiści są teraz zajęci nie wytwarzaniem wartości

Isomorphic Web Apps to podejście, które wymaga wysokiego poziomu umiejętności programistycznych. W wielu obszarach (przynajmniej na zachodzie) trudno jest znaleźć i zatrudnić wysoko wykwalifikowanych programistów. Wybór tworzenia Izomorficznych aplikacji internetowych przydziela tym programistom coś, co moim zdaniem generuje jakąkolwiek wartość biznesową. Są lepsze sposoby na wykorzystanie ich czasu.

podsumowanie

Isomorphic Web Apps ogranicza wybór języka/platformy serwera www tylko do javascript. Ma ambicje, aby umożliwić stopniowe Ulepszanie, ale nie może tego osiągnąć. Wprowadza wysoki poziom złożoności technicznej ze względu na różnice w blokowaniu / nieblokowaniu przepływu danych. Wprowadza okno czasowe, w którym rzeczy wydają się być interaktywne, ale nie są (niesamowita Dolina). Duża ilość javascript zawiesza również przeglądarki mobilne, z zasadą, że 1KB javascript oznacza 1ms zablokowanego wątku interfejsu użytkownika. A ponieważ wymaga skomplikowanego projektowania oprogramowania, wymaga cennego czasu i wysiłku od najlepszych programistów – istnieje lepszy sposób na wykorzystanie ich czasu.

na koniec chcę podkreślić, że Twoje doświadczenia mogą być inne niż moje. Być może istnieją scenariusze, gdy izomorficzne aplikacje internetowe są dobre. Ale nie są one srebrną kulą do wypełniania każdej luki między korzyściami sieciowymi po stronie serwera a korzyściami sieciowymi po stronie klienta, a jednocześnie nie mają żadnych wad obu podejść.

co o tym sądzisz? Rozważałeś „idąc izomorficznie”? Czy masz jakieś przemyślenia na temat wyzwań i kosztów? Jak sobie z nimi radzisz?

podziękowania

Dziękuję Oskarowi Wickströmowi i Perowi Ökvistowi za cenne dyskusje na ten temat. Oskar również przeglądał ten post-dziękuję Oskar.