Post
Framework, génial côté serveur mais attention côté client
Le 2 septembre 2008 - Lien permanent
Le développement web progresse sans cesse et s'organise pas mal ! C'est bien sûr dans la logique que les développeurs web se sont emparés du web pour en faire leur "QG".
L'on y retrouve énormément de ressources au point que ça devient un peu le bazar... Il faut bien ranger son bureau un jour.
C'est un peu ce que font les frameworks en regroupant le travail afin d'en faire des outils redoutables qui feront gagner un temps fou et faciliteront la tâche. Cela a d'abord débuté par les frameworks concernant des langages qui s'exécutent côté serveur tel que le PHP. Ceux-ci sont vraiment efficaces car ils fournissent différentes fonctions déjà toutes prêtes à l'usage ou presque.
Je ne manipule pas ce genre d'outils car je ne connais pas encore (et ça m'intéresse moins) ces langages. Toutefois, d'un point de vue extérieur, je n'y vois pas d'inconvénients !
Mais je pense qu'il a va autrement pour les frameworks qui concernent des langages qui s'exécutent côté client !
Là tout change, avant de pouvoir exécuter tout notre code, le client (c'est à dire le navigateur de l'internaute qui se rend sur votre site) va télécharger tout le code pour pouvoir l'interpréter. Plus ce code est lourd, plus le temps de téléchargement sera long et donc plus la page mettra du temps à s'afficher.
Les langages concernés sont les suivants: le CSS, le JavaScript et le HTML.
De mon point de vue, c'est un point primordial qu'il faut sans cesse garder en tête. Mais en quoi les frameworks sont concernés par cette problématique ?
Et bien c'est simple, étant donné que le framework est un regroupement de codes, cela fait que de base, il pèse un certains poids, qui n'est jamais négligeable.
Les premiers concernés sont les frameworks JavaScript. Ils apportent des fonctions extraordinaires... Mais de combien l'on se sert à la fois sur un site ? Un petit nombre assurément. Ce qui fait que l'on se retrouve a faire télécharger aux clients plein de code dont il n'en auront aucune utilité... Fort dommage.
Il faut donc bien s'assurer que l'on a vraiment besoin d'utiliser un framework pour notre site... Peut être que certaines fonctions peuvent être codée "à l'ancienne", sans framework !
Dans un autre cas, si c'est possible, il faut choisir uniquement les fonctions qui nous seront utiles dans le framework.
Mais le point qui m'a surtout amené a faire ce post sont les frameworks CSS. J'ai un peu exploré ceux-ci, et je n'ai pas vu l'intérêt de faire usage de l'ensemble. Cela m'a plutôt permis de dénicher des bouts de code utiles.
Utiliser un framework CSS permet de s'assurer d'obtenir le même rendu, même sur d'anciens navigateurs web, et d'éviter de réécrire toujours les mêmes éléments récurrents.
En gros, cela remet à zéro tous les styles que le navigateurs peut avoir par défaut et en récréer de nouveaux, pour que ce soit ainsi toujours les mêmes.
Très utile ! Mais le soucis est que ces framework en font un peu trop à mon goût. Ils intègrent des codes qui peuvent peut être s'avérer utiles... Mais ce n'est pas certain. En tous cas certainement pas pour tous les types de sites. Même problématique donc, le client télécharge des choses qui lui sont inutiles.
Pour ma part, je me suis construis un petit framework perso qui fait un "reset" des paramètres par défaut et en reconstruit seulement les parties que je laisse toujours telles qu'elles. Le reste sera de toute façon défini selon le site que je vais réaliser et ce dont j'ai besoin et uniquement ce dont j'ai besoin !
Enfin, concernant les framework HTML... C'est en cours de projet, à voir ce que cela donne mais j'ai peur que la problématique reste la même. Là aussi j'utilise un perso, mais uniquement pour avoir tout ce qui se trouve dans la balise <head> de pré-rempli.
Pour finir, je conclurais qu'il faut donc réfléchir avant de faire usage d'un framework. La question à se poser est: « Est-ce vraiment utile pour mon projet ? » !
Mais il est aussi a prendre en compte que maintenant les connexions internet sont plus rapides et que de nombreuses techniques de compression existent.
Liens en rapport:
- Définition et avantages d'un framework web par David Larlet
- Le framework jQuery qui est un framework JavaScript très puissant et que l'on peut télécharger directement compressé au maximum et qui, du coup, est pas mal léger.
- Le framework Mootools est est aussi un framework JavaScript pour lequel il est possible de choisir la partie de celui-ci que l'on souhaite télécharger.
- Le framework Blueprint qui est un framework CSS a regarder de près.
Commentaires
bruno bichet
"Là aussi j'utilise un perso, mais uniquement pour avoir tout ce qui se trouve dans la balise <head> de pré-rempli."
Je n'appelle pas ça un framework, ni même un nano-framework, tout au plus un modèle de page !
"Est-ce vraiment utile pour mon projet ?"
Là encore, pour moi par définition, un framework ne dépend pas du projet ou alors il faut utiliser des framework différents en fonction des projets.
De même que les vrais développeurs sont capables d'apprendre et d'utiliser le langage serveur qui servira au mieux les intérêts de leur application. Mais là, c'est sûr que c'est réservé au gros projet.
Après, si c'est pour avoir un menu déroulant ou afficher masquer une div, oui, pas besoin de jQuery, c'est vrai ;)
Le 2 septembre 2008, 15:08
Guirec
C'est vrai pour une page qualifiée de "pré-remplie". Quoi que la définition de framework c'est "boite à outils" en gros, donc dans un sens ce modèle est mon outil et donc peut être que l'écart de langage n'est pas si choquant que cela.
Je n'ai pas bien compris la deuxième partie de ton commentaire. Toutefois, évidement, l'on va choisir son framework en fonction de son projet. Il ne faut pas créer de dépendance, juste utiliser les bon outils.
Enfin je pense que même les petits projets peuvent se servir de framework. Je ne crois pas qu'il faille nécessairement avoir un gros projet pour mettre à profit ces outils.
En gros, ce que j'ai voulu dire c'est: un framework, c'est cool mais à utiliser avec intelligence :-)
Le 2 septembre 2008, 16:21
annso
Je suis totalement d'accord avec ton approche!
Surtout en ce qui concerne les frameworks CSS, je n'y ai pas encore trouvé d'intérêt pour mes projets.
Et récemment, je me suis aussi rendue compte que c'était valable en javascript: coder à l'ancienne, c'est quand même beaucoup plus léger quand on a qu'une ou 2 fonctions a écrire.
Pour finir, je pense que les frameworks PHP sont les plus intéressants, mais je préfère ne pas m'y mettre avant de maitriser un peu plus sérieusement le langage. En effet, je pense qu'utiliser un framework sans savoir ce que l'ont fait vraiment peut être "dangereux" (et laborieux) ...
Le 2 septembre 2008, 20:42
bruno bichet
Je veux juste préciser qu'en général un framework demande un certain temps pour être maitrisé et rentable, donc, en général on a tendance à l'utiliser y compris pour des projets qu'on aurait pu faire sans et c'est presque normal ;)
@annso > c'est clair, un framework ne se substitue pas à des connaissances solides que ce soit en php ou en css.
Le 3 septembre 2008, 15:34
Thibault
Pour le cas des frameworks CSS, outre la compatibilité avec tous les navigateurs, c'est aussi une manière plus efficace d'organiser son code. J'avouerais que je ne m'y suis pas mis parce que je n'ai pas bosser sur de gros projets depuis longtemps, et que je n'y voyait donc pas l'intérêt ;)
Pour le JavaScript, on a de plus en plus tendance a utiliser des effets dans les projets qui arrivent, parce que le client a vu ça sur le dernier site à la mode.
Je tiens aussi à rajouter que les avantages des framework PHP se retrouve chez n'importe quel type de framework. Coder sa propre fonction d'easing prends plus de temps que d'utiliser celle de Mootools. En plus, je pense que les fonctions de calcul compliqués telles que celle-ci sont plus optimisé sur un framework que la plupart de celle que l'on coderait nous même. (J'avoue, je suis un intégriste des framworks JS)
En fait, avec ton article, j'ai l'impression qu'on se retrouve un peu à l'époque du RTC. Un Framework JavaScript c'est une centaine de Ko, soit moins d'une seconde chez beaucoup de français. Même en tant qu'heureux possesseur d'iPhone que tu es, le débit est du même accabit en 3G. Je pense aussi qu'il ne faut pas oublier que le navigateur met en cache un certain nombre de fichier, ce qui ne signifie qu'un seul téléchargement pour la session sur le site au pire, pour plusieurs semaines au mieux.
Dernière chose, je suis pas totalement pour les frameworks web. Ca fait gagner du temps pour le développeur au détriment des perfs du serveur, donc en fait je ferais plutôt la critique inverse. Un client n'a qu'un traitement à faire pour une page. Un serveur c'est un traitement a faire par client. Tu prends Twitter et tu te pose la question du pourquoi des down à répétition il y a quelques temps :)
(sinon, content de voir que tu as repris du service, mais c'est dommage que tu n'ai pas redirigé ton ancien flux RSS)
Le 16 octobre 2008, 20:51