Je me suis mal exprimé, en fait "d'éliminer", il serait mieux de dire "choisir".
J'ai fait une sélection des frameworks existants les plus populaires par quelques recherches sur internet et commencé une première sélection à obtenir des frameworks qui nous permettent vraiment de faire de nouvelles choses (jQuery entre dans la catégorie framework, mais on le connaît déjà et on veut aller plus loin que ce qu'il propose par exemple). On y retire des frameworks qui commencent à se faire vieux (comme tu l'as dit, il faut viser le long terme sur cet investissement, même si en techno web le "long terme" se compte en années, pas en décennies) et on obtient une première sélection :
Angular, Ember, Backbone, CanJS, Meteor, SproutCore
Comme j'en ai déjà parlé, ce n'est pas comme si on nous laissait le temps d'avoir de la formation technologique, et j'ai beau adorer coder, après une journée à faire ça j'aime bien passer à autre chose en rentrant chez moi. Faisons donc confiance à Le Internet (et des auteurs d'articles bien plus éclairés sur le JS que mon humble personne) pour me faire un tour de ce qui se fait le plus en ce moment. Il s'agit de compter sur un framework apprécié, aux nombreuses contributions, avec assez de docs sur Internet, d'exemples ou de questions sur StackOverflow (ce qui n'est pas forcément une bonne chose, mais au moins montre qu'il y a assez de gens intéressés pour y répondre). Il faut tailler, il rester quoi ?
Angular, Ember, Backbone, CanJSMaintenant, penchons nous sur ces quatre gaillards. Mettez vous en ligne, et lançons quelques mots clés comme "comparatif". Je n'ai pas le temps d'étudier ces quatre là en profondeur, plutôt que de savoir ce que chacun fait, je veux savoir ce qu'ils font que les autres ne font pas. Et je tombe sur des concepts nouveaux pour moi qui peuvent m'intéresser. Plusieurs sites me renvoient notamment sur
cet article qui, même datant d'un an, semble être une bonne base de réflexion.
Là, on entre dans le goût personnel. Par exemple, la flexibilité de Backbone me fait un peu douter, je suis un homme de
convictions conventions. À contrario, la "learning curve" mauvaise d'Angular et d'Ember ne me rebutent pas telle qu'elle est affiché. "Un jeu d'enfant lors de sa prise en main, puis devient difficile pour des tâches plus précises" ? je code en CakePHP
*, j'ai vu pire.
Je doute de Backbone, le rapport final de l'article finit de me convaincre (mais je l'aurais sans doute retiré même sans ça). Je retire CanJS pour... une question de popularité, afin de garder deux finalistes. Il semble aller au fond des choses, mais là encore je préfère penser à long terme, et pas seulement pour l'appli : je suis en CDD actuellement, qu'est ce qui fera le mieux sur mon CV après ça entre Angular|Ember et CanJS ?
Reste donc deux frameworks proposés. Je fais de nouvelles recherches plus précises, et pour couper court à tout suspense, Angular en ressort vainqueur. J'aime bien le html déclaratif, ça change que d'utiliser les data-items pour tout et pour rien (et surtout en dehors de leur champ d'application). De plus Angular semble plus proche d'un travail de dev frontend, comme on le fait déjà par ex en ajoutant jQuery à son application.
Je suis après tombé sur des articles où les utilisateurs d'Ember lui reprochent d'être difficile à utiliser, trop rigide, moins adapté à leurs habitudes. Les devs en semblent conscients et veulent travailler sur cet aspect, tout en rappelant que Ember n'est pas adapté sur on veut un framework JS qui fonctionne sans avoir à changer sa manière de penser. Et l'extension du html au lieu d'ajouter un langage de template me séduit : d'accord, je ne suis pas un dev frontend, mais je ne comprends pas qu'on puisse aimer Smarty. Ça me parait aussi moche que ceux qui écrivent
<?php echo '<td>'.$var.'</td>'; ?>
Plutôt que :
<td><?php echo $var; ?></td>
(et ne me parlez pas de...)
<?php echo "<td>$var</td>"; ?>
Pour ces raisons, quelques comparatifs Angular/Ember (modulo mes goûts personnels), et ton avis détaillé qui finit de me convaincre, on part sur AngularJS épicétouhallonzyalonzo.
* CakePHP en un exemple :
« Je veux faire un gâteau au chocolat, comment faire ? »
« Tapez "make_cake_chocolate" »
« Wow, c'est facile ! et pour ajouter de la chantilly ? »
« Tapez "make_cake_chocolate+chantilly" »
« Super ! et pour ajouter des fraises dedans ? »
« Ah ? euh... suivez la procédure dans la doc... ça doit être dans les 30 pages de "ajouter des fruits dans un gâteau", ou l'annexe II, III et IV de "complexifier la recette"... à moins qu'en fait il faille faire des fraises d'abord et y ajouter un gâteau ensuite... vous avez cherché sur stack ? »