Dlaczego bazy kodu w programowaniu n-warstwowym mają teraz tyle samo, jeśli nie więcej, kodu JavaScript?

Od dłuższego czasu zajmuję się programowaniem internetowym i gdzieś straciłem orientację, dlaczego robimy to, co robimy dzisiaj (lub jak zaczęliśmy robić rzeczy w ten sposób)?

Zacząłem od podstawowego programowania stron ASP i bardzo wcześnie logika wyświetlania i biznesu była na stronie mieszana. Rozwój po stronie klienta był bardzo zróżnicowany (VBScript, różne warianty JavaScript) i otrzymaliśmy wiele ostrzeżeń o sprawdzaniu poprawności po stronie serwera (dlatego trzymałem się z dala od logiki po stronie klienta).

Potem przeniosłem się na chwilę do ColdFusion. ColdFusion był prawdopodobnie pierwszą platformą programistyczną, która oddzieliła logikę wyświetlania i biznesu za pomocą swoich tagów. Wydawało mi się to bardzo jasne, ale bardzo szczegółowe, a ColdFusion nie cieszył się dużym popytem na rynku, więc ruszyłem dalej.

Następnie wskoczyłem na wagon pasmowy ASP.NET i zacząłem stosować podejście MVC. Uświadomiłem sobie również, że Java wydaje się być językiem wieży z kości słoniowej dla systemów korporacyjnych, i wypróbowałem również ich podejście MVC. Później ASP.NET opracował ten wzorzec projektowy MVVM, a Java (a konkretnie J2EE lub JEE) również miała problemy i wyszła z podejściem MVC2.

Ale dzisiaj odkryłem, że programowanie zaplecza nie jest już tam, gdzie jest podniecenie i postęp. Ponadto praktyki MVC oparte na serwerze wydają się być przestarzałe (czy ludzie naprawdę już korzystają z JSTL?). Dzisiaj w większości projektów, w których pracuję, dowiedziałem się, że frameworki JavaScript i programowanie po stronie klienta są miejscem, w którym robione są wszystkie fascynujące i innowacyjne postępy.

Dlaczego nastąpiło takie przejście od rozwoju serwera do klienta? Zrobiłem prostą liczbę wierszy jednego z moich projektów JEE i w JavaScript jest więcej wierszy kodu niż Java (z wyłączeniem bibliotek stron trzecich). Uważam, że większość programowania backendowego przy użyciu języków programowania, takich jak Java lub C #, polega po prostu na stworzeniu interfejsu podobnego do REST, i że wszystkie ciężkie wysiłki związane z wyświetlaniem, wizualizacją, wejściem / wyjściem danych, interakcjami użytkownika itp. Są rozwiązywane poprzez frameworki po stronie klienta, takie jak Angular, Backbone, Ember, Knockout itp.

W erze przed jQuery widziałem wiele diagramów, w których istniała wyraźna, konceptualna linia między M, V i C w MVC w rozwoju n-poziomów. Post-jQuery, gdzie są rysowane te linie? Wygląda na to, że MVC i MVVM działają poprawnie w kodzie JavaScript po stronie klienta.

Chcę wiedzieć, dlaczego dokonaliśmy takiego przejścia (z nacisku na programowanie po stronie serwera na stronę klienta, z faworyzowania języków skompilowanych na języki skryptowe, z programowania imperatywnego na funkcjonalne, wydaje się, że wszystko to miało miejsce jednocześnie ) i jakie problemy rozwiązało to przejście / zmiana?

Przenoszenie obciążenia obliczeniowego między serwerem a klientem jest zjawiskiem cyklicznym i dzieje się tak już od dłuższego czasu.

Kiedy byłem na studiach społecznych, komputer osobisty dopiero zaczynał działać. Ale Ethernet nie był jeszcze w powszechnym użyciu i nikt nie miał sieci lokalnej. W tamtym czasie uczelnia posiadała komputer mainframe, który obsługiwał akta studentów i służył jako platforma do zajęć programistycznych. Administracja miała terminale, które były połączone z komputerem mainframe na zasadzie podziału czasu, ale uczniowie musieli uderzać karty, aby wykonać zadania programistyczne, co było żmudnym procesem. W końcu umieścili laboratorium, w którym uczniowie mogli zapisać się na terminale, ale nadal zajęło to około pół godziny, aby uzyskać wydruk błędów o grubości pół cala. Wszystkie prace związane z przetwarzaniem zostały wykonane na komputerze mainframe (serwerze).

