Zeste de Savoir et le futur du front

Bonjour tout le monde,

Voici un sujet dans lequel j'aimerais que l'on parle de l'organisation de Zeste de Savoir. Ceci peut impliquer des considérations techniques, mais l'origine de ces considérations doit être l'organisation, pas la technique elle-même.

L'état actuel du front

Commençons par faire le point sur ce qu'on a et ce que ça implique. Ici nous n'avons que des faits.

Le point de vue fonctionnel

On a un front qui marche pas mal, d'un point de vue utilisateur. On pourrait améliorer certaines chose, mais on peut toujours améliorer, et certaines améliorations sont déjà prévues (refonte de la page d'accueil, etc).

En soit c'est une grosse victoire et une excellente chose, pour laquelle je ne peux que remercier tous ceux qui ont contribué à ce qu'on en arrive là.

L'équipe de développement

Aujourd'hui elle est principalement constituée de Alex-D et Sandhose, ce qui est peu.

Les choix technologiques

Aucun framework n'a été utilisé : tout est 100% custom. Le fait est que ça fonctionne et que ça semble plutôt efficace en terme d'expérience utilisateur, si j'en crois mon peu d'expérience dans le domaine.

Les problèmes en cours et futurs

Si j'en crois les quelques points ci-dessus, tout est plutôt positif : ça marche et ça semble efficace. Sauf que… des problèmes pointent leur nez.

Zeste de Savoir n'est pas un projet intéressant pour son front

C'est un fait : on se contente d'afficher des données. Il y a très peu de dynamisme, et le but ne sera jamais d'en faire une application web. En fait, la seule partie intéressante techniquement qui pourrait se développer à court ou moyen terme c'est les outils de rédaction de tuto ; le reste n'est que design et montage HTML – ce deuxième point n'étant pas une activité transcendante mentalement.

Sources : [1], [2] et autres.

Conséquence : on manque de développeurs front

Sandhose est pris par d'autres occupations et le manque d'intérêt technique ne le motive pas à s'investir plus, ce qui est tout à fait compréhensible.

Alex-D, quant à lui, songe à réduire très fortement sa participation. Bien que ce ne soit pas la première annonce en ce sens, le fait qu'elle soit publique et répétée me fait dire que celle-ci est sérieuse, que ce n'est pas un coup de tête.

Zeste de Savoir doit donc s'en trouver de nouveaux. Sauf que…

Les pratiques diversifiées du monde du front

Dans le monde du front, on a des pratiques très diversifiées là où le back est souvent plus cadré (PEPs Python, conventions en Java, etc.). Résultat : reprendre un existant, c'est souvent devoir se faire à un style qui n'est pas le sien… ce qui est rarement motivant.

Nous sommes donc prisonniers des choix faits par le développeur principal, qui a utilisé les techniques qui lui seyaient le plus.

C'est d'autant plus vrai qu'ici…

Pas de framework

…on a pas de framework pour assurer une base connue (conventions minimales), mais un code 100% maison. Qu'il faut donc s'approprier de A à Z.

Ceci ne signifie pas que c'est compliqué ; mais la marche reste présente, au moins psychologiquement. C'est d'autant plus vrai que…

La documentation est quasi-vide

… la documentation du front est très loin d'être finie au moment où j'écris ces lignes.

Même si je passe outre les problèmes de placement de cette doc (rangée avec les autres ou non) et que je considère que le menu est complet, j'ai :

• 19 catégories de documentation au total
• 5 sont identifiés comme "complètement finis", soit 26% – dont l'installation qui est déjà détaillée par ailleurs
• 4 sont identifiés comme "en cours de rédaction", soit 21%, et dans des états très variables
• 10 sont identifiés comme "pas commencés", soit 53%

J'ai donc environ 1/3 de la documentation nécessaire pour que le "framework maison" soit utilisable par un tiers sans demander de l'aide ni perdre du temps à comprendre comment il fonctionne par rétro-ingénérie.

Le front a mauvaise réputation

Ce problème est encore accentué par la mauvaise réputation du développement front tel qu'on en a besoin sur Zeste de Savoir : le découpage et l'intégration HTML sont inintéressants. Qui a envie d'occuper son temps libre à gérer des pinaillages de CSS et des bugs JS incompréhensibles sur la version X.Y.Z du navigateur exotique Lambda ? Personne et ça se comprend.

Ce vers quoi devrait tendre Zeste de Savoir

Mon avis à ce point de la réflexion est le suivant :

Ceci passe bien sûr la rationalisation des outils de développement, mais pas seulement. Cela passe aussi par un système d'intégration front souple (dans son utilisation et son évolution) et facile à appréhender, ce qui implique entre autres, mais pas que, une excellente documentation.

Or, ce temps libre et cette volonté ne sont pas extensibles à l'infini !

Des idées de solutions ?

Voici les deux premières idées qui me viennent par la tête.

Garder le non-framework actuel et faire une documentation qui poutre

Avantages :

• C'est pas le plus long à faire
• Aucun risque de régression

Inconvénients :

• Je ne sais pas si le code actuel du front est souple et extensible. Dans quelle mesure va-t-il nous contraindre par la suite ?
• Cela laisse une marche d'apprentissage (ne serait-ce que psychologique) importante, surtout pour le contributeur occasionnel

Tout réécrire en utilisant le Très Connu framework Lambda

Oui, je mets les pieds dans le plat, mais c'est une hypothèse que j'envisage très sérieusement.

Avantages :

