Встроенный JavaScript - это хорошо или плохо?

16

В настоящее время я перешел с WordPress на Yii Framework, и внешний разработчик перестраивает мой сайт.

Одна вещь, которую я замечаю, заключается в том, что каждый раз, когда он вызывает AJAX / jQuery способом Yii, он вставляет встроенный JavaScript на веб-странице. Хотя кажется, что код JavaScript находится ниже нижнего колонтитула, он все еще встроен.

В целом, кажется, что код JavaScript чаще размещается внутри веб-страницы. Я всегда думал, что JavaScript-скрипты должны быть как можно больше размещены в JavaScript-файлах. Это грядущая «новая» тенденция? Или я все еще должен пытаться хранить код JavaScript в отдельных файлах?

Стивен
источник
Что именно вы подразумеваете под вставкой JavaScript на веб-странице ?
Салман А
3
Ради других, кто находит этот вопрос и думает о таких вещах, как <a onClick="function(){/* do stuff */} ">Click Here</a>я понимаю, считается ОЧЕНЬ плохим, и нужно отделять их код от их HTML. См .: Эта статья
TecBrat
1
@ user1066946 t.co/j1RpJgwoku :-)
Кос
1
@ user1066946 Мне действительно нравится использовать Angular, я только что заметил, что "семантическая сеть" образовала круг (с точки зрения сохранения некоторого связующего кода рядом с DOM)
Кос
1
«Хотя кажется, что код JavaScript находится ниже нижнего колонтитула, он по-прежнему встроен». - Звучит так, как будто вы имеете в виду встроенный JavaScript, а не «встроенный» JavaScript (на который ссылается TecBrat).
MrWhite

Ответы:

13

Встроенный JavaScript увеличивает время загрузки страницы, что не очень хорошо. При обращении к .jsфайлу, по крайней мере, это могут быть параллельные вызовы, и время загрузки контента уменьшается. Да, бывают ситуации, когда можно поместить JavaScript непосредственно в HTML-код, но вам лучше не загружать его как можно больше.

Имейте в виду, что время загрузки страницы (то есть HTML), а не все вызовы ресурсов влияют на показатели, влияющие на ранжирование (хотя для PageRank или в результатах поиска это не имеет значения). Дело в том, что это влияет на производительность сайтов для SEO, однако это проявляется.

closetnoc
источник
7
Согласование второго подключения к предположительно тому же хосту для загрузки того же объема данных быстрее, чем в активном потоке? обычно, если вы получаете, скажем, 50 Кбит / с для файла на хост, запуск второго сеанса может сократить его, так что оба теперь будут 25 Кбит / с. Если хост не регулирует соединение по какой-либо причине.
EkriirkE
Хотя есть минус для внешних файлов. Если это не сделано должным образом, вы создаете код блокировки DOM, то есть триггер doc.ready работает медленнее, что влияет на достигнутую скорость. Но если сделано правильно, внешний путь пойти
Мартейн
4
.jsфайлы лучше для кэширования, не имеет смысла, что два подключения к одному хосту магическим образом увеличат вашу скорость загрузки.
Мысль о разделении полосы пропускания, хотя я понимаю вашу логику и не совсем ошибочна, немного вводит в заблуждение. HTML-код меньше, занимая меньше времени, и любой последующий вызов может подождать.
closetnoc
3
если вы тратите время, вы ошибаетесь, рассматривая пропускную способность. Посмотрите на профилировщик во время загрузки: обычно время соединения в 10-100 раз БОЛЬШЕ, чем реальное время обмена данными. это означает, что FRAGMENTATION представляет собой реальную проблему, и использование внешнего выделенного файла для действительно маленьких js может оказаться хуже, чем встроенный. Inline лучше для браузера, который не выполняет реального распараллеливания
Lesto
29

На моем сайте конвертации валют большинство сеансов - это просмотры одной страницы. Это связано с тем, что пользователи могут производить расчет своей валюты непосредственно на целевой странице (все вычисления обрабатываются на стороне клиента с помощью JavaScript.)

Моя страница загружается и отображается примерно в два раза быстрее, когда все ресурсы (CSS, JS и даже изображения ) встроены в страницу. Поскольку очень немногие из моих пользователей просматривают несколько страниц, я бы не получил много пользы от кэширования некоторых ресурсов между просмотрами страниц.

