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 !

Yesterday, I was to a javascript developers conference in Toulouse and I saw a presentation of Ember.js and Backbone.js. Two frameworks I don't know a lot about, and I can compare with Yoshioka. And all that I listened reinforced the fact that the choices I made for the architecture of my framework were not so stupid.

Ember.js

Ember.js is the new name of Sproutcore 2.0. I didn't know and it is very interesting because Sproutcore was the seed in my mind that helped me build Yoshioka. Here's the story.

In 2010, a new real MVC framework is announced, from Apple! Sproutcore. I jumped on it to discover the Grail I was waiting for. Sproutcore was made with a ruby server which live build project files to javascripts loaded on your browser. It provides a MVC pattern and a sort of ORM to communicate with the server. But the bad side was it was very very inspired from Objective-C Cocoa framework from Apple which is very difficult to comprehend. So I gave up quickly, but keeping in mind to retry it quickly.

Then, some months later, YUI3 published some MVC modules in experimental state. This modules was very easiest to use when you have habbit to work with YUI, so I started to work with it immediately. And then, I decided to apply all the great ideas I learn from Sproutcore into YUI3 MVC : live compilation, separation of template files, localizations, fixtures, etc.

Bad sides

The bad sides of this framework is the Cocoa approach and the very closed framework. It is very difficult not to walk into the path. That was the feeling I had 3 years ago and it was the same thing that told Raphaël Rougeron who was talking about Ember.js. With Yoshioka and YUI, you are free and invited to rewrite the wheel every time you need it. I love rewriting the wheel because the wheels never fit perfectly for what I want.

Another bad point is a memory leak. I used to have similar issues on Yoshioka with dynamical locales. Ember comes with a cool feature wich is able to update a variable into a template without full re-render it. It's the same behavior I chose for locales : an element (a span for Yoshioka) with an ID, and an observer which update the value of the node when the attribute of the model change. The problem is this node and observers are very difficult to clean and they are never free to be removed by garbage collector. With a workaround in the way Yoshioka locales are updated, I gain some hundred MBits of RAM. Overblog was able to occupy 600MB of RAM with a eavy use of the app. Now, it rarely jumps over 150MB. Raphaël talked about 2Go of memory on their apps.

Backbone.js

Then, Jean-Christophe Queval talk about Backbone.js. I have not a lot to say about it because Barebones is the inspiration of YUI3 MVC modules. So it must be cool :)

But as he said, Backbone is more a toolbox than a framework. YUI3 will give the same design pattern with all the foundations of their framework and all the free available modules. It would be very easier to quickly create a web app compatible with suckin'browsers.

Socket.io

Finally, Cyrille Bogaert showed us a demo of a web video game using web socket to make multi players sync their positions in a game. This demo gave me an idea for trying improving performances on Overblog. I hope I will have some time to experiment the replacement of Ajax JSON-RPC by a theorically very quicker web socket between client and server wich will directly communicate with internal API by using Thrift.

I just push a new branch on Yoshioka with a new way to unit test the project.

Previously, all the test, and so all the required modules were loaded in the same page and all the tests runned in the same window context. Result in a big project like Overblog was that we had some false positives, some modules which didn't have declared its own dependancies but were loaded by previous tests, syntax errors which were not catched and highlighted as fail. And practical, we had to reload the entire page when modifying a code source file.

Now, the main page is only a summary page of all the tests files. The tests are run in an independant iframe. Each series of tests run in its own sand box without altering other test. We found that we had some false positive tests in Overblog project. We could too fix some syntax errors. And no need to reload all the page, just click the test's run button will reload only its files in its iframe.

A real productivity and quality gain !

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.

I was at SudWeb this week end, and I took the opportunity to present Yoshioka.js in a free elaboratory. Unfortunately, I choosed a very bad timelap : in another classroom, Bert Bos, cofunder of CSS, was talking about future of CSS… So, there was 5 to listen to me. Only elites ! That was a full improvisation, but they were captivated. And they like it if I can believe in this kind of tweet :

The experience was really plaisant, and I will make another presentations in the future. First, AperoWeb, and very probably, SudWeb 2013 !

Thank you guys !

When I did my presentation at SudWeb last week, I quickly made a plan in the morning and I improvised the afternoon in front of my listeners. So, the only thing I can give to you from this event is its plan.

YUI presentation

1. Loader

2. Sandboxes

3. Attributes

4. Combo

5. Problems

Presentation of a working yoshioka app

1. Show the Overblog admin panel after having opened the Networks tab of the Chrome developer's toolbar, to show the dynamic loading of the views and the AJAX requests of the models

Coding presentation

1. Configuration, Core (quickly)

2. Views

3. Templates

4. Models

5. Widgets

6. Internationalization: change the language without reloading the app

Deployment

1. Unit tests + demo integration on Hudson

2. Compilation: on the go (dev), build (prod)

3. Building process

4. Deployment

Maybe, some day, I'll fill each section with content ;)