• Le framework est connu, ça rassure tout contributeur (surtout l'occasionnel)
• On a toute la doc du framework qui existe
• On a la communauté du framework et tout ce que ça implique

Inconvénients :

• La grande masse de travail pour tout convertir
• J'imagine qu'il faut réussir à ne pas casser le framework, sans quoi il deviendrait un boulet
• Le site sera sans doute un peu plus lourd à charger (quoiqu'avec les fichiers du framework servis par des CDN et cachés dans les navigateurs, ceci reste à mesurer)

Autre, précisez :

Quand j'ai découvert ZDS, je me suis demandé comment apporter ma pierre à l'édifice. N'ayant que peu de connaissance en Python/Django et que peu de temps à disposition, je me suis dit que j'allais essayer de contribuer au front. Mais je ne l'ai pas fait. Pourquoi ? Je vois trois principales raisons à cela (dans un ordre quelconque) :

• Un manque de temps de mon côté
• Une absence de documentation ou son caractère incomplet.
• Essentiellement du bugfix

Concernant l'absence de documentation ou son caractère incomplet, je pense que malgré toute la bonne volonté du monde et tous les efforts possibles, la qualité de la documentation d'un framework maison n'atteindra jamais celle d'un framework très connu. Par exemple, si j'ai envie de m'occuper de l'intégration de la nouvelle page d'accueil, je me dis qu'il va falloir utiliser le système de grille du framework maison, mais je n'ai rien trouvé à son sujet dans la documentation. Du coup, je vais passer un temps fou (que je n'ai pas forcément à ma disposition) pour essayer de reverser engineerer cette partie du framework.

Concernant le fait que la plupart des issues avec le label front soient du bugfixing, personnellement j'ai peur d'introduire un nouveau bug en en fixant un. En effet, il me semble assez complexe pour une personne extérieure à la conception du framework de juger si le bug est dans le framework ou dans la customisation de celui-ci, vu que la limite entre les deux est très floue dans le cas d'un framework perso. Et faire du bugfixing, c'est vraiment ce qu'il y a de moins intéressant et de plus chiant à faire en front. Et à tout moment, il faut disposer du bon navigateur sous le bon OS pour ne serait-ce que reproduire le problème.

Vous l'aurez compris, je suis plutôt en faveur de l'utilisation d'un framework connu, ce qui permet au développeur front de s'affranchir de la plus grosse partie de l'écriture de la doc. Mais la quantité de travail à abattre pour migrer vers un framework connu me semble énorme, et envisager une migration sans figer l'évolution du (front du) site pendant ce temps soit possible : qui voudra intégrer une nouvelle page/feaure dans l'ancien framework alors qu'une migration est en cours (et ce pour un temps indéterminé) ?

Et il y a un point qui je n'ai vu abordé nulle part, c'est ce qui vient avant le développement front : la réalisation de la maquette. Aujourd'hui, j'ai cru comprendre que toutes les maquettes ont été faites par Alex-D, et lorsqu'il aura réduit son implication dans le projet, il va également falloir trouver quelqu'un en mesure de le remplacer. Et un dev front n'est pas forcément un bon designer…

Il nous faudra évidement un designer ou ergonome pour nous guider sur les nouvelles pages. Mais pour moi :

1. C'est en plus du front, l'un n'empêche pas l'autre, c'est un recrutement indépendant. Dans tous les cas on a plus personne pour faire l'intégration dans quelques semaines / mois.
2. Il y a pas des nouvelles pages tous les jours, c'est moins urgent.

Pour le reste, je suis d'accord avec l'analyse. On a un front "peu motivant" et des ressources en développeurs nulles d'ici peu. Il faut qu'on trouve des solutions.

En ce qui concerne les deux propositions, je suis d'accord que les deux doivent être considérées. Je ne souhaite pas donner d'avis précis pour le moment (moi et le front ça fait 42).

tl;dr

• Les bugfixs, doc ou pas, framework ou pas, c'est à la portée de tous
• Je préfère la framework maison
• J'attends l'API avec impatience

Comme l'a souligné btw03, le front, c'est beaucoup de bugfix en ce moment.

Et très honnêtement, et c'est la l'avantage peut-être du front par rapport au back, la plupart des bugs sont très facilement localisables. Exemple:

En se basant sur cette issue. La marche à suivre pour la résoudre est la suivante (en supposant que l'installation locale soit correcte):

• Dans l'inspecteur Chrome, on simule un mobile
• On inspecte l'élément en question
• Il y a la liste des règles CSS qui s'appliquent, avec la ligne ; on regarde dans le fichier main.css la ligne en question.
• Du fait que le main.css soit pas minimifié, ca garde une bonne structure des blocs. On regarde le bloc "parent", et il y a comme commentaire "ALL: Main / Forum topic, MP list".
• Le ALL correspond au fichier "all-support.scss" (suffit d'avoir navigué 5min dans les fichier pour comprendre ca, c'est même expliqué dans la doc l'orga des fichiers). Un petit Ctrl+F la dedans, et le tour est jouer!
• Le reste, framework ou pas, documentation ou pas, faut quand même connaitre un minimum le CSS/SASS pour pouvoir résoudre le bug…

Et il ne s'agit pas d'un cas isolé, la plupart des bugfixs se font comme ca. Alors on peux expliquer dans la doc cette démarche, mais sérieusement, j'ai pas trop envie d'apprendre aux futurs contributeurs à coder…

Maintenant, je sais que vous êtes en grande partie en faveur d'une framework. Le problème est qu'une framework, du fait qu'elle se doit le plus universelle possible, demande un structure bien stricte, mais surtout un nombre d'élément énorme. En plus, toutes les framework aujourd'hui se basent sur une grille. Ce site n'utilise pas de grille de ce type, mais juste un layout à deux colonnes. Voila 50% de l'intérêt et du code de framework envolé.

L'autre moitié intéressante d'une framework, c'est son UI-kit. Si on part sur bootstrap par exemple, on est parti pour override toutes les règles pour l'UI. Des boutons à la nav, en passant par les modales et les inputs. Autant dire que c'est pas l'idéal, autant niveau masse de boulot que niveau que niveau perfs: le navigateur va juste passer 2x plus de temps à calculer les règles…

S'il y a une chose qui mérite d'être clarifiée et documenté de mon point de vue, c'est les vues. Je passe réellement plus de temps à chercher dans quel bloc de quelle vue cette partie de la page se trouve… Ne connaissant pas réellement Django, ni le moteur de template qu'il utilise, c'est pour moi un réel frein pour un dev front "pur".

Il y a aussi la question du front pas intéressant. J'ai profité du meeting d'hier pour parler de l'API avec Andr0. Il m'a dit que l'on peut espérer un début d'API pas avant quelques mois. Si on veut rendre le front intéressant (je vais pas vous mentir, ça serait surtout pour moi, histoire que justement, mes contributions pour le front ne soient pas que des bugfixs…), il va falloir le repenser en partie, et éventuellement commencer à se baser sur un truc type AngularJS ou React. On aurait beaucoup de choses à dynamiser, genre le karma des posts, l'heure relative affichée un peu partout, les MPs et notifs, l'apercu markdown de l'éditeur…

Le problème est que pour tout ça, il nous faut un support: l'API.

Je sais que vous êtes concentrés sur des tas d'autres trucs, et que votre intérêt pour l'API est peut-être limité en tant que dev back, mais personnellement, ça me pousserait réellement à me remettre dans le projet. Si vous pouviez vous focaliser la dessus, qu'on ai de quoi bosser correctement, je vous assure que le front serait plus actif.

J'vais même plus loin, le jour ou on a une API, je promet… de… mettre en place des Unit Tests pour le front!

Z'êtes sur que vous voulez pas ? Alleeez!

Plus sérieusement, si j'ai la garantie que cette API deviendra un point prioritaire (je parle vraiment pas d'une API pour les clients tiers, juste une API pour sur le site même), je veux bien me remettre dans le bain dès maintenant, et faire du bugfix, et préparer le terrain en attendant… J'suis même prêt à faire de la doc si ca peut faire venir l'API plus rapidement

Donc voila, vous avez mon point de vue sur la question. J'espère que ca fera un peu bouger les choses

Sandhose

Salut !

Je suis désolé j'ai lu en diagonale les réponses (mais très précisément l'OP) car vous avez déjà sorti de beaux pavés.

Pour faire simple, je compte restructuré le code actuel pour lui faire suivre une logique composant plutôt que responsive : actuellement le code est réparti globalement par rapport au devices touchés. On se retrouve, malgré des commentaires, avec un fichier principal de 15km de long. Ca reste lisible, mais c'est toujours mieux quand c'est découpé, surtout que c'est juste du déplacement de code, ça se fait assez vite et ça clarifie les choses.

Framework or not framework ?

Alors, vous le savez, j'ai toujours été contre. Sauf qu'au boulot on m'impose Bootstrap. Sauf que je ne l'ai pas utilisé. La réalité est que ce que les gens veulent de bootstrap, c'est sa grille. Tout le reste c'est globalement pas utilisable (à part les conventions de nommage, mais du coup c'est déjà pas mal le cas).

Donc, il faut savoir que le site est basé sur une structure qui est relativement unique en son genre : ça prend toute la largeur, mais pas sur toutes les pages et ça reste tout de même responsive.

Donc ma solution est simple : inclure uniquement la grille Sass de Bootstrap et refondre tout ce qui peut l'être au niveau des largeurs.

Aussi, il faut que je rajoute une couche d'abstraction pour que les styles spécifiques à des balises sautent et permettent de changer le HTML sans péter le style.

En gros, si ça c'est fait, le front sera opé sans avoir besoin de tout se retaper pendant 10 mois.

Pourquoi passer totalement sur un Framework est une fausse solution ?

En gros, le seul argument que vous avez est : il y a une doc et une communauté. Mais vous oubliez à quel point nos besoins sont spécifiques, et à quel point j'ai passé des heures à tout réglé au poil de partout. La plupart des bugs qui restent sont autour des formulaires, parce que toujours pas de template pack.

Un framework, il faut le connaître sur le bout des doigts pour charger uniquement ce dont on a besoin. Mais, le site est bourré de besoins spécifiques : prenez un message du forum, à faire avec un framework c'est un enfer.

Pourquoi je n'aime pas les framework : parce que j'ai pu voir ce que ça donne : on modifie le HTML à tout va avec des dizaines de classes sur chaque balise HTML pour avoir le rendu qu'on veut. On se retrouve avec une hyper dépendance entre les éléments. Cette approche est géniale pour UNIX où chaque commande fait ce qu'on lui demande. Elle est horrible quand il s'agit de parser le HTML et appliquer les 189339 styles à chaque éléments là où ça peut être plus court de le faire "à la main".

En gros, je vais tenter d'assouplir la chose, mais gardez bien en tête qu'un dev back qui touche au front, framework ou pas, c'est l'assurance d'avoir quelque chose de désoptimisé (même chose quand un front touche au back, notez bien).

J'ai énormément bossé sur l'optimisation du front (templates, styles, JS, compression, mobile first, …) ce qui rend la chose tantôt simple tantôt complexe selon ce qu'il faut toucher.

Ultime question : est-ce qu'il est vraiment nécessaire d'avoir des dev dispos activement sur le projet sachant que le truc tourne et qu'après la page d'accueil, c'est de la refonte back qui arrive ?

En gros, est-ce que vous ne pensez pas que même de loin j'arriverais à tenir la charge (puisque faible) ?

Pourquoi cette proposition : tous les projets sur lesquels je bosse en ce moment où sont passé plus de 1 intégrateur sont un enfer. Même avec des commentaires et doc béton, ça n'y change rien, honnêtement.

@sandhose : l'API c'est comme tout le reste, comme toutes les autres zep, fonctionnalités ou bugfix, ça a la priorité qu'on lui accorde. En l'occurrence je pense que tout le monde est d'accord pour dire que l'API est une killer feature. Le problème est qu'encore hier les 2-3 personnes qui s'occupent de ces zep (cf zep17) se plaignaient de ne pas avancer par manque de retour extérieur. Sur ce point ce n'est même pas un problème de priorité ou de manque de dev, c'est un manque de retour utilisateurs qui la bloque.

Donc pour faire avancer l'API la meilleure chose a faire est d'aller commenter la zep17.

[\hs]

Plop !

Pour ma part, deux choses m'empêchent de contribuer au front autrement que par des issues Github :

1. l'absence d'un framework. Bon, ok, ceux qui me connaissent savent que je suis un Bootstrap lover, mais je pense que n'importe quel framework front reconnu peut faire l'affaire. Après, comme le dis Alex, un framework ne fait pas tout. C'est clair. Mais au moins pour le système de grille, ce serait un gros plus. Cela éviterait, à chaque sortie du nouvel iMachin ou iTruc, de remettre en question son css pour savoir si oui ou non il suivra le comportement prévu.

2. tous les outils qui gravitent autour du front. Je suis peut être de la vieille école, mais j'ai l'impression que c'est le parcours du combattant pour modifier une ligne de CSS. Sans nier le bien fondé de ces outils, et par là même mon incompétence à les utiliser, il me semble que c'est clairement rédhibitoire pour un contributeur lambda qui veut juste proposer trois lignes de CSS.

Pour la documentation front, clairement elle mériterait d'être mise à jour, après je ne jette la pierre à personne, on a tous une vie à côté de ce site.

Concernant ta proposition Alex de ne pas recruter d'autres front, clairement, je suis sceptique. Ce n'est pas contre toi c'est juste une question d'organisation du projet. On est un gros projet et il y a encore beaucoup a faire, je ne pense pas qu'il n'y ai que de la maintenance a faire. La zep3 est un exemple de nouvelle page et il y en aura probablement d'autres. Jusque la tu faisais le gros du taf et on savait qu'on avait sandhose qui était derrière en sécurité si on avait une urgence front et toi indisponible. La ce sera moins évident.

Il reste des bugs front, en partie sur mobile où par exemple la liste des sujets sur un forum sont totalement décalés vis a vis de la grille. C'est pas bloquant mais mais c'est un exemple pour montrer qu'il reste encore a travailler.

Je pense que sur chaque partie on a besoin de plusieurs personnes formés et apte a intervenir. C'est valable quelque soit la partie.

Passer a un framework classique me semble très coûteux et va prendre du temps alors que justement on a pas de dev front. Donc en pratique cette solution me semble utopique car on a pas les ressources pour le faire actuellement. Mais il n'empêche qu'on va manquer de dev front. Même si le gros est en place, même si c'est pas sexy de bosser sur le front de ce site, même si on a pas encore d'Api pour le rendre plus dynamique, … Il nous faut des dev front de plus dispo pour être tranquille.

Je pense qu'aujourd'hui on est tous plus tranquille que firm1 ne soit plus le seul a intervenir sur le back. Même si il reste des modules qu'il est le seul a totalement maitriser, au moins maintenant certains sont capable d'intervenir a peu prêt partout. J'aimerai la même chose pour le front, tout comme sur le markdown qui est encore trop dépendant de moi.

RE-HS : Une feature ne doit pas être développé pour faire un recrutement ou faire plaisir a qqun. Je vois pas pourquoi on irait mettre plus d'effort sur l'API "parce que ça nous promet l’arrivée d'un autre dev' front". C'est a mon sens un contre-sens même avec l'esprit du site : Avoir un esprit communautaire. On ne joue pas pour soi uniquement.

Pour tous : Le bugfix n'est pas drôle. Que ce soit pour du front ou du back. (et non, ce n'est pas a la portee de tous. Je connais HTML/CSS/SASS et pourtant il y aurait plus de risque que j'introduise un nouveau souci en en corrigeant un )

Le PO analyse plutôt bien la situation.

Mon avis est assez simple sur la situation, il existe des Framework qui ont été éprouvé largement et donc c'est leur métier de s'assurer que ça fonctionne d'emblée partout, et sur presque toutes les tailles. Quand on ouvre le fichier all-support.scss, il fait des kilometres de long, et sans la doc, il faut le vouloir vraiment pour s'y plonger. Or ici ma vision d'un projet comme ZdS est qu'il soit accessible naturellement, dans le cadre du front-end ce n'est pas le cas. La barrière psychologique a été évoquée par le PO juste titre.

Pour moi, ça fait depuis longtemps qu'on devrait clairement s'orienter vers un Framework Css (Bootstrap, Foundation, etc.) et ce concentrer sur les parties les plus intéressantes du front-end.

Je rejoins Kje aussi, le meilleur moyen de contribuer à l'API aujourd'hui est de commenter les discussion sur les ZEPs, sinon ça tourne en rond.

RE-HS : Une feature ne doit pas être développé pour faire un recrutement ou faire plaisir a qqun. Je vois pas pourquoi on irait mettre plus d'effort sur l'API "parce que ça nous promet l’arrivée d'un autre dev' front". C'est a mon sens un contre-sens même avec l'esprit du site : Avoir un esprit communautaire. On ne joue pas pour soi uniquement.

Je suis assez d'accord mais je rebondissais sur sa remarque qui sous entendais qu'on en avait rien a faire de l'API. Or en réalité je pense que tout le monde est d'accord pour dire que c'est un must have et une killer feature. Et ceux qui suivent les zep en question savent que ça avance. Mais le gros soucis est qu'il y a très très peu de retour sur les propositions faites. Il y a 3 personnes qui commentent activement (andro, javier et firm1) et moi qui suit de loin en aidant du peu de connaissances que j'ai des API. Je le disais, pas plus tard qu'hier ces contributeurs regrettaient que personne d'autre ne viennent contribuer en commentant les specs prévus et qui posent encore des interrogation. Donc le fond de ma pensée était : Au lieu de se plaindre des dev back qui feraient volontairement trainer le développement de l'API pour emmerder les fronts, il serait plutôt pertinent d'aller sur les zep concernées et mettre la main à la patte. L'avis d'un dev front utilisateur de ces api serait très utile !

Concernant ta proposition Alex de ne pas recruter d'autres front, clairement, je suis sceptique.

Ah nan mais s'il y a des gens motivés, pas de soucis. Ce que je veux dire c'est que dans le doute, j'estime que ça reste maintenable même en suivant le projet de loin.

Il reste des bugs front, en partie sur mobile où par exemple la liste des sujets sur un forum sont totalement décalés vis a vis de la grille. C'est pas bloquant mais mais c'est un exemple pour montrer qu'il reste encore a travailler.

Il y a déjà un hotfix en validation.

Pour moi, ça fait depuis longtemps qu'on devrait clairement s'orienter vers un Framework Css (Bootstrap, Foundation, etc.) et ce concentrer sur les parties les plus intéressantes du front-end.

En fait, très honêtement, en vous lisant ça fait très "un framework va résoudre tous nos problème" alors que pas du tout. Le site est bourré de spécifique, donc il faudra surcharge le framework de partout et au final, il ne restera que la grille (et encore… le design actuel ne tient ni sur une grille 12 ni une 16) et des conventions de nommage.

et ce concentrer sur les parties les plus intéressantes du front-end.

Aucune partie de ce site n'est intéressante pour ce qui est du front-end.

Résumé : faites ce qui vous chante. Mais personnellement je ne passerais pas sur du 100% Bootstrap sous prétexte que ça serait plus maintenable alors que non. Si quelqu'un a envie de se farcir toutes les templates et refaire tout le style pour que ça colle à un framework, qu'il le fasse. Mais pour moi ça n'est pas une solution magique.

Globalement, les bugs encore présents sont :

• des bugs introduits lors des dernières updates
• des choses qui n'ont jamais été traitées

Framework ou pas, ces bugs seraient les mêmes.

tous les outils qui gravitent autour du front.

Eh bien, saches que même si on passait sur du full Bootstrap, la pile d'outils serait la même. Ça peut paraître étrange, mais ce sont des outils de build, le compression, d'optimisation, etc.

Il ne me semble pas envisageable de remettre en question la nécessité de ces outils (leur rôle, pas leur techno ou mise en oeuvre).

Comme précisé plus haut par les autres, il y'a aussi :

• la documentation complète , et la communauté autour d'un Framework.
• les outils déjà pré-disponible dans un Framework
• le fait qu'il existe déjà des template-pack qui permettent d'interfacer les gros Frameworks du marché (bootstrap, foundation) avec notre gestionnaire de formulaire "crispy-forms" coté back-end

Améliorer l'outil de rédaction est déjà quelque chose d'assez intéressant par rapport au reste (modifier des couleurs et placer des liens).

Merci pour le PO et l'explication plutôt claire des choses

Framework ou pas framework

Etat des lieux : le choix à t0

Vaste question. Je l'ai dit dans l'autre topic, si j'avais "conçu" ZdS j'aurais sans doute choisi un framework. D'abord parce que je suis mal à l'aise avec le CSS et les mediaqueries, ensuite pour éviter le genre de discussions qui se trament aujourd'hui.

Dans un projet comme celui-ci (et plein d'autres à vrai dire), c'est un garde-fou, un moyen de se "percher" pour éviter de se faire ruer dans les brancards à la moindre occasion. "Ce que tu as fait est naze" "C'est pas moi c'est Bootstrap". Bon on en n'est pas là, mais c'est l'idée.

Maintenant, ce qui est fait est fait. Et vu le résultat, c'est plutôt très bien fait. Donc il faut conjuguer avec.

Je ne suis pas tout à fait d'accord avec toi Alex par contre sur le "on se retrouve avec 50000 classes sur un élément". Quand tu viens du back, et j'aurais tendance à dire quand tu as pas mal d'expérience dans d'autres choses que le front, tu préfère une approche déclarative des choses, proprement découpée. Ça ne me gène pas de voir que le champ de réponse est un .field, avec un .spacer-top, qui prend toute la largeur de l'écran .full-width, qu'il a une hauteur minimale .medium-default-height, … Oui ça fait plein de classes. Mais ça se lit en regardant directement le code HTML plutôt que d'ouvrir la console Chrome pour inspecter le CSS. Pour moi un bon framework (même maison) possède cette approche déclarative. (et je suis à peu près persuadé que c'est ce que tu as fait). L'approche .textarea-reponse-message avec tout dedans me rebute totalement, ça fait des répétitions de partout. Et à ce compte là à quoi servent les classes CSS ? Donc j'ai sans doute mal saisi ton message.

Ce qu'il faut faire à t

Alex a posé les bases dans son message et je l'encourage à faire ce qu'il a dit.

Partir sur un framework, maintenant, ça me paraît inenvisageable (je peux me tromper hein, bien évidemment ça n'engage que ma propre opinion). J'ai vécu cette situation : on passe d'un intégrateur à 0, d'un framework maison à Bootstrap.

Primo, c'est énormément de travail. Vraiment, c'est considérable. Chez nous c'est un dev back que ça intéressait qui s'en est occupé. Il a sué sang et eaux pour s'en défaire. Pourtant le framework maison ne paraissait pas si éloigné que cela de Bootstrap et assez "découpé proprement". Ça a été un enfer pour lui, vraiment. Et c'est un travail d'une ingratitude assez rare. C'est long, tu passes par des étapes où tu casses absolument tout, tu te demandes si tu vas finir par t'en sortir.

Secundo, c'est un travail excessivement risqué. Ça amène inexorablement un lot de régression monstrueux. Je ne compte plus le nombre de mes interfaces qui ont été cassées lors du changement de framework. Pourtant c'était pas bien compliqué. Mais un spacer et tout fout le camp. Un clear j'en parle même pas.

Je pense qu'il faut faire une passe complète avant qu'Alex lâche du leste, avec un dev back collé à ses baskets. Et qu'il faut impérativement que la doc soit écrite par ces deux personnes.

D'une part ça sera beaucoup plus simple pour Alex. Il a le nez dedans : autant écrire de la javadoc sur mes méthodes je peux le faire seul, autant quand je rédige une spec' ou une doc API je le fais de consorts avec un client de l'API : un de mes collègues ou un client final (j'y reviendrai plus bas). Ça permet de mettre en lumière des trucs foireux. C'est normal d'avoir des trucs foireux quand on a travaillé seul sur un projet. Personne ne produit un code parfaitement maintenable et conceptuellement sans faille du premier coup, tout seul. C'est encore plus vrai pour un framework maison.

Deuxièmement, la personne qui a écrit la doc avec Alex pourra faire office de roue de secours dans le cas où Alex n'est pas là. Pas un expert, c'est certain, mais il aura une connaissance partielle du sujet "Ah oui je me souviens, c'est la classe machin qui fait ça, c'est dans la doc". De trois, ça permet une ouverture d'esprit pour les deux personnes. Un dev back qui plonge dans du front en ressort vraiment vraiment grandi, croyez-moi. Un dev front qui écrit une API-front (puisque ça revient à ça) de consorts avec quelqu'un qui a peu de connaissances dans le domaine apprend lui aussi, et ça lui ouvre généralement des perspectives "ah ouais .clear-both c'est moins lisible pour quelqu'un qui ne connaît pas le CSS que .reset-floats, je note".

Bilan, livrable : une doc avec assurance qu'elle est exhaustive et correcte (puisqu'écrite par le développeur) et compréhensible pour de futurs contributeurs (puisque co-écrite par un novice).

Pré-requis :

• du temps pour Alex, mais moins que ce qu'il faudrait pour l'écrire seul.

• du temps d'un développeur back (et c'est précieux).

• un dev back disponible qui n'a pas une vue malsaine du front (c'est rare…) et qui n'a pas de préjugé sur les méthodes des autres personnes (en gros, un mec ouvert d'esprit) : c'est plus rare qu'il n'y paraît.

