Quels sont les avantages et les inconvénients de Angular.js vs. Elm?

Question

Je cherche à faire de la programmation réactive dans le navigateur et de comparer angular.js (http://angularjs.org/) avec Elm (http://elm-lang.org/).

Quels sont les avantages/problèmes relatifs à chacun?

Answer 1

Je pense qu'ils sont des bêtes différentes, IMO, bien qu'ils partagent l'objectif d'être aussi déclaratif que possible, et une attitude de "hé, faisons les choses Ils devraient nous faire ". Maintenant, avec AngularJS vous êtes toujours en territoire "familier". C'est-à-dire, vous écrivez un balisage ici, écrivez quelques JS là-bas, et ensuite vous le servez. Même flux de travail que d'habitude. L '"innovation" de AngularJS, pour autant que je sache, est que étend HTML avec des types d'éléments supplémentaires de sorte que vous pouvez déclarer beaucoup d'aspects et le comportement de votre application directement dans le balisage, puis son JS lib contient la machinerie nécessaire pour vous donner un modèle, un routage, une liaison de données, une validation de formulaire, une localisation, etc. (... écrire ceci me fait me demander si AngularJS souffre d'un peu de bloat), ce qui en fait un web complet cadre de l'application dev. Et cela vous pousse à écrire votre code dans un style déclaratif.

Avec Elm vous êtes vraiment en train de vous lancer (si vous avez un environnement «typique» d'arrière-plan frontend HTML/JS). C'est une façon différente de faire (et de penser à) le développement de l'interface graphique. Vous allez écrire dans un langage complètement nouveau - conçu spécifiquement pour créer des interfaces utilisateur graphiques d'une manière fonctionnelle et réactive - et idéalement, vous ne traiterez jamais (du moins pas directement) avec les API DOM traditionnelles. Elm vient avec une sorte de "bibliothèque standard" qui vous donne des outils pour créer et manipuler des graphiques/texte/etc à travers le temps. Votre code de langage Elm décrira, de manière totalement déclarative, ce à quoi vous voulez que votre GUI ressemble et se comporte au fil du temps et des événements (entrée utilisateur, etc.) se produisent. Ensuite, il compilera tout à HTML/JS/CSS dans l'ordre qui fonctionne sur le navigateur.

Elm est très jeune aussi. C'est à vous et à vos besoins de décider si c'est un inconvénient ou non. J'imagine que choisir AngularJS est exactement le même vieux "hey essayons ce truc JS lib/framework" - le processus auquel nous sommes habitués dans le monde de JS. Vous récupérez les fichiers lib, les ajoutez à votre projet et commencez à utiliser son API. Alors qu'avec Elm, vous devez commencer à approcher votre flux de travail et les solutions aux problèmes différemment. AngularJS vous donne beaucoup de structure, et c'est différent de, par exemple, Backbone.js, mais en fin de compte, si vous voulez faire des interfaces graphiques et des comportements graphiques avancés, avec AngularJS, vous êtes de retour à écrire une tonne de trucs de plomberie que vous n'auriez pas à écrire si vous utilisiez Elm. D'autre part, si vous devez développer et lancer une grande application Web maintenant, avec les widgets GUI habituels que nous avons utilisés sur le web jusqu'à présent, je serais enclin à dire aller pour AngularJS parce que c'est plus stable. Cela dit, je pense qu'Elm est la chose la plus intéressante et la plus prometteuse qui se passe dans le monde du développement front-end pour le moment. Et, si je devais développer et libérer des trucs lourds graphiques aujourd'hui, je serait aller pour Elm, car on peut faire des choses très complexes avec l'interface graphique dans très peu de lignes de code.Mais je dois d'abord entrer dans son état d'esprit, et faire face au fait qu'il est très jeune et l'intégrer avec une base de code JS frontend existante pourrait ne pas être facile ou même possible.

Edit:

En Mars 2015, Elm est beaucoup plus robuste, et il y a beaucoup d'outillage pour elle (débogueur voyage dans le temps vient à l'esprit).

Les restes angulaires étant, bien, plus de la même chose. Je dois noter que l'approche d'Angular, avec son approche de changement de modèle ("liaison de données bidirectionnelle"), est totalement inadaptée à des choses comme les jeux sur navigateur, alors que Elm excelle dans les jeux et les éléments graphiques avancés qui doivent être performants. De plus, Elm dispose maintenant d'une bibliothèque HTML rapide (utilisant l'approche de dom dom), pour quand vous avez besoin de parler en HTML. Mon os à choisir avec Elm est que son système de type n'est pas aussi expressif que par exemple. Haskell. Certains peuvent penser que cela demande du luxe, mais au contraire, il s'agit de perdre la capacité d'exprimer des fonctions de base. En particulier, les programmeurs JS expérimentés souffrent de systèmes de type statique non-expressifs, car cela signifie que le code polymorphe que nous avons l'habitude d'exprimer facilement dans JS devient une erreur de type dans Elm, en raison d'un manque de temps. types de rang 2.

Heureusement, toutes les fonctionnalités «liste de souhaits» qui manquent dans Elm, ne sont pas là en raison discussion en cours à leur sujet et leurs solutions de rechange. C'est donc un pari sûr qu'ils (ou les meilleures alternatives) finiront par arriver à la langue.

Answer 2

Les deux configurations graphiques statiques complexes et l'interactivité sont beaucoup plus simples dans Elm que dans HTML/CSS/tout framework JavaScript. Avec Elm, la complexité accidentelle réside dans les types, mais cela vaut la peine learning about them - ils aident à mieux comprendre, déboguer et modifier les logiciels, et ils devraient déjà vous être familiers si vous venez d'un environnement de programmation fonctionnel. Notez que vous pouvez également embed Elm in HTML/JS, donc en théorie, vous pouvez migrer progressivement.

Answer 3

Elm est beaucoup plus opiniâtre que Angular, et notamment par rapport à gestion d'état. Si vous trouvez que l'état devient un problème dans une application angulaire conventionnelle, alors vous pourriez être tenté de regarder vers un état monolithique centralisé en utilisant une approche de type Redux, ngrx venant rapidement à l'esprit.

Elm incarne la notion d'état central immuable et était inspiration for Redux. Elm impose un seul état immuable avec une fonction pure de mise à jour (réducteur). À mon avis, cela rend beaucoup plus simple la gestion de l'état dans une application web hautement réactive que la confusion qui peut survenir en utilisant un modèle OO-like dans Angular.

Elm est idéal pour la plupart des applications, mais il peut devenir un peu plus complexe lorsque vous voulez travailler avec des bibliothèques JS externes (par exemple google maps), car son interface de fonction étrangère (ports) est assez rigide. Le type d'animations nécessaires dans Material Design a également été difficile pour l'architecture Elm - cela ne veut pas dire qu'il n'y a pas d'animations, mais qu'elles prennent plus de câblage que vous ne le souhaitez.