¿Cuándo y cómo se usa JavaScript del lado del servidor? [cerrado]

De vez en cuando busco ayuda de JavaScript y me encuentro con el término "JavaScript del lado del servidor". ¿Cuándo usarías JavaScript del lado del servidor? ¿Y cómo?

Mis experiencias con JavaScript han estado en el navegador. ¿Existe una versión compilada de JS?

Está el proyecto Phobos , que es un marco de JavaScript del lado del servidor.

En el pasado, el servidor web Netscape también ofrecía un script java del lado del servidor.

En ambos casos, JavaScript se usa como usaría cualquier idioma en el servidor. Normalmente para manejar solicitudes HTTP y generar contenido.

Rhino , que es el sistema JavaScript de Mozilla para Java, compila JavaScript en códigos de bytes de Java, que la JVM puede elegir como JIT. Otros sistemas utilizan otros medios para ejecutar scripts java, incluso hasta el punto de que algunos compilan JIT sus códigos internos de scripts java.

Preveo que habrá más y más JavaScript en el servidor. Cuando escribe aplicaciones "gruesas" en JavaScript en el cliente, es posible que también pueda escribir su lógica en JavaScript en el servidor para no tener que dar saltos cognitivos de un idioma a otro. Los entornos serán diferentes, pero gran parte de su código y conocimientos se podrán compartir.

Finalmente, JavaScript es probablemente el lenguaje singular que tiene más dinero apuntando hacia él en este momento en términos de implementaciones. De Apple, Mozilla, Google e incluso Microsoft, así como los esfuerzos para convertirlo en un lenguaje aún más avanzado (es decir, básicamente un esquema con sintaxis Algol sin macros).

La mayoría de esas implementaciones están enterradas en el navegador, pero eso no quiere decir que tampoco haya valor en el lado del servidor.

Las herramientas son el lugar más grande donde falta JavaScript, especialmente en el lado del servidor, pero si considera algo como Phobos, donde puede depurar el JavaScript del lado del servidor en el IDE, es un gran avance.

Personalmente, estoy lanzando JavaScript en mis aplicaciones como pintura blanca. Ofrece extensibilidad económica por muy poco costo y es un gran facilitador.

No es AJAX, a menos que las personas estén usando el término de manera incorrecta. Como su nombre indica, SSJS es JavaScript que se ejecuta en el servidor, interpretado por un motor JavaScript independiente (es decir, independiente del navegador), como SpiderMonkey.

¿Por qué molestarse? Bueno, un área en la que actualmente lo veo subutilizado es en la validación de datos. Con SSJS, escribe un fragmento de código que luego se usa tanto en el servidor como en el cliente. Por lo tanto, obtiene comentarios inmediatos del usuario del JS del lado del cliente que coincidirá automáticamente con la verificación de datos que tiene lugar en el servidor.

NOTICIAS 2013

Node.js (ver también el artículo de Wikipedia ) es un éxito, ¡y su comunidad está creciendo !

MongoDB (en el servidor), Chrome (en el cliente) y Node.js (en el servidor) utilizan el motor JavaScript V8 .

PD: puede usar solo un idioma, Javascript, para todos los módulos de su proyecto: API de cliente, interfaz de cliente, "centro de servidor" y base de datos del servidor (por ejemplo, procedimientos almacenados). ¡Todos los programadores "codifican una vez"!

La principal distinción entre los idiomas "Server-Javascript" y "Client-Javascript" se explica en http://www.commonJS.org/ , la biblioteca estándar para Server-Javascript .

CommonJS existe desde 2009, y en la actualidad (2013) es un maduro estándar , utilizado tanto, MongoDB y Node.js .

NOTA HISTÓRICA: ¡el paquete abierto "cliente + servidor Javascript" activo más antiguo (incluido el uso de PostgreSQL) está vivo!
Lanzado en 2001 y en continuo desarrollo desde entonces, Whitebeam es una tecnología madura de Javascript (y DOM). La última actualización fue en enero de 2016.

NOTICIAS 2016

El motor Node.js continúa como un tiempo de ejecución construido en el JavaScript V8 de Chrome... ¡Y ahora es, de hecho, un éxito consolidado! Las últimas versiones son v7.0 y v6.8 LTS .

JSON , como formato de intercambio de datos, ha tenido un interés creciente y continuo en los últimos años, habiendo superado en 2016 el interés en XML (ver también en el contexto de Ciencia, donde fue superado en 2011 ). Como formato nativo de Javascript, también es un buen indicador de tendencias lingüísticas.

El motor V8 (más rápido) también es el más utilizado, desde 2014: en el cliente más popular ( Chrome en equipos de escritorio y WebView en Android) y popular en servidores : Node.js como tiempo de ejecución y PostgreSQL con PL / V8 para SQL y procedimientos almacenados. .

... Quizás la contribución más importante del lado del servidor en 2016 fue un soporte de base de datos rápido y robusto para JSON y Javascript: con PostgreSQL 9.1+ (2016-10) puede cargar PL / V8 (y dialectos como Coffeshop) de manera simple CREATE EXTENSIONmando; con PostgreSQL 9.5+ (2016-10) el más importante, un conjunto ortogonal completo de funciones y operadores JSON y JSONb .