• une co-opération assez efficace entre ces deux personnes.

• trouver un outil de rédaction / mise en page de doc front qui tient la route et qui ne soit pas infâme à utiliser

• choisir un outil de communication entre les deux développeurs

A vue de louche, ça pourrait se faire en 5h pour ces deux personnes. Un peu plus si ce n'est pas fait d'une seule traite. (donc forcément plus, 5h à deux sur un truc comme ça tu deviens barge).

Les BugFixes sont à la portée de tous

Non. Clairement, non.

Faut surtout pas partir dans cette optique là sinon on court à la catastrophe et à l'énervement général. Un bugfix dans du code back, si ce dernier est bien fichu, t'as à peu près l'assurance que si tu fais une niaiserie tu vas casser un test unitaire ou un test d'intégration. T'as un gros filet de sécurité. En JS c'est un peu moins le cas mais tu as des outils pour le faire (Jasmine, …) si tant est que tu touches à du JS bas-niveau. Exemple : une méthode de calcul de dates client en JS ("Il y a X heures"), ça se teste très bien et si tu casses un truc là-dedans tu le verras.

Le CSS c'est nettement plus complexe. Le seul filet de sécurité que tu peux mettre en place ce sont des tests d'intégration avec browser embarqué du style : "Je rédige une réponse à un message". Le test se déroulerait alors de la façon suivante :

