que - ¿Despegará el JavaScript del lado del servidor? ¿Qué implementación es más estable?

javascript pdf (17)

¿Alguien ve el despegue del JavaScript del lado del servidor? Hay un par de implementaciones, pero todo parece ser un poco exagerado (como en, "hacerlo PORQUE PODEMOS" tipo de actitud).

Tengo curiosidad por saber si alguien realmente escribe JavaScript para el lado del servidor y cuáles han sido sus experiencias con él hasta la fecha.

Además, ¿qué implementación se considera generalmente la más estable?

¿Alguien ve el Javascript en el servidor despegar?

Intente buscar en http://www.appjet.com una startup que hace aplicaciones de JavaScript alojadas para tener una idea de lo que puede hacer. Me gusta especialmente el proceso de aprendizaje que empuja suavemente al usuario para construir cosas con un mínimo de gastos generales ~ http://appjet.com/learn-to-program/lessons/intro

Ahora puede parecer una idea extraña en este momento usar JavaScript pero pensar cuando las PC comenzaron a salir. Todos los empollones que conocía estaban tipeando en su nuevo Trash-80 , Commodore64 , Apple] escribiendo juegos o aplicaciones simples en BASIC.

¿Dónde está hoy el básico para el hacker más joven?

Es posible que JavaScript podría hacer para las aplicaciones del servidor basadas en la web como lo hizo BASIC para la PC.

¿Por qué querría procesar algo en Javascript cuando puede procesarlo en PHP o ASP.NET que están diseñados específicamente para esta tarea?

Tal vez porque JavaScript es un lenguaje de programación más poderoso que esos dos? Por ejemplo, tiene funciones como tipos de datos de primera clase y soporte para cierres.

Steve Yegge ha escrito sobre la migración de Ruby on Rails al JavaScript del servidor como un proyecto interno dentro de Google ("Rhino on Rails"). Lo hizo porque le gustan los rieles, pero el uso de Ruby no está permitido en Google.

Antes de ser adquirida por Google, JotSpot usó JavaScript del lado del servidor para permitirle consultar su base de datos y mostrar sus páginas. Usaron a Rhino para hacerlo. CouchDB utiliza JavaScript del lado del servidor para crear vistas de su base de datos.

Como puede ver en estos ejemplos, una excelente manera de usar JavaScript en el servidor es para complementos. Una de las razones por las que se usa es que puede crear un entorno aislado para que las personas puedan ejecutar su código. Además, debido a la forma en que funciona el JavaScript como idioma, puede proporcionar herramientas de usuario específicamente adaptadas a las tareas que los usuarios necesitan completar. Si hace esto bien, los usuarios no necesitan aprender un nuevo idioma para completar sus tareas, un vistazo rápido a su API y ejemplos son suficientes para ponerlos en camino. Compare esto con muchos de los otros idiomas y puede ver por qué usar JavaScript en el lado del servidor para proporcionar una arquitectura de plugins es tan tentador.

Una solución popular secundaria, que se puede ver a través de un proyecto como Jaxer , es que un problema común de las aplicaciones web que hacen la validación del lado del cliente es que, dado que JavaScript se pasa fácilmente por alto en el navegador, la validación debe ejecutarse una vez más. el servidor. Un sistema como Jaxer le permite escribir alguna funcionalidad de validación que sea reutilizable entre el servidor y el cliente.

Bueno, todos los miembros del servidor de ASP soportaron JavaScript desde hace años y todos usaron VBShiate. Pero tengo que estar de acuerdo con los demás: JS no parece ser la herramienta adecuada aquí, y me encanta hacer JS en el lado del cliente :)

No puedo ver a la mayoría de los desarrolladores superar su disgusto por la programación de JavaScript del lado del cliente. Prefiero ir a Java para cosas del lado del servidor antes de elegir JavaScript.

Nunca he oído hablar de esto, pero me parece que estoy usando la herramienta incorrecta para el trabajo. Dado que los lenguajes de programación son solo herramientas diseñadas para ayudarnos a resolver algún problema.

¿Por qué querría procesar algo en Javascript cuando puede procesarlo en PHP o ASP.NET que están diseñados específicamente para esta tarea?

Claro que puedes clavar un clavo con un destornillador, pero un martillo funciona mucho mejor porque en realidad fue diseñado para ello ...

Entonces no, no lo veo despegar.

Parece que la mayoría de ustedes se dejan intimidar por esta idea debido a lo desagradables que han sido las diversas implementaciones de JavaScript del lado del cliente. Revisaría las soluciones existentes antes de juzgar, sin embargo, porque recuerde que ninguna solución particular de SS / JS está ligada a las implementaciones de JS que se usan actualmente en los navegadores. Javascript está basado en ECMAScript, recuerde, una especificación que actualmente se encuentra en un estado bastante maduro. Sospecho que una solución SS / JS que admita especificaciones más recientes de ECMA no sería más engorrosa que usar otros lenguajes de scripting para la tarea. Recuerda, Ruby no fue escrita para ser un "lenguaje web" originalmente, tampoco.

Personalmente hice un sitio completo en JavaScript del lado del servidor usando ASP. Lo encontré bastante agradable porque pude tener un buen código de reutilización. Esto incluyó:

validación de parámetros
modelado de objetos
transporte de objetos

Junto con una herramienta de modelado de alto nivel y gen de código, me divertí con ese proyecto.

No tengo números en perf por desgracia, ya que solo se usa en una intranet. Sin embargo, debo suponer que el rendimiento está a la par con los sitios ASP con respaldo de VBScript.

