Salut,
J'ai un projet d'application web open source qui pourrait plutôt bien marcher, mais j'aimerais qu'il soit capable d'attirer les contributeurs pendant longtemps. Pour ça, j'aimerais trouver une techno front qui ne soit pas trop exotique (pas d'Aurelia), pas trop complexe (pas d'Angular), toujours suffisamment active, et j'aimerais être sûr qu'elle soit encore intéressante pour plusieurs années, j'ai pas envie que le projet soit abandonné à cause de la techno devenue obsolète.

Vous conseilleriez quoi de suffisamment léger pour que l'apprentissage du framework soit quasi transparent ?

T'es pas obligé de partir sur un Framework. Tu peux combiner des libs entres elles, comme ça, si dans le futur des solutions bien meilleures viennent à voir le jour, tu pourras ne remplacer que certain briques de ton App.

Niveau vue, je pense que t'es tranquille si tu pars sur React voire Vuejs.
Après pour tout le reste ça va dépendre de ton projet. Tu veux faire quoi exactement ?

Je rejoins LECROU, sauf pour React : si Angular représente ta limite de complexité, alors tu oublies React : la courbe d'apprentissage de React est un peu violente (mais l'outil vaut le coup).

Penche-toi éventuellement sur Ember, ou Backbone, un peu vieillissant mais solide.

Je trouve React bien plus accessible que Ember, Angular, et autres frameworks du genre. Le truc c'est qu'il a des mauvaises pratiques à éviter avec React. D'ou l'utilisation d'une architecture qui s'appelle le Flux. Pour te faciliter l'utilisation de React et la mise en place du Flux tu devrais choisir un "framework de flux" en quelque sorte. Je te conseille Redux, le plus prometteur en ce moment.

Donc je te conseille React + Redux pour le front. Certes tu auras deux fois plus de choses à apprendre mais le jeu en vaut la chandelle. Niveau techno front end c'est ce qui émerge le plus en ce moment. Utilises un boilerplate aussi pour éviter d'écrire les bases, les fondations du projet.

Et de toute façon si tu cherches quelque chose de facile à apprendre il y aura de boulot de ton côté à faire. Le C est très simple, mais imagine le travail qu'il y aurait à faire pour faire un site en C...

Le 25 juin 2016 à 09:53:56 LECROU a écrit :
T'es pas obligé de partir sur un Framework. Tu peux combiner des libs entres elles, comme ça, si dans le futur des solutions bien meilleures viennent à voir le jour, tu pourras ne remplacer que certain briques de ton App.

Niveau vue, je pense que t'es tranquille si tu pars sur React voire Vuejs.
Après pour tout le reste ça va dépendre de ton projet. Tu veux faire quoi exactement ?

C'est une bonne idée, mais je vois mal ça utilisable en pratique. Le "remplacement de bibliothèque" c'est une belle histoire mais en pratique j'ai jamais vu ça applicable nulle part sans un gros refactoring de l'appli (même en respectant les bonnes pratiques avec adapters, proxies, etc.), et pour les libs front JS ça me parait encore pire à ce niveau là.

Vuejs revient souvent en ce moment, je vais voir ce que ça donne !

Le 25 juin 2016 à 10:47:32 lisarael a écrit :
Je rejoins LECROU, sauf pour React : si Angular représente ta limite de complexité, alors tu oublies React : la courbe d'apprentissage de React est un peu violente (mais l'outil vaut le coup).

Penche-toi éventuellement sur Ember, ou Backbone, un peu vieillissant mais solide.

Étonnamment je trouve React beaucoup plus facile à utiliser qu'Angular. Les concepts sont plus complexes (basiquement Angular c'est que de l'injection de dépendances...) mais Angular est tellement foutoir et magique que ça le rend super relou à apprendre

Pour Backbone pourquoi pas après tout, dans le genre simple c'est vrai que ça tient la route. Ember je connais pas du tout, je vais voir à y jeter un coup d'oeil, mais le côté vieillissant me rebute un peu. Un exemple que j'ai en tête c'est Wekan (un trello like) qui utilise Meteor et qui n'a plus d'évolutions parce que plus personne ne fait de Meteor aujourd'hui (ou presque)