• j'affiche la page du fil de discussion

• je remplis le textarea (avec du texte alakon, histoire de blinder le test)

• je clique sur le bouton envoyer

Exemple de régression détectée par ce test : un display:none sur les boutons de formulaire.

Exemple de régression non détectée par ce test : tu as foutu en l'air le layout de la page, complètement.

Les tests front sont un domaine très délicat. J'essaie de blinder autant que je le peux pour parer aux catastrophes, mais le genre de bugs qu'on pourrait rencontrer avec de nouveaux arrivants qui se viandent dans le CSS vont être du second style : en modifiant le layout de tel ou tel composant, j'ai cassé la page "à propos" (que personne va voir en pré-prod). T'as de grandes chances que ça parte en prod sans être repéré (pour peu que ce soit dans un modal perdu). Ça peut avoir des conséquences assez casse-pied (impossibilité d'uploader une image dans la galerie).

Donc non, on ne peut pas renvoyer en "les bugfixes c'est fastoche tout le monde peut le faire". Si c'était aussi simple que ça le PO n'aurait que peu d'intérêt. Il faut former des gens sur le front de ZdS, c'est vital. Et les accompagner dans le bugfix est sans doute une très bonne idée complémentaire à celle que j'ai citée plus haut.

Ça peut paraître moche de prendre les gens par la main comme cela, mais je pense que c'est la condition sine qua non de la résolution du soucis exposé ici.

Le front pas intéressant

J'ai été le premier à souligner la chose pendant la bêta. J'en ai remis une couche ces derniers temps. Oui, clairement, pour un "expert" front ce n'est pas intéressant.

Pourquoi l'API n'est pas la panacée

Déjà, parce que c'est long à mettre en place. Et ce n'est pas une question de bonne volonté. Les fonctionnalités sont nombreuses sur le site. Les exposer par API peut paraître simple de prime abord (on route un path sur une méthode qui existe déjà en lui injectant les bons paramètres). Dans les faits, le plus long dans une API c'est sa spécification. Parce qu'elle est destinée à un ensemble de client tiers (pas que le site justement) et qu'on ne peut pas tout casser comme on le ferait sur le back du site ou sur un template.

La phase de spécification pour l'API est cruciale. Et pourtant, on peut être certain qu'on va découvrir des saletés dans ses premières versions. C'est normal c'est le lot commun de tous les développeurs d'API. L'API Github est en v3, pourtant on ne peut pas considérer que ce soit un projet très ancien (un peu). Une API ça évolue au rythme des fonctionnalités ajoutées, des modifications du back, et c'est ultra sensible, car c'est pas facile à tester de bout en bout. Il faut des tests d'intégration qui passent sur chaque primitive (méthode) de l'API, en couvrant un maximum de cas possibles. Et ça, c'est extrêmement long également.

L'API à l'étude pour l'instant est celle des membres, celle qui va t'intéresser principalement c'est celle des forums. On a abattu pas mal de boulot pour poser les bases d'une API saine (ETag, pagination, cache, …) et scalable mais le gros du boulot pour chaque nouveau module va être d'en spécifier les primitives. Et il y a fort à parier que pour les tutoriels ça va être très long car il existe bon nombre de fonctionnalités à exposer aux clients.

Ensuite, c'est chouette parce que ça permet de dynamiser en utilisant React ou AngularJS. Oui. Mais là encore, va y avoir de grosses discussions et il va falloir faire attention du framework choisi. Tu n'apprécies pas l'organisation des templates de Django (et/ou celle de ZdS) par exemple, perso celle de React me rebute complètement. Avoir des bouts de templates dans le code JS je trouve cela illisible. Pourtant je comprends bien que maintenir un DOM virtuel sans cela est impossible. Ça va amener énormément de discussions et de décisions cruciales (on déclare dans des templates/directives à la sauce Angular ? ou on prend l'approche DOM virtuel de React ?) à ce moment là pour ne pas faire son petit truc dans son coin et que tout le monde soit conscient des tenants et aboutissants des choix retenus. Ça aussi, mine de rien, ça va prendre un sacré paquet de temps… :\

