Kiedy JavaScript powinien generować HTML?

Staram się generować jak najmniej kodu HTML z JavaScript, jak to możliwe. Zamiast tego wolę manipulować istniejącym znacznikiem, kiedy tylko mogę, i generować HTML tylko wtedy, gdy potrzebuję dynamicznie wstawiać element, który nie jest dobrym kandydatem do korzystania z Ajax. Uważam, że znacznie ułatwia to utrzymanie kodu i szybkie wprowadzanie zmian, ponieważ znaczniki są łatwiejsze do odczytania i śledzenia. Moja ogólna zasada brzmi: HTML to struktura dokumentu, CSS to prezentacja, JavaScript to zachowanie.

Widziałem jednak dużo kodu JS, który generuje kopie HTML, w tym całe formularze i modalne okna dialogowe o dużej zawartości. Zasadniczo, która metoda jest uważana za najlepszą praktykę? W jakich okolicznościach JavaScript powinien być używany do generowania HTML, a kiedy nie?

Ilekroć napotkałem ciężkie generowanie HTML w javascript, było to prawie wyłącznie w samodzielnej wtyczce interfejsu użytkownika. Ma to sens, ponieważ pozwala na zamknięcie całej wtyczki w jednym pliku .js (+ a .css w celu dostosowania stylów), dzięki czemu jest łatwo wielokrotnego użytku, dystrybuowalne i niezależne od frameworku używanego w aplikacji.

Jeśli więc piszesz samodzielną wtyczkę javascript lub ogólny składnik interfejsu użytkownika, którego chcesz używać w różnych aplikacjach, takie podejście ma swoje zalety. W przeciwnym razie myślę, że jest to zarówno czystsze, łatwiejsze do napisania, jak i łatwiejsze w utrzymaniu, gdy trzymasz generowanie HTML z dala od javascript i po stronie serwera.

Myślę, że problem polega na tym, że porównujesz czysto napisane szablony po stronie serwera do źle napisanego generowania HTML po stronie klienta ad-hoc. Oczywiście dokładnie napisany kod jest łatwiejszy do odczytania, utrzymania i śledzenia.

Nazywasz kod po stronie klienta „kopcami HTML”, ale oczywiście jest to ten sam HTML, niezależnie od tego, gdzie jest generowany. „Kopiec” jest tak naprawdę dużą bryłą kodu.

Istnieje wiele bibliotek szablonów po stronie klienta. Działają podobnie jak po stronie serwera. Jeśli chodzi o to, co wolisz, kompromis wydajności jest skomplikowany, ale JSON jest zwykle bardziej kompaktowy niż HTML, a staje się, że posiadanie szablonu na kliencie może wyeliminować niektóre wywołania serwera. Z drugiej strony klient może mieć wyłączoną obsługę JS lub być zbyt wolny, aby był praktyczny, więc zależy to również od odbiorców docelowych. Ogólnie uważam, że podejścia są dość porównywalne, a największym czynnikiem są możliwości przeglądarki docelowej grupy odbiorców.

Zależy to jednak dokładnie od tego, co robisz, od tego, czy wolisz JS od środowiska serwerowego, jakie preferujesz rozwiązanie szablonowe itp.

Istnieje tendencja do używania szablonów po stronie klienta, w skrajnym przypadku serwer miałby zapewniać tylko interfejs API RESTful, na przykład w formacie JSON, jednocześnie wykonując wszystkie renderowanie po stronie klienta. Zaletą tego podejścia jest to, że kod JS i szablony są zasobami statycznymi, które można buforować, proxy i dystrybuować za pośrednictwem CDN. Nie można tego zrobić, jeśli masz dynamiczny HTML wygenerowany po stronie serwera. Ponadto zwracanie tylko danych z RESTful API w lekkim formacie zużywa znacznie mniej zasobów po stronie serwera, co przyspiesza reakcję. Jest również lżejszy, co oznacza mniej transferu sieci, co ponownie przyspiesza. W ten sposób możesz mieć bardzo responsywną aplikację o niskim opóźnieniu, nawet na wolnych połączeniach, takich jak 3G. Dlatego takie podejście jest popularne w przypadku stron i aplikacji mobilnych.

Istnieje wiele bibliotek wykonawczych szablony JS, jeden z popularnych należą Czysta , Wąsy i dust.js . Później jest używany przez LinkedIn, opisali zalety w swoim artykule „Pozostawienie stron JSP w pyle: przeniesienie LinkedIn do szablonów po stronie klienta dust.js” .

Zaletą generowania kodu HTML na kliencie jest to, że odciążasz renderowanie do każdego klienta, który na ogół nie pracuje i czeka na odpowiedź. Uwolnienie większej liczby zasobów serwera w celu dostarczania tylko danych JSON i treści statycznych (HTML, JS i CSS).

