Почему я должен избегать встроенных сценариев?

Знающий друг недавно посмотрел сайт, который я помог запустить, и прокомментировал что-то вроде «очень крутой сайт, позор встроенным сценариям в исходном коде».

Я определенно могу удалить встроенные скрипты там, где это происходит; Я смутно осознаю, что это «плохо». Мой вопрос: каковы реальные проблемы с встроенными сценариями? Есть ли существенная проблема с производительностью, или это в основном просто вопрос хорошего стиля? Могу ли я оправдать немедленные действия в области встроенных сценариев для моих начальников, когда есть другие вещи, над которыми можно работать, которые могут оказать более очевидное влияние на сайт? Если вы заглянули на веб-сайт и взглянули на исходный код, какие факторы заставили бы вас сказать «хм, профессиональная работа здесь» и что заставило бы вас отказаться от явно любительской работы?

Хорошо, этот вопрос превратился в несколько вопросов в письменной форме. Но в основном встроенные скрипты - в чем дело?

Каковы реальные проблемы со встроенными сценариями? Есть ли существенная проблема с производительностью, или это в основном просто вопрос хорошего стиля?

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

Могу ли я оправдать немедленные действия в области встроенных сценариев для моих начальников, когда есть другие вещи, над которыми можно работать, которые могут оказать более очевидное влияние на сайт?

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

Если вы заглянули на веб-сайт и взглянули на исходный код, какие факторы заставили бы вас сказать «хм, профессиональная работа здесь» и что заставило бы вас отказаться от явно любительской работы?

Фактор номер один, который сказал бы мне, что это не профессионально, - это чрезмерное использование таблиц или делений. Вот статья, объясняющая, почему ни один из них не должен использоваться чрезмерно.

Я не собираюсь быть защитником дьявола, но нет строгой связи между любительской работой и встроенным JavaScript. Давайте посмотрим исходный код нескольких самых известных сайтов:

• Google,
• Википедия,
• Microsoft,
• Adobe,
• Dell,
• IBM.

Каждая из их домашних страниц использует встроенный JavaScript. Означает ли это, что все эти компании нанимают любительских людей для создания своих домашних страниц?

Я один из тех разработчиков, которые не могут поместить код JavaScript в HTML. Я никогда не делаю это внутри проектов, над которыми я работаю (за исключением, вероятно, некоторых вызовов, подобных <a href="javascript:...">проектам, где ненавязчивый JavaScript не был требованием с самого начала, и я всегда удаляю встроенный JavaScript, когда я рефакторинг кода кого-то другого. Но стоит ли это усилий Не уверен.

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

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

• Что делать, если большинство ваших пользователей приходят с пустым кешем?
• Считаете ли вы, что с внешним файлом .js к этому файлу будет обращаться запрос при каждом запросе страницы, если веб-сайт не настроен должным образом (и обычно это не так),
• Действительно ли файл .js кэшируется (с IIS это может быть не так просто)?

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

Затем следует последний аргумент: вы смешали JavaScript и HTML в своем источнике, так что вы отстой. Но кто сказал, что вы смешали оба? Исходный код, используемый браузером, не всегда является исходным кодом, который вы написали. Например, исходный код может быть сжат, уменьшенным или несколько CSS или JS файлов могут быть объединены в один файл, но это не значит , что вы действительно назвали переменные a, b, c... a1и т.д. , или что вы написали Огромный файл CSS без пробелов и переносов. Таким же образом вы можете легко вставить внешний исходный код JavaScript в HTML во время компиляции или позже через шаблоны.

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

• Это может быть плохо.
• Напротив, это может быть признаком того, что веб-сайт был написан профессионалами, которые заботились о производительности, провели специальные тесты и определили, что их клиентам будет быстрее встроить части JavaScript.
• Или это может вообще ничего не значить.

так что скорее позор человеку, который говорит «очень крутой сайт, позор встроенным сценариям в исходном коде», просто взглянув на исходный код, отправленный в браузер, ничего не зная о том, как был создан сайт.

Как правило, хорошо пытаться разделить HTML и JS. HTML для представления, JS для логики приложения. Но по моему опыту крайняя развязка html и javascript (ради чистоты) не делает его более понятным; это на самом деле может быть менее ремонтопригодным.

Например, я иногда использую этот шаблон (заимствованный из ASP.net) при настройке обработчиков событий:

<input type="button" id="yourId" onclick="clickYourId()" />

или же

<input type="button" id="yourId" onclick="clickYourId(this)" />

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

С другой стороны, представьте, что вы читаете чужой код, который составляет сто тысяч строк, и вы сталкиваетесь с магическим элементом, который запускает событие javascript:

<input id="yourId"  />

Как вы можете легко сказать мне, какой метод JavaScript это вызывает? Chrome сделал это проще, но, возможно, событие связано с идентификатором, или, возможно, оно связано с первым дочерним элементом контейнера. Возможно, событие прикреплено к родительскому объекту. Кто знает? Удачи в поиске. :)

Кроме того, я бы сказал, что полное скрытие javascript от дизайнера может на самом деле увеличить вероятность того, что он сломает его при обновлении. Если кто-то редактирует код для магически активного элемента, какое указание в коде у него будет, что позволит ему узнать, что это активный элемент на странице?

Короче говоря, лучшая практика - разделять HTML и Javascript. Но также понять, что эмпирические правила иногда контрпродуктивны, когда доводятся до крайности. Я бы поспорил за подход к средней дороге. Избегайте большого количества встроенных js. Если вы используете inline, подпись функции должна быть очень простой, например:

1. emptyFunction()
2. doCallWithThis(this)
3. atTheExtremOnlyPassOneNumber(2)

Один из аргументов, которые я здесь упускаю, - это возможность повышенной защиты от атак с использованием межсайтовых скриптов .

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

Вот несколько причин.

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

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

3. Встроенный скрипт сложнее отлаживать, потому что номер строки, связанный с любой ошибкой, не имеет смысла.

4. Считается, что встроенный скрипт мешает анализу доступности (508 / WAI), хотя это не означает, что все встроенные скрипты вызывают проблемы. Если у вас есть программа чтения с экрана, объявляющая содержание скрипта, у вас есть проблема! (Никогда не видел, чтобы это произошло, хотя).

5. Встроенный скрипт не может быть протестирован независимо от его страницы; внешние файлы Javascript можно запускать с помощью независимого тестирования, включая автоматические тесты.

6. Встроенный скрипт может привести к плохому разделению проблем (как описано во многих других ответах здесь).

Есть несколько причин, по которым не стоит включать скрипт:

• Прежде всего, очевидный ответ - это делает код чище, более кратким, более легким для понимания и чтения.

• С более практической точки зрения вы часто хотите повторно использовать сценарии / CSS / и т. Д. на всех страницах вашего сайта, вставка этих частей будет означать необходимость редактировать каждую страницу каждый раз, когда вы вносите небольшие изменения.

• Если вы используете SCM для своего проекта, то благодаря тому, что ваши различные компоненты хорошо разделены, вы сможете легко отслеживать изменения и фиксировать их для всех участников.

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

Я не знаю о каких-либо формальных тестах в этой области, хотя весьма вероятно, что кто-то сделал их.

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

Ответ действительно зависит от того, как используется встроенный код (в предположении JavaScript).

Мы использовали комбинацию встроенного кода, SSI (включая серверную часть), js-файлов и css-файлов, чтобы создать требуемые эффекты, а также уменьшить количество обращений сервера к событиям onClick.

Таким образом, кто-то может сделать общее заявление о том, что использование «встроенного кода» плохо без полного понимания того, как он используется, может вводить в заблуждение.

Сказав это, если каждая страница имеет одну и ту же копию и вставил код javascript вместо использования файла js, я говорю, что это плохо.

Если у каждой страницы есть свой собственный экземпляр и вставленный раздел CCS вместо использования файла CSS, я говорю, что это плохо.

Кроме того, стоит добавить всю библиотеку js на каждую страницу, особенно если ни одна из функций не используется на этой странице.

Я собираюсь принять встроенный JavaScript здесь.

Не видя код, трудно быть уверенным. Я подозреваю, что он ссылался на одну из двух вещей:

1. Вы <script>разбросаны по всей странице
2. Все, что вы JS находится в заголовке страницы, а не во внешних файлах

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

Что касается второго - это не обязательно плохо. Код этой страницы должен быть на этой странице. Если у вас есть повторяющийся код между страницами, вы должны использовать его <script src>. Затем, когда вы создадите новую страницу, вы можете просто включить этот файл, и любые ошибки, которые вы там исправили, не нужно будет пересматривать.

Одна из причин, по которой НЕ следует использовать InLine Javascript (даже не onclick = "DoThis (this)" для кнопок), заключается в том, что вы намерены превратить свое веб-приложение в приложение Chrome. Итак, если вы планируете перенести свое веб-приложение в приложение Native Chrome, начните с НЕ включая ЛЮБОГО встроенного JavaScript. Это объясняется в самом начале того, что вам нужно будет изменить (обязательно) в вашем веб-приложении, если вы собираетесь «хромировать» его.

Каковы реальные проблемы с встроенными сценариями?

Встроенные сценарии плохи, и их следует избегать, потому что они затрудняют чтение кода.

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

Сложность обычно исходит из вложенных кодировок. В следующей строке кода есть проблема, вы можете ее обнаружить?

<a onclick='alert("What\'s going wrong here?")'>Alert!</a>

В идеале код написан таким образом, чтобы его можно было легко обнаружить в случае ошибки. Джоэл Спольски написал отличную статью, которая подчеркивает этот момент еще в 2005 году . Примеры кода могли бы использовать некоторые существенные улучшения, поскольку они показывают, что их возраст составляет 9 лет, но основополагающая концепция все еще остается сильной: пишите код так, чтобы было легко выявлять ошибки.

Есть ли существенная проблема с производительностью, или это в основном просто вопрос хорошего стиля?

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

Могу ли я оправдать немедленные действия в области встроенных сценариев для моих начальников, когда есть другие вещи, над которыми можно работать, которые могут оказать более очевидное влияние на сайт?

Нет. Если это глупо, и это работает, это не глупо.

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

Какие факторы заставили бы вас сказать «хм, профессиональная работа здесь», и что заставило бы вас отказаться от явно любительской работы?

Я предпочитаю определять «профессионал» просто как человека, которому платят за выполнение задачи, а не предполагать, что он обладает какой-либо значительной способностью в том, что ему платят за выполнение. Многие профессионалы, безусловно, способны выполнять хорошую работу, но чаще всего я в ужасе отскакиваю от ужасной работы, которую проделали другие профессионалы, а не от того, что придумал любитель. Большая часть моей работы на сегодняшний день была связана с спасением проектов крушения поезда, которые были испорчены первыми разработчиками, поэтому ваш пробег может варьироваться.

С учетом всего сказанного, как правило, легко выбрать программирование качества предприятия