Ale komputery mainframe były drogie, więc firmy zaczęły instalować sieci lokalne, a obciążenie przetwarzania przesunęło się z serwera na pojedyncze komputery klienckie, które były wystarczająco mocne, aby uruchamiać pojedyncze edytory tekstu, arkusze kalkulacyjne i aplikacje biznesowe, ale nie były wystarczająco mocne, aby dzielić się swoją mocą obliczeniową z innymi. Serwer był podobną maszyną o podobnych możliwościach (być może więcej pamięci i miejsca na dysku twardym), ale najczęściej służył do udostępniania plików. Nazywało się to Klient / Serwer. Większość przetwarzania została przeniesiona na komputery klienckie.

Jedną z wad wykonywania całego przetwarzania na komputerach klienckich było to, że zostałeś uwięziony w tym nieustannym cyklu instalacji i aktualizacji oprogramowania, a także wszystkie związane z tym bóle głowy. Model programowania tych maszyn (oparte na zdarzeniach, kodowane interfejsy użytkownika) zachęcał do tworzenia niechlujnych, trudnych do utrzymania programów (duże kule błota). Większość użytkowników końcowych nie była w stanie właściwie utrzymywać swojego sprzętu i oprogramowania, co wymagało użycia armii personelu technicznego.

W miarę jak komputery stawały się coraz potężniejsze, możliwe stały się podziały pracy. Teraz możesz mieć serwery plików, serwery baz danych, serwery WWW, serwery wydruku i tak dalej. Każda maszyna może być nieco zoptymalizowana do wykonywanego zadania i obsługiwana przez osobę posiadającą wymaganą wiedzę. Można pisać programy działające w przeglądarce internetowej, więc instalacje klienta nie są już wymagane. Nazywało się to Multi-Tier lub n-Tier. Przeglądarki były zasadniczo używane jako głupie terminale, podobnie jak w czasach komputerów mainframe, chociaż metoda komunikacji z serwerem była bardziej wyrafinowana, mniej zastrzeżona i opierała się raczej na mechanizmach przerwania niż na dzieleniu czasu i odpytywaniu. Przetwarzanie wróciło z powrotem na serwer (y).

Jednak tworzenie stron internetowych przyniosło zupełnie nowy zestaw problemów. Większość aplikacji biznesowych napisanych dla przeglądarki to statyczne formularze i raporty. Interfejs użytkownika był bardzo mało interaktywny. Javascript nie znalazł jeszcze drugiego wiatru i wystąpiły poważne problemy z niekompatybilnością przeglądarki, które zniechęciły do ​​jego powszechnego stosowania. Jednak sprawy się poprawiły. HTML5 i CSS3 zapewniają znacznie nowe możliwości w modelu programowania przeglądarki, pojawiła się jQuery i pomogła całej generacji programistów odkryć, jak użyteczny może być JavaScript. Pojawiły się nowe frameworki interfejsu użytkownika. Możliwe stało się pisanie wysoce interaktywnych interfejsów użytkownika w przeglądarce, nawet kompletnych gier. Przetwarzanie wróciło ponownie do klienta.

Dzisiaj możesz kupić moc obliczeniową w chmurze, tyle, ile chcesz, i uruchamiać programy na serwerze. Powiedziałbym, że jesteśmy teraz w miejscu, w którym jako programista masz wiele możliwości wyboru mocy przetwarzania, zarówno na kliencie, jak i na serwerze.

Wygląda na to, że łączysz dwie bardzo różne koncepcje:

1. Rozdzielenie prezentacji i logiki biznesowej (MVC) => zwiększa łatwość konserwacji
2. Przypisanie wykonania do węzła => zwiększenie wydajności