Flash Media Server tiene un script con Server Side Action Script, que en realidad es solo javascript (ECMAScript). Entonces, lo hago mucho. De hecho, la mayor parte de mi día fue lidiar con SSAS.

Y lo odio. Aunque para ser justos, muchos de ellos están más relacionados con la base de código (no tan buena) que heredé que el idioma real.

La programación del lado del servidor ha existido por mucho más tiempo que el lado del cliente, y ya tiene muchas buenas soluciones.

JavaScript ha sobrevivido y se ha hecho popular simplemente porque los desarrolladores tienen muy pocas opciones al respecto: es el único idioma que puede interactuar con un DOM. Su única competencia en el lado del cliente proviene de cosas como Flash y Silverlight, que tienen un modelo muy diferente.

Esta es también la razón por la cual JavaScript ha recibido tanto esfuerzo para actualizarlo y agregar características modernas. Si fuera posible para todo el mercado del navegador descartar JavaScript y reemplazarlo por algo diseñado adecuadamente para la tarea, estoy seguro de que lo haría. Tal como está, Javascript tiene extraños objetos basados en prototipos, algunas funciones de programación funcionales ordenadas, colecciones limitadas y peculiares y muy pocas bibliotecas.

Para los pequeños scripts está bien, pero es un lenguaje horrible para escribir sistemas complicados y grandes. Que cosas como Firefox y Gmail estén (parcialmente) escritas en él es un logro heroico de su parte, no una señal de que el lenguaje está listo para el desarrollo real de aplicaciones.

El soporte para JS en el servidor se ha fortalecido y la cantidad de marcos se está ampliando aún más rápido.

Recientemente, se fundó el grupo serversideJS . Tienen mucha gente inteligente que ha estado trabajando en JS durante mucho tiempo (algunos de ellos más de 10).

El objetivo de este proyecto es crear una biblioteca estándar que finalmente permita a los desarrolladores web elegir entre cualquier número de herramientas y marcos web y ejecutar ese código en la plataforma que tenga más sentido para su aplicación.

a las personas que dicen "¿por qué elegirías JS en lugar de Java o cualquier otro idioma?" - Deberías leer esta Re-Introducción de Crockford y olvidarte del DOM - el DOM es excelente, pero eso no es culpa de JS y JS no es el DOM.

Creo que el Javascript del lado del servidor está garantizado para despegar. Es solo cuestión de tiempo.

Mozilla, Google y Adobe tienen tanto interés creado para Javascript que se necesitaría un milagro para desalojarlo del mundo de los navegadores. El siguiente paso lógico es mover esto al lado del servidor.

Este es un paso para alejarse de la gran cantidad de tecnología de Internet que generalmente incluye todos estos

HTML
CSS
Javascript
Idioma Serverside J2EE / ASP / Ruby / Python / PHP
SQL

No he escuchado mucho sobre el estado actual de los marcos del Servidor Javascript, excepto que son en su mayoría incompletos.

XChat puede ejecutar complementos de Javascript.
Tengo un software de contabilidad completamente escrito en Javascript.
Hay esta interesante biblioteca de IO para V8: http://tinyclouds.org/node/
CouchDB es una base de datos de documentos con ''consultas'' escritas en Javascript (TraceMonkey).

Teniendo esto en cuenta, creo que el Javascript en el servidor despegó.

Veo que js del lado del servidor ofrecerá ventajas considerables en futuras aplicaciones. ¿Por qué? Las aplicaciones web que pueden estar fuera de línea, la tienda de db del lado del cliente, los engranajes de google, etc.

Siguiendo esta tendencia, cada vez más lógica se mueve hacia el lado del cliente. Use un ORM que funcione para el lado del cliente y use otro en el lado del servidor (ya sea PHP / Ruby / lo que sea), escriba su lógica de sincronización dos veces en dos idiomas diferentes, escriba su lógica comercial dos veces en dos idiomas diferentes.

¿Qué tal usar js en el cliente Y en el lado del servidor y escribir el código una vez?

¿Convincente?

Me gusta leer el blog de Googler Steve Yegge, y recientemente me encontré con su artículo en el que argumenta que Mozilla Rhino es una buena solución para JS en el servidor. Es una transcripción algo descuidada, es posible que prefiera ver el video de la charla . También ofrece un poco de información sobre por qué cree que la JS del servidor es una buena idea en primer lugar (o más bien, por qué cree que es una buena idea usar un lenguaje dinámico para ejecutar Java). Pensé que los puntos que hacía eran convincentes, por lo que es posible que desee comprobarlo.

Un tiempo antes, también publicó algo sobre lenguajes dinámicos en general (es un gran admirador de ellos), por si acaso se preguntaba por qué usar JS en absoluto.

Personalmente, he estado desarrollando y usando mi propio marco de JavaScript durante aproximadamente 4 años.

Lo bueno de JS en el servidor es que implementado en ASP Classic no necesitas ningún otro plugin o software instalado, además también estoy usando mi framework javascript (client) en mi servidor, que me permite disfrutar de la misma funcionalidad y el rendimiento comprobado de mis funciones en ambos entornos, cliente y servidor.

No solo para la validación de datos, sino también para decir que las construcciones dinámicas en HTML o CSS se pueden realizar en el cliente o en el servidor, al menos con mi marco.

Hasta ahora funciona rápido, no tengo nada de lo que quejarme o arrepentirme, excepto su excelente usabilidad y escalabilidad que he estado disfrutando durante los últimos 4 años, hasta el punto de que estoy cambiando mi código ASP Classic a código JavaScript.

Puedes verlo en la práctica en http://www.laferia.com.do

Node.js ha despegado y ha demostrado que el JavaScript del servidor está aquí para quedarse =)