Comment on peut engager des gens à s'intéresser au front ?

Il faut les prendre par la main.

Et pas juste dire "je promets de […] si […]". Tu déplaces le problème en fait. La dépendance se fera sur toi et plus Alex. Mais c'est le même soucis. Pire, tu te places en porte-à-faux vis à vis de tout le monde. Et si jamais tu n'as plus le temps ou plus envie, ça risque d'agacer tout le monde avec des promesses que tu n'as (et certainement pour de très bonnes raisons) pas pu tenir.

Alex l'a dit : un seul intégrateur c'est souvent suffisant. Je serais curieux de comparer avec des projets de site web open source (j'en trouve pas des masses) pour voir combien il existe d'intégrateurs. M'étonnerait qu'il y en ait plus d'un sur un projet de la taille de ZdS.

Par contre à chaque phase de transition (inévitable hein) on va avoir ce soucis. Et l'idée c'est de mettre en place une procédure d'accompagnement qui fonctionne bien.

PS : j'ai commencé à rédiger hier, fini aujourd'hui, ça peut sembler décousu, désolé si c'est le cas. (et j'ai oublié des trucs que je voulais dire entre temps, … tant pis c'est déjà bien assez)

C'est super complet comme réponse, et je commence à mieux comprendre votre point de vue (même si c'est un peu long à lire, du coup )

