Por supuesto, todo esto depende de lo que piense que es la calificación actual de Scala para aplicaciones web y, lo que es más importante, qué tipo de aplicaciones web está buscando construir. Ya hay muchos buenos frameworks / herramientas web de Scala, por ejemplo, BlueEyes, Circumflex, Lift, Play 1.x / 2.x, Scalate, Scalatra, Spray y Unfiltered. Algunos de estos son kits de herramientas básicos / DSL de manejo HTTP (por ejemplo, Sin filtro y Scalatra) y otros más están dirigidos a la pila completa con motores de plantilla y ORM (por ejemplo, Levantar y Jugar).
Al igual que en todos los demás lenguajes utilizados en el desarrollo web, los diferentes marcos hacen diferentes compensaciones en el nivel de abstracción de protocolo HTTP, gestión de estado, motor de plantillas (si corresponde) y estilo API general. Sin embargo, como Scala es un híbrido OOP / FP con una sintaxis extremadamente flexible, también hay grandes diferencias en cómo se diseñan y usan las API. Creo que este último es uno de los principales desafíos que enfrentamos en la comunidad de Scala para lograr una mayor adopción de los usuarios, y se aplica a todos los marcos, no solo a los marcos web.
Muchos prefieren adoptar Scala gradualmente; comience escribiendo código Java sin punto y coma y comience a aprovechar el poder de Scala a medida que se vuelve natural. Algunos marcos web, como Scalatra + Scalate, toman este enfoque desde una perspectiva de marco. Construyen DSL envoltorios bastante delgados sobre la API de Servlet para hacer que la API sea más bonita. La accesibilidad de estos marcos / API es muy alta para cualquier persona que provenga de un entorno OOP / imperativo, ya que se basan en lo que probablemente sean conceptos familiares. Sin embargo, a medida que uno tenga más experiencia con Scala, muchos sentirán que los conceptos más poderosos de Scala y la programación funcional se vuelven más naturales. Las pequeñas abstracciones de las “API antiguas” comienzan a filtrarse y pueden parecer limitantes cuando se utilizan con otro código idiomático más Scala.
- ¿A quién se le ocurrió primero el botón de 'comentarios' al costado de un sitio?
- Cómo averiguar los datos consumidos por páginas web individuales
- En el desarrollo de software, ¿cuál es la diferencia entre las aplicaciones de escritorio y las aplicaciones web?
- ¿Cuál es la diferencia entre sitio web dinámico y aplicación web?
- ¿Cómo se usa la programación reactiva funcional para aplicaciones web?
Proyectos como Lift, BlueEyes y Unfiltered adoptan un enfoque completamente nuevo y aprovechan los conceptos de Scala como piedras angulares en sus API. La desventaja de esto es que la API se sentirá más extraña para los desarrolladores que vienen de otros lenguajes y marcos. Si también tenemos en cuenta que la mayoría de los frameworks web de Scala (con las notables excepciones de Lift and Play) no brindan mucha guía sobre cómo conectar y configurar aplicaciones más grandes, está claro que aprender un nuevo framework, una nueva arquitectura y un nuevo idioma puede ser difícil al mismo tiempo que intenta mantenerse productivo. En esencia, aprender Scala en un marco idiomático Scala puede ser un poco abrumador, en particular si aún no hay veteranos en la organización.
¡Sin embargo, el ecosistema Scala está lleno de opciones! Actualmente estamos desarrollando en la rama maestra de Play 2.xy espero / creo que estén logrando un buen equilibrio entre una implementación idiomática de Scala y una API que sea accesible para los desarrolladores que provienen de otros marcos / idiomas. Definitivamente, todavía hay mucho camino por recorrer antes de la versión 2.0, pero Play aprovecha la composición de la función en su núcleo (es decir, pruebas fáciles, sin hilos locales, muy poco estado compartido y efectos secundarios retrasados) mientras se mantiene un DSL “más familiar” para manejo de solicitudes. También tiene un sistema de plantillas basado en Scala muy agradable. En mi opinión, todo esto podría conducir a un marco en el que los desarrolladores novatos de Scala puedan volverse productivos rápidamente mientras escriben código idiomático de Scala sin siquiera pensarlo. No es necesario asimilar inmediatamente el funcionamiento interno de la API, pero a medida que los conceptos de Scala se vuelvan más naturales, también lo hará el funcionamiento interno de la API. Dicho esto, Play todavía tiene muchos rasgos que no son tan atractivos (ciclo de recarga bastante lento, todavía bajo un fuerte desarrollo con cambios de API de vez en cuando, muy poca documentación e implementación desconocida).
La conclusión es que ya hay muchas herramientas excelentes para el desarrollo web en Scala, especialmente si los desarrolladores ya están familiarizados con Scala; de lo contrario, la curva de aprendizaje será empinada. Para un desarrollo web de uso general más convencional (a falta de una palabra menos cargada), mi apuesta es mantener un ojo en Play.