Le 25 juin 2016 à 12:22:36 EncoreUnNouveau a écrit :
Je trouve React bien plus accessible que Ember, Angular, et autres frameworks du genre. Le truc c'est qu'il a des mauvaises pratiques à éviter avec React. D'ou l'utilisation d'une architecture qui s'appelle le Flux. Pour te faciliter l'utilisation de React et la mise en place du Flux tu devrais choisir un "framework de flux" en quelque sorte. Je te conseille Redux, le plus prometteur en ce moment.

Donc je te conseille React + Redux pour le front. Certes tu auras deux fois plus de choses à apprendre mais le jeu en vaut la chandelle. Niveau techno front end c'est ce qui émerge le plus en ce moment. Utilises un boilerplate aussi pour éviter d'écrire les bases, les fondations du projet.

Et de toute façon si tu cherches quelque chose de facile à apprendre il y aura de boulot de ton côté à faire. Le C est très simple, mais imagine le travail qu'il y aurait à faire pour faire un site en C...

J'avoue que j'ai aussi un bon feeling sur le couple React-Redux pour l'avenir moi aussi, mais c'est quand même un commitement assez important. Je vais voir pour y réfléchir aussi

Pour Backbone pourquoi pas après tout, dans le genre simple c'est vrai que ça tient la route. Ember je connais pas du tout, je vais voir à y jeter un coup d'oeil, mais le côté vieillissant me rebute un peu. Un exemple que j'ai en tête c'est Wekan (un trello like) qui utilise Meteor et qui n'a plus d'évolutions parce que plus personne ne fait de Meteor aujourd'hui (ou presque)

J'utilise Meteor sur quelques projets dans l'agence web où je bosse. On en parle beaucoup moins qu'avant, c'est plus aussi "hype" qu'il y a un an mais ça reste tout de même un framework très intéressant.
Les dernières mises à jour ont contribué à le rendre plus évolutif en le faisant migrer totalement vers npm plutôt que de forcer les utilisateurs à avoir un écosystème séparé pour ses packages.

Le plus problématique reste le scaling de ton app, mais franchement, à moins d'avoir un énorme succès, tu devrais être tranquillle.

Le 25 juin 2016 à 13:51:13 Childermass a écrit :

Le 25 juin 2016 à 09:53:56 LECROU a écrit :
T'es pas obligé de partir sur un Framework. Tu peux combiner des libs entres elles, comme ça, si dans le futur des solutions bien meilleures viennent à voir le jour, tu pourras ne remplacer que certain briques de ton App.

Niveau vue, je pense que t'es tranquille si tu pars sur React voire Vuejs.
Après pour tout le reste ça va dépendre de ton projet. Tu veux faire quoi exactement ?

C'est une bonne idée, mais je vois mal ça utilisable en pratique. Le "remplacement de bibliothèque" c'est une belle histoire mais en pratique j'ai jamais vu ça applicable nulle part sans un gros refactoring de l'appli (même en respectant les bonnes pratiques avec adapters, proxies, etc.), et pour les libs front JS ça me parait encore pire à ce niveau là.

C'est beaucoup plus simple que de remplacer tout un framework. Là tu ne changes qu'une brique. Et si tu as bien développer tes modules, il n'y a que les interfaces qui changent. Donc en fait si c'est difficile c'est de ta faute et non des libs utilisées. Et j'ai déjà eu à faire ce genre, de choses, c'est pas si compliqué que ça si tu as bien réfléchi à ton architecture logicielle. Regardes du côté des microservices. Je trouve que l'assemblage de libs est dans l'esprit de ce type d'architecture.

Certes React + Redux ça demande un investissement important, mais bon c'est ça l'info je ne t'apprends rien. Sinon je te conseille surtout de te mettre à l'ES6. C'est généralement le point bloquant des personnes qui apprennent un framework ou une lib JS aujourd'hui

Allez, après un peu de réflexion je pense partir sur React + Redux, ça fait un moment que ça me titille, j'ai pas encore eu l'occasion de les utiliser sur un vrai projet

Merci !