Это выглядит так:
Серверы дороги, но пользователи бесплатно дадут вам время обработки в своих браузерах. Поэтому код на стороне сервера является относительно дорогим по сравнению с кодом на стороне клиента на любом сайте, достаточно большом, чтобы запускать более одного сервера. Однако есть некоторые вещи, которые вы не можете оставить клиенту, такие как проверка и извлечение данных. Вы хотели бы сделать их на клиенте, потому что это означает более быстрое время отклика для пользователей и меньше серверной инфраструктуры для себя, но проблемы безопасности и доступности означают, что требуется код на стороне сервера.
Что обычно происходит, вы делаете оба. Вы пишете логику на стороне сервера, потому что это необходимо, но вы также пишете ту же логику в javascript в надежде обеспечить более быстрые ответы пользователю и сэкономить вашим серверам немного дополнительной работы в некоторых ситуациях. Это особенно эффективно для кода проверки.
Поскольку мы все (в основном) программисты, мы должны немедленно обнаружить новую проблему. Не только дополнительная работа, связанная с разработкой двух наборов одной и той же логики, но и работа, связанная с ее обслуживанием, неизбежные ошибки, возникающие из-за платформ, не соответствуют друг другу, и ошибки, появляющиеся по мере того, как реализации со временем расходятся.
Введите javascript на стороне сервера. Идея состоит в том, что вы можете написать код один раз, поэтому один и тот же код работает как на сервере, так и на клиенте. Казалось бы, это решает большую часть проблемы: вы получаете полный набор серверной и клиентской логики одновременно, нет дрейфа и двойного обслуживания. Также хорошо, когда ваши разработчики должны знать только один язык для работы как сервера, так и клиента.
К сожалению, в реальном мире это не так хорошо работает. Проблема в четыре раза:
- Вид страницы на сервере по-прежнему сильно отличается от вида страницы на клиенте. Сервер должен иметь возможность разговаривать напрямую с базой данных, чего не следует делать из браузера. Браузер должен выполнять такие вещи, как манипулирование DOM, который не совпадает с сервером.
- Вы не управляете движком javascript клиента, а это означает, что все еще будут существенные языковые различия между кодом вашего сервера и кодом клиента.
- База данных обычно является более узким местом, чем веб-сервер, поэтому экономия минимальна.
- Хотя почти каждый знает небольшой JavaScript, немногие разработчики действительно знают и понимают Javascript хорошо .
Это не совсем неопровержимые технические проблемы: вы ограничиваете поддерживаемый сервером язык подмножеством javascript, который хорошо поддерживается в большинстве браузеров, предоставляете IDE, которая знает это подмножество и расширения на стороне сервера, устанавливаете некоторые правила о структуре страницы, чтобы минимизировать проблемы с DOM, и предоставить некоторый шаблонный javascript для включения на клиенте, чтобы сделать платформу немного приятнее в использовании. В результате получается что-то вроде Aptana Studio / Jaxer или совсем недавно Node.js, что может быть довольно неплохо.
Но не идеально. На мой взгляд, слишком много подводных камней и небольших проблем с совместимостью, чтобы это действительно блестело. В конечном счете, дополнительные серверы по-прежнему дешевы по сравнению со временем разработки, и большинство программистов могут быть гораздо более продуктивными, используя что-то кроме javascript.
Что я действительно хотел бы увидеть, так это частичный javascript на стороне сервера. Когда запрашивается страница или отправляется форма, серверная платформа запрашивает проверку в javascript, возможно, в качестве плагина к веб-серверу, который полностью независим от остальных, но ответ построен с использованием платформы по вашему выбору.