Êtes-vous prêt à écrire votre HTML et CSS uniquement en Javascript avec OJ ?

Aujourd’hui, le Blog du Webdesisgn vous décortique une ressource permettant de remplacer tous les langages web par du Javascript

Il y a quelques jours est sortie une library révolutionnaire, peut-être en avez-vous entendu parler: OJ !

OJ, le web enfin unifié

La puissance d’Oj est qu’elle homogénéise le développement web: plus besoin d’un langage différent pour le style, les vues et le code. Tout est fait en Javascript ! Et c’est génial !

Les avantages d’OJ

Un des principaux avantages d’OJ est qu’il est possible de mettre le code de rendu (anciennement HTML), le style et le code Javascript dans un même fichier. Pratique pour s’y retrouver. Plus besoin de structure de dossiers compliqué comme tous ces frameworks.

Les quelques inconvénients minimes

La library est un poil lourd: 44.6k une fois compressé et minifiée, mais ce n’est pas si grave, les gens ont tous de bonnes connexions, maintenant.

L’inconvénient de faire un code qui se génère côté client est que cela rend l’expérience utilisateur plus hétérogène : les visiteurs avec un bon PC auront une expérience plaisante et fluide, et les smartphones auront quelques petites difficultés. Mais bon, qui navigue depuis un téléphone, de nos jours?

Le SEO peut aussi être quelque peu affecté par cette méthode de fonctionnement, vu que les pages ne sont pas réellement lisibles par Google en l’état.

Enfin, il faut tout de même noter qu’avec une application node js, il est même possible de faire le rendu des templates côté serveur, et donc d’annuler presque tout ces inconvénients!

Parlons sérieusement

Vous l’aurez compris, je ne suis pas un fan de cette library. Non pas que l’idée ait été mal traitée, mais je pense que l’idée elle-même n’est pas « bonne ». Pourtant, cette idée est assez fréquente (je l’avais moi-même eu en démarrant mon apprentissage du web: et si tout le HTML et le CSS étaient générés en PHP?).

C’est pourquoi j’ai décidé de faire cet article : non pas pour enfoncer cette ressource, qui de toute manière ne percera pas (ou alors vraiment, il va falloir que je songe à changer de métier), mais pour mettre en garde contre une idée cul-de-sac, et expliquer pourquoi ce n’est pas une bonne solution.

Vouloir traiter les vues, le style et le code dynamique avec un seul langage est une erreur, car ces trois parts d’un site web sont très spécifiques, et surtout très différents.

En effet, le HTML, rappelons-le, est là pour structurer l’information, et le CSS pour la mettre en forme. Deux taches complémentaires, mais différentes. Radicalement différentes. C’est pour ça que l’idée d’éclater ce code en plusieurs fichiers différents est vite devenue standard. Besoin de travailler sur la structure ? Il suffit d’ouvrir le fichier HTML correspondant. Besoins de changer le style? Pas de problème, tout est rangé.

Une idée s’en approchant, et à mon gout bien mieux traité, serait un environnement basé sur Slim pour le HTML et Sass pour le CSS. Les fichiers se ressemblent, l’expérience est unifiée, mais les fichiers gardent leur rôle et leurs spécificités.

Note: je ne fais pas de commentaires sur les performances déplorables qu’apporte cette solution par rapport a du CSS/HTML, je pense que ce n’est pas nécessaire. Mais quand même, OJ c’est lent.