Question framework

Je l'ai déjà dit dans mon message précédent, je ne suis pas sûr que l'utilisation d'une framework va réellement arranger les choses, puisque l'on risque d'override des tonnes de styles. Si je comprend bien, le problème, c'est les fichiers de 3km, et le manque de classes "universelles".

Pour les fichiers longs, si on garde la structure actuelle des fichiers, avec une framework, on risque de garder ces fichiers aussi longs, puisqu'au final, je doute qu'on ai énormément de style en moins propre à ZdS.

Du coup, pour moi, on devrait essayer de séparer autrement les fichiers de styles. Actuellement, ils sont essentiellement séparés par taille d'écran. On peut imaginer de séparer par module, et par fonction. On aurait par exemple un fichier pour tout ce qui concerne le layout de base (la sidebar, avec le contenu central), un pour le header, un pour le footer, un pour la navigation, un pour les listes (Sujet de forum/MP), un pour la mise en page du rendu Markdown, un pour l'éditeur, …

Je veux bien essayer d'élaborer une séparation plus claire d'ici la semaine prochaine, et vous me direz à ce moment la ce que vous en pensez.

Pourquoi j'insiste sur l'API

Il faut dire que ça fait un moment qu'Alex me parle limite d'une appli single-page, avec 0 réel chargement de page. Il rêve (et moi aussi ; dis moi Alex si je me trompe ) que toute la navigation, toutes les interactions se fassent par l'API. Sans aller jusque la, dynamiser ce que j'ai cité plus haut nécessiterais une framework JS (à moins qu'on fasse tout à la main, mais la c'est pire que la framework maison CSS… ). J'ai cité React pour donner un autre exemple de framework. Je pensais également me tourner vers Angular. Je sais que ça demande des discussions, et je comptais même ouvrir une ZEP par rapport à ça.

