Czy wbudowany JavaScript jest dobry czy zły?

Obecnie przeszedłem z frameworka WordPress na Yii, a zewnętrzny programista przebudowuje moją witrynę.

Zauważam, że za każdym razem, gdy wywołuje on AJAX / jQuery w sposób Yii, osadza wstawia JavaScript na stronie internetowej. Chociaż wydaje się, że kod JavaScript jest umieszczony pod stopką, nadal jest wbudowany.

Zasadniczo wydaje się, że kod JavaScript jest częściej umieszczany na stronie internetowej. Zawsze uważałem, że skrypty JavaScript powinny, w miarę możliwości, być umieszczane w plikach JavaScript. Czy to nadchodzący „nowy” trend? Czy powinienem nadal próbować przechowywać kod JavaScript w osobnych plikach?

Inline JavaScript wydłuża czas pobierania strony, co nie jest dobre. W przypadku wywołania .jspliku mogą to być co najmniej połączenia równoległe, a czasy pobierania zawartości ulegają skróceniu. Tak, są chwile, w których dobrze jest umieścić JavaScript bezpośrednio w kodzie HTML, ale często lepiej jest rozładowywać to w jak największym stopniu.

Należy pamiętać, że czasy pobierania stron (czyli HTML), a nie wszystkie wywołania zasobów wpływają na wskaźniki wpływające na ranking (chociaż jako PageRank lub w SERPs to nie ma znaczenia). Chodzi o to, że wpływa to na wydajność witryn pod kątem SEO, jakkolwiek się manifestuje.

W mojej witrynie do przeliczania walut większość sesji to wyświetlenia jednej strony. Wynika to z faktu, że użytkownicy mogą dokonywać obliczeń waluty bezpośrednio na stronie docelowej (wszystkie obliczenia są obsługiwane po stronie klienta za pomocą JavaScript).

Moja strona pobiera się i renderuje w około połowie czasu, gdy wszystkie zasoby (css, js, a nawet obrazy ) są wbudowane na stronie. Ponieważ tak niewielu moich użytkowników przegląda wiele stron, nie skorzystałbym wiele z tych zasobów buforowanych między odsłonami.

Moja strona nie jest typowa. Większość witryn ma wiele stron na sesję i duże obrazy, przez co moja technika byłaby mniej przydatna. Nie ma jednego poprawnego rozwiązania tego pytania; to zależy od strony. Musisz to zmierzyć sam na podstawie typowego zachowania użytkowników.

JavaScript nie musi być źle w twoim pliku HTML, ale musisz go wywołać.

To jest źle, jeśli masz dużą ilość JavaScript używany na wielu stronach. W takim przypadku JavaScript powinien znajdować się w zewnętrznym, skompresowanym i zbuforowanym pliku, a jeśli Twoja witryna ma bardzo duży ruch, powinieneś skorzystać z CDN.

Jeśli jednak masz niewielką ilość kodu JavaScript, zapisanie go w pliku zewnętrznym może zostać zanegowane przez konieczność wysłania dodatkowego żądania HTTP w celu jego odzyskania. W tym przypadku bardziej efektywne byłoby utrzymanie JavaScript na twojej stronie.

Z drugiej strony, jeśli ten sam mały fragment kodu JavaScript zostanie użyty na wielu stronach, korzystne byłoby umieszczenie go w pliku zewnętrznym, aby skorzystać z buforowania.

Ostatecznie musisz porównać rozmiar JavaScript z kosztem generowania dodatkowych żądań HTTP. W większości przypadków w przypadku „przeciętnej” witryny prawdopodobnie nie będzie to miało większego znaczenia po prostu umieszczenie jej w zewnętrznym pliku.

Jestem programistą Yii i mogę powiedzieć, że Yii nie ma z tym nic wspólnego . Jest całkowicie po stronie programisty , niezależnie od tego, czy umieści kod JavaScript w osobnym pliku i zarejestruje go za pomocą CClientScript::registerScriptFilemetody HTML (widok) , czy umieści go bezpośrednio w kodzie widoku (HTML) i zarejestruje za pomocą CClientScript::registerScriptmetody.

Zgodnie z twoją odpowiedzią większość (profesjonalnych?) Programistów Yii zdecydowanie głosuje za pierwszym podejściem, czyli utrzymaniem jak największej ilości kodu JavaScript w osobnych plikach. Z pewnością nie jest to nowy trend kodowania, ale raczej zła praktyka programisty. Tak przynajmniej wygląda społeczność Yii.

EDYCJA : Właściwie to zapomniałem o najważniejszym sporze. Yii (podobnie jak większość innych profesjonalnych frameworków PHP) jest oparty na wzorcu projektowym MVC (właściwie: wzorcu architektonicznym). I ten sam wzór może być użyty z przodu: kod HTML to model (dane), CSS to widok (dekorator), a JavaScript to kontroler. Wszystkie są umieszczane w osobnych plikach , .jsa .csspliki - zminimalizowane, zaciemnione i spakowane gzip w najlepszym scenariuszu.

