Plusy i minusy aplikacji internetowej opartej tylko na HTML / JavaScript [zamknięte]

Pochodzę z formularzy ASP.NET i w przeszłości zauważyłem, że kodowanie po stronie serwera jest bardzo wydajne. Ostatnio jednak chciałem wycofać kod front-end serwera i zastąpić go czystym HTML / JavaScript, który uzyskuje dostęp do danych za pośrednictwem usług internetowych JSON. Nie mam w tym prawdziwego doświadczenia, dlatego chciałbym usłyszeć, czy jest to wypróbowany i przetestowany model. Jakie są otaczające go pułapki?

Uważam, że formanty użytkownika ASP.NET są bardzo przydatne, dlatego chciałbym zachować teorię, przechowując szablony znaczników w oddzielnych plikach HTML na serwerze. Zostaną one pobrane i wykorzystane odpowiednio przez jQuery AJAX i wtyczkę szablonów jQuery HTML.

Wszelkie uwagi będą bardzo mile widziane.

PS Przepraszam za pytanie noob, ale czy ten typ architektury internetowej jest nazywany web-2.0, czy też jestem całkowicie zbędny?

Użyłem tej techniki wyłącznie do aplikacji internetowej, nad którą pracujemy. Mój backend jest hostowany w Google App Engine przy użyciu Java SDK, a mój frontend używa HTML, CSS i JavaScript (z jQuery).

Projekt jest mniejszy z samym sobą i projektantem stron internetowych i oboje uważamy, że ta metoda pomogła nam pracować znacznie szybciej i szybciej wprowadzić coś na rynek.

Zaleta: praca z projektantami stron internetowych

Główną zaletą tej techniki jest to, że projektant stron internetowych, który zna się na PHP, ale nie uważa się za programistę, może pracować bez ograniczeń w HTML i CSS bez konieczności brodzenia przez niezliczone linie JSP, taglib i innych stron po stronie serwera znaczniki, o których mówiliśmy od lat, mają znacznie ułatwić życie programistom front-end.

Bez znaczników po stronie serwera jesteśmy bardziej zwinni. Projektant stron internetowych zmienił swój oryginalny projekt 3 lub 4 razy, z niewielkimi zmianami z mojej strony.

Jego komentarz do mnie był taki, że czuł, że HTML żyje, ponieważ mógł go edytować, a następnie natychmiast zobaczyć zmiany na swoim komputerze z dynamicznymi danymi. Obaj czerpiemy z tego korzyści, ponieważ integracja odbywa się głównie automatycznie.

Kod po stronie serwera i przekazywanie kodu HTML / CSS

W poprzednich projektach musiał przekazywać HTML i CSS programistom Java, którzy następnie brali jego HTML i CSS i całkowicie przepisywali je przy użyciu technologii JSP. Zajmie to dużo czasu i zwykle spowoduje subtelne, ale ważne różnice w faktycznym renderowaniu stron, a także jego walidację w walidatorze W3C.

Ogólnie rzecz biorąc, oboje jesteśmy bardzo zadowoleni z tej techniki i nadal mam zero stron JSP lub kodu po stronie serwera na moich stronach HTML.

Pułapki techniki REST / JSON

Być może największe pułapki to te, których jeszcze nie spotkaliśmy. W pełni spodziewam się, że będę miał spory z bardziej doświadczonymi programistami Java, którzy zostali poddani praniu mózgu przez to, co fundacja Apache i zespół Spring powiedział im, w jaki sposób biblioteki znaczników ułatwiają programistom frontendową pracę z kodem. W pełni spodziewam się, że pojawi się krzywa uczenia się w miarę rozwoju tego projektu i pozyskamy kolejnych programistów, którzy mogą być zmuszeni oduczyć się tych przestarzałych technik, które z mojego doświadczenia utrudniły pracę projektantom stron internetowych .

Kolejną pułapką jest to, że kod JavaScript stał się bardzo ogromny. Jest to bardziej problem, być może dlatego, że używam tej techniki po raz pierwszy i dlatego, że wprowadziliśmy niewielki techniczny dług w pracy nad szybkim wydaniem. Być może wybranie lepszego frameworka pomogłoby złagodzić dużą część kodu. Moim zdaniem żadna z tych rzeczy nie była przeszkodą i zachęcam do dalszego korzystania z tej techniki i doskonalenia swoich umiejętności w tym zakresie.

Zaleta: na platformie można budować inne aplikacje

Na koniec powinienem wspomnieć o ukrytej przewadze. Ponieważ między usługami RESTful Web i zapleczem istnieje dobry stopień oddzielenia, stworzyłem również platformę, którą można łatwo rozszerzyć.

Jeden z naszych operatorów chciał wypróbować próbę koncepcji w innej aplikacji, a dzięki moim usługom RESTful udało nam się stworzyć zupełnie inną nakładkę na aplikację, aby rozwiązać zupełnie inny problem. Szybko opracowany dowód koncepcji wykorzystał własny HTML, CSS i JavaScript, ale wykorzystał usługi RESTful jako backend i źródło danych.