Sauf que, pour ça, on a besoin d'une base d'API. Comme je l'avais dit mardi à Andr0 sur IRC, je ne demande pas d'API complète, propre, et qui gère tous les cas possibles. Actuellement, pour le karma, la requète ce fait sur /forums/message/like/?message=[ID], et répond un JSON type {"upvotes": x, "downvotes": y}. On est d'accord que c'est pas l'idéal, et je ne souhaite pas ça pour l'API finale pour les clients tiers.

Et pourtant, ne serait-ce que ça, pour une v0 (voir une v(-1) ), pour ce que j'ai cité plus haut, pour un usage interne suffirait.

Maintenant, je sais que les choses doivent êtres clarifiées au niveau de l'API, et je vais essayer de contribuer au maximum sur les ZEPs concernées.

Par rapport au bugfix

En disant que tous le monde pouvais s'occuper des bugfixs front, je vais préciser:

Tous le monde ne peut pas forcément régler tous les bugs, mais quelqu'un qui connait un minimum le site peut facilement localiser le bug, et faire un correctif. Je ne parle pas de bugs venant du fait que certaines faces du CSS sont un peu obscures pour tout le monde, qui demandent, eux, parfois des heures, mais je pense que la plupart des bugs peuvent être fixés par à peu près n'importe quel contributeur lambda. Si le fix casse quelque chose, on a un processus de QA qui est censé éviter les régressions. Si Alex ou moi-même faisions la plupart de la QA front, je pense que l'on verrait tout de suite s'il y a quelque chose qui ne va pas dans la PR en question.

Tout ce que j'ai entendu pour le moment sur pourquoi on fait pas de bugfix, c'est "je risque de générer un autre bug". Je n'ai pas vu une seule PR front de quelqu'un d'autre qu'Alex ou moi même qui a été refusé parce qu'elle crée un bug, ou acceptée, mais qui crée un bug à côté. Il n'y a tout simplement presque aucune PR front venant de quelqu'un d'autre qu'Alex ou moi-même.

"Il faut prendre les choses en main"

D'accord. Je vais réorganiser les fichier, contribuer pour l'API, et orienter pour les bugfixs. (Nan, je déconne pas, et y'a aucun sarcasme la dedans )

J'aimerais juste que quelques devs backs (qui s'y connaissent un minimum en CSS) s'essaient au bugfix, et je serais ravi de l'aider, de l'orienter

Je poste ce message, j'ai pas eu le temps de le relire, j'ai pas eu le temps de dire tout ce que j'avais à dire, mais j'ai du partir. Je le post quand même, et je corrigerais / compléterais ce soir

Sandhose

Je veux bien essayer d'élaborer une séparation plus claire d'ici la semaine prochaine, et vous me direz à ce moment la ce que vous en pensez.

Tu as du oublier de me lire, j'ai moi-même annoncé que je vais restructurer tout ça

