¿Tiene sentido construir aplicaciones web puras basadas en JavaScript (tanto del lado del cliente como del servidor)?

Question

Siempre he considerado JavaScript como una gran adición (o más bien, en los últimos años, como imprescindible) al lado del cliente de cualquier aplicación web. Incluso cuando comencé a usar Mootools, que se aleja un gran paso de la manipulación de DOM, y apunta hacia un marco OO de propósito general, todavía no creía que consideraría usar JavaScript para el desarrollo del lado del servidor. JavaScript pertenece al frente, punto, eso es lo que pensé.

Bueno, parece que according to some damn smart people, estaba equivocado. Por primera vez, el concurso de plataforma de desarrollo web llamado Plat_Form aceptó un equipo que usó JavaScript puro ambos en el servidor y el lado del cliente. Además, esto es lo que los organizadores del concurso tuvieron que decir al respecto:

"Teníamos una única aplicación de un equipo, Upstream Agile, que funcionaría con JavaScript tanto en el servidor como en el lado del cliente. convertirse en una tendencia importante en los próximos años, consideramos que su participación es una visión del futuro y aceptamos este equipo aunque no se han aplicado otros con esta plataforma. "

Así que mi pregunta es: ¿es realmente un concepto viable? crear aplicaciones web de varios niveles puramente en JavaScript? Si es así, ¿cuáles serían las ventajas de usar JavaScript para el frente y el back-end?

EDITAR: El enlace en la respuesta de Vanwaril (Why node.js is totally awesome) revela una discusión interesante en la sección de comentarios que vale la pena leer. Yo, por mi parte, he decidido que aunque usar Javascript en el servidor es un concepto viable y podría tener sus beneficios, definitivamente no comenzaría a construir una aplicación empresarial con esa arquitectura. Por ahora. Puede que sea necesario volver a formular esta pregunta en un año. Puedo imaginar que la respuesta cambiará drásticamente en el futuro cercano.

Answer 1

En primer lugar, echó un vistazo a node.js? JavaScript es uno de los idiomas que, en los últimos años, ha visto avances en el desarrollo, y es probable que siga creciendo.

En términos de funcionalidad, es menos maduro en comparación con otras tecnologías del lado del servidor, pero la comunidad activa no lo está haciendo muy atrás.

Finalmente, dado que es un lenguaje que se ejecuta tanto en la parte frontal como en la parte de atrás, sus implicaciones para los formatos de reutilización de códigos e intercambio de datos hacen que el desarrollo de aplicaciones sea mucho más rápido.

Aún no estoy seguro de que esté listo para la producción (a menos que esté dispuesto a contribuir con la base de código), pero el JavaScript del lado del servidor es una buena opción para experimentar.

Answer 2

Así que mi pregunta es: ¿es realmente un concepto viable, crear aplicaciones web de varios niveles puramente en JavaScript?

Sí, aunque las herramientas son relativamente inmaduras en comparación con muchos otros idiomas.

Si es así, ¿cuáles serían las ventajas de usar JavaScript para el frente y el back-end?

• Sin cambiar de idioma para los desarrolladores
• reutilización de código (por ejemplo, ¿Quieres comprobar que los datos es sano? El mismo código se puede utilizar en el cliente y el servidor).

Answer 3

Estamos construyendo nuestras interfaces CMS & usando http://Helma.at, que actualmente prestan servicio ~ 250 mio páginas/mes. Esto es JavaScript a través de & a través de.

Tenga en cuenta que esto no es el sangrado tecnología de punta, como parece suponer: Helma está en desarrollo desde 1998 y lo usamos en la producción desde 1999.

Answer 4

Ésta no es una idea nueva. De hecho, es tan viejo como para haber estado de moda y luego salió y ahora regresa nuevamente.

Clasic ASP en el servidor de Windows IIS puede usar javascript como el lenguaje de scripting del lado del servidor. puede hablar con el sistema de archivos local y el servidor SQL, etc. cosas muy simples.

Puede escribir fácilmente algún código ASP que devuelva JSON para ser consumido por su script del lado del cliente ajax.

El problema es que MS ha ignorado el ASP clásico y se ha mudado a asp.net (C# o VB.net), así que tenemos que esperar a que la comunidad reinvente javascript del lado del servidor para volver al 2001 .

Answer 5

Unhosted es un "proyecto" que es totalmente acerca de las aplicaciones JavaScript-que se ejecutan en sólo el navegador web y el servidor utilizan simplemente como almacén de datos (cifrados). Encontrará algunos ejemplos allí.

Answer 6

Para responder realmente a la pregunta, sí, es perfectamente viable crear aplicaciones web cliente-servidor completamente en JavaScript, y marcos que obtuvieron tracción en los dos años transcurridos desde que se formuló la pregunta, notablemente Meteor, hacen que esto mucho más fácil de lo que solía ser:

One Language. Escriba las partes del cliente y del servidor de su interfaz en JavaScript.

- http://docs.meteor.com

Answer 7

código del lado del servidor tiene que ser especialmente robusto y bien diseñado, ya que gestiona más de un cliente en un entorno multihilo. La complejidad de los procesos de nivel empresarial y la necesidad de una reutilización precisa del código siempre me han llevado a escribir código del lado del servidor en Java. No consideraría usar script Java porque está dirigido a un uso diferente.

Dicho esto, utilizo el script Java en el servidor para replicar scripts de validación del lado del cliente, por ejemplo. De esta forma, puede usar el código de validación de una pieza en ambos extremos. El usuario obtiene una validación de navegador receptiva, pero la parte posterior vuelve a validar en caso de que alguien pase por alto la validación del front end.