Dawno temu obliczenia klient / serwer były często mylone, sugerując, że pierwsze, ponieważ generalnie klienci nie oferowali dużej mocy obliczeniowej w porównaniu do serwerów. Dlatego wydawało się naturalne przeniesienie „ciężkiego” obliczenia logiki biznesowej (M) na serwery, przy jednoczesnym zachowaniu „lekkiego” przetwarzania widoku (V) dla klientów. Z kolei musiałeś zaimplementować jakiś arbiter (C), aby tłumaczyć między nimi.

Ponieważ klienci mają teraz łatwą obsługę, która kiedyś sugerowała, że ​​jest to kosztowny sprzęt serwerowy, linie rozmazały się, gdzie wykonać logikę biznesową - po stronie klienta lub po stronie serwera. Naprawdę odpowiedź zależy od konkretnego przypadku użycia i wyboru kompromisów, np .:

• opóźnienie klienta a złożoność: przetwarzanie po stronie serwera upraszcza systemy, ponieważ nie trzeba wdrażać / pobierać kodu do klienta, jednak wiąże się to z kosztem opóźnienia po stronie klienta podczas obliczeń.

• złożoność a obciążenie serwera: przetwarzanie po stronie klienta może zwiększać złożoność systemu, ale może również pomóc zmniejszyć obciążenie serwera.

• zdecentralizowana odporność aplikacji a centralne wykonywanie: w świecie aplikacji mobilnych może być ważne, aby klienci nadal pracowali pomimo rozłączenia sieci. Jest to jednak kosztem zarządzania wieloma wdrożonymi wersjami logiki biznesowej.

Jest to niewyczerpująca lista wielu kompromisów.

Ponieważ użytkownicy zawsze chcieli mieć te same funkcje, dzwonki i gwizdy w swoich aplikacjach internetowych (nie tylko witrynach internetowych), jakie mieli w aplikacjach komputerowych. Sprawienie, aby wszystko działało w przeglądarce (właściwie w wielu przeglądarkach), nie przypomina dawnych czasów, kiedy można było połączyć formularz VB z bazą danych z niewielkim kodem. Łatwiej to zrobić, gdy nie musisz wracać na serwer.

większość programowania zaplecza przy użyciu języków programowania, takich jak Java lub C #, polega po prostu na stworzeniu interfejsu podobnego do REST, i że wszystkie ciężkie wysiłki związane z wyświetlaniem, wizualizacją, wejściem / wyjściem danych, interakcjami użytkownika itp. są rozwiązywane przez klienta ramy boczne, takie jak Angular, Backbone, Ember, Knockout itp.

Być może programowanie / usługi zaplecza wydaje się być tą samą starą rzeczą, ale jest sercem aplikacji. Praktyki kodowania mogą być bardziej wydajne w tych obszarach. Narzędzia, języki, przeglądarki i frameworki wciąż ewoluują, więc tworzenie interfejsu użytkownika / interfejsu użytkownika jest trudne. Są to nowe rzeczy, których nie miała stara ASP. Gdybyśmy mogli uciec od interfejsów użytkownika z prostymi formularzami i tabelami HTML, nie byłoby też dużego zainteresowania / szumu w tych obszarach, ale użytkownicy chcą przeciągania i upuszczania, animacji, przejść, wyskakujących okienek itp.

Dzisiaj w większości projektów, w których pracuję, dowiedziałem się, że frameworki JavaScript i programowanie po stronie klienta są miejscem, w którym robione są wszystkie fascynujące i innowacyjne postępy.

Dlaczego nastąpiło takie przejście od rozwoju serwera do klienta?

W rzeczywistości są tutaj dwa pytania:

1. Dlaczego programowanie po stronie klienta odbywa się tam?
2. Dlaczego aplikacje są napisane do działania na kliencie, a nie na serwerze?

Oba są w rzeczywistości różne.

Dlaczego programowanie po stronie klienta odbywa się tam?

Ponieważ środowisko wykonawcze, środowisko i ekosystem dojrzewały znacznie w ciągu ostatnich trzech lat, co otworzyło nowe nisze, na które czekali innowatorzy.

