La problématique du billet est posée d’entrée et se veut à la fois naïve et critique. En effet, si nous vous demandions de développer des pages web, nul doute que vous souhaiteriez coder à la fois proprement et en optimisant le code source au maximum. Néanmoins, la tendance actuelle semble de plus en plus négative envers le code et tend à se dégrader à l’avenir.
Tout ceux qui comme moi sont passés par des écoles sérieuses et disciplinées savent qu’il ne faut pas coder dans tous les sens et avec n’importe quoi. Le choix du langage, de la technologie ou des outils intégrés est donc primordial et requiert généralement un savoir-faire pour éviter de se retrouver rapidement avec un code illisible voire imbuvable. Pour les autodidactes, je nuance bien entendu puisque beaucoup d’entre eux programment comme de réels génies et sans fausse note apparente. Par conséquent, nous sommes tout d’accord sur le fait qu’avoir un code lisible, aéré et commenté est un point fort !
L’art du développement web se tient dans la conception et la structure des pages web, mêlant plusieurs langages avec l’HTML en maître. Tout part donc d’une bonne intégration web (CSS compris) puis s’ajoute à cela les besoins complémentaires selon vos envies (PHP, Javascript, XML, Ajax, ASP, etc.). Cet ensemble doit être harmonieux, logique et surtout compréhensible. C’est d’ailleurs en ce sens que la programmation orientée objet (POO pour les intimes) a connu son heure de gloire. En terme de performance, elle n’apporte pas nécessairement de meilleurs résultats (contrairement aux idées préconçues), mais sa lisibilité est facilitée par la création de classes et objets modifiables, etc. En résumé, nous codons théoriquement des pages avec un code indenté, commenté et optimisé pour l’avenir.
L’objectif des bons développeurs (je ne me considère pas comme tel) est de créer un code qui pourra être repris et surtout compris par un tiers. C’est sur ce principe que fonctionne l’open source et la plupart des CMS que nous aimons utiliser. D’ailleurs, lorsqu’un CMS comme Magento pointe le bout de son nez avec un code riche et technique à souhait, la communauté se fait moins forte (mais de qualité néanmoins). La simplicité et la compréhension restent les points essentiels d’un code d’avenir.
Un code optimisé à quelle fin ?
L’optimisation est entrée dans le coeur des développeurs depuis quelques mois. Non pas qu’elle n’intéressait personne avant, elle s’est réellement démocratisée depuis peu, avec en ligne de mire l’idée d’un chargement plus rapide et un code plus « Google friendly »… Le paradoxe de ces optimisations tient au fait que nous bénéficions dorénavant de connexions agréables et rapides, mais malgré cela, nous souhaitons optimiser à 100% nos pages web. Pourquoi ne le faisions-nous pas avant ? Préférions-nous nos images non compressées, nos codes lourds, nos bases de données mal agencées (…) ? J’en doute fortement, mais la problématique du PageSpeed de Google et du web-mobile a fortement accru la sensibilité envers l’optimisation du code source.
Nous voilà donc dans une nouvelle ère. Avec le web-mobile et l’optimisation de masse pour convaincre Google que nous sommes les plus beaux et les plus forts, nous nous retrouvons avec des codes frôlant le ridicule. Il suffit de voir les critères imposés par le PageSpeed notamment qui prêtent parfois à sourire. Je me rappelle d’un web pas si ancien dans lequel les développeurs n’aimaient pas spécialement les mises en cache. Maintenant, tous vont dans le même sens et donneraient monts et merveilles pour mettre en cache leurs pages. J’avoue être parfois étonné et amusé par les réactions dans le monde du web. J’attends avec impatience que Google nous demande de sauter dans un trou pour que nos pages soient dans le trio de tête, ça va faire du ménage sur Terre… (rire)
Plus sérieusement, les optimisations demandées ne sont pas nécessairement à l’avantage des développeurs et me tracassent un peu pour l’avenir. Prenons plusieurs exemples. Les fichiers CSS, HTML, Javascript doivent être compressés au maximum pour améliorer la vitesse de chargement, nous nous retrouvons donc avec des codes en prose (au revoir jolie indentation…) dont les commentaires ont été retirés pour gagner quelques octets. Les fichiers externalisés n’étant pas modifiables directement, nous nous retrouvons donc à préférer télécharger les codes et les optimiser (il n’y a pas si longtemps, on préférait externaliser). Le sprite CSS devient ridicule car les outils demandent de lier beaucoup d’images, même des fichiers sans rapport direct… Sur le principe, je comprends ces critères, mais à ce rythme, où allons-nous ? Reprendrons-nous innerhtml avec l’Ajax même s’il est déprécié (pour gagner quelques lignes de code) ? Allons-nous supprimer toutes les lignes de code « évitables » pour faire la chasse aux octets ? Arrêterons-nous d’utiliser des CMS pratiques parce que certains objectifs peuvent difficilement être atteints ?
Bien sûr, ce billet de blog se veut critique envers le « toujours plus » imposé par le chargement des pages (vivement la fibre optique nationalisée alors ?) et les développeurs qui appliquent tout et son contraire au gré du vent. Je n’en veux à personne, mais la crainte d’un web moins lisible, moins clair et pas forcément meilleur en terme de résultats me dérange et m’inquiète. Continuons de coder proprement en optimisant le maximum de points, mais évitons la chasse aux octets hypocrites parce qu’un des critères de l’algorithme de Google ou le web-mobile l’ont demandé (avec la 3G minimum, nous sommes bien loin du 56Ko d’antan quand même…).