Bueno, para mi último trabajo, en una empresa de publicación de medios (con una fuerte presencia en línea, por supuesto), pasamos por el proceso de decidir cuál sería nuestro marco de aplicación web predeterminado, y teníamos algunas opciones sobre la mesa, incluida Play , Node Express, Python Flask / Tornado y Ruby on Rails.
Echamos a Ruby on Rails por problemas de rendimiento, aunque se perderían los formularios instantáneos tipo Django creados a partir de su modelo de base de datos.
Me asignaron la tarea de evaluar Play 2, y ya teníamos experiencia en Play / Scala, aunque la mitad de los desarrolladores estaban enfocados en el front-end (pero estaban abiertos a Scala). Así que tuve en cuenta la curva de aprendizaje, junto con su familiaridad con JavaScript, al considerar el juego.
- ¿Cuáles son los diferentes tipos de servicios de prueba de software?
- ¿Qué características son vitales o que faltan en los lenguajes de programación en general?
- ¿Cuándo se puede llamar arquitecto a un ingeniero de software? Hoy, muchos afirman ser arquitectos. ¿Son lo que dicen?
- ¿Cuál es la mejor manera de evaluar la tecnología informática?
- ¿Cuál es su opinión sobre la programación de pares?
Al jefe se le ocurrió una larga lista de puntos, y me propuse abordarlos a todos (tenga en cuenta que nos estábamos inclinando hacia la opción Scala, pero tanto Java como Scala están disponibles para usted):
- Jugar es simple para comenzar “reproducir nuevo ” .. sin configuración del entorno.
- Fuerte soporte MVC
- Solicitudes asincrónicas debido a netty, una tecnología madura y rápida.
- La convención sobre la configuración … sin XML, se elimina rápidamente al escribir código. Pasas más tiempo escribiendo código, pero de cierta manera.
- Archivo de rutas extremadamente intuitivo que admite expresiones regulares
- Comprobación de tipos en tiempo de compilación para aplicaciones completas, rutas y plantillas. Muy bueno para mantener aplicaciones grandes, suavizando la necesidad de una cobertura de prueba infalible.
- Play se basa en sbt que permite experimentar con classpath cargado. Puede hacer cosas como probar los puntos finales de su controlador para ver qué devuelven.
- Sbt también es ideal para “prueba automática al guardar”. LinkedIn confirma que esto mejora dramáticamente la productividad del desarrollador sobre otros marcos de Java.
- JVM madurez / optimización / rendimiento compilado
- Play viene con una base de datos integrada en memoria
- Los IDE de Java son muy potentes, y los IDE de Scala son bastante buenos ahora, incluidas las herramientas de depuración.
- Scala, que también es totalmente compatible con Play, atrae a desarrolladores de élite, y la base de usuarios de Scala está creciendo rápidamente en Nueva York
- Pruebas asincrónicas en scala usando specs2
- Websockets fuera de la caja:
def index = WebSocket.using [String] {request =>
// Registrar eventos en la consola
val in = Iteratee.foreach [String] (println) .mapDone {_ =>
println ("Desconectado")
}
// Envía un solo '¡Hola!' mensaje
val out = Enumerator ("¡Hola!")
(En fuera)
}
- Las aplicaciones JVM son las más fáciles de implementar / mantener y tienen el rendimiento más predecible.
- Java / Scala tiene simultaneidad incorporada sin sacrificar la flexibilidad, como con la VM de un solo subproceso de Node.
- Scala puede ser críptico, pero esto se alivia mucho al dividir las funciones en funciones simples / obvias con nombres descriptivos. A su vez, es recompensado con la “expresividad” del código, diciendo más con menos.
- Amplio soporte de biblioteca de terceros
- Según LinkedIn, casi todo es flexible / conectable / configurable
- compila coffeescript / less y muestra errores en el navegador.
- Proporciona automáticamente archivos Javascript minificados
- Soporte simple de NoSQL
- Usando Ok (anyMethodThatGenerateSomeHtml) puede conectar cualquier otro sistema de plantillas existente.
- Se puede usar con el marco de plantilla “Japid” para un rendimiento que puede acercarse fácilmente al de los archivos estáticos
- Los actores Akka (Java / Scala), y los futuros / promesas y para las comprensiones (scala) permiten E / S sin bloqueo sin “callback hell” (código de espagueti profundamente anidado que salta por todo el lugar)
- Autenticación incorporada
- Soporte completo de integración continua con Play para Java y Scala con Jenkins. Probablemente los otros principales sistemas de CI también.
Así que terminé esa lista y no recibí mucha respuesta. Era más o menos un TL; DR. Entonces, el tipo que presentaba Flask / Tornado (marco web asíncrono de Python) no ofreció mucho, para mi decepción. El chico que presentó Node.js era un chico de front end con mucha familiaridad con Javascript. Solo abordó un puñado de puntos, sin comparar / contrastar mucho. Acabo de pasar al modo Steve Jobs, con algunas diapositivas, que muestran lo fácil que fue comenzar y algunas de las herramientas disponibles.
Bueno, de todos modos tenía un pie fuera de la puerta, así que realmente no iba a presionar a nadie para que adoptara tecnologías que no le entusiasmaban. Eligieron Node.js, probablemente por el sesgo de front-end, y el hecho de que nadie realmente dijo, o podría decir algo horriblemente malo sobre Node.js, para los fines de lo que la compañía requería. Creo que, independientemente de la experiencia existente y la preferencia de los empleados, en un mundo ideal, Play / Scala habría sido la elección correcta, pero aprendí, como se sugirió cuando inicialmente hice una consulta sobre Quora aquí … ¿Cómo elijo entre marcos web asincrónicos? Mi grupo de tecnología es bastante independiente del lenguaje y estamos tratando de estandarizar algunas tecnologías. … que estos marcos web tenían diferencias insignificantes en términos de capacidad, por lo que la experiencia / preferencia realmente debería considerarse con el mayor peso.