Je n'aime pas le code moderne

Cher journal,

Avant propos

Développeur PHP depuis près de dix ans, internaute depuis quinze et geek depuis vingt-cinq, comme tout bon geek, je fais de la veille. Je m’intéresse aux nouveautés, j’étudie scrupuleusement les spécifications des langages que j’utilise (soit PHP, Javascript, CSS et HTML), en bref, je me tiens au courant et j’applique les recommandations les plus récentes.

C’était mieux avant

J’adorais Internet. Je l’aime toujours, mais moins qu’avant. “Avant” ? Avant l’avènement des réseaux sociaux.

Similairement, bien que j’aime toujours coder, j’aime le code moins qu’avant. “Avant” ? Avant l’avènement des frameworks usines-à-gaz qui ne respectent même pas les principes élémentaires de codage ou du modèle MVC (du code logique dans des commentaires ? du code brut dans les templates ?).

Mon framework à moi !

Je travaille depuis quelques temps sur un framework maison, composé d’un loader du même genre que celui de CakePHP mais en plus lisible (CoreLoader::load_vendor('phpmailer') ou CoreLoader::load_controller('home') par exemple), d’un routeur particulièrement complet (prenant en charge des routes automatiques, les droits des utilisateurs en fonction de la route demandée, etc.), de templates, etc.

Bien que j’ai codé moi-même le gros du framework, l’idée reste qu’il s’agisse d’une agrégation des meilleures librairies dans leur domaine respectif:

• PHPMailer
• Redbean
• Smarty
• etc.

Changement de cap

La philosophie du Libre

Hier, j’ai eu une épiphanie:

“Hey, coder toi-même ce qui existe déjà ? Pas trop la philosophie du Libre !”

Ok. Ça implique - apparemment - d’utiliser des trucs tout moches modernes du genre composer. Bon, allez, je m’y colle.

Je cherche un peu une librairie pour remplacer mon routeur, et je tombe sur un certain nombre d’entre elles:

• klein
• Toro
• Aura

Et puis tiens, PHP-Error pourrait être pas mal.

La déconvenue

Oh ! Il y a un éditeur intégré pour modifier le code en direct quand une erreur se présente ! Cool ! Oh, ça m’enregistre un fichier presque vide quand il y a un antislash dans un namespace ! Bon, ben encore une application moderne qui mise sur l’apparence et qui en fait est tout bugguée…

Mon application de test n’est pas à la racine. Aucun problème pour mon routeur, mais klein ne fonctionne pas sans .htaccess pour le rewrite, Aura est beaucoup trop gros et aucun des trois ne matche mes routes sur la variable PATH_INFO mais sur le chemin relatif depuis DOCUMENT_ROOT. Bizarre…

Cause et effet

De façon assez étrange, ni Smarty, ni Redbean ne mentionnent composer dans leur documentation, et PHPMailer s’en passe parfaitement. D’ailleurs, j’aime beaucoup la raison avouée pour laquelle l’auteur de Redbean ne propose pas de package composer. Certe, les trois peuvent s’installer via le gestionnaire de dépendances, mais de manière plus ou moins officieuse.

Personnellement, j’ai bien envie de tomber dans la facilité et voir un lien entre la qualité des librairies, le fait que composer soit obligatoire ou non pour les installer, et la vétusté/simplicité de leur site Internet.

J’ai testé pas mal d’autres librairies encore et je constate une chose: une grosse partie a une page web créée avec Bootstrap. Encore des clones de bootstrap… Certains mieux réalisés que d’autres toutefois, mais on sent toujours cette patte bootstrap, c’en est désespérant. Ni Redbean, ni Smarty n’utilisent bootstrap sur leur site.

Là encore, j’ai envie de tomber dans la facilité: comment avoir confiance dans une librairie dont l’auteur ne prend pas la peine de faire un site sans tomber dans le piège oisif de bootstrap, ou du moins, faire en sorte que ça ne se voit pas ?

Du coup, je ne comprends pas comment il est possible que de telles librairies ou outils puissent avoir une telle cote de popularité.

Le mal-aimé

En parlant de popularité, autre exemple: PEAR.

PEAR existait avant composer. Avoir sa librairie disponible sur PEAR était, à une époque, la quintessence, l’aboutissement, une reconnaissance extrême. Bien sûr, PEAR est un framework alors que composer est un gestionnaire de dépendances, mais tout de même. Aujourd’hui, tout le monde boude PEAR, à part Horde et quelques irréductible de ce que j’appelle l’artisanat du web, vestige d’une époque où le code devait être bien écrit, quasiment exempt de bugs, et fonctionner partout sans la moindre nécessité d’adaptation. Il semblerait qu’on ait perdu cette versatilité au prix d’artifices plus ou moins alambiqués (genre certains design-patterns, les namespaces, les traits, etc.).

Interopérable ?

Le pire, c’est que toutes ces libs modernes suivent les recommandations PSR, donc devraient être facilement utilisables partout quelle que soit la configuration du serveur sur lequel elles sont installées.

D’ailleurs, je crois que les “standards” recommandés par le PHP-FIG ne servent qu’à composer. Il y a évidemment quelques bonnes idées dedans (UTF-8 sans BOM, LoggerInterface, etc.) qui contribuent effectivement et efficacement à l’interopérabilité des librairies PHP, mais désormais, je fuirai les librairies arborant fièrement avoir suivi ces recommandations parce que cela signifie qu’il va être pratiquement impossible de les utiliser sans composer (qui a, par ailleurs, la fâcheuse tendance à installer tout un tas de truc que je n’ai jamais demandé et qui n’existe pas dans les archives).

On n’est jamais mieux servis que par soi-même

Au final, je vais faire ce que j’ai toujours fais: continuer de tester des librairies, et intégrer à mon framework les meilleures d’entre elles, les plus simples à installer et utiliser, même si elles devaient être quelque peu obsolètes (simplepie par exemple).

Pour ceux que ça intéresse, voici les différentes librairies que j’utilise, outre Redbean, PHPMailer et Smarty (sans composer et sans les avoir modifier de quelque manière que ce soit):

• Munee - concaténation et minification à la volée de CSS et JS avec support de less, scss, coffescript, etc.
• Parsedown - parser markdown
• phpass - génération de hash sécurisés pour les mots de passe, en l’absence de blowfish

Happy end, quand même

Je note tout de même que cette expérience m’a tout de même apporté de bonnes surprises, comme monolog, sentry ou climate que j’intégrerai peut être à mon framework, malgré l’utilisation “nécessaire” de composer et leur usage abusif des namespaces…

Ou bien je coderai mes propres libs, les distribuerai sous licence Libre, hors composer, en mentionnant que j’ai une approche plus conservatrice du dév…