Le blog de Phil

J'habite Malakoff, la plus belle ville du monde

JSF VS GWT: Choix final: JSF

Ça fait depuis 3 mois que l’on a débuté notre nouveau projet.

Mais comme il arrive que cette note soit consultée, je vais donner les choix que l’on a effectués.

 

Nous avons finalement opté pour JSF.

Le lancement en dé-bug est plus rapide, par ailleurs, une fois le projet construit (j’ai fait le même projet deux fois, une fois en JSF, l’autre fois en GWT), le projet JSF tourne plus vite sous JBoss que le projet GWT.

 

Par ailleurs, s’il faut regarder dans la boite noire, il est plus facile de regarder JSF que GWT.

Donc on peut dire que le choix s’est basé sur les critères suivants:

JSF s’intègre plus facilement dans le reste (Spring, Hibernate, Maven), permet de séparer plus facilement les couches et les fonctionnalités (ce qui est nécessaire car notre fonctionnel est lourd)  et le résultats s’est montré plus performant une fois que l’on a construit le projet (via Maven) et que l’on l’a fait tourner sous JBoss.

25 juillet 2012 Posted by | GWT, Informatique, Java, JSF | , , | Laisser un commentaire

JSF VS GWT, round 1.

Mon blog ne parlant pas que de politique (si, si, je vous jure, c’est vrai), j’ai eu envie de parler de mon travail.

En ce moment, je regarde à fond le choix entre deux technologies: GWT et JSF.

Et j’ai eu envie de revenir sur mon ressenti, surtout que l’ami Sami, qui a écrit un très bon livre sur GWT, a répondu à un autre de ses amis (que je ne connaissais pas) qui explique que GWT n’est plus aussi pertinent qu’avant.
De quoi s’agit-il?

Alors que JSF est un MVC permettant de séparer la présentation d’une vue du traitement métier pour une application web, GWT est un compilateur qui va transformer du code Java, langage informatique universel, en HTML/Java-script/CSS pour la vue.

 

Pour comprendre l’enjeu, il faut revenir à la préhistoire de l’informatique.

Avant, on envoyait une requête au serveur, le serveur traitait, et il rechargeait toute la page. JSF part de ce principe.

Le java-script, langage interprété par votre navigateur, était peu utilisé.

 

Aujourd’hui, le java-script, combiné avec le CSS et le HTML, est mieux utilisé. Votre page web devient une application à part entière et il est possible de demander au serveur de ne recharger qu’une partie de la page.

C’est l’avènement des technologies AJAX et de la philosophie web 2.0.

C’est beau?

Oui mais, il y a un problème: le java-script dépend de votre navigateur, et certains navigateurs sont des cauchemars pour les développeurs (enfin surtout un: Internet Explorer).

 

C’est là qu’intervient GWT: GWT va compiler un site en plusieurs versions, et il va le faire pour chaque navigateur. GWT va optimiser le java-script pour chaque navigateur.

Là est la force de GWT.

Par ailleurs, grâce à l’IDE Eclipse, il sera possible de lancer le site en mode Hosted pour le débogage.

 

Seulement, le choix entre GWT et JSF n’est pas si évident, et aujourd’hui, j’ai tendance à préférer JSF.

La première raison est que JSF est plus facile à maîtriser et qu’il permet de séparer la vue des autres couches plus facilement.

La seconde raison est que JSF ou GWT doivent s’intégrer facilement dans les autres technologies qui ont fait leurs preuves, c’est à dire Maven pour la construction de projet, Hibernate pour la persistance, et Spring pour l’injection de dépendance.

Or l’archétype Maven pour GWT est bourré de faute.

Et comme en mode hosted Google nous impose un Jetty comme moteur de Servlet (alors que le Tomcat est tellement plus simple), j’ai un peu de mal à faire tourner l’ensemble GWT/Jetty dès que j’ajoute Spring (en ce moment, il ne trouve pas une classe Spring).

 

Bref, JSF, même si au départ a été mal conçu, a une structure tellement flexible, que Aujourd’hui, il est possible de faire de l’AJAX avec JSF sans toucher au java-script.

Il existe des librairies comme Primefaces ou RichFaces.

A lire aussi sur le sujet:JSF, je t’aime, moi non plus.

1 mars 2012 Posted by | GWT, Java, JSF | , , , , , | Laisser un commentaire