Мой сайт не типичный. Большинство сайтов имеют несколько страниц за сеанс и большие изображения, которые делают мою технику менее применимой. Нет единственно правильного решения этого вопроса; это зависит от сайта. Вы должны измерить это самостоятельно, основываясь на типичном поведении ваших пользователей.

Стивен Остермиллер
источник
12

Не обязательно плохо иметь JavaScript в вашем HTML-файле, но вы должны сделать это.

Это является плохим , если у вас есть большое количество JavaScript используется на нескольких страницах. В этом случае JavaScript должен быть во внешнем, сжатом и кэшируемом файле, и если ваш сайт имеет очень большой трафик, вы должны использовать CDN.

Однако, если у вас небольшое количество JavaScript, сохранение его во внешнем файле может быть сведено на нет тем, что вам нужно сделать дополнительный HTTP-запрос для его получения. В этом случае было бы более эффективно сохранить JavaScript на вашей странице.

С другой стороны, если этот же небольшой фрагмент JavaScript используется на нескольких страницах, было бы полезно поместить его во внешний файл, чтобы воспользоваться преимуществами кэширования.

В конечном итоге вы должны сопоставить размер JavaScript с дополнительными затратами на выполнение дополнительных HTTP-запросов. По большей части, для «среднего» сайта, это, вероятно, не будет иметь большого значения, просто поместив его во внешний файл.

foamcow
источник
4

Я разработчик Yii и могу вам сказать, что Yii не имеет к этому никакого отношения . Это полностью на стороне разработчика , независимо от того, поместил ли он или она код Javascript в отдельный файл и зарегистрировал его на странице HTML (просмотр) с помощью CClientScript::registerScriptFileметода, или поместил его непосредственно для просмотра кода (HTML) и зарегистрировал его с помощью CClientScript::registerScriptметода.

Согласно вашему ответу, большинство (профессиональных?) Разработчиков Yii решительно голосуют за первый подход, то есть сохранение как можно большего количества кода Javascript в отдельных файлах. Таким образом, это, безусловно, не новая тенденция кодирования, а скорее плохая практика разработчиков. По крайней мере, так это выглядит в сообществе Yii.

РЕДАКТИРОВАТЬ : На самом деле я забыл о самом важном аргументе. Yii (как и большинство других профессиональных PHP-фреймворков) построен на основе шаблона проектирования MVC (фактически - архитектурного шаблона). И тот же шаблон можно использовать во фронтэнде: HTML-код - это модель (данные), CSS - это вид (декоратор), а Javascript - это контроллер. Все они помещаются в отдельные файлы , .jsа .cssфайлы - минимизированы, запутаны и сжаты в лучшем сценарии.

Когда вы создаете свое приложение Yii, вы можете сломать шаблон MVC и сохранить все в одном файле. Вопрос в том, стоит ли это делать, каковы преимущества (нет?) И к чему это вас приведет? Вы можете использовать ту же самую аргументацию, когда спрашиваете, сохранять ли код JS встроенным или нет?

trejder
источник
Ok. Разработчик, кажется, использует сторонние виджеты для всего; Автозаполнение, загрузка изображений Ajax и т. Д. Все это добавляет встроенные JS.
Стивен
Нет, я не могу согласиться Я использую Twitter Bootstrap в своих приложениях Yii (возможно, самое большое расширение Yii и огромный набор виджетов), а также многие другие расширения Yii, и ни одно из них не использует встроенный JS. Вашему разработчику, возможно, очень повезет найти виджеты и расширения, которые используют только встроенный Javascript. Вы должны иметь достаточный опыт работы с Yii, чтобы начать писать собственные расширения (за исключением тех немногих, которые написаны очень плохо), и даже опытный разработчик Yii использует встроенный код в качестве последнего варианта, если все остальное не удается.
Трейдер
Использование сторонних расширений и виджетов в Yii - отличная идея (вам не нужно снова изобретать колесо). Но использование встроенного JS-кода в приложении или расширении Yii на самом деле является плохим отношением. Так что либо заставьте своего разработчика писать лучший код / ​​используйте лучшие расширения и виджеты, либо ... найдите лучшего разработчика! :]
Трейдер
Хорошо, спасибо за отзыв. Помимо Stackoverflow, где я могу найти хорошее сообщество Yii?
Стивен
На форуме Yii . Большинство страниц свободно доступны. Некоторые требуют регистрации учетной записи и входа в систему. Большинство разработчиков Yii в Stack Overflow имеют собственные аккаунты на форуме. После почти шести лет существования Yii Framework заработал большое сообщество разработчиков, поэтому, если вы посмотрите внимательно, вы сможете найти несколько разработчиков Yii в вашем местном сообществе или даже в своем районе. Удачи.
Трейдер
3

