[Résolu] Drupal 8 à Drupagora 2014

Salut Drupy,

Je n'étais pas à Drupagora et je n'ai aucune idée du contenu de la conférence dont tu parles car je n'en sais que ce que tu en dis et cela me laisse un peu sans voix.
Je n'ai pas étudié Drupal 8 en profondeur, manque de temps, mais j'ai eu l'occasion de tester ses capacités d'un point de vue Site Builder et j'ai récemment pu éprouver un peu la qualité de son code en participant à quatre jours de sprints en présence de certains de plus gros contributeurs.
A mon sens, on ne peut pas parler de Drupal 8 en général car les changements que cette nouvelle version introduit sont si profonds que cela n'a pas de sens. On peut les observer par le prisme des initiatives qui ont conduit à cette mouture ou alors en empruntant le regard des différents intervenants dans la conception d'un projet Drupal.

Je commence par les intervenants et en particulier le Site Builder. Si tu ne connais pas ce terme, il désigne une personne qui va construire un site en ne se servant que des options proposées par l'interface du coeur et des modules contribués. Le Site Builder habitué à Drupal 7 ne sera pas dépaysé par Drupal 8 car l'organisation de son administration n'a pas changé. Il trouvera dans le coeur quelques uns des modules qu'il était habitué à ajouter auparavant comme Views, un peu de Display Suite (encore), quelque chose qui ressemble à Features issue de l'initiative CMI (on y revient), quelque chose qui ressemble à BEAN, CKEditor et un système d'édition en place (directement dans la page), tout un tas de types de champs dont les Entity References, et, enfin, un vrai système d'internationalisation... En bref, avec uniquement ce qui est présent dans le coeur, il pourra déjà faire un site fonctionnel et il ne lui manquera que quelques modules pour gérer des aspects un peu plus subtils. Tous ces modules, désormais gérés dans le coeur, seront donc maintenus avec la même rigueur et seront donc, de fait, stabilisés.

Prenons ensuite les Thémeurs. Avec Drupal 7 certains se sont arraché les cheveux à tenter de comprendre le système de rendu, quand il fallait modifier un template, son format, quand il fallait créer une fonction, à quel endroit... Parfois, cela a même mené à d'importants problèmes de performances ou de sécurité car il était tout à fait possible de coder dans les templates. Maintenant, toutes les fonctions de thème font appel à des templates, écrits avec le moteur Twig qui interdit formellement tout usage de PHP. L'appel à la fonction thème est déprécié en faveur des render arrays qui permettent de pouvoir altérer les données jusqu'au dernier moment. Toutes ces choses ont été réalisées à la demande des thémeurs et pour leur plus grand plaisir. Certes il leur faudra apprendre (pour certains) à utiliser Twig, mais cela n'incluant pas toute la complexité de PHP cela semble plus simple. Ils se poseront moins de questions également sur ce qu'ils ont à faire car tout à été uniformisé. En bonus, les templates Twig sont précompilés en PHP et ils bénéficient donc des mêmes performances que le moteur précédent.
Outre toutes ces problématiques de templates, Drupal 8 est livré avec un système permettant de faciliter la gestion du Responsive Web Design en proposant de gérer les Brekpoints et en leur associant même des Styles d'Image spécifiques pour éviter aux utilisateurs mobiles de charger des pages énormes ou pour avoir des versions Retina des illustrations du site Internet. Ils pourront plus facilement maîtriser le markup HTML généré par Drupal, pourront toujours surcharger mais aussi désactiver les feuilles de style et fichiers javascript du coeur.

Pour finir, les Développeurs ne seront pas en reste même s'ils seront probablement les plus touchés par cette évolution. En effet, le passage au tout objet (ou presque), l'appui sur des libraires développées et maintenues par des équipes externes et les changements et enrichissements de l'API nécessiteront un temps d'apprentissage. Cependant, l'ouverture de notre communauté à d'autres, comme celle de Symfony, permettra aussi certainement d'apporte du sang neuf dans les rangs des mainteneurs. De plus, en s'appuyant plus sur l'écosystème, on s'oblige à suivre des règles (PSR-0 et PSR-4 par exemple) et on renforce toutes les équipes par l'expérience commune. A ce stade de l'évolution du Web et de PHP, toutes les équipes de tous les concurrents de Drupal se tournent vers l'extérieur car les solutions que l'on trouve dans un petit groupe n'arrivent souvent pas à la chevilles de celles trouvées par une population plus spécialisée ou plus vaste. L'arrivée de l'Objet dans Drupal est aussi une excellente nouvelle d'un point de vue qualité car c'est une condition importante à l'écriture de tests robustes qui valident le modèle et empêchent les régressions.
En tant que développeur, j'ai commencé à m'intéresser à la transition du coeur et, même si je souffre beaucoup en ouvrant le code, l'ingénieur qui est en moi reconnaît des patterns et valide des choix. Il faudra des formations pour certains, juste du temps pour d'autres, mais de la motivation pour tous pour surmonter ce changement. La communauté est déjà en marche pour aider à la transition par l'écriture de très nombreux articles assez approfondis et qui relatent de l'avancée des travaux, mais aussi par la création d'outils pour aider les autres développeurs à progresser plus vite. Ainsi, il existe déjà aujourd'hui deux outils pour faciliter la transition : Console, un outil en ligne de commande permettant de générer à peu près tout ce qui est utile dans Drupal (module, entité, configuration, services...) et Module Upgrader qui, comme son nom l'indique, aide à mettre à jour un module de la version 7 à la version 8. Ceux-ci ne sont pas aujourd'hui finalisés mais permettent et promettent déjà de belles choses.

