Коли і як ви використовуєте JavaScript на стороні сервера? [зачинено]

Іноді я шукаю якусь довідку щодо JavaScript і зустрічаю термін "JavaScript на стороні сервера". Коли ви використовуєте JavaScript на стороні сервера? І як?

Мій досвід роботи з JavaScript був у браузері. Чи існує компільована версія JS?

Існує проект Phobos , який є серверною структурою JavaScript на стороні сервера.

Ще вдень веб-сервер Netscape також пропонував сценарій Java на стороні сервера.

В обох випадках JavaScript використовується так само, як і будь-яка мова на сервері. Зазвичай обробляють HTTP-запити та генерують вміст.

Rhino , яка є системою JavaScript Mozilla для Java, компілює JavaScript у байтові коди Java, які JVM може вибрати для JIT. Інші системи використовують інші засоби для виконання сценарію Java, навіть до того, що деякі JIT компілюють свої внутрішні коди сценарію Java.

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

Нарешті, JavaScript, мабуть, є єдиною мовою, на яку зараз вказує найбільше грошей з точки зору реалізацій. Від Apple, Mozilla, Google і навіть Microsoft, а також зусиль, щоб зробити її ще більш вдосконаленою мовою (тобто, в основному, схема зі синтаксисом Алгола без макросів).

Більшість з цих реалізацій поховані у браузері, але це не означає, що значення на сервері також не має значення.

Інструментарій - це найбільше місце, де не вистачає JavaScript, особливо на стороні сервера, але якщо ви розглядаєте щось на зразок Фобоса, де ви можете налагодити JavaScript на стороні сервера в IDE, це великий прогрес.

Особисто я кидаю JavaScript у своїх додатках, як біла фарба. Він пропонує дешеву розширюваність за дуже невеликі витрати і є чудовим фактором, що сприяє.

Це не AJAX, якщо люди не вживають цей термін неправильно. Як випливає з назви, SSJS - це JavaScript, який працює на сервері, інтерпретується автономним (тобто незалежним від браузера) механізмом JavaScript, як SpiderMonkey.

Навіщо турбуватись? Ну, одна область, яку я зараз бачу недостатньо використаною, - це перевірка даних. За допомогою SSJS ви пишете один шматок коду, який потім використовується як на сервері, так і на клієнті. Таким чином, ви отримуєте негайний відгук користувачів від клієнтського JS, який автоматично збігається з перевіркою даних, що відбувається на сервері.

НОВИНИ 2013 року

Node.js (див. Також у статті Вікіпедії ) - це успіх, і його спільнота зростає !

MongoDB (на сервері), Chrome (на клієнті) та Node.js (на сервері) використовують механізм JavaScript V8 .

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

Основна різниця між мовами "Server-Javascript" та "Client-Javascript" пояснюється на веб- сайті http://www.commonJS.org/ , стандартній бібліотеці для Server-Javascript .

CommonJS існує з 2009 року, і на сьогоднішній день (2013) є зрілим стандартом , використовуваним в обох, MongoDB і Node.js .

ІСТОРИЧНЕ ПРИМІТКА: найстаріший активний відкритий пакет "клієнт + сервер" (включаючи використання PostgreSQL) відкритий!
Випущений в 2001 році і з тих пір постійно розробляється, Whitebeam є зрілою технологією Javascript (і DOM). Останнє оновлення було в січні 2016 року.

НОВИНИ 2016 року

Двигун Node.js продовжує виконуватися, побудований на JavaScript V8 від Chrome... І зараз, насправді, це консолідований успіх! Останні релізи - v7.0 і v6.8 LTS .