Tworzymy aplikację internetową, która generuje wyłącznie HTML przy pomocy Javascript. 87% trafień na serwer to dane JSON, zawartość statyczna jest zazwyczaj ładowana raz, a następnie z pamięci podręcznej przeglądarki.

Ale nie możesz go użyć - przynajmniej nie łatwo - jeśli potrzebujesz SEO. Lub jeśli kierujesz reklamy na populację, która ma wyłączoną obsługę Javascript, ale nie jestem pewien, czy ta funkcja jest nadal aktualna w przypadku YouTube, Twittera, Facebooka, Gmaila ... naturalnie zmuszając ludzi do jej włączenia.

Jeśli chodzi o dynamiczne ładowanie strony, należy zdać sobie sprawę, że za wszystkimi „JQuery AJAX Cloud!” magia, dzieją się tylko dwie możliwe rzeczy:

1. Kod elementu jest wstrzykiwany do div (zły) lub
2. Treść ładowana jest w ramce iframe (lepiej, ale to nie to samo ...)

Jeśli chodzi o oryginalne pytanie, tworzę treść HTML tylko za pomocą Javascript, gdy tworzę aplikację internetową, która odczytuje dane XML lub JSON przechowywane na serwerze, i to się bardzo zmienia.

Nie ma większego sensu ładowanie treści statycznych na stronie za pomocą Javascript, ponieważ zawsze istnieje możliwość, że nie załaduje się ona poprawnie lub klient wyłączy ją („weź te nieznośne reklamy!”). Ponadto utrudnia to zmianę treści HTML, gdy jest umieszczona w brzydkim document.write()lub łańcuchu document.createElement().

Masz rację; albo wpisz nieprzetworzony kod HTML, albo jeśli konieczna jest zawartość dynamiczna, użyj skryptu po stronie serwera, aby wyświetlić niezbędne dane. Użyj Javascript do wstrzykiwania HTML tylko wtedy, gdy witryna ma działać bez połączenia z Internetem lub podobnej sprawy.

Ostatnia uwaga, jeśli chcesz zaimplementować xmlhttprequests, er, AJAX, na stronie internetowej, prawdopodobnie najlepszym / najbezpieczniejszym sposobem na to jest przechowywanie danych w formacie danych (np. XML), ładowanie i wysyłanie ich odpowiednio na kliencie. document.writei element.innerHTMLtak naprawdę nie jest to najlepszy sposób na manipulowanie treścią i na pewno spowoduje potencjalne bóle głowy w przyszłości (dlaczego ten skrypt nie działa? Mój zepsuty <i>tag zapisuje kursywą wszystko! itp.).

Moja mantra na ten temat brzmi: kiedy jest łatwiej i nikt nie dba o znaczniki.

Możesz także wykorzystać oba te elementy i zdefiniować limit, w którym zbyt trudno jest dbać o znaczniki, a wolisz skupić się na drzewie DOM. Na przykład formularz z dynamicznymi wierszami (np. „Dodaj kolejny załącznik”), prawdopodobnie potrzebujesz formularza w HTML, przycisku „dodaj wiersz” i przycisku przesłania… prawdopodobnie nie chcesz generować HTML z językiem po stronie serwera lub coś takiego.

Inną praktyczną zasadą może być wielokrotnego użytku. Jeśli Twoje rozwiązanie można zastosować do innych problemów po stronie klienta, obuduj je w js.

Tworzymy aplikacje jednostronicowe (Google Mail) i dosłownie nie ma generowania HTML po stronie serwera w naszych aplikacjach. Zamiast tego używamy Backbone.js do strukturyzowania strony klienta i Kierownicy do renderowania naszego JSON w szablony, które przechodzą na stronę. To naprawdę działa bardzo dobrze i zbliżamy się do końca naszej pierwszej aplikacji, która z niej korzysta, a my zajmiemy się jeszcze większym projektem w przyszłości.

Każdy gruby klient, na którym serwer służy tylko do utrwalania danych i zwracania wyników zapytań, jest potomkiem plakatu na czas, gdy chcesz, aby JavaScript generował HTML. Pamiętaj tylko, aby użyć dobrego silnika szablonów, aby był czysty i łatwy.

Generuję kod HTML w jquery, ponieważ korzystam z portletu, a po wykonaniu kodu jsp muszę utworzyć pętlę z kodem HTML, której nie mogę dostać do pętli java for z jakimś kodem javascript. Renderuję więc arraylistę Java w tablicy javascript i używam ciągów do generowania HTML.