Toutes ces choses que je cite je ne les ai pas vus dans une conférence ou une démo, je les ai expérimentés moi même et j'ai pu constater que malgré des bugs plus ou moins pénibles, toutes ces choses fonctionnent déjà !

Je vais maintenant revenir sur ta liste pour essayer de comprendre ce qui a voulu être dit et y apporter mon point de vue :

• le bébé D8 arrive avec du retard et par le siège (certes, ce n'est pas un secret)

Ce n'est pas faute d'avoir un certain nombre de personnes qui y travaillent de manière très intensive, la plupart de manière totalement bénévole. C'est bien joli de profiter de l'Open Source mais si on choisit de ne rien en financer c'est normal que les choses n'avancent pas.

• visiblement en surpoids. On lui prédit un régime d'entrée de jeu

Le coeur intègre pas mal d'anciens modules et pas forcément les plus légers. Comme tout système en phase de développement, on s'intéresse d'abord et avant tout aux fonctionnalités et on cherche ensuite à l'optimiser. C'est donc normal, maintenant que la phase de bêta a débuté, qu'on s'intéresse à lui faire perdre un peu de poids. Je serais curieux de voir quelqu'un faire un test, à fonctionnalités égales, des performances de D7 contre D8. L'architecture orientée objet assortie du système d'autoloading permet d'avoir beaucoup moins de choses chargées en mémoire et ne n'invoquer que le strict nécessaire. Je ne serais pas étonné de voir que la lourdeur présumée de l'objet (optimisée avec PHP 5.4, 5.5 et 5.6 et les systèmes de cache d'opcode) soit un peu exagérée.

• s'il survit, il faudra de toute façon le couper la tête (je veux dire le "FRONT")

Pourquoi ? Il y a des personnes qui étudient la possibilité de le faire, il y a même une initiative qui essaie de faire en sorte que ce soit possible (Webservices) mais je pense plutôt que l'on verra naître des sites qui utiliseront à la fois la couche front et les webservices au lieu de sites dont Drupal servirait de pur backoffice.

• disposant de moins de 5% d'ADN commun avec la mère. On peut douter de la filiation... (et donc du retour sur l'investissement D7)

Le code n'est pas l'ADN d'un projet Open Source. On retrouve dans D8 absolument tous les concepts qui sont nés et qui ont survécu tout au long des versions précédentes. On parle toujours d'entités, de noeuds, de taxonomie, de blocs... En prenant la chose dans ce sens je dirais à l'inverse que 100% de l'ADN de Drupal a été conservé.

• Il va falloir que la toute la famille apprenne le langage des sourds (le javascript) pour parler à la tête, du coup manquante.

Certains parlent d'une future version de Drupal (9, 10...) qui serait écrite en Javascript. Cependant, on en est très loin et ce genre de choix, lointain, se fera en fonction de l'évolution du web. Aujourd'hui, Javascript n'est pas un outil essentiel pour le développement Drupal avec D8. C'est un outil essentiel pour le développement web.

• il est en outre possible que le malotru nous balance en retour, plein de cailloux - "des galets" - en guise d'accusés de réception (là, j'ai pas bien compris...)

Je ne vois pas non plus de quoi il est question.

• et le père a quitté le domicile conjugal - sans reconnaître l'enfant - avant l'accouchement au vue des premières radiographies. (On appelle ça un "fork")

La création de Backdrop devrait être, au contraire, considérée comme une bénédiction pour les DSI car cela signifie que leurs projets D7 seront maintenus par une équipe dédiée. En effet, ce fork a pour objectif de conserver une compatibilité descendants et des usages qui ne dépayseront pas les équipes.

Voilà, si je devais faire un gros résumé de tout ça, je dirais que globalement, comme avec toutes version majeure d'un logiciel, on va certainement avoir du mal à faire la transition mais je ne pense sincèrement pas que cette nouvelle version soit de mauvaise qualité ou aille globalement dans le mauvais sens. Le métier se professionnalise ce qui ne peut pas être un mal quand on considère la cible principale de Drupal.

My 2 cents.