JSON , як формат обміну даними, постійно зростає інтерес в останні роки, перевершивши в 2016 році інтерес до XML (див. Також у контексті Science, де перевершив 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 .

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

Одне з переконливих застосувань JavaScript на сервері є доповненням до перевірки даних на стороні клієнта. Наприклад, ви можете використовувати ту саму бібліотеку перевірки JavaScript на клієнті та на сервері. Це гарантує, що ви використовуєте ту саму логіку на клієнті, що і на сервері, але (потенційно) уникаєте непотрібного туди-назад, попередньо перевіривши на стороні клієнта.

Вікіпедія перераховує ряд серверних реалізацій JavaScript тут .

Це може стосуватися використання javascript для розміщення повідомлень на веб-сервері без перезавантаження сторінки: іншими словами, AJAX.

Але швидше за все, я думаю, це означає щось на зразок Aptana / Jaxer (або, сьогодні, Node.js), яка використовує javascript для мови на сервері. У цьому випадку пам’ятайте, що javascript - це лише мова: DOM, що використовується у веб-браузері, є своєрідним API. Серверні двигуни javascript забезпечували б власні об'єкти API, орієнтовані на серверні завдання, такі як доступ до БД та файлової системи.

Серверний javascript - цікава ідея через проблему перевірки на стороні клієнта: ви хочете зробити перевірку на стороні клієнта, щоб уникнути надсилання непотрібних запитів на ваш сервер. Це покращує продуктивність сервера і зменшує затримки клієнта. Але ви повинні зробити перевірку на стороні сервера, оскільки ви не можете довіряти клієнту. Це призводить до великої кількості повторюваних кодів між клієнтом та сервером.

Теорія полягає в тому, що якщо ваші клієнтська та серверна мови збігаються, вам більше не знадобляться дві реалізації однієї логіки. На практиці це працює не так добре, оскільки перегляди клієнта та сервера запиту на сторінку настільки різні і тому, що ви не контролюєте механізм javascript, що використовується клієнтом.

Це насправді залежить, якщо ви говорите про ASP.NET або класичний ASP. Якщо ви використовуєте ASP.NET, не так багато вагомих причин для використання Javascript.

ASP Classic - це інший випадок. Ви можете використовувати Javascript на стороні сервера в ASP так само, як і VBScript. Ви можете отримати доступ до об'єктів Application, Server, Request і Response так само, як через VBScript.

Використання Javascript на стороні сервера в ASP, а не VBScript, може мати реальні переваги. Це означає, що ви можете ділитися кодом між кодом браузера та кодом сервера. Це також означає, що вашим розробникам не потрібно мати справу з двома різними мовами.

У ASP є деякі недоліки Javascript на стороні сервера. По-перше, здається, це не так швидко, як VBScript на стороні сервера при конкатенації рядків. Це також не так добре, як здійснення дзвінків до COM-об'єктів, як VBScript (ви можете отримати дані назад лише через COM-дзвінки через повернене значення, а не за допомогою параметрів out / byref).

Можливо, ви захочете мати певні функції як у браузері, так і на сервері, щоб мати абсолютно однакову реалізацію.

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

Очевидно, Rhino може компілювати JavaScript для класів Java.

Традиційно Javascript працює навколо об'єктної моделі документа. Але що, якщо ви працюєте в магазині Java і хочете використовувати механізм сценаріїв навколо вашої користувацької об’єктної моделі? Саме тоді з’являється серверний Javascript.

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

Я пам’ятаю, з Cocoon (платформа Apache Java / XML / Javascript MVC) я раніше використовував серверний Javascript, оскільки там було щось (я вважаю, cforms), яке потрібно було написати в Javascript і було запущено на сервері, хоча я вірю, що ви міг написати це на Java.

До того часу ми використовували Rhyno, будь ласка, перевірте: http://peter.michaux.ca/articles/server-side-javascript-with-rhino-and-jetty

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

Перевірте, як Стів Єгге використовує серверний JavaScript із Rhino та чому. У нього є купа матеріалів про те, як він відчуває, що JavaScript працює і з’являється.

Так, я щойно прочитав про SSJS у своєму блозі якогось хлопця на ім'я Джон Резіг .

Він описує двигун під назвою 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"

За допомогою 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 починається і закінчується так, як це робить, щоб дозволити включення того самого файлу.