Когда и как использовать серверный JavaScript?

Это может относиться к использованию javascript для отправки сообщений на веб-сервер без повторной загрузки страницы: другими словами, AJAX.

Но более вероятно, что я думаю, что это означает что-то вроде Аптана / Джаксер (или, сегодня, Node.js), который использует javascript для серверного языка. В этом случае помните, что javascript - это просто язык: модель DOM, используемая в веб-браузере, представляет собой своего рода API. Серверные механизмы javascript будут предоставлять свои собственные объекты API, ориентированные на такие серверные задачи, как доступ к базе данных и файловой системе.

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

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

Возможно, вы захотите иметь некоторые функции как в браузере, так и на сервере, чтобы иметь одинаковую реализацию.

Примером может служить средство визуализации для синтаксиса вики, которое вы запускаете в браузере для редактора WYSIWYG и на сервере для визуализации результирующей страницы. Таким образом, вы знаете, что оба полученных результата в обоих случаях будут одинаковыми.

Очевидно, Носорог может компилировать JavaScript в классы Java.

Традиционно Javascript работает с объектной моделью документа. Но что, если вы работаете в магазине Java и хотите, чтобы ваша пользовательская объектная модель создавала скриптовый движок? Вот тогда и появляется серверный Javascript.

http://en.wikipedia.org/wiki/Server-side_JavaScript

Это действительно зависит от того, говорите ли вы об ASP.NET или классическом ASP. Если вы используете ASP.NET, у вас не так много веских причин для использования Javascript.

Другое дело - ASP Classic. Вы можете использовать Javascript на стороне сервера в ASP точно так же, как и VBScript. Вы можете получить доступ к объектам Application, Server, Request и Response так же, как через VBScript.

Использование Javascript на стороне сервера в ASP может дать реальные преимущества, а не VBScript. Это означает, что вы можете совместно использовать код между кодом браузера и кодом сервера. Это также означает, что вашим разработчикам не нужно иметь дело с двумя разными языками.

Однако у серверного Javascript в ASP есть некоторые недостатки. Во-первых, это не так быстро, как VBScript на стороне сервера при конкатенации строк. Это также не так хорошо, как выполнение вызовов COM-объектов, как VBScript (вы можете получать данные обратно из вызовов COM только через возвращаемое значение, а не через параметры out / byref).

Это не AJAX, если только люди не используют этот термин неправильно. Как следует из названия, SSJS - это JavaScript, который запускается на сервере и интерпретируется автономным (то есть независимым от браузера) движком JavaScript, таким как SpiderMonkey.

Зачем беспокоиться? Что ж, одна область, в которой я сейчас вижу, что он недостаточно используется, - это проверка данных. Используя SSJS, вы пишете один фрагмент кода, который затем используется как на сервере, так и на клиенте. Таким образом, вы получаете немедленную обратную связь с пользователем от клиентского JS, которая будет автоматически соответствовать проверке данных, происходящей на сервере.

Классический ASP мог использовать JavaScript на сервере, хотя большинство людей использовали VBScript.

Одним из убедительных примеров использования JavaScript на сервере является дополнение к проверке данных на стороне клиента. Например, вы можете использовать одну и ту же библиотеку проверки JavaScript на клиенте и на сервере. Это гарантирует, что вы используете ту же логику на клиенте, что и на сервере, но (потенциально) избегаете ненужного возврата за счет предварительной проверки на стороне клиента.

В Википедии перечислены несколько реализаций серверного JavaScript здесь.

Я помню, что с Кокон (инфраструктура Apache Java / XML / Javascript MVC) я использовал серверный Javascript, поскольку было что-то (я считаю, что cforms), которое нужно было написать на Javascript, и работало на сервере, хотя я верю вам мог бы написать это на Java.

К тому времени мы использовали Rhyno, проверьте: http://peter.michaux.ca/articles/server-side-javascript-with-rhino-and-jetty

Да, я только что прочитал о SSJS на блог, написанном каким-то парнем по имени ДжонResig.

Он описывает движок под названием Jaxer, который, по его словам, выглядит следующим образом: «Представьте, что вы удалили часть визуального рендеринга Firefox и вместо этого заменили ее перехватчиком для Apache - грубо говоря, это то, чем является Jaxer».

Для всех, кто знаком с ASP.NET. HTML выглядит знакомо.

<html>
<head>
  <script src = "http://code.jquery.com/jquery.js" runat = "both"></script>
  <script>
    jQuery(function($){
      $("form").submit(function(){
        save( $("textarea").val() );
        return false;
      });
    });
  </script>
 <script runat = "server">
    function save( text ){
      Jaxer.File.write("tmp.txt", text);
    }
    save.proxy = true;

    function load(){
      $("textarea").val(
        Jaxer.File.exists("tmp.txt") ? Jaxer.File.read("tmp.txt") : "");
    }
  </script>
</head>
<body onserverload = "load()">
   <form action = "" method = "post">
    <textarea></textarea>
    <input type = "submit"/>
  </form>
