Nicolas de Loof qui joue les remplaçant est sur scène à nouveau pour prendre un créneau laissé libre, et nous parler de Web 2.0.
Loin du buzzword, Nicolas rappelle d’abord l’architecture du Web, le principe d’un navigateur, les feuilles de style, les moteurs de Javascripts, bref les bases que chacun se doit de connaître lorsqu’il fait du développement Web.
Programmer le navigateur : puissant mais délicat. Vous devez prendre en compte toutes les particularités de chaque navigateur. Si vous n’avez pas entendu parler de XSS ou autre, j’imagine que votre culture dans le domaine de la sécurité web est limité : c’est normal.
Dans les navigateurs, un code mal construit peut entrainer des fuites mémoires dans le DOM par exemple. Encore une fois, quelque soit le langage, l’écriture d’une bonne application web demande donc un bon niveau et une bonne connaissance de plusieurs mécanismes. Comme dans tous langages vous allez me dire… Qui a dit que le web était simple ?
Il a l’embarras du choix dans les librairies Javascript : prototype, jQuery, ext-JS, bref… des librairies à maitriser.
Un développeur web ce sera peut-être 35% de Java, 20% de CSS et de design, 40% de javascriopt et 5% de matière grasse.
HTML5 certes, mais quid du support aujourd’hui ? Et comment moderniser les anciens navigateurs ? Comment dire à son cher client qu’Internet Explorer 6 est une vieille bouse de 11 ans qui devrait être interdit dans les entreprises ?
Nicolas de Loof résume la situation : le web n’est pas simple, mais passionnant. Lui en tant qu’architecte ne souhaite pas avoir à traiter les problématiques bas niveaux pour faire des échanges client-serveur. En tant que chef de projet, si j’ai des compétences Java j’aimerai bien pouvoir utiliser des gars pas chers pour faire ma moche application de gestion qui se trouve tourner dans un navigateur. Or les développeurs JavaScript ne veulent faire que de belles applications et demandent un salaire indécent, bien plus élevé que le salaire d’un Indien…
Bref heureusement il y a une technologie qui répond à tout cela : Google Web Toolkit, dit « GWT ». Le « Pourquoi » de GWT est simple : il permet d’écrire en Java du code qui sera compilé vers du Javascript. On va donc utiliser JS comme assembleur de nos applications webs.
GWT optimise aussi le code généré selon le navigateur, voir même la langue de l’utilisateur. Finalement vous ne payez que ce vous voyez. Pas de
« si je suis sur IE8 fait ceci, si je suis sur IE7 fait cela et si je suis sur IE6 : prie »
GWT est simple, pas cher (open-source), incomparablement moins cher que l’approche MVC. C’est nativement Ajax et très extensible avec Ext-GWT, GWT-Fx ou Smart-GWT. Son point fort est bien entendu que le code JS est généré pour différents navigateurs, ce qui permet d’utiliser les meilleurs pratiques de chaque navigateur.
Le premier nom de GWT était « Red Pill » en référence à Matrix. Soit tu veux regarder comment c’est fait, soit tu t’en sers et tu oublies comment cela fonctionne.
GWT est équipé avec un mode hosté. Out of process Hoster mode permet d’utiliser n’importe quel navigateur pour faire du debug pas à pas dans son code Java.. qui est en fait compilé vers du code Javascript.
GWT 2.x c’est aussi le découpage de votre code JS en paquet et son chargement via runAsnyc. Il existe des bundles pour du CSS et du code natif.
Nicolas parle maintenant du métier de Designer, qui lui sait faire de belles applications. Dans GWT il y a l’UIBinder, pour binder des composants existants à des composants GWT.
Nicolas explique alors que cela permet de produire des applications riches sans devoir prendre (pour l’instant) la pente de l’apprentissage du web (html5, css3, javascript…)
Qui sont les concurrents de GWT ? Peut-être Adobe Flex et le langage ActionScript, qui par contre ne tourne pas sur Apple. Sinon vous avez Microsoft Silverlight. Mais bon, Microsoft a juste annoncé son abandon en octobre 2010. Désolé si je viens de blesser quelqu’un en écrivant ses lignes. Sinon vous avez JavaFX aussi… vous connaissez pas ? En fait moi non plus…
Nicolas explique ensuite le modèle MVP (model/view/presenter), ce qui facilite les tests lorsque la vue n’est pas générée mais mockée. Il présente le modèle « Activity and Places » cousin d’un moteur similaire dans Android. Pour gérer finalement dans l’application le bouton « back » il faut définir des « Places ». Il s’agit donc de l’état bookmarkable de l’application.
Google a aussi annoncé un framework graphique « Cell » qui permet de faire des tableaux paginés, mais cela reste encore un peu artisanal. Nicolas parle aussi du plugin Maven, car c’est l’un des auteurs du premier plugin Maven pour GWT. Google a reprit en main le plugin et propose maintenant un meilleur support de Maven. Les artefacts sont publiés, les chemins en dur ou l’intégration de javax.servlet sont enfin résolus (il ne faut PAS packager un servlet.jar).
Pour terminer, Nicolas cite 2 livres en Français : GWT2 de Sami Jaber et GWT par Olivier Gérardin.
GWT est maintenant un framework mature, qui cependant pêche encore par sa partie « librairie de composant ». Il faut alors se tourner vers des frameworks, parfois propriétaire, mais qui ajoutent un risque de complexité et de support à votre application. Nicolas de Loof réserverait plutôt GWT à des projets d’application de gestions dans un navigateur.
0 no like
C’est vrai, pas de mvc avec GWT, mais du MVP (http://code.google.com/intl/fr-FR/webtoolkit/doc/latest/DevGuideMvpActivitiesAndPlaces.html)
Avec le même coût de mise en oeuvre, voire plus.
Lors des montées de version mineures, il y a des régressions.
Bref, c’est loin d’être la pilule rouge. Ou alors la pilule va être dure à avaler.
Bref, un bon développeur web doit être nécessaire pour réaliser une application web.
Et à tous les chefs de projets qui ne veulent pas payer leur développeur web.
Pay peanuts, get monkeys…
Hello,
> « si je suis sur IE8 fait ceci, si je suis sur IE7 fait cela et si je suis sur IE6 : prie »
Cela fait quand même plus de 10 ans que les techniques de « browser detection » ont été abandonnées. Non seulement ces techniques n’étaient pas fiables et pas flexibles, mais encore elles se révélaient inférieures aux approches combinées de « feature detection » et de « fluid design », toujours d’actualité aujourd’hui. Je doute que l’on retrouve encore, de nos jours, des développeurs, des outils ou des librairies utilisant encore de la « browser detection » (peut-être pour suggérer des versions de sites alternatives pour des mobiles, et encore…).
En tout cas, c’est chouette tous ces retours sur la conférence, merci beaucoup! J’espère que vous en profitez bien là-bas (ici Paris, temps pourri).
« En tant que chef de projet, si j’ai des compétences Java j’aimerai bien pouvoir utiliser des gars pas chers pour faire ma moche application de gestion qui se trouve tourner dans un navigateur. Or les développeurs JavaScript ne veulent faire que de belles applications et demandent un salaire indécent, bien plus élevé que le salaire d’un Indien… »
Cette citation me choque sur plusieurs points :
– « ma moche application de gestion » : Nous faisons des applications pour les utilisateurs. Notre objectif devrait toujours être de faire des applications agréables à l’oeil et à utiliser.
– « Or les développeurs JavaScript ne veulent faire que de belles applications » Et ils ont raisons. Comment peut-on souhaiter travailler sur des applications au rendu désagréable ?
– » et demandent un salaire indécent » c’est le marché qui fixe le prix, c’est le principe de l’offre et de la demande. Aujourd’hui les développeur Java sont chers parceque la demande est forte, demain qui sait …
– « bien plus élevé que le salaire d’un Indien » Là on touche le fond. On passe sur tous les problèmes inhérent au développement offshore. Ce genre d’arguments contribue à dévaloriser le travail des développeurs encore un peu plus. Il ne faut pas s’étonner si en France quand on est développeur on est un sous-homme. Et pour mémoire les chefs de projets Idien sont au moins 4 fois moins Cher. C’est peut-être eux qu’il faudrait commencer par sous traiter.
Je n’ai que ce lien à fournir où tout y est dit:
http://ryandoherty.net/2007/04/29/why-google-web-toolkit-rots-your-brain/
A noter l’article date de 2007!!!!
Côté .Net il y a aussi Script#. Loin de la puissance de GWT mais bien quand même. http://projects.nikhilk.net/ScriptSharp