W końcu inny kierownik projektu zobaczył, co zrobiłem, i od razu stało się jasne, że ta funkcja musi być czymś więcej niż tylko dowodem koncepcji, więc jego zespół ją wdrożył.

Nie mogę wystarczająco podkreślić, jak architektura ta jest wielokrotnego użytku, zarówno na poziomie aplikacji, jak i HTML / CSS / JavaScript, i zdecydowanie zachęcam do wypróbowania tego w następnym projekcie.

Jest to z pewnością realna strategia, ale nie jest to srebrna kula.

Plusy :

• właściwie wykonane aplikacje są bardzo responsywne
• masz wyraźne oddzielenie logiki (na serwerze) i prezentacji (na kliencie); serwer wcale nie musi zajmować się prezentacyjnymi aspektami aplikacji
• potencjalnie bardziej wydajne wykorzystanie przepustowości sieci (wysyłasz tylko nieprzetworzone dane, brak prezentacji)
• łatwiejsze tworzenie graficznych interfejsów GUI, ponieważ jesteś mniej zależny od paradygmatu żądanie / odpowiedź

Wady :

• musisz napisać kod klienta w JavaScript lub języku, który można skompilować do Javascript, ponieważ jest to jedyna dostępna funkcja w przeglądarce
• zużycie zasobów na kliencie może być wyższe, więc aplikacja może nie działać dobrze na urządzeniach niespełniających norm (np. przeglądarki mobilne itp.)
• to w ogóle nie będzie działać przy wyłączonym javascript; jeśli jest to strona publiczna, musisz się mocno zastanowić, czy chcesz podjąć to ryzyko (szczególnie jeśli rozważasz SEO i dostępność - podejście oparte na javascriptach jest zwykle katastrofalne na tych dwóch frontach)
• dużo logiki trzeba napisać dwa razy: raz na kliencie i jeszcze raz na serwerze (ponieważ nigdy nie można ufać klientowi)
• współbieżność może być piekłem, dlatego należy bardzo ostrożnie projektować kod po stronie klienta i być przygotowanym na wszelkiego rodzaju problemy dotyczące współbieżności

Jest to zdecydowanie możliwe i prawdopodobnie zalecane jako najlepsza praktyka. To, co proponujesz, to rozdzielenie interfejsu użytkownika od logiki biznesowej, dzięki czemu istnieje wyraźny rozdział obaw. To jest naprawdę dobre.

Zbyt często ramy staramy się mieszać ze sobą, a ty dostajesz monolityczne oprogramowanie, w którym interfejs użytkownika, logika biznesowa i dane są ze sobą powiązane. Utrudnia to utrzymanie i modyfikację.

Po podzieleniu aplikacji na 2 części możesz całkowicie zastąpić interfejs użytkownika czymś innym - programem komputerowym lub innym interfejsem dla urządzeń mobilnych w porównaniu z przeglądarkami na komputery.

Podstępne bity, które znajdziesz, gdy to robisz, to to, że trochę kodu, który teoretycznie powinien znajdować się na serwerze, lepiej byłoby umieścić na kliencie - na przykład sprawdzanie poprawności, jego szybsze i bardziej responsywne dla użytkownika umieszczenie kodu sprawdzającego na formularz na kliencie, niż uderzenie w serwer, aby sprawdzić, powiedzmy, pole tekstowe zawiera tylko znaki alfanumeryczne. To samo często dotyczy warstw danych i warstw biznesowych. Musisz tylko podejmować świadome i praktyczne decyzje dotyczące tego, kiedy złamać rozróżnienie między warstwami.

Jednym minusem jest konieczność skopiowania części logiki w JavaScript i ASP.net. W zależności od aplikacji może to nie być dla ciebie dużym problemem. Często pojawia się, ponieważ nie chcesz prosić serwera o sprawdzenie wszystkich drobiazgów („Czy użytkownik może nacisnąć ten przycisk lub wybrać tę opcję w tej sytuacji?”), Ale nie chcesz też polegać na kliencie jako jedynym, który dokonuje weryfikacji, ponieważ użytkownik ma kontrolę nad klientem.

Jeśli nadal używasz formularzy internetowych ASP.NET i chcesz przyspieszyć swoje aplikacje, oto co powinieneś zrobić:

• Zaprojektuj swoją aplikację z myślą o SOLID
• Wyłącz ViewStatena wszystkich stronach i kontrolach użytkownika

• Nie używaj kontrolek po stronie serwera

  <%: VeiwModel.Title%> zamiast <asp: Literal id = "Title" runat = "server">

• W backendie przesłoń metodę OnInit i wykonaj tam całą inicjalizację:

  chronione zastąpienie void OnInit (System.EventArgs e) {CreateViewModel (); base.OnInit (e); }

• Skompresuj wszystkie pliki .css i .js do 1 za pomocą SquishIt

• Leniwe ładowanie obrazów
• Buforuj złożone obiekty

Na koniec sprawdź www.porsche.se. Czy to nie cholernie szybka strona internetowa?