2009-03-27 4 views
26

Является ли использование JavaScript на стороне сервера распространенным? Зачем использовать его в отличие от других скриптов на стороне сервера? Существует ли конкретный вариант использования, который делает его лучше, чем другие серверные языки?Server Side Javascript: Почему?

Кроме того, смущенный тем, как начать экспериментировать с ним, я нахожусь на freeBSD, что мне нужно установить для запуска JavaScript на стороне сервера?

ответ

43

Это выглядит следующим образом:

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

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

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

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

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

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

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

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

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

+8

Ничего себе! Какая скорость ввода? –

+0

Нет способа, которым вы только что написали, что ...: p –

+5

:) Время _last_ кто-то задал вопрос вроде этого, он был закрыт, прежде чем я смог нажать submit. У меня было достаточно работы на посту, я решил ее сохранить. –

6

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

Также см:

+0

+1: Знаете, я никогда не думал, что когда-нибудь проголосую за серверный бонус javascript, но ваш ответ - хорошая еда для размышлений! –

3

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

Это, как говорится, я не знаю что существует много новых разработок, происходящих с «Server-Side Javascript»

3

Javascript - отличный язык с основами стиля прототипа self/scheme и синтаксисом стиля C. Есть некоторые проблемы, см. Javascript the Good Parts, но в целом это язык с первой скоростью. Проблема в том, что большинство программистов javascript - ужасные программисты, потому что это очень доступно для начала.

Одна команда из Google построила Rhino on Rails, которая является структурой MVC, такой как Ruby on Rails, которая написана на javascript и работает на Rhino - интерпретаторе javascript для виртуальной машины Java. В этом случае у них было требование использовать виртуальную машину Java, но хотелось получить быстрый язык (javascript быстр), поддерживается утиная печать и была гибкой.

Другой пример - это что-то вроде CouchDB, ориентированной на документ базы данных, которая использует json, поскольку это транспортный формат и javascript, так как это запрос & индексный язык. Они хотели, чтобы база данных была как можно более родной.

Javascript хорош в обработке строк и dom (xml), будучи изолированным, создавая сети, расширяя себя и т. Д. Эти особенности - это то, что вы часто делаете при разработке веб-приложений.

Все, что сказал, я фактически не разрабатываю javascript на стороне сервера. Это не плохая идея, но определенно менее распространенная.

1

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

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

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