paginas - javascript pdf
¿Cuándo y cómo se usa JavaScript del lado del servidor? (12)
Ocasionalmente, busco algo de ayuda de JavaScript y me aparece el término "JavaScript del lado del servidor". ¿Cuándo usarías JavaScript en el servidor? ¿Y cómo?
Mis experiencias de JavaScript han estado en el navegador. ¿Hay una versión compilada de JS?
Classic ASP podía usar JavaScript en el servidor, aunque la mayoría de las personas usaba VBScript.
Un uso convincente de JavaScript en el servidor es un complemento de la validación de datos del lado del cliente. Por ejemplo, puede usar la misma biblioteca de validación de JavaScript en el cliente y en el servidor. Esto asegura que estás usando la misma lógica en el cliente que en el servidor, pero (potencialmente) evitando un viaje de ida y vuelta innecesario al validar previamente en el lado del cliente.
Wikipedia enumera una serie de implementaciones de JavaScript del lado del servidor aquí .
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 procesador para una sintaxis de wiki, que ejecuta en el navegador para el editor WYSIWYG y en el servidor para representar la página resultante. De esta forma sabrá que ambos resultados rendidos serán exactamente iguales en ambos casos.
Aparentemente Rhino puede compilar JavaScript a las clases de Java.
No es AJAX, a menos que la gente use el término incorrectamente. Como su nombre indica, SSJS es JavaScript que se ejecuta en el servidor, interpretado por un motor de JavaScript independiente (es decir, independiente del navegador), como SpiderMonkey.
¿Por qué molestarse? Bueno, un área en la que actualmente la veo subutilizada es en la validación de datos. Con SSJS, escribe un código que luego se usa tanto en el servidor como en el cliente. De este modo, obtiene comentarios inmediatos de los usuarios desde el JS del lado del cliente que coincidirán automáticamente con la verificación de datos que tiene lugar en el servidor.
Realmente depende si está hablando de ASP.NET o ASP clásico. Si está utilizando ASP.NET, no hay muchas buenas razones para usar Javascript.
ASP Classic es un caso diferente. Puede usar Javascript en el lado del servidor en ASP de la misma forma que usaría VBScript. Puede acceder a los objetos Application, Server, Request y Response 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 usar VBScript. Significa que puede compartir código entre el código del navegador y el código del servidor. También significa que tus desarrolladores no necesitan lidiar con dos idiomas diferentes.
Sin embargo, hay algunos inconvenientes en el lado del servidor de Javascript 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 realizar llamadas a objetos COM como VBScript (solo puede recuperar datos de llamadas COM a través del valor devuelto, en lugar de a través de los parámetros out / byref).
Recuerdo que con Cocoon (framework Java / XML / Javascript MVC de Apache) solía usar el Javascript del lado del servidor ya que había algo (creo que cforms) que debía escribirse en Javascript y se estaba ejecutando en el servidor aunque yo te crea podría escribirlo en Java.
Usamos Rhyno en ese momento, por favor verifique: http://peter.michaux.ca/articles/server-side-javascript-with-rhino-and-jetty
Tradicionalmente, Javascript corre alrededor del Modelo de Objetos de Documento. Pero, ¿y si trabajas para una tienda de Java y quieres un motor de scripts alrededor de tu modelo de objetos personalizado? Entonces es cuando entra el Javascript del lado del servidor.
http://steve-yegge.blogspot.com/2007/06/rhino-on-rails.html
Mira cómo Steve Yegge está usando JavaScript del lado del servidor con Rhino y por qué. Él tiene un montón de cosas sobre cómo siente que JavaScript está arriba y que viene.
Está el proyecto Phobos , que es un marco de JavaScript del lado del servidor.
Back In The Day, el servidor web de Netscape también ofrecía un script java en el servidor.
En ambos casos, JavaScript se usa tal como lo haría con cualquier idioma en el servidor. Típicamente para manejar solicitudes HTTP y generar contenido.
Rhino , que es el sistema de JavaScript de Mozilla para Java, compila JavaScript en códigos de bytes de Java, que la JVM puede elegir JIT. Otros sistemas usan otros medios para ejecutar el script java, incluso hasta el punto de que algunos son JIT que compilan sus códigos internos del script java.
Preveo que habrá más y más JavaScript en el servidor. Cuando escribe aplicaciones "densas" en JavaScript en el cliente, entonces también puede escribir su lógica en JavaScript en el servidor para no tener que hacer saltos cognitivos de un idioma a otro. Los entornos serán diferentes, pero gran parte de tu código y conocimiento serán compartibles.
Finalmente, JavaScript es probablemente el lenguaje singular que tiene más dinero apuntando en este momento en términos de implementaciones. Desde 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 de Algol sin macros).
La mayoría de esas implementaciones están ocultas en el navegador, pero eso no quiere decir que tampoco haya ningún 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 consideramos algo como Phobos, donde puede depurar su 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.
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 es más probable que crea que significa algo como Aptana / Jaxer (o, en la actualidad, Node.js), que usa javascript para un lenguaje de servidor. En este caso, recuerde que javascript es solo un idioma: el DOM usado en un navegador web es un tipo de API. Los motores javascript del lado del servidor proporcionarían sus propios objetos API, orientados a tareas del lado del servidor, como la base de datos y el acceso al sistema de archivos.
La javascript del lado del servidor es una idea interesante debido al problema de validación del lado del cliente: desea hacer 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 hacer 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 de cliente y servidor de una solicitud de página son muy diferentes y porque no controlas el motor de JavaScript utilizado por el cliente.
Con ASP puede usar JavaScript del lado del servidor de varias maneras. La forma más común de usarlo 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 inicia y finaliza de la forma en que lo hace para permitir la inclusión del mismo archivo.
Sí, acabo de leer acerca de SSJS en un blog por un tipo llamado John Resig .
Él describe un motor llamado Jaxer, que dice es "Imagínese arrancar la parte visual de renderizado de Firefox y reemplazarlo con un gancho a Apache en su lugar - hablando en términos generales, eso es lo que Jaxer es".
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 que runat = "sever" y runat = "both"
NOTICIAS DE 2013
Node.js (ver también en el artículo de Wikipedia ) es un éxito, ¡y su comunidad está creciendo !
MongoDB (en el servidor), Chorme (en el cliente) y Node.js (en el servidor) usan el motor de JavaScript V8 .
PD: puede usar solo un idioma, Javascript, para todos sus módulos de proyecto: API de cliente, interfaz de cliente, "concentrador de servidor" y base de datos de servidor (por ejemplo, procedimientos almacenados). ¡Todos los programadores "codificando 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 hoy (2013) es un estándar maduro , utilizado en ambos, MongoDB y Node.js.
NOTA HISTÓRICA: el paquete abierto activo más antiguo "cliente + servidor Javascript" (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 DE 2016
El motor Node.js continúa como un tiempo de ejecución basado en JavaScript V8 de Chrome ... ¡Y ahora es, de hecho, un éxito consolidado! Los últimos lanzamientos son v7.0 y v6.8 LTS .
JSON , como formato de intercambio de datos, tiene un interés continuamente creciente en los últimos años, habiendo superado en 2016 el interés en XML (véase también en el contexto de la Ciencia, donde se superó en 2011 ). Como el formato nativo de Javascript, también es un buen indicador de tendencia de idioma.
El motor V8 (más rápido) también es el más utilizado desde 2014: en el cliente más popular ( Chrome en computadoras 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 .
... Tal vez 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) a través de simple Comando CREATE EXTENSION ; con PostgreSQL 9.5+ (2016-10) el más importante, un conjunto ortogonal completo de funciones y operadores JSON y JSONb .
Entonces, como un hecho, existe una pila de desarrollo de JavaScript unificada , rápida, resistente y confiable.