Remplacement de angular par les technologies Web standard

Question

Je travaille sur un projet qui a le luxe d'utiliser ECMA 6 sur les derniers navigateurs pour un produit qui sera expédié dans 1,5 an. Nous avons donc pensé pourquoi ne pas utiliser les composants Web maintenant que Angular 2 n'est pas disponible (qui sera ECMA 6). Et pendant que nous y sommes, pouvons-nous remplacer Angular tout à fait sans avoir à revenir à l'âge de pierre?

Comment remplacer Angular?

Il y a ce site appelé youmightnotneedjquery.com qui est essentiellement sur la façon dont les navigateurs modernes ont la plupart des choses pour lesquelles jQuery était traditionnellement utilisé. Je suis intéressé de voir quelque chose comme ça pour Angular.

Nous utilisons principalement quatre Angular fonctionnalités. Quelles sont mes options pour les remplacer?

• Directives angulaires -> Composants Web
• Modules angulaires -> Modules ECMA 6 (pas exactement la même chose )
• Itinéraires angulaires -> ???
• Liaison de données angulaire à 2 voies -> ???

PS. Nous ne voulons pas remplacer Angular par quelque chose de similaire comme Backbone ou Ember. Nous voulons le remplacer par des technologies Web standard, mais si nous devons utiliser de petits outils pour combler l'écart, nous considère-le.

Answer 1

J'ai fait des recherches au cours des 3 dernières semaines et il se trouve que beaucoup de gens réfléchissent à une alternative après que Angular a pris un chemin de changement radical. cela fonctionne en ce moment avec polyfills du projet Polymer . Donc pour répondre à la question:

• Directives angulaires -> Les composants Web utilisent le polyfill jusqu'à ce que tous les navigateurs le prennent en charge.
• Modules angulaires -> Modules ECMA 6 une partie du problème est résolue avec les importations HTML. Mais vous pouvez également utiliser Traceur jusqu'à ce que les navigateurs le prennent en charge.
• Itinéraires angulaires -> Il y a un composant pour cela ™ utilisez <app-router> .
• Liaison de données angulaire à 2 voies -> Polymer ajoute une couche "magique" au-dessus des composants Web standard standard. Cela inclut de nombreuses fonctionnalités, y compris liaison de données .

+ Plus Plus

Si vous vous interrogez sur le processus de construction pour la concaténation de fichiers afin de réduire le nombre de requêtes HTTP, jetez un œil à article d'Addy Osmani sur Vulcanize . Spoiler: vous n'en aurez peut-être pas besoin avec les optimisations HTTP 2 à venir.

De nombreux projets Angular utilisent Twitter Bootstrap pour la mise en page. Polymer peut le faire et il fonctionne bien avec Google Éléments en papier (totalement facultatif mais superbement génial).

Si vous voulez vous familiariser avec les composants Web en général, voici un tas d'articles Nice: http://webcomponents.org/articles/

Et voici une multitude de composants Web: http://customelements.io/ Je ne sais pas si ça va être un nouveau NPM, mais la liste des composants est assez impressionnante et grandit.

Il est relativement compliqué d'exposer une API pour un Angular. Les gens ont trouvé toutes sortes de méthodes de fonction de lien à émission d'événements . En les composants Web, cependant, c'est vraiment facile pour faire interagir votre composant avec le monde extérieur et en effet l'API et les événements que vous exposez ne sont pas très différents des balises HTML standard comme <audio>.

Tout comme Angular , vous pouvez également utiliser Polymer with Dart .

Conclusion

Dans l'ensemble, je ne vois aucune raison d'utiliser Angular sauf si:

1. Vous avez un énorme investissement de code source dans angular et vous ne voulez pas tout porter sur le Web standard. (Angular 2.0 rendra votre code obsolète de toute façon, donc vous êtes coincé avec Angular 1. *)
2. Votre équipe est trop paresseuse pour apprendre une nouvelle technologie (dans ce cas, le web pourrait de toute façon ne pas être la bonne plate-forme pour cette attitude).

Angular était bon pour ce qu'il faisait et avait son propre cycle Hype . Les composants Web résolvent de nombreux problèmes Angular essayait de résoudre. Probablement Angular avait un rôle de preuve de concept pour les composants Web. Mais maintenant il est temps Le Web se réinvente tous les jours et il est inévitable de déplace le fromage de quelqu'un .

Je ne dis pas que Le polymère est la réponse ultime à tout. Au mieux c'est un autre Angular qui rendra inutile dans quelques années, mais maintenant c'est le bon moment pour l'apprendre et l'utiliser. Le W3Cstandardsne pasmourir facilement cependant, et Polymer a tendance à être beaucoup plus proche d'eux.

Il y a un élément pour ça ™ est le nouveau Il y a une application pour ça ™

Answer 2

TLDR: envisagez sérieusement d'écrire une application presque Angular 2.0-compatible Angular 1.3 avant de lancer votre propre framework)

Il semble que vous ayez identifié que Angular fait beaucoup de choses dans le bon sens et c'est pourquoi vous essayez de le reproduire, donc en gros vous allez rouler le vôtre en combinant un méli-mélo de bibliothèques. À moins que vous n'ayez un investissement énorme en heures d'ingénierie, le cadre que vous construirez sera probablement:

• Légèrement documenté
• Un cauchemar de maintenance multi-navigateur et (pire que tout)
• Difficile pour les nouvelles recrues d'apprendre

S'il n'y avait pas de framework qui faisait déjà ce que vous vouliez faire, je pense que rouler le vôtre est logique, mais en essayant de recréer Angular vous êtes:

• Prendre en charge de nombreux travaux d'ingénierie déjà effectués par une équipe dédiée, qui auraient pu être consacrés à la construction de produits
• Il a été BEAUCOUP plus difficile d'intégrer de nouveaux employés parce que vous devez:
  • Trouvez des candidats qui souhaitent utiliser un cadre local au lieu de développer leurs compétences dans un cadre open source qu'ils pourraient utiliser ailleurs
  • Former ces employés à utiliser votre framework (et bonne chance à moins que votre documentation ne soit mature)

Je sais que votre question demande comment remplacer Angular, mais j'ai vu trop d'entreprises choisir de rouler les leurs et de les payer plus tard. Encore une fois, si votre budget comprend une tonne de ressources de base pour construire (et documenter et maintenir) le cadre et que vous ne pensez pas qu'il y ait une chance que les coins soient coupés lorsque Push viendra plus tard si les délais sont serrés, le vôtre pourrait avoir un sens. Cependant, je pense que vous devriez sérieusement envisager de lire comment écrire des applications Angular 1.3 pour qu'elles soient faciles à porter vers Angular 2.0 et aller = Angular. Regardez simplement la taille de la communauté que vous manquez:
http://www.airpair.com/js/javascript-framework-comparison