Attends peut-être quelques retours. J'ai proposé cette idée, personne (parmi les candidats potentiels) n'a encore émis son avis. Je pense que c'est la bonne approche, tu sembles le penser aussi, mais ça n'engage que nous deux. Faut voir avec les personnes que ça pourrait intéresser (et j'ai peur qu'il n'y en ai pas trop). Peut-être qu'ils trouveront à raison que c'est une mauvaise solution.

De mon coté, je ne vois toujours pas comment restructurer le projet va nous permettre de :

• avoir une documentation propre et élégante
• avoir un code normalisé avec des noms de classes connue (au hasard je tombe sur une balise et je vois ces classes css : my-account-dropdown mobile-menu-bloc mobile-all-links, il faut faire de la rétro-ingénierie pour comprendre)
• gagner en qualité de code : si même celui qui a conçu le moteur css du site réussi a rajouter des bugs en même temps qu'il tente d'en fixer, on est pas sorti de l'auberge.
• être plus efficace
• être autonome sur le code le jour ou Alex-D ne sera plus là.

Bref, on a des souci pour le moyen et le long terme.

Typiquement, j'ai cru voir évoqué la question de la difficulté de migration sur un framework. Pour m'être déjà essayé à l'exercice lors (ça remonte maintenant) de la première beta-privée, je me souviens que ça m'avait pris un simple week-end pour mettre en place un design temporaire à base de Framework en partant du moteur d'Alex-D. C'était certes sale au niveau css (normal c'était temporaire), mais je suis sur que si Alex-D lui même s'occupait de la migration, ça prendrait même pas 2 jours et ça sera assez propre, et bonus ultime, ça l'épargnera de faire une doc .

Pour faire simple :

• tu veux que je normalise le nom des classes et tu me sors trois parfaits contre-exemples :
  • my-account-dropdown : permet de cibler spécifique CE dropdown là (celui lié à l'avatar)
  • mobile-menu-bloc : gestion de la sidebar mobile
  • mobile-all-links : c'est pas du style mais à destination du JS pour build le menu mobile

si même celui qui a conçu le moteur css du site réussi a rajouter des bugs en même temps qu'il tente d'en fixer, on est pas sorti de l'auberge.

C'est ta façon de voir les choses. Moi je la vois autrement : j'ai fait une évolution (design des listes de topics sur mobile) qui était partiellement buguée et donc le hotfix présenté dans la foulée corrige le soucis. Ca n'est pas du bugfix mais une évol mal testée. Cf le topic sur la preprod donc.

de la première beta-privée, je me souviens que ça m'avait pris un simple week-end pour mettre en place un design temporaire à base de Framework en partant du moteur d'Alex-D

Très honnêtement, c'est limite insultant. Ce que tu avait produit était cool pour faire le dev puis la bêta back. C'était par contre très très trèèèès loin fonctionnellement de ce à quoi on est arrivé aujourd'hui, ce pour plein de raisons.

En fait c'est relativement simple, si vous accepter quelque chose proche de ma proposition, à savoir réorganiser et documenter mon code, je le fais. S'il s'agit de porter le site sur un framework, je quitte dès à présent le développement car tout ce que ferais sera de toute façon refait, autant que je ne perde pas mon temps.

Ah, ça c'est parce que j'ai réagit entre midi et deux, et que j'allais être à la bourre en cours, du coup j'ai un peu lu en diagonale

Et c'est la que tu te trompe.

• On utilise un sprite, contrairement à toutes les frameworks: doc nécessaire
• On utiliserais pas la grille, puisque comme l'a souligné Alex, notre layout ne se résume à aucune grille
• Le gros dropdown du header, la sidebar, la liste des sujets, le fil d'un sujet, l'éditeur, le footer tel qu'il est, même le karma ou les boutons d'actions, … Tout ça, tu ne le trouve dans aucune framework, et si on est dans l'optique "il faut à tout prix une doc", la doc de la framework qu'on utilisera ne suffira pas.
• Comme dit X fois, si on commence à se baser sur une fw, on va passer notre temps à override des tonnes de trucs. Comment désorienter plus quelqu'un que en lui donnant plus d'endroits à chercher si jamais il veux comprendre comment ça marche ? Est-ce que telle ou telle règle vient de X, ou du CSS custom ?

Je crois que j'ai jamais plus écrit de !important (c-à-d, je donne plus d'importance à une propriété pour qu'elle override correctement une autre propriété) qu'avec une framework.

De mon coté, je ne vois toujours pas comment restructurer le projet va nous permettre de :

• avoir une documentation propre et élégante

Ca permet de dire "ce truc appartient à ce module, regardez dans ce fichier". Et classer ensuite les éléments par modules.

• avoir un code normalisé avec des noms de classes connue (au hasard je tombe sur une balise et je vois ces classes css : my-account-dropdown mobile-menu-bloc mobile-all-links, il faut faire de la rétro-ingénierie pour comprendre)

cf. Alex + c'est des éléments qu'une framework ne fournira jamais

• gagner en qualité de code : si même celui qui a conçu le moteur css du site réussi a rajouter des bugs en même temps qu'il tente d'en fixer, on est pas sorti de l'auberge.

cf. Alex + Le code d'Alex est de très bonne qualité, une fois que t'y a mis le nez dedans. Je n'ai pas encore vu dans son code un fix à la con genre une position: relative pour corriger la place d'un élément de quelques pixels… Pour moi, les conflits avec ce qui est dans une framework est plus source d'arrachage de cheveux que ça.

• être plus efficace

Et perdre quelques mois de devs ? Je doute que ça motive Alex de rester si on lui demande d'adapter tout l'existant. Et je dois avouer ne pas vouloir non plus passer des journées entières à faire ça. (EDIT: Je viens de voir la fin du message d'Alex, donc j'avais plutôt raison )

• être autonome sur le code le jour ou Alex-D ne sera plus là.

C'est vrai qu'a part clarifier le code, ça ne fera pas venir automatiquement quelques devs front avec son talent. Mais je ne pense pas non plus que l'utilisation d'une framework connue le fasse aussi.

Pour moi le seul avantage valable d'une framework dans notre cas, c'est que c'est rassurant pour les nouveaux contributeurs. Autrement, ça peux vite se transformer en arrachage de cheveux, et en override dans tous les sens pour les contributeurs qui s'investissent un minimum…

Voila voila, j'ai tout dit

Bon, je vais avoir du mal à faire un pavé, contrairement à vous, mais voici mon ressenti :

actuellement, ce sont les deux du front qui, à mon sens, sont techniquement et fonctionnellement dans le vrai.

De l'extérieur, même si les gens ne s'extasient pas devant l'interface (désolé Alex-D, c'est vraiment pas la réaction qui est provoquée), ils sont unanimes à propos de son efficacité/clareté.

On sait en plus, aujourd'hui, qu'on est plutôt dans le haut du panier en ce qui concerne l'accessibilité, et la PR qui a été mergée hier suite à ma QA devrait encore améliorer les choses (d'ailleurs faudra que QUentinC vienne sur la preprod lors de la release de la v1.3 pour y passer son lecteur d'écran avec son utilisation perso).

En fait j'ai plus de soucis avec les outils du front style bower and co qui ont tendance à ne marcher qu'une fois la calvitie atteinte (j'imagine le défi quand Alex-D s'y est mis ^^). Mais une fois que c'est fait on a un JS qui est ultra accessible. Le CSS c'est plus complexe quand on ne connait pas scss. J'ai eu un cas où la classe CSS que je voulais modifier était introuvable dans tous les fichiers .scss. Ce qui met une vraie barrière à l'entrée pour les profils transversaux. Le JS est très bien codé.

Mais clairement, un framework, je dis non. C'est la merde pour tout surcharger et même si pour moi la notion de "grille" est inconnue, de ce que j'ai pu toucher à JQueryUI et bootstrap, je vois déjà la quantité de travail à fournir pour faire un truc à peine 80% aussi fonctionnel qu'aujourd'hui.