¿Cuáles son los pros y los contras de los principales marcos web JavaScript del lado del servidor?

Wakanda

Trabajo en el proyecto Wakanda, así que, en cuanto a la primera publicación, no es totalmente objetivo, pero creo que es al menos informativo

Visión general
+ Productivo, fácil de aprender, potente
– Casi en Beta, todavía pequeña comunidad

Modelo impulsado
+ Almacén de datos de objetos de JavaScript
+ API HTTP REST nativa
+ Sistema de autenticación nativa
– Menos escalable horizontalmente (contexto potencial del servidor)

Ejecutar en Webkit / JavaScriptCore / SquirrelFish / Nitro
+ Multihilo
+ Preventivo
+ 64bit
+ Escalabilidad vertical (agregue núcleos y memoria -> más potencia)

API HTTP adicionales
+ Servicio JSON-RPC incorporado
+ posibilidad de implementar sus propias API (como YQL, Atom, …)
– Sin jabón nativo

Soporte nativo de API HTML5 en el servidor
+ Trabajadores web
+ clon estructurado
+ Almacenamiento de sesión
+ Temporizadores
+ Blob
o XMLHttpRequest parcial
o trabajar en el cumplimiento de FileSystem

Otras API SSJS nativas
+ Módulo CommonJS 1.1.1
+ Prueba de unidad CommonJS 1.0
+ Consola, depurador
+ Buffer compatible con NodeJS, Net
o parcial del sistema CommonJS 1.0

Herramientas
+ Gerente de soluciones
+ Diseñador de modelos
+ Editor de código
+ Depurador visual
+ Diseñador de interfaz gráfica
+ Marco Ajax

Materiales
+ Documentación grande
+ Videos de taller
+ Foro activo
o requiere más tutoriales y demostraciones
– …

Madurez
+ Creado por 4D, cuyo otro producto hace que las aplicaciones comerciales funcionen desde hace 25 años
– Todavía no hay versión de producción (principios de 2012 – Beta en diciembre de 2011)

Probablemente la mayor diferencia es si el marco fomenta un estilo de programación síncrono o asíncrono.

El nodo es asíncrono, mientras que los otros son sincronizados, aunque, por ejemplo, Ringo también permite realizar operaciones asincrónicas.

Las API asíncronas proporcionan un control preciso sobre IO con poca sobrecarga cuando se manejan múltiples flujos de IO. Las API de sincronización proporcionan un mayor nivel de abstracción y, a menudo, hacen que escribir y mantener código sea más fácil y rápido.

Por lo tanto, un enfoque asíncrono es más adecuado para los componentes de infraestructura en los que se manejan predominantemente eventos y se transmiten mensajes entre flujos de E / S o se necesita reducir el último rendimiento. Por otro lado, un enfoque de sincronización es más adecuado para escribir la mayoría de las otras aplicaciones web CRUD, especialmente aquellas con una lógica empresarial compleja.

Debo señalar que estas líneas pueden borrarse, por lo que, por ejemplo, mi paquete Common Node ( http://olegp.github.com/common-node ) le permite ejecutar el código de sincronización en la parte superior de Node.js usando fibras (hilos ligeros) .

Mi presentación sobre el futuro de JavaScript del lado del servidor también puede ser de interés:

Diapositivas: http://www.slideshare.net/olegp/
Vídeo:

RingoJs

Facilidad de uso
+ Cargador de módulo de recarga automática (no se requiere reinicio)
+ REPL con autocompletado e historial
+ Depurador gráfico
+ Servicio web listo para usar
o documentos de API, abrir Wiki (todavía falta mucho)
– requiere JVM
– …

Caracteristicas
+ Marco web con todas las funciones (plantillas, envío de solicitudes, sesiones, ..)
+ Entre el cumplimiento más completo de CommonJs
+ Fácil acceso a cualquier biblioteca Java
o Velocidad (no es V8 pero Rhino brilla en RingoJs)
– …

Diseño
Tiempo de ejecución sólido como una roca (10 años de experiencia ejecutando SSJS en JVM)
+ Mayormente JavaScript puro (esfuerzo continuo)
– …

Madurez
o Impulsa sitios de pequeña escala. Cerca de 0.7

(Honestamente: es difícil encontrar inconvenientes cuando estás tan cerca del proyecto, pero creo que eso también me hace capaz de identificar a los profesionales … así que, por favor, sugiere ediciones para insertar en algunos inconvenientes; estoy seguro de que RingoJs los tiene. )