Серверная Сторона Javascript: Почему?

Это звучит так:

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

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

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

введите серверный javascript. Идея в том, что вы можете написать код один раз, поэтому один и тот же код работает как на сервере, так и на клиенте. Это, по-видимому, решит большую часть проблемы: вы получите полный набор как серверной, так и клиентской логики, выполненной одновременно, нет дрейфа и двойного обслуживания. Также приятно, когда вашим разработчикам нужно знать только один язык для работы сервера и клиента.

к сожалению, в реальном мире это не получилось. Проблема в четыре раза:

1. представление сервера страницы по-прежнему сильно отличается от представления клиента страницы. Сервер должен иметь возможность делать такие вещи, как говорить непосредственно с базой данных, которая просто не должно быть сделано из браузера. Браузер должен делать такие вещи, как манипулировать DOM, который не соответствует серверу.
2. вы не контролируете движок javascript клиента, что означает, что по-прежнему будут важные языковые различия между вашим кодом сервера и кодом клиента.
3. база данных обычно более узкое, чем веб-сервер, поэтому экономия минимальна.
4. хотя почти все знают немного javascript, не так много разработчики действительно знают и понимают JavaScript ну.

Это не совсем неприступные технические проблемы: вы ограничиваете поддерживаемый сервером язык поднабором javascript, который хорошо поддерживается в большинстве браузеров, предоставляете IDE, которая знает это подмножество и серверные расширения, делаете некоторые правила о структуре страницы, чтобы минимизировать проблемы DOM, и предоставляете некоторый javascript котельной плиты для включения на клиенте, чтобы сделать платформу немного приятнее использовать. Результатом является что-то вроде Aptana Studio/Jaxer или более позднего узла.js, что может быть довольно приятно.

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

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