Pour faire de l’Ajax, on a deux solutions :
- Faire du code javascript à la mimine
- Utiliser des toolkits tout prêts qui nous évitent plein de code
Personnellement, je suis assez fainéant, j’ai donc testé trois frameworks Ajax :
And the winner is … pas si simple.
J’ai d’abord installé GWT. La prise en main est assez simple, à condition de connaître Java et ses principes de gestion des IHM. En effet, la programmation dynamique et événementielle se faire en Java ; un compilateur permet de traduire ensuite ce Java en Javascript. J’ai assez vite trouvé des limitations à ce produit.
Je me suis ensuite attelé à Dojo ; j’ai vraiment été bluffé par la richesse des démos fournies avec le toolkit. En revanche, la documentation inexistante ne permet pas de prise en main rapide. C’est dommage.
Enfin, je me suis tourné vers un produit commercial, gratuit pour les particuliers, qui est Backbase. Les démos, là aussi, sont très réussies, mais, contrairement à Dojo, une vraie doc est présente et permet d’éclaircir les idées. Les concepts sont en revanche assez trapus, et ce produit est compliqué à metter en oeuvre.
En conclusion, pour des petits besoins rapides, GWT me semble une bonne solution, et pour des applications complexes avec des IHM très riches, un investissement (en temps d’acquisition) vers Backbase me semble une bonne idée.
Tu vas un peu vite en besogne mon cher Fabien… Je suis sûr que certains de tes auditeurs ne savent pas ce qu’est Ajax (Asynchronous Javascript And XML). En gros, c’est mettre beaucoup de javascript dans une page web (et faire communiquer les composants informatiques en XML, bien que ce dernier point ne soit pas indispensable pour l’utilisateur, mais plutôt une facilité de développement pour les informaticiens) pour qu’un logiciel développé « dans du web » puisse avoir des fonctionnalités proches de ce qu’on a l’habitude de voir avec un « client lourd ».
Exemple : je suppose que tout le monde a déjà vu tourner dans sa vie Outlook (ou Evolution pour les Linuxiens 😉 ). Lorsqu’on gère l’agenda, on peut faire du copier/coller de rendez-vous, voir du « drag & drop » (glisser/déplacer). Il m’est arrivé de présenter des agendas développés dans du web (exemple : webcalendar. En général, je ne mobilise pas les foules. Présentation austère, pas de glisser/déplacer…
Avec la technologie « Ajax », la présentation devient plus « sexy », et on commence à trouver des mécanismes plus évolués.
Le développement de ces interfaces homme-machine (IHM) est toujours possible « à la main », mais les incompatibilités entre les différents navigateurs rend une programmation manuelle longue et fastidieuse. Le concept « Ajax » facilite le développement de ces IHM.
Reste que le concept séduit… En tout cas, en théorie. Cas en pratique, je reste méditatif sur l?efficacité de ces technos basées sur le web. Les avantages :
pas besoin d?installer un client particulier (tout navigateur moderne convient) => théoriquement, multi-systèmes et multi-OS,
relative standardisation de la gestion de l?authentification et de la sécurité, ce qui me fait dire que l?interface avec un SSO (Single Sign On) sera plus facile à obtenir auprès d?un éditeur (c?est à mon avis LE principal argument),
et… c?est tout ? Pour l?utilisateur, oui. Pour l?équipe de développement, il y a le fait qu?il devient possible d?harmoniser les flux échangés entre les différentes composantes de l?architecture, avec le XML (mais pas besoin d?Ajax pour ça).
Les inconvénients :
nécessite plus de puissance CPU et de RAM sur le client (quoi que certains clients lourds développés avec de mauvais logiciels de RAD nous ont habitués à ce genre de chose) ;
nécessite des développeurs « modernes » (je connais d?anciens programmeurs de COBOL CICS ou même de Pascal qui vont se faire mal aux dents s?ils devaient passé à ce genre de techno ? mais l?argument est vrai pour d?autres techniques ?) ;
l?argument de dire que ça marche avec tout navigateur… OK pour les PC. Mais je ne suis pas sûr qu?il y a beaucoup de programme développés avec le concept Ajax qui tournent de base avec un PC, un Pocket PC (et de petits écrans), ou des SmartPhones et autre téléphones IP embarquant un navigateur et quelques compatibilité Javascript ;
mais surtout… les éditeurs ont du mal à s?y mettre. Lorsqu?un éditeur part sur un nouveau développement, développer en web (et donc, utiliser Ajax) a un sens. Mais lorsque le programme existe déjà avec une philosophie « client lourd » (façon client développé en VB ou autre Borland machin bidule), la migration revient presque à repartir à zéro. Et alors, peu le font…
En conclusion : c?est une techno qui me plait beaucoup, qui a quelques avantages certains, mais sont-ils suffisants pour que les éditeurs migrent ? Je n?en sais rien… A titre d?exemple personnel : j?ai beau être demandeur, excepté un logiciel de prise de rendez-vous qui est moderne, je doute que la moindre autre application complexe de mon SI soit migré en techno web dans les 10 ans… Les brontosaures ont disparus, ils ne se sont pas adaptés. Et comme pour l?instant, il n?y a pas beaucoup de relève (en tout cas, dans ma branche), les brontosaures ont encore de l?avenir…
Commentaire by Emmanuel DESVIGNE — 5 juin 2006 @ 22:13
Merci Maître Manu,
Tu auras certainement remarqué que cet article était dans la rubrique « Geek ». J’espère donc que mes lecteurs auront choisi cet article en toute connaissance de cause.
Au départ, j’étais assez réticent à l’usage de Ajax ; à la réflexion, c’est une philosophie qui s’intègre très bien dans une architecture Webservices->XML->XSL->XHTML->Ajax.
C’était la cogitation du jour.
Commentaire by Fabien — 6 juin 2006 @ 8:46
Ah ben oui, mince, ya des thèmes (Actualités internet, Geek, Humeur, Lectures, Quotidien…). Mea culpa ! Bon, promis, je sors…
(mais j’assume tout de même la conclusion que nous partageons : bonne techno… espérant qu’elle prenne auprès des éditeurs).
Commentaire by Emmanuel DESVIGNE — 6 juin 2006 @ 19:34