Cuáles son las ventajas y desventajas de Angular.js vs Elm?

Creo que son bestias diferentes, IMO, aunque comparten el objetivo de ser lo más declarativos posible, y una actitud de "hey, hagamos las cosas Como Deberíamos Hacerlas".

Ahora, con AngularJS todavía estás en territorio "familiar". Es decir, escribes algo de marcado por aquí, escribes algo de JS por allá, y luego lo sirves. El mismo flujo de trabajo de siempre. La" innovación " de AngularJS, por lo que puedo decir, es que extiende HTML con adicional tipos de elementos para que pueda declarar muchos aspectos y comportamiento de su aplicación directamente en el marcado, y luego su JS lib contiene la maquinaria necesaria para brindarle plantillas, enrutamiento, enlace de datos, validación de formularios, localización, etc. (...escribir esto me hace preguntarme si tal vez AngularJS sufre de un poco de hinchazón.), lo que lo convierte en un marco de desarrollo de aplicaciones web muy completo. Y te empuja a escribir tu código en un estilo declarativo.

Con Elm eres realmente entrar en un territorio nuevo (si tiene un fondo de desarrollo "típico" de HTML/JS frontend). Es una forma diferente de hacer (y pensar) el desarrollo de GUI. Escribirá en un lenguaje completamente nuevo, hecho específicamente para crear GUI de una manera de programación reactiva funcional, e idealmente nunca tratará (al menos no directamente) con ninguna de las API DOM tradicionales. Elm viene con una especie de "biblioteca estándar" que le da herramientas para crear y manipular gráficos / texto / etc a través de tiempo.

Su código de lenguaje Elm describirá, de una manera totalmente declarativa, cómo desea que su GUI se vea y se comporte a medida que pasa el tiempo y ocurren eventos (entrada del usuario, etc.). Luego, lo compilará todo en HTML / JS / CSS para que se ejecute en el navegador.

Elm también es muy joven. Depende de usted y de sus necesidades decidir si eso es una desventaja o no.

Supongo que para mí elegir AngularJS es lo mismo de siempre "hey vamos a probar esto de JS lib / framework" - proceso estamos solía hacerlo en el mundo JS. Tomas los archivos lib, los agregas a tu proyecto y comienzas a usar su API. Mientras que con Elm, usted tiene que empezar a abordar su flujo de trabajo y soluciones a los problemas de manera diferente.

AngularJS te da mucha estructura, y es diferente de, digamos, Backbone.js, pero al final del día, si quieres hacer algunos GUIs avanzados y comportamientos gráficos, con AngularJS estás de vuelta a escribir un montón de cosas de plomería que no tendrías que escribir si estuvieras usando Olmo.

Por otro lado, si tienes que desarrollar y lanzar una gran aplicación web ahora mismo, con los widgets GUI habituales que hemos estado usando en la web hasta ahora, me inclino a decir ir por AngularJS porque es más estable.

Dicho esto, creo que Elm es las cosas más interesantes y prometedoras que están sucediendo en el mundo de desarrollo de frontend en este momento. Y, si tuviera que desarrollar y lanzar algunas cosas gráficas pesadas hoy, yo iría por Elm, ya que uno puede hacer cosas GUI muy complejas con él en muy pocas líneas de código. Pero tendría que entrar en su mentalidad primero, y lidiar con el hecho de que es muy joven e integrarlo con una base de código JS frontend existente podría no ser fácil o incluso posible atm.

Editar:

A partir de marzo de 2015, Elm es mucho más robusto, y hay excelentes herramientas para ello (me viene a la mente un depurador que viaja en el tiempo).

Angular sigue siendo, bueno, más de lo mismo. Debo notar que Angular enfoque, con su un-tonelada-de-cosas-suceden-siempre-un-modelo-cambia enfoque ("2-way data binding") hace que sea totalmente inadecuado para cosas tales como juegos basados en navegador, mientras que Elm sobresale en los juegos y avanzada GUI cosas que necesita para funcionar bien. Además, Elm ahora tiene una biblioteca HTML rápida (usando el enfoque de diferencias dom virtuales), para cuando necesite hablar en HTML.

Mi hueso para recoger con Elm es que su sistema de tipos no es tan expresivo como, por ejemplo, Haskell. Algunos pueden pensar que esto es pedir lujo, pero por el contrario, se trata de perder la capacidad de expresar funciones básicas. Especialmente nosotros, programadores experimentados de JS, sufrimos de sistemas de tipos estáticos no suficientemente expresivos, porque significa que el código polimórfico que estamos acostumbrados a expresar fácilmente en JS, se convierte en un error de tipo en Elm, debido a la falta de, por ejemplo, tipos rank-2.

Afortunadamente, todas las características de la "lista de deseos" que faltan en Elm, no están allí debido a la discusión en curso sobre ellos y su alternativa. Así que es una apuesta segura que ellos (o las mejores alternativas) eventualmente llegarán al idioma.