Оказание javascript на уровне сервера. Хорошая или плохая идея?

Question

Теперь сообщество wiki!

Я хочу, чтобы понять первую: Это не вопрос, по отношению к стороне сервера Javascript или работает бок Javascript сервера. Речь идет о предоставлении кода Javascript (который будет выполняться на стороне клиента) из кода на стороне сервера.

Сказав это, взгляните на ниже ASP.net кода, например:

hlRemoveCategory.Attributes.Add("onclick", "return confirm('Are you sure you want to delete this?');") 

Это предписывающее событие на сторону клиента onclick на стороне сервера.

Как противиться писать Javascript на стороне клиента:

$('a[rel=remove]').bind('click', function(event) { 
    return confirm('Are you sure you want to delete this?'); 
} 

Теперь вопрос, который я хочу спросить: Что такое преимущество рендеринга JavaScript из серверного кода? Или наоборот?

Я лично предпочитаю второй путь от подключения на стороне клиента UI/поведение HTML-элементов по следующим причинам:

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

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

Тема ветвящейся от этого аргумента может достигать: управление

• кода: это проще, чтобы сделать все от серверной стороны?
• Разделение беспокойства: легче ли клиентская логика разделена на серверную логику?
• Эффективность: что более эффективно с точки зрения кодирования и работы?

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

Дайте мне знать ваши мысли.

UPDATE1: Похоже, что все мы, участвовавшие в этом посту, имеют общее мнение; Хорошо знать, что есть другие, которые думают одинаково. Теперь, чтобы убедить ребят;) Спасибо всем.

Answer 1

Ваш второй пример значительно превосходит первый пример. Javascript - это ваш уровень поведения и должен быть отделен от семантической разметки (контента) и CSS (презентации). Существует ряд причин, по которым это лучше:

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

Есть много других аргументов и причин, но они должны вам начать ...

Кроме того, из вашего примера кажется, что у вас есть нормальные ссылки в документе, который может удалить содержимое. Это также будет плохой практикой. Все, что удаляет или обновляет контент, должно выполняться в запросе POST (не GET). Таким образом, это должно быть результатом подачи формы. В противном случае, например. googlebot может случайно удалить весь ваш контент, просто сканировав вашу страницу (и роботы поисковых систем не выполняют JS, поэтому ваше предупреждение не поможет там)

Answer 2

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

Иногда вы хотите использовать какую-то информацию, которая доступна на стороне сервера, чтобы решить, следует ли добавить или не событие, или создать код для события, например:

if (categoryCanBeDeleted) { 
    hlRemoveCategory.Attributes.Add(
    "onclick", 
    "return confirm('Are you sure you want to delete the " + categoryType + "?');" 
); 
} 

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

Answer 3

В два большие различия я могу думать на фронте:

• вы теряете кэширование на стороне клиента, вы получили бы, если Javascript был в отдельном JS файл
• , если вам нужно изменить ваш javascript, вы должны перекомпилировать (экстраполировать это на то, что происходит после того, как вы выпустили свой продукт: если вам нужно перекомпилировать, вам необходимо перераспределить двоичные файлы вместо измененного файла js)
• проще использовать отладчик VS если javascript находится в отдельном файле; вы можете просто установить точку останова в этом файле, если вы создаете сторону сервера кода, тогда вам нужно использовать функцию работающих документов, найти сгенерированный код и затем добавить точку останова, и эту точку останова следует добавлять вручную каждый раз, когда вы повторно -продолжите свое приложение. Исходя из этого, если код находится в отдельном файле, вы можете просто настроить свой код на код javascript, F5 на странице своего браузера и продолжить отладку без необходимости остановки и перезапуска отладчика.

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

Answer 4

Похоже, вы уже знаете, что делать. Оказание его на стороне сервера - плохая идея.

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

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

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

<Rant>

Это не легко отделить HTML и JavaScript, и даже CSS, особенно если вы хотите, чтобы некоторые AJAX или UI благость. Чтобы иметь полное разделение, нам пришлось бы перейти к модели настольного приложения, где весь внешний код сгенерировал на стороне клиента программно с использованием Javascript, а все взаимодействие с сервером ограничивается чистым обменом данными.

Большинство восходящей связи (клиент к серверу) - это уже просто обмен данными, но не связь по потоку. Многие серверные скрипты генерируют HTML, объединяют его с данными и вертелит его обратно. Это прекрасно, пока сервер остается в команде генерации HTML-представлений. Но когда фантастический Javascript приходит на борт и начинает добавлять строки к таблицам, а div для комментариев, точно реплицируя существующую структуру HTML, мы создали две точки, в которых генерируется разметка.

$(".comments").append($("<div>", { 
    "id": "123", 
    "class": "comment", 
    "html": "I would argue this is still bad practice..." 
})); 

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

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

<div style="position: absolute; top: 100px; left: 250px;">..</div>

Мы облажались наши прекрасные смысловые страницы, но это должно было быть сделано.

</Rant>

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

Answer 5

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

Обратной стороной медали является то, что сделать это быстро и простой (по крайней мере, в краткосрочной перспективе).

ИМО, это не приближается к перевесу минусов подхода, но это причина.