Posts with “#javascript” — 3 posts

Mercredi 23 Janvier, j'ai fait ma première présentation en public pour parler de javascript à mes confrères toulousains. J'ai cherché à partager l'expérience que nous avons gagné lors du développement du back office d'Overblog Kiwi sous forme d'application javascript en MVC.

Beaucoup de trac face à 80 personnes, comme vous pouvez le constater, des oublis, une expression pas terrible… mais ça a plu ! Je recommencerais très problablement l'expérience dès que possible. J'aimerais évengéliser les codeurs toulousains à YUI3.

Quand vous lancez des tests unitaires verbeux, il est difficile de retrouver ses propres messages de debug dans la console. Voici une petite astuce très simple pour y voir rapidement plus clair.

Voilà à quoi peut ressembler une console de debug après avoir lancé une batterie de test. Ça peut aussi être le cas en faisant tourner son application en mode debug. Difficile de retrouver son console.log('lol') perdu dans cette masse de messages.

Heureusement, Chrome permet de filter les types de messages envoyés à la console. Pas assez cependant, on ne peut pas afficher les messages de type "info" ou "debug" indépendemment du reste. Mais on peut n'afficher que les messages de type "errors" et "warning". Je choisis donc l'onglet "warning" et place des console.warn('lol') dans mon code.

Petit disclaimer avant d'entrer dans le vif du sujet : je vais dorénavant rédiger quelques articles en français plutôt qu'en anglais. Simplement parce que je ne suis pas très à l'aise en anglais et que je perds beaucoup de temps et de flexibilité dans la rédaction, et puis aussi car il existe très peu de ressources javascript en français.

Fond ou forme

La première question à se poser quand on va choisir les technologies pour développer un site web concerne son contenu. Chaque site est composé à proportion différente de fond et de forme. Le fond, ça sera l'information affichée à l'utilisateur, le contenu du document, ce qui se lit (ou visionne) uniquement. La forme, c'est l'interface. C'est la partie du site qui permet d'intéragir avec celui-ci afin d'envoyer des commandes à un serveur ou simplement modifier le contenu.

Un blog ou un site d'actualité aura une proportion de fond bien plus élevé que de forme. On se rend sur une page d'article pour le lire. On y fait rarement d'autre type d'actions.

Au contraire, sur un backoffice tel qu'une administration de blog ou un CMS, on va utiliser le site en tant qu'interface graphique pour modifier des données sur un serveur. Ce sera cette fois la forme qui primera.

Site de contenu

Que cherche l'utilisateur qui consulte la première catégorie de site, un site de contenu ?

Il veut que le contenu s'affiche rapidement, qu'il soit accessible, lisible, récupérable. Généralement, il va très peu intéragir avec son interface. Il va naviguer dans les différents liens du site, mais c'est tout. Voici donc les points à mettre en avant :

• vitesse d'affichage du contenu

• mise en évidence du contenu

• éviter de distraire le visiteur avec une interface complexe

Site interactif

Pour le second type de site, l'utilisateur aura d'autres besoin. Il voudra une interface riche avec des éléments d'interface pratique qui lui facilite la tâche dans la manipulation de ses données, il voudra un rendu graphique agréable et ergonomique, une grande fluidité d'animation. Les points suivants seront les plus importants :

• design, images

• interface riche, visuelle, animée, adaptative

• données affichées fraiches

Servir du contenu HTML

Le gros intérêt de faire générer des pages HTML par le serveur, c'est qu'on peut très simplement faire usage d'un cache qui permet de renvoyer la page en quelques dizaines de millisecondes au lieu des centaines nécessaires lorsqu'on interroge la base de données. L'inconvénient, c'est que si on veut que le cache serve à quelquechose, il faut garder une version de la page dans un état statique pendant un temps conséquent (de plusieurs minutes à plusieurs heures). Ça ne peut donc fonctionner qu'avec des pages affichant du contenu qui ne change que très peu.

Générer du HTML sur le client

Générer le contenu depuis le client grâce à une webapp javascript a l'avantage d'accélérer les requêtes entre le client et le serveur. Les données, fraiches car non cachées, s'affichent très rapidement car le serveur n'a qu'à faire une simple requête en base de données, formatter le résultat en JSON et c'est le client qui se débrouille pour transformer ça en HTML. Le prix à payer est un chargement initial relativement long selon la taille du site qui peut décourager le visiteur de rester sur le site.

Le choix

Par ce principe, on fera le bon choix en sélectionnant une solution de génération de pages par le serveur avec un cache. On pourra par contre choisir une webapp javascript pour un backoffice pour profiter d'une interface riche tout en économisant du traffic entre le client et le serveur.

Cependant, il arrive que la distinction entre les deux types de sites ne soit pas si simple à déterminer et qu'on ait besoin d'un mix des deux mondes. C'est le cas de Twitter par exemple, dont le site est un mélange assez équilibré d'affichage de contenu et d'interface de publication et d'interaction et qui a su intelligemment profiter des deux solutions. La première page chargée est générée par le serveur et peut donc être consultée immédiament par le visiteur. La webapp est chargée dans un second temps et exécutée de façon transparente. Elle prend la main pour les requêtes suivantes, soulageant alors le serveur et améliorant l'expérience utilisateur.

C'est donc à vous de peser votre site sur cette balance avant d'affirmer quelle choix est le meilleur !