</body>
</html>

Обратите внимание на runat = "sever" и runat = "both"

http://steve-yegge.blogspot.com/2007/06/rhino-on-rails.html

Узнайте, как Стив Йегге использует серверный JavaScript с Rhino и почему. У него есть много информации о том, как, по его мнению, развивается JavaScript.

Есть проект Фобос, который представляет собой серверную платформу JavaScript.

В те времена веб-сервер Netscape также предлагал серверный java-скрипт.

В обоих случаях JavaScript используется так же, как и любой язык на сервере. Обычно для обработки HTTP-запросов и создания контента.

Носорог, система JavaScript Mozilla для Java, компилирует JavaScript в байтовые коды Java, которые JVM может выбрать для JIT. Другие системы используют другие средства для выполнения java-сценария, даже до такой степени, что некоторые из них JIT компилируют свои внутренние коды java-сценариев.

Я предвижу, что на сервере будет все больше и больше JavaScript. Когда вы пишете «толстые» приложения на JavaScript на клиенте, вы также можете написать свою логику на JavaScript на сервере, чтобы вам не приходилось совершать когнитивные скачки с одного языка на другой. Среды будут разными, но большая часть вашего кода и знаний будет общедоступна.

Наконец, JavaScript, вероятно, является единственным языком, на который сейчас больше всего средств с точки зрения реализаций. От Apple, Mozilla, Google и даже Microsoft, а также попытки сделать его еще более продвинутым языком (то есть в основном схемой с синтаксисом Algol без макросов).

Большая часть этих реализаций скрыта в браузере, но это не значит, что на стороне сервера нет никакой ценности.

Инструменты - это самое большое место, где не хватает JavaScript, особенно на стороне сервера, но если вы рассматриваете что-то вроде Phobos, где вы можете отлаживать свой серверный JavaScript JavaScript в среде IDE, это большое достижение.

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

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

file.js

<!--//--><%

//javascript code
function example(){return "Hello, World!";}

//%>

file.html

<%@LANGUAGE = "javascript"%>
<!-- METADATA TYPE = "typelib" 
FILE = "C:\Archivos de programa\Archivos comunes\System\ado\msado15.dll" -->
<!--#include file = "file.js"-->
<html>
<head>
  <script language = "javascript" src = "file.js"></script>
</head>
<body>
<%=example();%>
<script language = "javascript">alert(example());</script>
</body>
</html>

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

НОВОСТИ 2013

Node.js (см. Также в статье Википедии) - успех, а его сообщество растет!

MongoDB (на сервере), Хром (на клиенте) и Node.js (на сервере) используют Двигатель JavaScript V8.

PS: вы можете использовать только один язык, Javascript, для всех модулей вашего проекта: клиентских API, клиентского интерфейса, «серверного концентратора» и серверной базы данных (например, хранимых процедур). Все программисты «кодируют один раз»!

Основное различие между языками "Сервер-Javascript" и «Клиент-Javascript» объясняется в http://www.commonJS.org/, стандартной библиотеке для Сервер-Javascript.

CommonJS существует с 2009 года, а сегодня (2013 год) это зрелый стандарт, используется как в MongoDB, так и в Node.js.

ИСТОРИЧЕСКОЕ ПРИМЕЧАНИЕ: активный открытый пакет самый старый «клиент + сервер Javascript» (включая использование PostgreSQL) жив!
Выпущенная в 2001 году и с тех пор непрерывно развивающаяся, Уайтбим представляет собой зрелую технологию Javascript (и DOM). Последнее обновление было в январе 2016 года.

НОВОСТИ 2016

Движок Node.js продолжает работать как среда выполнения, построенная на V8 JavaScript Chrome ... И теперь, по сути, это совокупный успех! Последние выпуски - v7.0 и v6.8 LTS.

JSON, как формат обмена данными, вызывает постоянно растущий интерес в последние годы, превзойдя в 2016 году интерес к XML (см. Также в контексте науки, где превзошли в 2011 г.). Как собственный формат Javascript, он также является хорошим индикатором языковых тенденций.

Двигатель V8 (более быстрый) также является наиболее часто используемым с 2014 года: в самых популярных клиент (Chrome на настольных компьютерах и WebView в Android) и популярным в серверы - Node.js в качестве среды выполнения и PostgreSQL с PL / V8 для SQL и хранимых процедур.

... Возможно, самым важным вкладом на стороне сервера в 2016 году была быстрая и надежная поддержка баз данных для JSON и Javascript: с PostgreSQL 9.1+ (2016-10) вы можете загружать PL / V8 (и такие диалекты, как Coffeshop) с помощью простых CREATE EXTENSION команда; с PostgreSQL 9.5+ (2016-10) наиболее важным, полный ортогональный набор Функции и операторы JSON и JSONb.

Итак, на самом деле существует быстрый, отказоустойчивый и надежный унифицированный стек разработки JavaScript.