На самом деле это зависит от цели веб-страницы, которую вы разрабатываете:

Я использую небольшое количество встроенного JavaScript, в то время как я предпочитаю использовать внешние файлы JavaScript, если он большой.

В любом случае, когда страница загружает JavaScript, она должна быть выполнена первой. Лучше всего использовать внешний JavaScript, чтобы он не удлинял содержание вашей страницы. Это также облегчает отладку.

Абхиджит Бхатту
источник
2

Ответ на самом деле зависит от того, что делается.

Если вы заметили встроенный JavaScript, который используется по всему сайту (например, виджет, который отображается внутри заголовка на всех страницах сайта), то было бы целесообразно переместить его в «общий» файл JavaScript.

Фактически, я бы переместил как можно больше JavaScript в общий файл JavaScript, даже если бы он использовался на одной странице. Я бы настроил сервер для отправки сильных заголовков кэширования и сжатия для файлов JavaScript; что уменьшает размер страниц, но не увеличивает размер файла JavaScript на много.

С другой стороны, если JavaScript - это просто набор параметров конфигурации / инициализации, например:

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

где по какой-то причине было невозможно переместить код во внешний файл JavaScript (например, когда параметры изображения поступают из базы данных), я бы оставил его встроенным. Сказав это, я бы выбрал сторонние плагины, которые являются "ненавязчивыми" (или конвертируют их как таковые).

Салман А
источник
2

Эти ответы не попадают в цель. Посмотрите на встроенное кэширование .

Поскольку Yii написан на PHP, распространенный (или, возможно, необычный) шаблон PHP, который вы обнаружите, заключается в том, что разработчики иногда пишут код PHP для динамической генерации кода Javascript на сервере - на основе некоторого состояния, условия или значения, известного серверу - а затем отправить все это клиенту в одном пакете, позволяя клиенту выполнить функцию и пропустить некоторые вычисления, которые уже были выполнены сервером.

Вместо того, чтобы отправлять клиенту целую связку общих функций Javascript в файле .js, которые не имеют контекста, пока не будут предоставлены данные (данные, которые могут храниться на сервере и требовать передачи туда и обратно), мы можем «запечь» контекст / данные как часть функции Javascript. Это экономно, потому что это означает, что вы отправляете функциональные возможности / данные вместе и отправляете только функциональные возможности / данные, которые могут понадобиться клиенту в данный момент, вместо отправки всего приложения при первой загрузке страницы. Это также означает, что вам не нужно подвергать все свое приложение легкой загрузке и обратной переработке при загрузке первой страницы, потому что вы вводите только небольшие части функциональности, которые могут понадобиться каждому отдельному клиенту в данный момент. Не уверен, насколько хорошо это предвещает SEO, но я уверен, что он может быть оптимизирован соответственно.

Рассмотрим случай, когда конечный пользователь пишет страницу в некотором программном обеспечении CMS с помощью редактора WYSIWYG. Как этот пользователь собирается добавить новые функции на страницу, если у них нет доступа к вашим исходным файлам .js на сервере? Они переключаются на вкладку HTML и используют встроенный Javascript.

Не весь встроенный Javascript плох; иногда onclick тоже хорошо. Как общая рекомендация, избегайте написания встроенного Javascript, и вы будете на пути к созданию хороших привычек.

Ссылки:

грушевый сидр
источник
0

Обычно встроенный JS-код плох, как говорили другие до меня.

Но я думаю о случае использования, где встроенный JS лучше .

Подумайте о CMS, которая вставляет управляемую JS галерею. Галерея может быть сделано в jQuery. Он идентифицируется атрибутом id, который не только уникален на странице, но и уникален для всего сайта. В этом случае - я думаю - встроенный JS был бы лучше, потому что код JS используется только на одной странице, и у вас нет накладных расходов HTTP

yunzen
источник