tutorial - Server Side Javascript: ¿Por qué?

javascript tutorial

Question

¿Es frecuente el uso de javascript del lado del servidor? ¿Por qué uno lo usaría en oposición a cualquier otro script del lado del servidor? ¿Hay algún caso de uso específico que lo haga mejor que otros idiomas del lado del servidor?

Además, confundido sobre cómo empezar a experimentar con él, estoy en freeBSD, ¿qué necesitaría instalar para ejecutar el javascript del lado del servidor?

Answer 1

Creo que un uso realmente bueno de Javascript del lado del servidor que no se usa con la suficiente frecuencia es para la validación de datos. Con él, puede escribir un archivo javascript para validar un formulario, verificarlo en el lado del cliente, y luego verificarlo nuevamente en el lado del servidor porque no debemos confiar en nada en el lado del cliente. Te permite mantener tus reglas de validación en SECO. Muy práctico.

Ver también:

• ¿Despegará Javascript del servidor? ¿Qué implementación es la más estable?
• ¿Cuándo y cómo usas el servidor de JavaScript?

Answer 2

Dice así:

Los servidores son caros, pero los usuarios le darán tiempo de procesamiento en sus navegadores de forma gratuita. Por lo tanto, el código del lado del servidor es relativamente caro en comparación con el código del lado del cliente en cualquier sitio lo suficientemente grande como para necesitar ejecutar más de un servidor. Sin embargo, hay algunas cosas que no puede dejarle al cliente, como la validación y recuperación de datos. Le gustaría hacerlo en el cliente, porque significa tiempos de respuesta más rápidos para los usuarios y menos infraestructura de servidor para usted mismo, pero las preocupaciones de seguridad y accesibilidad significan que se requiere el código del lado del servidor.

Lo que normalmente sucede es que haces ambas cosas. Usted escribe la lógica del lado del servidor porque tiene que hacerlo, pero también escribe la misma lógica en javascript con la esperanza de proporcionar respuestas más rápidas al usuario y ahorrarles un poco más de trabajo a los servidores en algunas situaciones. Esto es especialmente efectivo para el código de validación.

Ya que todos somos (en su mayoría) programadores aquí, debemos detectar inmediatamente el nuevo problema. No solo el trabajo adicional involucrado en el desarrollo de dos conjuntos de la misma lógica, sino también el trabajo involucrado en su mantenimiento, los errores inevitables resultantes de las plataformas no coinciden bien, y los errores introducidos a medida que las implementaciones se separan con el tiempo.

Ingrese javascript del lado del servidor. La idea es que puede escribir el código una vez, por lo que el mismo código se ejecuta tanto en el servidor como en el cliente. Esto parece resolver la mayor parte del problema: obtiene el conjunto completo de la lógica del servidor y del cliente al mismo tiempo, no hay desviaciones ni un doble mantenimiento. También es bueno cuando sus desarrolladores solo necesitan saber un idioma para el trabajo del servidor y del cliente.

Desafortunadamente, en el mundo real no funciona tan bien. El problema es cuádruple:

1. La vista del servidor de una página sigue siendo muy diferente de la vista del cliente de una página. El servidor debe poder hacer cosas como hablar directamente a una base de datos que simplemente no se debe hacer desde el navegador. El navegador debe hacer cosas como manipular un DOM que no coincida con el servidor.
2. No controla el motor javascript del cliente, lo que significa que todavía habrá importantes diferencias de idioma entre su código de servidor y su código de cliente.
3. La base de datos suele ser un cuello de botella más grande que el servidor web, por lo que los ahorros son mínimos.
4. Si bien casi todo el mundo sabe un poco de javascript, no hay muchos desarrolladores que realmente lo conozcan y lo entiendan bien .

Estos no son problemas técnicos completamente irrefutables: restringe el lenguaje compatible con el servidor a un subconjunto de javascript que está bien soportado en la mayoría de los navegadores, proporciona un IDE que conoce este subconjunto y las extensiones del lado del servidor, establece algunas reglas sobre la estructura de la página para minimizar los problemas de DOM, y proporcionar algunos javascript de placa de caldera para incluirlos en el cliente y hacer que la plataforma sea un poco más agradable de usar. El resultado es algo como Aptana Studio / Jaxer, o más recientemente Node.js, que puede ser bastante bueno.

Pero no es perfecto. En mi opinión, hay demasiados escollos y pocos problemas de compatibilidad para que esto brille. En última instancia, los servidores adicionales siguen siendo baratos en comparación con el tiempo del desarrollador, y la mayoría de los programadores pueden ser mucho más productivos utilizando algo que no sea javascript.

Lo que realmente me gustaría ver es un javascript parcial del lado del servidor. Cuando se solicita una página o se envía un formulario, la plataforma del servidor solicita la validación en javascript, tal vez como un complemento del servidor web que es completamente independiente del resto, pero la respuesta se crea utilizando la plataforma de su elección.

Answer 3

Javascript es solo un idioma Debido a que es solo un idioma, puede usarlo en cualquier lugar que desee ... en su navegador, en el servidor, incrustado en otras aplicaciones, aplicaciones independientes, etc.

Dicho esto, no sé si hay muchos desarrollos nuevos en desarrollo con "Server-Side Javascript"

Answer 4

Javascript es un lenguaje perfectamente bueno con una base de estilo de prototipo auto / esquema y una sintaxis de estilo C. Hay algunos problemas, vea Javascript las partes buenas, pero en general es un lenguaje de primera calidad. El problema es que la mayoría de los programadores de javascript son programadores terribles porque es muy accesible para comenzar.

Un equipo de Google creó Rhino on Rails, que es un marco MVC como Ruby on Rails, que está escrito en javascript y se ejecuta en Rhino, un intérprete de javascript para Java VM. En este caso, tenían el requisito de usar la máquina virtual Java, pero querían obtener un lenguaje que fuera rápido (javascript es rápido), admitiera la escritura de pato y fuera flexible.

Otro ejemplo es algo como CouchDB, una base de datos orientada a documentos que utiliza json como formato de transporte y javascript como idioma de consulta e índice. Querían que la base de datos fuera lo más nativa posible de la web.

Javascript es bueno para la manipulación de cadenas y dom (xml), el uso de espacios aislados, la creación de redes, la ampliación de sí mismo, etc. Este tipo de funciones es lo que hace a menudo al desarrollar aplicaciones web.

Dicho todo esto, en realidad no desarrollo javascript del lado del servidor. No es una mala idea, pero definitivamente menos común.

Answer 5

Usamos javascript en el cliente porque está ahí, no porque de una lista de idiomas fue nuestra elección. No lo elegiría para ninguna tarea en el servidor.

Puede ejecutar cualquier idioma que desee en el servidor, de hecho, tantos como desee.

javascript es confiable y fácil de usar, pero es demasiado laborioso para tareas comunes en el servidor.