Каковы аргументы против включения сценариев на стороне сервера в блоки кода JavaScript?

• Внедрение скрипта: тег на стороне сервера может содержать код, который может сломать код JavaScript.

Так что пишите код правильно и убедитесь, что значения корректно экранируются при введении в контекст JavaScript. Если ваш фреймворк не включает инструмент "цитирования" JavaScript (подсказка: поддержка JSON, вероятно, все, что вам нужно), напишите его.

• Модульное тестирование. Сложнее изолировать блоки кода для тестирования

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

Таким образом, страница может содержать:

<script>
  (function(window) {
    window['pageData'] = {
      companyName: '<%= company.name %>',
      // etc
    };
  })(this);
</script>

Теперь ваш прекрасно инкапсулированный чистый код JavaScript в файлах «.js» просто должен проверить наличие window.pageData, и все готово.

• Разделение кода: мы должны максимально разделять технологии веб-страниц.

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

Правила кодирования и эстетика — это хорошо. Однако следует быть прагматичным и смотреть на все в перспективе. Важно помнить, что контекстом таких правил не всегда является Совершенное Божественное Творение, и в случае с HTML, CSS и JavaScript я думаю, что этот факт очевиден. В такой несовершенной среде жесткие правила могут заставить вас выполнять ненужную работу и код, который на самом деле сложнее поддерживать.

редактировать а вот еще кое-что, о чем я только что подумал; своего рода компромисс. «Трюк», популяризированный (частично) бандой jQuery с их средством «микрошаблонов» (извиняюсь перед веб-гением, который на самом деле наткнулся на это первым), заключается в использовании тегов <script>, которые являются своего рода «стерилизованными»:

<script id='pageData' type='text/plain'>
  {
    'companyName': '<%= company.name %>',
    'accountType': '<%= user.primaryAccount.type %>',
    // etc
  }
</script>

Теперь сам браузер даже не будет выполнять этот скрипт - атрибут "type" не является чем-то, что он понимает как код, поэтому он просто игнорирует его. Однако браузеры делают доступ к содержимому таких скриптов, поэтому ваш код может найти скрипт по значению "id", а затем с помощью какой-либо безопасной библиотеки JSON или встроенного API браузера, если он доступен, проанализировать нотацию. и извлечь то, что ему нужно. Значения по-прежнему должны быть правильно заключены в кавычки и т. д., но вы несколько безопаснее от дыр XSS, потому что они анализируются как JSON, а не как «живой» полноценный JavaScript.

The reason for doing this was so that the developer did not have to define the constant in two places.

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

Каждое руководство/правило стиля, доведенное до крайности, приводит к анти-шаблону. В этом случае ваша настойчивость в разделении технологий нарушает принцип DRY и потенциально может затруднить сопровождение кода. Даже сам DRY, если его довести до крайности, может привести к анти-шаблону: softcoding .

Сопровождаемость кода — прекрасный баланс. Руководства по стилю помогут сохранить этот баланс. Но надо знать, когда эти самые проводники помогают, а когда сами становятся проблемой.

Обратите внимание, что в приведенном вами примере код не нарушит выделение или синтаксический анализ синтаксиса (даже stackoverflow правильно его выделяет), поэтому аргумент IDE не будет работать, поскольку IDE все еще может правильно анализировать этот код.

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

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

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