Podczas budowania aplikacji Yii możesz przełamać wzór MVC i zachować wszystko w tym samym pliku. Pytanie brzmi - czy warto to zrobić, jakie są korzyści (brak?) I dokąd cię to zaprowadzi? Możesz użyć tej samej argumentacji, pytając, czy zachować kod JS w wierszu, czy nie?

To zależy od celu strony, którą tworzysz:

Używam niewielkiej ilości wbudowanego JavaScript, natomiast wolę wybrać zewnętrzne pliki JavaScript, jeśli są duże.

Tak czy inaczej, gdy strona ładuje JavaScript, musi być najpierw wykonana. Najlepszą praktyką jest używanie zewnętrznego JavaScript, aby nie wydłużał zawartości strony. Ułatwia także debugowanie.

Odpowiedź zależy od tego, co się robi.

Jeśli zauważysz wbudowany JavaScript, który jest używany w całej witrynie (np. Widżet, który wyświetla się w nagłówku na wszystkich stronach witryny), wskazane byłoby przeniesienie go do „wspólnego” pliku JavaScript.

W rzeczywistości chciałbym przenieść jak najwięcej kodu JavaScript do wspólnego pliku JavaScript, jak to możliwe, nawet gdyby był używany na jednej stronie. Skonfigurowałbym serwer tak, aby wysyłał silne buforowanie i nagłówki kompresji plików JavaScript; co zmniejsza rozmiar stron, ale nie zwiększa rozmiaru pliku JavaScript.

Z drugiej strony, jeśli JavaScript jest po prostu zbiorem opcji konfiguracji / inicjalizacji, np .:

$(function () {
    myplugin({
        images: ["img1", "img2", "img3"]
    });
});

gdzie z jakiegoś powodu nie było możliwe przeniesienie kodu do zewnętrznego pliku JavaScript (np. gdy parametry obrazu pochodzą z bazy danych) trzymałbym go w linii. Powiedziawszy to, wybrałbym wtyczki stron trzecich, które są „dyskretne” (lub przekonwertowały je jako takie).

Te odpowiedzi nie mają znaczenia. Zobacz buforowanie Inline .

Ponieważ Yii jest kodowany w PHP, powszechnym (lub być może nietypowym) wzorcem PHP jest to, że programiści czasami piszą kod PHP w celu dynamicznego generowania kodu JavaScript na serwerze - w oparciu o pewien stan, warunek lub wartość znaną przez serwer - a następnie wysłać to wszystko do klienta w jednej partii, umożliwiając klientowi wykonanie funkcji i pominięcie niektórych obliczeń wykonanych już przez serwer.

Zamiast wysyłać do klienta całą masę ogólnych funkcji JavaScript w pliku .js, które nie mają kontekstu, dopóki nie zostaną dostarczone dane (dane, które mogą znajdować się na serwerze i wymagają podróży w obie strony), możemy „upiec” kontekst / dane jako część funkcji Javascript. Jest to oszczędne, ponieważ oznacza, że ​​wysyłasz razem funkcjonalność / dane i wysyłasz tylko funkcjonalność / dane, których klient może potrzebować w danym momencie, zamiast wysyłania całej aplikacji przy ładowaniu pierwszej strony. Oznacza to również, że nie musisz narażać całej aplikacji na łatwość pobierania i inżynierii wstecznej przy ładowaniu pierwszej strony, ponieważ wstrzykujesz tylko niewielkie części funkcji, których może potrzebować każdy klient w danym momencie. Nie jestem pewien, jak dobrze wróży to SEO, ale jestem pewien, że można go odpowiednio zoptymalizować.

Rozważ przypadek, gdy użytkownik końcowy pisze stronę w niektórych programach CMS za pomocą edytora WYSIWYG. W jaki sposób ten użytkownik doda nową funkcjonalność do strony, jeśli nie ma dostępu do źródłowych plików .js na serwerze? Przełączają się na kartę HTML i używają wbudowanego Javascript.

Nie wszystkie wbudowane Javascript jest złe; czasami też kliknięcie jest w porządku. Jako ogólną rekomendację, unikaj pisania wbudowanego Javascript, a będziesz na dobrej drodze do budowania dobrych nawyków.

Bibliografia:

• Buforowanie wbudowane
• Optymalizacja dynamicznego JavaScript z wbudowanymi pamięciami podręcznymi
• Objaśnienie maszyn wirtualnych JavaScript w JavaScript - wbudowane pamięci podręczne
• Dlaczego powinienem unikać skryptów wbudowanych? (patrz odpowiedź MainMa i użytkownik1389596)

Zwykle wbudowany kod JS jest zły, jak inni mówili przede mną.

Ale myślę o przypadku użycia, w którym wbudowany JS jest lepszy .

Pomyśl o CMS, który wstawia galerię opartą na JS. Galeria może być wykonana w jQuery. Jest identyfikowany przez atrybut id, który jest nie tylko unikalny na stronie, ale także unikalny w całej witrynie. W tym przypadku - myślę - wbudowany JS byłby lepszy, ponieważ kod JS jest używany tylko na jednej stronie i nie ma narzutu HTTP