Читая комментарии к сообщению в блоге Крейга Баклера, сможет ли когда-нибудь завоевать популярность серверный JavaScript? подтверждает то, что Дуглас Крокфорд написал о JavaScript : это был типичный выпуск. Многие люди могут видеть это только в контексте браузера. Большая часть этого связана с путаницей между языком и DOM браузера. Интерфейс DOM — это место, где большинство программистов JavaScript проводят свое время.
Это также подтверждает еще один факт: многие люди ненавидят JavaScript. Однако я уверен — для программистов, которые ценят более тонкие функции JavaScript и могут принять его более грубые части, — что новости движутся на стороне сервера, неудивительно и, вероятно, приветствуется. И я уверен, что это только начало.
Так где же сейчас можно найти JavaScript на стороне сервера?
Jaxer — это фреймворк и сервер JavaScript для веб-приложений. API-интерфейс на стороне сервера, как и любой другой, включает доступ к базам данных, файлам и сетевым сокетам. Размыта граница между серверными и клиентскими сценариями; например, серверные сценарии могут манипулировать DOM веб-страницы.
Скрипты встраивают стиль ASP в ваш HTML:
<p id="msg"></p> <script runat="server"> var nme = document.createTextNode( "Hello my name is Jaxer."); var para = document.getElementById("name"); para.appendChild(nme); </script> runat может быть как server , both и server-proxy или server-proxy . Если установлено на server , скрипт проверяется перед отправкой страницы в браузер. Если не установлено, сценарии выполняются на стороне клиента. Если установлено значение « server-proxy , то функции можно вызывать из клиентского скрипта по имени, но через Ajax проксируют на серверный эквивалент.
Helma — это еще один фреймворк для веб-приложений, использующий JavaScript для сценариев на стороне сервера. Helma имеет систему шаблонов, что означает, что она избегает смешивания кода JavaScript на стороне сервера и на стороне клиента. Вместо этого вы пишете действия в JavaScript, которые затем визуализируют шаблоны, вводя данные в процесс рендеринга. Каждый HTTP-запрос запускает настроенное действие.
Вот пример шаблона или скина на языке жаргона Helma с именем ‘hello’:
<p>Hello, my name is <% response.name %>.</p>
И действие, которое делает это:
res.data.name = 'Helma'; this.renderSkin('hello');
Существует множество примеров серверного JavaScript, как показано в разделе « Серверный JavaScript» в Википедии. Почти все они используют Rhino или SpiderMonkey для выполнения JavaScript.
Является ли JavaScript на стороне сервера серьезным предложением?
Хотя реализации JavaScript на сервере появляются, это далеко от повсеместного распространения PHP-хостинга. Справедливый комментарий заключается в том, что серверный JavaScript в настоящее время привязан к инфраструктуре, в которой он находится. Таким образом, JavaScript, написанный в одной среде, вряд ли будет переносимым из-за отсутствия стандартного API. Это необходимость, которая уже была определена, и поэтому работа группы ServerJS началась. Такие проекты, как jslibs, также направлены на решение этой проблемы.
Отсутствие услуг хостинга также является проблемой, хотя Jaxer и AppJet предоставляют свои собственные хостинговые платформы. Приложения Helma могут быть размещены с сервисами, которые поддерживают Java. Как только проблема со стандартной библиотекой будет решена, я уверен, что мы увидим улучшение поддержки хостинга — вы будете запрашивать у вашего хоста поддержку «mod_javascript».
Наконец, JavaScript имеет более чем достаточно грубых деталей, чтобы заставить многих людей нервничать по поводу его использования на стороне сервера. Я серьезно думаю, что ECMAScript 3.1 и ECMAScript Harmony в конечном итоге это покроют.
Мы видим поддержку JavaScript на многих платформах, как веб-, так и настольных, локальных и серверных. Будет ли серверная поддержка JavaScript, предлагаемая в пакетах хостинга, такой же распространенной, как PHP? Я думаю, что это неизбежно.