Entonces, de hecho, existe una pila de desarrollo de JavaScript unificada , rápida, resistente y confiable .

ASP clásico pudo usar JavaScript en el servidor, aunque la mayoría de la gente usó VBScript.

Un uso convincente de JavaScript en el servidor es como complemento de la validación de datos del lado del cliente. Por ejemplo, puede utilizar la misma biblioteca de validación de JavaScript en el cliente y en el servidor. Esto asegura que está utilizando la misma lógica en el cliente que en el servidor, pero (potencialmente) evitando un viaje de ida y vuelta innecesario mediante la validación previa en el lado del cliente.

Wikipedia enumera una serie de implementaciones de JavaScript del lado del servidor aquí .

Podría referirse al uso de javascript para publicar mensajes en un servidor web sin volver a cargar la página: en otras palabras, AJAX.

Pero lo más probable es que crea que significa algo como Aptana / Jaxer (o, hoy, Node.js), que usa javascript para un lenguaje del lado del servidor. En este caso, recuerde que javascript es solo un lenguaje: el DOM utilizado en un navegador web es una especie de API. Los motores de JavaScript del lado del servidor proporcionarían sus propios objetos API, orientados a tareas del lado del servidor como el acceso a la base de datos y al sistema de archivos.

El JavaScript del lado del servidor es una idea interesante debido al problema de validación del lado del cliente: desea realizar la validación del lado del cliente para evitar enviar solicitudes innecesarias a su servidor. Esto mejora el rendimiento del servidor y reduce la latencia en el cliente. Pero debe realizar la validación del lado del servidor porque no puede confiar en el cliente. Esto da como resultado una gran cantidad de código duplicado entre el cliente y el servidor.

La teoría es que si los idiomas de su cliente y servidor coinciden, ya no necesitará dos implementaciones de la misma lógica. En la práctica, no funciona tan bien, porque las vistas del cliente y del servidor de una solicitud de página son muy diferentes y porque usted no controla el motor javascript que utiliza el cliente.

Realmente depende de si está hablando de ASP.NET o ASP clásico. Si está utilizando ASP.NET, no hay muchas buenas razones para utilizar Javascript.

ASP Classic es un caso diferente. Puede usar Javascript en el lado del servidor en ASP de la misma manera que usaría VBScript. Puede acceder a los objetos Aplicación, Servidor, Solicitud y Respuesta de la misma manera que a través de VBScript.

Puede haber beneficios reales al usar Javascript en el lado del servidor en ASP en lugar de VBScript. Significa que puede compartir código entre el código del navegador y el código del servidor. También significa que sus desarrolladores no necesitan trabajar con dos lenguajes diferentes.

Sin embargo, hay algunas desventajas del Javascript del lado del servidor en ASP. En primer lugar, no parece ser tan rápido como VBScript en el lado del servidor en la concatenación de cadenas. Tampoco es tan bueno como hacer llamadas a objetos COM como VBScript (solo puede recuperar datos de llamadas COM a través del valor de retorno, en lugar de a través de los parámetros out / byref).

Es posible que desee tener alguna funcionalidad tanto en el navegador como en el servidor para tener exactamente la misma implementación.

Un ejemplo sería un renderizador para una sintaxis wiki, que ejecuta en el navegador para el editor WYSIWYG y en el servidor para renderizar la página resultante. De esta forma, sabrá que ambos resultados renderizados serán exactamente iguales en ambos casos.

Aparentemente, Rhino puede compilar JavaScript en clases de Java.

Tradicionalmente, Javascript se ejecuta en el modelo de objetos de documento. Pero, ¿qué pasa si trabaja para una tienda de Java y le gustaría un motor de scripting alrededor de su modelo de objetos personalizados? Ahí es cuando entra Javascript del lado del servidor.

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

Recuerdo con cocoon (el marco MVC Java / XML / Javascript de Apache) solía usar Javascript del lado del servidor ya que había algo (creo que cforms) que necesitaba estar escrito en Javascript y se estaba ejecutando en el servidor a pesar de que te creo podría escribirlo en Java.

Usamos Rhyno en ese momento, verifique: http://peter.michaux.ca/articles/server-side-javascript-with-rhino-and-jetty

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

Vea cómo Steve Yegge usa JavaScript del lado del servidor con Rhino y por qué. Tiene un montón de cosas sobre cómo siente que JavaScript está en auge.

Sí, acabo de leer sobre SSJS en un blog de un tipo llamado John Resig .

Describe un motor llamado Jaxer, que dice que es "Imagine arrancar la parte de renderizado visual de Firefox y reemplazarla con un enlace a Apache, en términos generales, eso es lo que es Jaxer".

Para cualquiera que conozca ASP.NET El HTML parece familiar

<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>

Tenga en cuenta el runat = "sever" y runat = "both"

Con ASP puede utilizar JavaScript del lado del servidor de varias formas. La forma en que lo uso más comúnmente es tener el mismo código ejecutándose en el cliente y en el servidor para la validación .

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 comienza y termina de la forma en que lo hace para permitir la inclusión del mismo archivo.