bootstrap - ¿Pros y contras de la implementación de Javascript del servidor?

option value html

Question

Acabo de comenzar a experimentar con el motor javascript del lado del servidor Aptana Jaxer para mi próximo proyecto. Y tengo algunas preguntas sobre eso

• Al usar el lado del servidor JS, podemos implementar la aplicación web completa sin usar ningún idioma del lado del servidor (como C #, java, etc.). O el lado del servidor JS se encuentra entre el servidor web y otra pila de idiomas.

• ¿Es realmente un mejor enfoque?

• ¿Cuáles son las ventajas y desventajas?

• ¿Cómo funciona esto bien en términos de rendimiento?

• ¿hay alguna implementación en tiempo real (sitios web públicos) que solo use el lado del servidor JS (no otros idiomas)?

• ¿Cuáles son las alternativas disponibles sobre Aptana jaxer (código abierto)?

• ¿Qué tan bien podemos implementar & maitain db transacciones? ¿Podemos hacer eso en el servidor JS ..?

• ¿Es posible desarrollar servicios RESTFul y SOAP en el servidor JS ...?

Sé que esto es demasiado largo (y preguntas ingenuas). Solo espero que alguien ya se haya topado con todo esto mientras implementa JS del lado del servidor.

EDITAR:

Según los comentarios de Matthew y Ken, he agregado algo de claridad a la pregunta: ¿es realmente un mejor enfoque?

esto es lo que pretendo preguntar ..

¿Es realmente un enfoque mejor que usar lenguajes del lado del servidor (supongamos que c #), cómo podemos comparar esto con la implementación de c # de un sitio web (rendimiento, características del idioma)? ¿Y cuál es un mejor enfoque, usando JS solo en el lado del servidor o JS en la capa intermedia entre la pila de otro idioma y el servidor web?

Answer 1

Como prefacio, uso SSJS en mi trabajo diario. Ejecutamos un sitio web razonablemente grande (en términos de complejidad y de páginas vistas) en SpiderMonkey. Agregaré a la excelente respuesta de Matthew donde tengo experiencia.

¿Es realmente un enfoque mejor que usar lenguajes del lado del servidor (suponga que c #)

"Mejor" realmente depende de lo que quieras hacer con él. JavaScript en sí tiene algunas características geniales, así como bastante horribles. Si realmente desea desarrollar JS (cliente o servidor), no puedo recomendar lo suficiente como para ver la presentación de Douglas Crockford, Javascript: The Good Parts si aún no lo ha hecho. Ha hecho un trabajo fantástico clasificando el crucero, y es un excelente orador para arrancar.

Lo más importante que me parece que el mundo SSJS carece en este momento es la madurez. No estoy familiarizado con C #, pero JavaScript no tiene una biblioteca estándar madura ni medios de distribución de paquetes maduros. Para mí eso es una gran pieza del rompecabezas.

Dicho esto, mantén tus ojos en el grupo CommonJS . Están trabajando para definir esas cosas exactas. Además, la documentación de Jaxer Api enumera las incorporaciones que se incluyen con ese marco.

¿Cómo funciona esto bien en términos de rendimiento?

JavaScript en sí mismo no es un lenguaje lento, ni tampoco es particularmente rápido. Como señaló Matthew, debería ser comparable a cualquier otro lenguaje de scripting que utilizarías. La guerra entre los proveedores de navegadores para ver quién puede construir el navegador más rápido también beneficiará a la multitud de SSJS.

La recolección de basura generacional que el equipo V8 incorpora en su motor es un gran ejemplo de esto. Detener la máquina virtual para liberar los objetos inalcanzables del montón y recuperar su memoria puede ser algo lento, pero lo han mitigado al reducir la cantidad de objetos que deben inspeccionarse cuando se ejecuta el recolector de basura.

¿Qué tan bien podemos implementar y mantener transacciones de db? ¿Podemos hacer eso en el servidor JS ..?

Jaxer parece tener API de bases de datos MySQL y SQLite. Como mencionó Matthew, si usas Rhino, puedes usar la API de JDBC.

Editar : Enlaces añadidos

Answer 2

Soy el desarrollador de Myna (www.mynajs.org), una plataforma JS de servidor de código abierto basada en Rhino y Java. Abordaré los problemas relacionados con Myna, pero muchos de estos puntos se aplican a JS del lado del servidor en general:

Al usar el lado del servidor JS, podemos implementar la aplicación web completa sin usar ningún idioma del lado del servidor (como C #, java, etc.). O el lado del servidor JS se encuentra entre el servidor web y otra pila de idiomas.

En Myna es posible escribir toda tu aplicación en JS. Myna ya incluye API para acceso a bases de datos, mapeo relacional de objetos, criptografía, OpenID, etc.

¿Es realmente un mejor enfoque que c # / Java?

Con un servidor basado en Rhino es trivial desplegar Java cuando sea necesario. Puede instalar fácilmente bibliotecas de Java de código abierto / comercial / codificadas a mano y luego crearlas desde JS. Esto significa que obtiene el rápido desarrollo de JS pero mantiene las ventajas de la plataforma Java

¿Cuáles son las ventajas y desventajas?

pros:

• Desarrollo rápido : en Myna solo creas archivos en webroot con una extensión .sjs. Esto significa que puede crear un ciclo de navegador editar-guardar-actualizar que es muy rápido para el código de depuración / retoque.

• Fácil JSON : tener soporte para JS en el lado del servidor significa mover estructuras complejas es muy fácil

• Código compartido : si necesita realizar la misma función tanto en el servidor como en el navegador, puede usar el mismo código

• ORM dinámico : los lenguajes compilados tipificados estáticamente hacen que sea difícil alterar los objetos en tiempo de ejecución. Esto generalmente significa que el ORM tiene que ser definido por adelantado. En Myna, construir ORM es tan simple como

  var manager =new Myna.DataManager("DataSource name").getManager("table name");

  Obtiene un objeto que puede realizar todas las operaciones CRUD básicas sin definir nunca explícitamente las tablas DB. Como otro ejemplo, puede insertar una fila con todos los valores coincidentes de una publicación de formulario:

  manager.create($req.data);

• Programación funcional : si ha comenzado a jugar con las funciones avanzadas de JavaScript, apreciará lo útiles que son en el lado del servidor. Debido al entorno coherente del lado del servidor, es seguro utilizar funciones avanzadas como Array Extras , generadores e iteradores , tareas de desestructuración y E4X

contras:

• Herramientas : los lenguajes tipificados estáticamente como C # y Java tienen excelentes herramientas de desarrollo e IDE. Los lenguajes dinámicos como JS simplemente no tienen el soporte de herramientas todavía. Personalmente, considero que la gran reducción en el código repetitivo y en el casting de tipo exigente lo compensa, pero esto sigue siendo una gran desventaja si ha estado haciendo mucho desarrollo en IDE. Si actualmente está utilizando un IDE, considere usar jedit para lenguajes dinámicos

• Madurez / Estandarización : Serverside JS sigue siendo un nuevo paradigma, y ​​hay muchos jugadores y no hay ganadores claros. ECMA no tiene ningún estándar para los servidores JS. Como se mencionó en la respuesta de Brandon, el grupo CommonJS está intentando formar un estándar JS del lado del servidor y Myna tiene soporte experimental de CommonJS a través de Narwhal

¿Cómo funciona esto bien en términos de rendimiento?

En velocidad computacional sin formato, pocos lenguajes dinámicos pueden coincidir con lenguajes compilados tipificados estáticamente como C # y Java. Habiendo dicho eso, realmente no importa. Cualquier parte de su aplicación que sea computacionalmente intensiva debería estar escrita en Java, o usar una biblioteca de Java existente. No sugeriría que alguien escriba una base de datos en JS, por ejemplo. Para aplicaciones web del mundo real / servicios SOA, la causa principal de la desaceleración no es la velocidad computacional sin formato, es un código ineficiente, especialmente el acceso a la base de datos. Myna ayuda con esto haciendo cosas como:

• almacenamiento en caché interno de scripts JS compilados
• Uso interno de declaraciones preparadas en caché para transacciones de base de datos
• Consulta y caché de fragmentos de salida.
• Agrupación de conexiones de base de datos
• Soporte automático de hash ETag
• Herramientas de perfilado
• Carga perezosa de metadatos

¿Qué tan bien podemos implementar y mantener transacciones de db? ¿Podemos hacer eso en el servidor JS ..?

Si se refiere a la transacción como en "un conjunto de sentencias de SQL que pueden revertirse o confirmarse", entonces Myna aún no admite transacciones. Estoy abierto a implementar esto si hay suficiente interés.

Si te refieres a "¿qué tipo de soporte de base de datos tiene JS del lado del servidor?" entonces la respuesta depende de la plataforma. La plataforma Myna proporciona las siguientes características de base de datos:

• Una aplicación de administración basada en la web donde puede definir "fuentes de datos", es decir, información de conexión de base de datos. A continuación, puede consultar estas fuentes de datos por nombre. Myna incluye controladores JDBC para H2, MySQL, Microsoft SQL Server y Postgresql, pero se puede usar cualquier fuente de datos JDBC u ODBC
• Myna.Database y Myna.Table proporcionan acceso a los metdatos Myna.Table base de datos, así como la creación y modificación de tablas.
• El objeto Query de Myna es compatible con maxRows, paginación, parámetros SQL, controladores de fila personalizados, consulta de consulta, almacenamiento en caché y más
• El objeto DataManager de Myna admite la creación de objetos ORM en tiempo de ejecución

¿Es posible desarrollar servicios RESTFul y SOAP en el servidor JS ...?

El soporte REST y SOAP son características específicas de la plataforma. El objeto WebService de Myna es compatible con los siguientes protocolos:

• JABÓN
• XML-RPC
• JSON-RPC
• Ext Directo
• JSON-MYNA (un protocolo simple que utiliza publicaciones de forma normal y devuelve JSON. Fácil de usar desde el navegador)

Myna también entiende los métodos de solicitud PUT y DELETE y presenta el acceso al contenido del cuerpo de la solicitud en forma de texto y binario, de modo que es posible manejar estos métodos RESTful de una manera específica de la aplicación.

Depuración

La depuración tradicional de punto de interrupción es un verdadero desafío del servidor. Aunque Rhino admite enlaces de depuración, el uso de estos desde una aplicación web sin estado sería bastante complicado. Personalmente, ni siquiera uso los depuradores de punto de interrupción, incluso cuando están disponibles (por ejemplo, firebug). En su lugar prefiero el registro.

En myna

 Myna.log(type,label,detail)

generará un subproceso de baja prioridad para escribir un mensaje de registro HTML en la base de datos de registro de Myna. Estos registros se pueden buscar a través del Administrador de Myna. Los registros también registran las marcas de tiempo y los milisegundos transcurridos para fines de creación de perfiles. Myna.dump (obj) también se puede utilizar para presentar una representación de tabla HTML de cualquier objeto. Myna también registra todas las excepciones no manejadas con seguimientos de pila, contexto de código fuente y detalles de solicitud. Entre dump (), log () y el controlador de errores predeterminado, no tengo muchas dificultades para depurar el código Myna

Answer 3

Al usar el lado del servidor JS, podemos implementar la aplicación web completa sin usar ningún idioma del lado del servidor (como C #, java, etc.).

No debería ser necesario escribir código en ningún otro idioma, aunque muchos frameworks de JavaScript del lado del servidor usan el motor Rhino, que le permite llamar a cualquier código Java.

¿Es realmente un mejor enfoque?

No creo que JavaScript (como idioma) sea realmente una opción mejor o peor que los lenguajes tradicionales del lado del servidor. Tiene ventajas (junto con otros lenguajes dinámicos como Ruby y Python) como flexibilidad, creación rápida de prototipos (sin intención de usar el juego de palabras), flexibilidad, etc. Por otra parte, no tiene el soporte de biblioteca que tienen Java y C # o tipografía estática (No voy a entrar en el debate sobre cuál es mejor aquí; me gustan los dos por diferentes motivos).

Si desea lo mejor de ambos, puede utilizar JavaScript como lenguaje de scripting, integrado en su aplicación. Rhino para Java y JScript.NET facilitan la manipulación de objetos "nativos" en JavaScript. Podría, por ejemplo, escribir sus clases de dominio en Java o C #, y escribirlas con JavaScript donde desee más flexibilidad. Sin embargo, si se siente lo suficientemente cómodo con JavaScript, escribir en un solo idioma puede ser más sencillo.

Nunca he escrito una aplicación "real" del lado del servidor con JavaScript, por lo que realmente no puedo emitir un juicio acerca de si es mejor o peor que .NET (nunca he usado JScript.NET). Sin embargo, he jugado con algunos marcos para divertirme y actualmente estoy reescribiendo mi sitio personal usando Helma NG. Hasta ahora ha sido una buena experiencia (mucho mejor que PHP, que nunca me ha gustado).

¿Cuáles son las ventajas y desventajas?

Ventajas:

• Solo se necesita un idioma para la programación del lado del servidor y del lado del cliente.
• Posibilidad de código compartido, para cosas como validación de formularios. Jaxer le permite ejecutar scripts en el cliente, el servidor o ambos.
• Puedes programar en JavaScript (asumiendo que te gusta el idioma).

Desventajas:

• Muchos marcos son experimentales / no muy maduros.
• Tienes que programar en JavaScript (asumiendo que no te gusta el idioma).

¿Cómo funciona esto bien en términos de rendimiento?

El rendimiento debe ser aproximadamente comparable a otros lenguajes de script.

¿hay alguna implementación en tiempo real (sitios web públicos) que solo use el lado del servidor JS (no otros idiomas)?

No sé de ningún sitio web grande que use JavaScript, pero puede haber algunos.

¿Cuáles son las alternativas disponibles sobre Aptana jaxer (código abierto)?

Wikipedia tiene una gran lista de opciones , pero no tiene mucha información útil. Hay muchas opciones con una amplia gama en madurez y tamaño.

Aquí hay algunos con los que estoy familiarizado (en diversos grados)

• Helma - Framework basado en Rhino (Java) con registro activo.
• Helma NG - Helma Next Generation (reescritura experimental, en desarrollo activo).
• Phobos - Tiene un buen soporte en NetBeans .
• v8cgi : pequeño y simple, utiliza el motor V8 de Google, probablemente todavía no esté listo para la producción.
• Jaxer : se ejecuta en Spidermonkey con una implementación DOM, por lo que puede manipular la página con marcos como jQuery o Prototype. Tiene buen soporte IDE en Aptana Studio.

¿Qué tan bien podemos implementar y mantener transacciones de db? ¿Podemos hacer eso en el servidor JS ..?

Los marcos basados ​​en Rhino le permiten usar clases de Java, por lo que tiene soporte completo de JDBC. No he usado las bibliotecas de la base de datos de Jaxer, así que no sé nada acerca de sus capacidades.

¿Es posible desarrollar servicios RESTFul y SOAP en el servidor JS ...?

Las API RESTful no deberían ser ningún problema. No conozco ningún soporte específico para SOAP, pero debería ser posible .