Tworzenie front-endu było trudne . Trzeba było zaprogramować przeglądarki - zawsze wrogie środowisko - używając ograniczonych funkcji ECMAScript 3, w ekosystemie, który nie posiadał wcześniejszego stanu wiedzy ani narzędzi do tworzenia aplikacji typu gruby klient. Nie było modułów ładujących. Nie można poprawnie obsługiwać zależności. Było mało narzędzi do szorowania. Ramy były niedojrzałe, a zła reputacja frontu zdystansowała innowatorów, którzy mogli rozwiązać te problemy.

Ponieważ czynniki te stopniowo się zmieniały, stworzyły masę krytyczną do szybkiego opracowywania bogatych aplikacji klienckich i konsekwentnego ich uruchamiania.

Odpowiadając na twoje pytanie, nowe technologie typu front-end nie tyle posunęły naprzód, ile uwolniły wąskie gardła i pozwoliły klientom nadążyć za aspiracjami użytkowników.

Dlaczego aplikacje są napisane do działania na kliencie, a nie na serwerze?

Istnieje wiele bezpośrednich przyczyn, ale najbardziej wyraźnym z ostatnich lat jest wzrost liczby smartfonów.

Smartfony sprawiają, że obliczenia o średniej mocy są tanie, wszechobecne i przydatne. Są własnością miliardów ludzi na całym świecie i zasadniczo przenieśli komputery do klasy średniej gospodarek wschodzących. Ale sieci komórkowe są powolne, niejednolite i ograniczone przez geograficzne, inżynierskie i polityczne trudne problemy. W tym środowisku nieuniknione jest, aby aplikacje lokalnie zapisywały stan i łatały niechętnie dane w górę w operacjach bezstanowych.

Jak może być inaczej? Wyobraź sobie, że Twój smartfon to tylko głupi terminal. Każda mutacja stanu musiałaby być asynchroniczna i zawodna. Każde ładowanie treści kosztowałoby cenne centy. Będziesz musiał zainwestować w ogromne farmy serwerów z pięcioma dziewięcioma przestojami. Koszty obliczeniowe byłyby ponoszone bezpośrednio przez Ciebie, więc nagły wzrost popularności może faktycznie zatankować Twój biznes.

Aplikacje po stronie klienta pozwalają szybko i synchronicznie obsługiwać stan poszczególnych użytkowników. Pozwalają obciążyć użytkowników kosztami obliczeniowymi. Pozwalają uniknąć przestojów i słabej łączności sieciowej. Sprawiają, że kod serwera jest tak głupi, że można go buforować w samej infrastrukturze sieciowej - statyczne pliki HTML i JS lub konserwowane odpowiedzi dla aplikacji mobilnych.

Mówiąc bardzo szeroko: rozwój po stronie klienta wykorzystuje niskie koszty komputerów osobistych o średniej mocy i pozwala uniknąć wysokich kosztów scentralizowanych komputerów o dużej mocy.

Zadałeś kilka pytań, z których niektóre mają już dobre odpowiedzi. Kilka nie otrzymało jeszcze odpowiedzi:

Chcę wiedzieć, dlaczego dokonaliśmy takiego przejścia (z nacisku na programowanie po stronie serwera na oprogramowanie po stronie klienta ... wszystkie wydają się występować jednocześnie) i jakie problemy rozwiązało to przejście / zmiana?

Robert Harvey udzielił doskonałej odpowiedzi.

... od faworyzowania języków skompilowanych po języki skryptowe,

Języki skryptowe mają wiele zalet ( także ) w stosunku do języków skompilowanych, np .:

• są łatwiejsze do nauczenia się i obsługi
• wyeliminować czas kompilacji (szybszy rozwój)
• zapewnia więcej funkcji (kontrola aplikacji wyższej klasy)
• pozwalają na szybkie zmiany w uruchomionym kodzie
• itp.

... od programowania imperatywnego do programowania funkcjonalnego,

Oto dobre porównanie, ale podsumowałbym to mówiąc, że w oprogramowaniu rozproszonym (myśl w chmurze) zarządzanie zmianami stanu (synchronizacja między wieloma węzłami) może być ogromnym problemem. W programowaniu funkcjonalnym potrzeba radzenia sobie ze zmianami stanu jest znacznie mniejsza.