Crédit photo michael.heiss Licence Commons Creatives 2.0
Imaginons que vous êtes votre framework Web Java favori… Disons que vous habitez dans une maison, qui représente votre framework Web Java.
Fermez les yeux… visualisez une petite usine qui fume avec 345 tuyaux, plusieurs portes d’entrées, des grillages à certains endroits, une pelouse fatiguée, un panneau « Attention, Chien Dangereux (et Con)« , des panneaux solaires qui ne sont pas raccordés, un autocollant « Java 7 Rulez » et des empilements de briques… Il y a souvent des coupures, des problèmes d’allocations de ressources, des débordements de pile. Lorsque vous voulez fermer les volets, vous devez relancer le groupe électrogène. Pour ajouter une chambre supplémentaire, vous avez fait poser une extension sur le toit…
Un jour, un gars vient sonner chez vous. Vous ouvrez la porte et il vous dit : « Bonjour, moi je m’appelle PHP, j’ai l’air moins sérieux que toi, mais je fais tourner de gros sites Webs« . Et toi, tu le regardes comme un hippie Baba-Cool bien gentil, mais au final tu lui lances un « t’es incapable de monter en charge« .
Vlam, tu refermes la porte.
Le lendemain, un autre gars vient te voir et te tape sur l’épaule : « Bonjour, moi c’est Ruby on Rails. Je t’éclate en productivité et en plus mes développeurs s’amusent« . Là tu lui ris très fort au nez et tu lui dis : « Ouais mais Ruby c’est pas comme le Latin ? Une langue morte ?« . Vlam, et tu lâches le chien pour voir s’il a vraiment des soucis de montée en charge.
Le surlendemain, un mec qui semble avoir fumé un arbre sonne à ta porte. Il porte un teeshirt « NE TIREZ PAS : JE TOURNE SUR LA JVM ».
C’est Mr Grails.
Fier comme un pape : « Salut, moi c’est Grails. Je suis enfin là pour t’apporter de la productivité, je suis en Groovy et je tourne sur la JVM… Gentil… pas tirer…« . Et toi de répondre : « Grails c’est pas si performant en production, il faut apprendre Groovy, et en plus tu portes un teeshirt moche« . Le gars a juste le temps de reculer lorsque tu refermes la porte.
Quelques jours plus tard, un gars en costard-cravate, look banal, sonne à ta porte… « Salut, moi c’est JSF2. Je suis un standard, j’ai plusieurs implémentations possibles, je suis là pour tuer Struts2. Comme je suis un standard, je suis bon pour toi et pour ton CV. Par contre pour avoir des composants intéressants il faudra que tu prennes RichFaces/IceFaces ou autre. Et pour ce qui est du REST, on prendra mon pote JAX-RS… et pour la mise en prod on prendra le serveur Trucmuche de 80mo… et blablablabla…« .
Bon là c’est facile, le bonhomme se taille en 4 tout seul. Refermons la porte poliment et retournons à TéléFoot.
Licence Commons Creatives, crédit photo Kenichi Nobusue
Quelques idées sérieuses
Le développement Web fait-il partie du génome des développeurs Java ?
Autant PHP me semble fortement lié à une culture Web, autant Java n’est pas forcément associé au Web. Lors des présentations de Play! Framework, Nicolas Leroux et Guillaume Bort demandaient à la salle du Paris JUG :
Qui est développeur Web ?
Quelques mains timides se lèvent sur les quelques 450 personnes présentes. Guillaume demande ensuite qui a déjà fait des JSPs ou des Servlets. Et là, presque tout le monde lève sa main… Donc si nous comprenons bien ce qui se passe, vous n’êtes pas développeur Web, mais pourtant vous faîtes des JSPs, des Servlets et du Struts…
Ce qui est dommage si nous continuons sur cette idée, c’est que du coup, vous n’avez pas forcément de connaissances en HTML, en CSS, en JavaScript. Si je vous dis que le protocole HTTP est sans état, cela vous semble-t-il alors normal de voir des frameworks massivement avec état, comme le principe même de JSF par exemple ?
Le Web est un vaste espace documentaire. Chaque ressource doit disposer d’une adresse unique, d’une URI. Les répertoires virtuels d’un site doivent être autant de conteneur, pour classer et ranger vos objets, par catégorie. Le protocole Web dispose depuis 15 ans des verbes d’action pour manipuler les documents : GET,POST,DELETE et PUT essentiellement. Saviez-vous que JSF 1.x ne faisait que des POSTs pour échanger des données avec le serveur ? Qui imagine avoir des URLs bookmarkable avec ce type de framework ?
Chaque URL affichée par votre navigateur représente finalement une vue. Les premiers frameworks du monde Java, Struts 1.x pour n’en citer qu’un, ont été construit par dessus l’API des Servlets. Intéressant, lorsque l’on pense qu’une Servlet ajoute la notion de session du côté du serveur, concept qui va rendre la vie des développeurs Javas un peu plus compliqué que prévu. Tout d’un coup, un navigateur qui n’est pas connecté au serveur Web en permanence, demande au serveur de maintenir une session. Le concept magique de session, qui permet d’acheter des oiseaux dans un magasin, devient la référence pour les développeurs Webs. Cette démonstration a eu l’effet d’un lampadaire sur les moustiques : tout le monde a plongé dans le monde formidable de la session. J’y reviens plus loin dans quelques lignes.
Le jour où Gavin King a annoncé Seam, il explique entre autre avec fierté que son framework gère le bouton « Back » du navigateur… Chose qui me semble normal, et que nous savions gérer en 1997 avec du Perl, et un peu d’huile de coude.
La session dans les frameworks Webs Java est un objet assez mal compris. L’implémentation de certains frameworks Webs, que j’appelle « avec session » comme Tapestry, Struts ou Wicket, utilisent un Cookie pour identifier la session du navigateur avec une session en mémoire sur le serveur. Ce ticket permet de stocker sur le serveur des objets volumineux. Je vois alors le framework Web comme une sorte de Mont de Piété. Vous déposez vos valeurs, on vous donne un ticket. Lorsque vous revenez, vous récupérez alors vos valeurs, votre session contre ce ticket. Ce mécanisme est nécessaire car il n’est pas souhaitable de sérialiser vos données et de les passer au client. Le souci : cela entraîne une consommation de mémoire du côté serveur car le développeur Java aura tendance à mettre en session tout et n’importe quoi.
Il y a eu une tentative de faire travailler le navigateur Web, et de lui donner alors toutes les données de session. L’avantage ? Les Serveurs sans état peuvent alors être monté en cluster, et le navigateur passe les données de session de page en page. Cela fonctionne avec de la réécriture d’URL lorsque vous faîtes des GET ou en postant les données dans des champs cachés si vous faîtes du POST. Cela marche très bien, c’est le principe d’eBay. Il y a cependant quelques limitations, comme la taille des URIs par exemple. Vous ne vous êtes pas demandé quel serait la taille maximale d’une URI ?
Avant tout, la RFC 2616 (Hypertext Transfer Protocol — HTTP/1.1) précise dans la section 3.2.1 qu’il n’y a pas de limite sur la taille d’une URI. En théorie, il serait donc possible de passer des données de session énorme. Dans les faits, c’est faux. Internet Explorer ne dépasse pas 2083 caractères, Firefox pousse jusqu’à 65565 caractères. Mais les serveurs Webs comme Apache limitent à 4000 caractères par défaut, comme parfois les proxy qui se chargent de faire de la redirection ou du load-balancing.
En général, les frameworks Webs évitent d’avoir une notion de session qui coûte de la mémoire côté serveur lorsque celle-ci n’est pas indispensable. Les frameworks Javas ont proposé très tôt ce concept de Session. Pour monter plus de Sessions, il faudra souvent avoir plus de mémoire. Personne n’aura expliqué au développeur Web Java comment calculer la taille de sa session.
Il y eu ensuite le souci de la durée de vie des Sessions. Soit aucune session, proche des EJB stateless, soit avec une session, on pense aux EJBs statefull. Mais ce concept métier ne fonctionnait pas bien avec le Web. Lorsque les premières architectures Webs pour la partie vue ont commencé à discuter avec des architectures métiers écrites sur la base des EJB 2.x, ce fut assez amusant. Pour que le monde du Web puisse afficher des données sur plusieurs écrans successifs, il fallait les stocker dans le « Web Tiers ». Nous avons utilisé des DTO, représentant des données venues de la partie métier. Puis quelqu’un a dit un jour que la séparation entre le Web tiers et l’EJB Tiers était une grosse bêtise inventée par des vendeurs de machines. Et nous avons tué cette idée aussi rapidement qu’elle s’était diffusée. Je rigole pas trop fort car je connais encore beaucoup de systèmes en production avec un tiers Web, et un tiers EJB. Il y a un firewall entre le monde extérieur et le Web tiers. Puis un deuxième firewall entre le web tiers et l’ejb tiers. Bien entendu, 4 machines pour le tout, afin de faire du load-balancing… J’imagine le sourire du commercial qui a vendu les machines à l’époque.
Seam a introduit le concept de conversation. En décembre 2006 j’en parlais avec passion. Cela a été repris dans CDI, dans JEE6. Et le concept de conversation Flash est aussi maintenant partie intégrante de Grails ou de Play! Framework par exemple. Preuve qu’il est possible de gérer de manière fine la durée des sessions.
Tout ceci pour dire que je crois que les frameworks Javas et le monde Web ne se sont pas vraiment compris. Nous avons souvent une complexité culturelle avec Java, qui n’est pas nécessaire lorsque l’on fait du Web (idée de Guillaume Bort, auteur de Play! Framework). Les développeurs Javas que je connais, même les meilleurs, n’ont pas nécessairement la culture Web. Avoir une culture Web pour moi, c’est connaître le protocole HTTP, HTML, CSS, REST et les possibilités des architectures sans états. Ce n’est pas imposer une vision middleware, qui ne fonctionne pas avec le Web. C’est certainement une chose sur laquelle nous devons encore travailler, nous qui sommes développeur Java. Le jour où SUN Microsystems, IBM et HP ont décidé que pour vendre de la machine, il fallait de la complexité, nous aurions dû faire attention. Pourquoi les autres langages comme PHP, Python, Perl ou C# ont-ils des frameworks Webs digne de ce nom ? Parce qu’ils n’ont pas cherché à en faire une longue histoire compliquée. Parce qu’ils ont respecté HTTP pour ce qu’il était, sans essayer une danse du ventre pour séduire les développeurs, pour finalement les planter quelques mois plus tard. Que celui qui n’a jamais entendu un AdminSys râler à propos de Tomcat et des serveurs d’applications lève la main…
J’écris cela car je pense que le Web et Java ont encore des efforts pour se comprendre. Je ne suis pas extasié devant GWT, inventé pour masquer la complexité de JavaScript. Je ne suis pas impressionné par Apache Wicket qui permet de coder « à la Swing » dans un monde massivement orienté objet une application Web, qui n’a que faire de l’orienté objet. Je ne suis pas impressionné par JSF 2 qui a rattrapé le retard, mais qui dispose de plusieurs implémentations, qui demande le support d’une librairie externe pour faire de l’AJAX, et qui demande des librairies pour faire de l’orienté composant…
Je suis impressionné par contre par la créativité des développeurs Javas, qui cherchent parfois à faire du client lourd dans un navigateur, en appelant cela « un client léger ». Bon sang, une application Web n’a rien à voir avec la vision à papa, avec des fenêtres et des boutons qui font pouet-pouet… Prenez dans ce cas une techno comme Flex par exemple, pour faire un client déporté
Je pense qu’il est temps de faire simple. Les vraies architectures Webs c’est pour maintenant. Allez lire sur le blog de Guillaume Bort pourquoi Play! Framework n’est pas basé sur l’API Servlet. C’est très intéressant.
Merci de penser que Java et les frameworks Webs c’est simple.
Ca me rappelle une anecdote. A la conférence ParisWeb 2009 (dédiée à la qualité des conceptions Web et à l’accessibilité), alors que 3 à 400 développeurs Web étaient dans l’amphi, l’orateur a demandé « qui fait du Java ». Nous étions deux à lever la main !
Merci pour ton poste qui pose les premières briques pour déclencher une réflexion sur le développement Web dans le mode Java. Directeur technique d’une entreprise Web c’est à dire qui un entreprise créant des sites Web plus ou moins complexe, j’ai eu à réfléchir de ce problème car nous développons des sites en Java, .NET, PHP. Comment permettre aux intégrateurs (personnes connaissant parfaitement le HMTL, CSS, Javascript ) de travailler sur un projet avec l’équipe de développement avec le plus d’aisance possible.
Mon commentaire se limitera à la portée du post à savoir le développement d’application Web en Java.
Quand je suis arrivé, l’équipe Java utilisait struts et les intégrateurs devaient absolument connaître les taglib pour pouvoir être autonome vis à vis du code et de l’application. Nous avons décidé de tester Wicket comme Framework de développement pour l’équipe Java et depuis plus de 8 mois que nous l’utilisons tout le monde est ravi, surtout les intégrateurs qui peuvent à tout moment jouer très facilement avec leur environnement de développement préféré (oublié les eclipse, Intellij ou Netbean) pour éditer seulement les pages HTML.
J’ai essayé d’utiliser Play comme Framework de développement mais malheureusement pour moi ce Framework n’offre pas la même flexibilité du côté front-end que Wicket. Les intégrateurs doivent absolument réapprendre un nouveau langage de Scripting ce qui n’est pas à mon point de vu le bon choix pour développer des applications.
@Jerome : D’accord avec toi sur la facilité d’intégration lorsque tu dois faire cohabiter des monteurs webs avec des développeurs Java. Autant il est courant de voir des bons développeurs Webs avec un bon niveau en PHP, autant c’est plutôt rare avec un profil Java. C’est bien le signe qu’il y a quelque chose qui cloche dans notre culture.
A titre personnel, je préfère que le développeur Java prenne en charge la partie intégration et se bouge un peu pour aller jusqu’au navigateur. Avec Spring MVC par exemple, tu peux intégrer Tiles, Facelets ou autre pour préparer des modèles de page HTML. Idem avec Grails ou Play! par exemple. Le travail d’intégration est relativement léger.
Le Web c’est bien, c’est sympa. C’est dommage de ne pas s’investir et de passer la main dès que les mots CSS ou HTML tombent dans la discussion.
Je m’arrête 2s juste pour dire combien je suis d’accord avec cet article, ça ne fait jamais de mal 🙂
@Nicolas
De mon point de vue, l’intégration et le développement sont deux métiers différents. Certe un développeur Java doit avoir des connaissances HTML, CSS, Javascript pour pouvoir se débrouiller une fois le visuel monté, mais tout dépend réellement de ton niveau d’intégration avec la maquette originale (PSD). Nous nous devons en tant que firme web de nous rapprocher le plus possible des visuels créés par notre directeur artistique et je n’ai jamais rencontré un développeur tant PHP, Java ou .NET arrivé à un tel niveau d’intégration. Souvent les bons développeurs PHP qui font de l’intégration sont trés souvent des intégrateurs qui ont appris le PHP.
> Et toi, tu le regardes comme un hippie Baba-Cool bien gentil, mais au final tu
> lui lances un « t’es incapable de monter en charge
Effectivement, c’est une remarque que j’entends souvent au ParisJUG, a croire que vous travaillez tous chez Google. Cela me fait toujours penser à une vieille mission dans une banque avec une équipe de 6 dev + 1 CDP pour quelque chose comme 5000 visites / mois.
> Ouais mais Ruby c’est pas comme le Latin ? Une langue morte ?
Encore juste, si cela n’a pas 80% du marché, c’est pas intéressant. A croire que le critère est la possibilité de l’utiliser chez son client le plus frileux (et comme vous avez pratiquement que des clients banque / assurance ou grosses boites…)
> Le jour où Gavin King a annoncé Seam, il explique entre autre avec fierté que > son framework gère le bouton « Back » du navigateur… Chose qui me semble
> normal, et que nous savions gérer en 1997 avec du Perl, et un peu d’huile de
> coude.
tu me fais penser a l’anniversaire ParisJUG ou la salle a applaudit le fait de tester sans compiler une pauvre page HTNL et autres trucs ridicules. Et moi de penser : je fais tout cela depuis 1998.
> Nous avons souvent une complexité culturelle avec Java
Et tu peux pas savoir a quel point. Votre référentiel est maintenant tellement erroné que toute chose simple est devenu suspect aux yeux d’un développeur Java. Comme les admin mainframe voici 10 ans quand je parlais du PC qu’ils qualifiaient de « jouet ». Tu m’as dit d’ailleurs a notre 1ere rencontre « moi aussi, je faisais du P mais maintenant je fais un truc sérieux¨.
> qui n’est pas nécessaire lorsque l’on fait du Web
Qui n’est pratiquement jamais nécessaire :). La clé du dev a mes yeux est la simplicité. C’est un sujet intéressant que j’aimerais débattre, car d’expérience tous les gros trucs bien complexe sont partis a la poubelle.
> Bien entendu, 4 machines pour le tout, afin de faire du load-balancing…
> J’imagine le sourire du commercial qui a vendu les machines à l’époque.
Tu touches une partie de l’explication. Nous sommes dans un monde de SSII qui vend du service pour des clients ignares lisant 01. Qaund on regarde le fonctionnement d’un éditeur c’est bizaremment plus les mêmes technos.
@Benoit je devais être la deuxième main levé au Paris-Web 2009.
Pour compléter le propos, je suis toujours étonné de manque de porosité entre les communautés « intégrateur web » et le monde java. Il y a seulement quelques travailleurs deux web qui passent au normandy jug sur certains sujets connexes (flex, scrum).
Pour revenir, « Les développeurs Javas que je connais, même les meilleurs, n’ont pas nécessairement la culture Web. », j’ai été super étonné d’une conversation que j’ai eu avec Antonio sur des exemples de HTML du chapitre JSF du livre Java EE 6. En effet, je râlais sur des exemples avec des mises en page de formulaire avec des tableaux. Je lui ai donc soumis une version mise en page avec du CSS (qui est un peu moins verbeuse si je me souviens bien).
> »Je ne suis pas impressionné par JSF 2 qui a rattrapé le retard, mais qui dispose de plusieurs implémentations, qui demande le support d’une librairie externe pour faire de l’AJAX, et qui demande des librairies pour faire de l’orienté composant… »
– JSF2 gère l’ajax nativement
– mais qui dispose de plusieurs implémentations (je ne comprends pas non plus le sens de la phrase), c’est un inconvénient ?
– il ne demande pas non plus de librairie pour faire de l’orienté composant, il est nativement orienté composant.
@youen J’ai eu exactement la même réaction en lisant le bouquin d’Antonio !
@Damien : j’ai corrigé la coquille concernant Ajax et JSF2 dans le texte. Je ferai un long post sur JSF2 pour la peine, afin de faire une distinction entre cet article où je polémique volontairement, et ce que je pense réellement de JSF2. JSF est vraiment intéressant lorsque tu prends des librairies en plus comme IceFaces ou RichFaces, afin de pouvoir vraiment faire ce que j’appelle de l’orienté composant : des tableaux dynamiques, des panels et des trucs sympas, qui donnent un intérêt certain à JSF par rapport à d’autres frameworks. C’est un plus comparé à d’autres frameworks qui te demanderont plus de travail pour écrire des TagLibs, et finalement faire un peu près la même chose. J’apprécie ces composants dans JSF, j’en parle depuis fin 2006 sur le Touilleur Express.
JSF2 et Ajax : http://weblogs.java.net/blog/2009/01/21/simple-jsf2ajax-example
Pour Damien, de la vieille lecture sur JSF 1.2. Cela date de mi 2005.
http://www.touilleur-express.fr/2005/06/17/struts-ou-jsf-ou-les-deux/
J’en profite pour poser une question qui me turlupine depuis un moment déjà : comment, en ne connaissant que Java, peut on produire un site web grand public ?
Le seul exemple que je connais, c’est linkedin, et à mon avis ils ont dû en chier non ?
Je me demande si je ne vais pas finir par apprendre le php :/
ps : mon anti-spam word était « grails c top ».. coincidence ? :p
@Nicolas :
JSF 1.X n’était intéressant que si tu l’accompagnais d’une librairie proposant des widgets graphiques (j’appelle çà widget pour faire le distinguo avec les composants).
JSF 2, n’a plus besoin de Richfaces, IceFaces pour exister. Si tu es, ce que vous appelez un bon développeur web et que tu sais te servir de CSS, HTML, JS, alors tu pourras créer toi meme tes composants assez facilement.
A mon avis le couple JSF2 + jquery-ui a de beaux jours devant lui. Si tu as besoin d’un coup de main pour ton article sur JSF2, n’hésites pas.
et bien moi personnellement je suis plutôt négativement surpris par l’article.
Nicolas, tu as une réelle capacité a bien expliquer les choses, à les simplifier, vulgariser (dans le sens très positif du terme). Cependant à trop vouloir imager et simplifier les choses, on transforme un sujet complexe en une pointe d’iceberg qui cache les vrais problèmes.
Après 10 ans d’expérience (donc bien moins que toi à priori!), je ne peux qu’être choqué par ton article.
La question n’est pas de savoir si un fwk est assez simple ou non. S’il était simple de faire qqch de simple (sympa la formulation) ça se saurait.
Tu sembles dire que ‘peu importe le type d’appli’, il devrait y avoir un fwk simple. Et s’il est pas simple, c’est qu’il faut passer au flex, pkoi ne pas tout déployer en eclipse RCP dès qu’il n’y a pas de fwk web simple???.
Mais le web est synonyme d’économie de déploiement, c’est la base de notre métier depuis 15 ans et ce pourquoi nous sommes confrontés en permanence aux problématiques qui rendent les choses compliquées.
Tu ne peux comparer une appli vitrine qui ne fait rien à une appli de trading qui va te demander de tenir une charge monstrueuse, de servir une sécurité énorme et garantir une robustesse dantesque.
Car il est bien là le problème, il faut savoir utiliser php quand c’est simple et basculer à l’artillerie lourde quand on a pas le choix.
A chaque démo funky d’un nouveau fwk, ici Play!, il est toujours tentant de s’enflammer. Après on met en application et __selon le type__ d’appli, là on peut vite avoir des suées.
Moi je suis désolé mais fort de mon expérience, sur de grosses applis d’entreprise,
– jamais je ne m’amuserai à employer la dernière base objet à la mode ‘qui arrache tout’ alors que je sais pertinemment que mon client me demandera dans 2 ans des process de reporting énormes avec extraction de statistiques
– jamais je n’accepterais ces fwks ‘sympas’ à très haute productivité ou même du php sur une appli qui se plug à une bdd contenant entre 100 et 1500 tables. Il y a ce qu’on appelle la dette technique. Alors coder une appli en 2 semaines m’intéresse pas si au moindre ajout de colonne je doit me taper 4000 requêtes coder en dur.
– idem pour le stateful, je suis désolé mais là encore, on dispose de moyens qui permettent désormais de tenir la charge avec du stateful, que ce soit niveau hardware ou niveau fwk bien plus léger qu’avant (SEAM typiquement), ce qui n’était pas le cas il y a 12 ans avec les vieux serveur est les specs précédentes. Ces FWKs sont là pour bridger entre le web qui n’est nativement pas stateful et le middleware EE (you know ENTERPRISE edition?) qui offre des solutions stateful non pas sympas mais REQUISES pour répondre à des besoins réels.
– j’aimerai bien une étude poussée sur une réponse à un appel d’offre pour une appli bancaire. Une réponse que tu donnerais pour une implémentation en php ou Play! sur une base objet ou en exploitant un de ces fwk orientés CRUD super so quickly implementable that it makes ORM sucks ou même IBatis. Je serai déjà surpris de la faisabilité du bignou
Je ne dis pas Play! ou php ou IBatis ou db4o sont nuls, ils sont excellents mais arrêtons de confondre une appli de pages perso, un blog, une appli moyenne, une appli qui doit supporter le failover, un appli qui doit gérer des accès concurrents en protégeant les données et les applis d’entreprises qui ont besoin de tout.
Notre boulot, en tant qu’architectes, n’est pas de trouver le meilleur fwk mais bien de trouver la techno la plus viable, pérenne, robuste, productive EN FONCTION DE L’APPLI QU’ON NOUS DEMANDE DE REALISER.
Très bon article, je rejoins ton avis sur pas mal de points, notamment sur les architectures trop complexes pour rien (DTO…) et sur l’aspect statefull des frameworks, dont on pourrait bien souvent se passer et qui nous apporte finalement pas mal de problèmes…
J’avais dailleurs écrit un petit billet là dessus en comparant Wicket et Play, après avoir pas mal galéré à cause de l’aspect statefull de Wicket (meme si je reste persaudé que c’est un très bon et très puissant framework) :
http://coffeebean.loicdescotte.com/2010/03/philosophies-de-frameworks.html
Loïc
@Anthony.
100% d’accord avec toi. La création de site Web ne dépend pas du langage de programmation ou du framework que tu utilises. Gérant des équipes multidisciplinaires .NET, Java et PHP, nous développons tous les jours des sites dans ces trois langages.
Chaque langage a ses forces et ses faiblesses mais la clé la création des sites Web suppose qu’une des personnes de ton équipe connaisse parfaitement le CSS, Javascript et surtout les problématiques reliées aux navigateurs.
La réflexion devrait plutôt se porter sur l’utilisation des langages dans la création d’applications Web ou pas.
J’entends très souvent dire que le langage PHP est le seul langage approprier pour développer des sites Web. De mon point de vue, le langage PHP est tellement orienté Web qu’il oblige les développeurs PHP d’être des développeurs Web ce qui n’est pas le cas pour les développeurs Java ou .NET.
Le jour où les entreprises rechercheront des spécialistes Web Java et non pas juste des spécialistes Java connaissant la finance, l’aéronautique, les télécoms etc… les développeurs Java devront commencer à acquérir ces connaissances Web qui leurs font défaut.
Pour ce qui est de Play! je me suis amusé avec après avoir été vu une présentation assez bluffante de Guillaume Bort. C’est vrai que c’est simple, vraiment bien pensé, tout est bien imbriqué et intégré…
Par contre (c’est un peu hors sujet) mais je pense qu’il manque encore quelques « composants » (des tags en fait puisqu’il n’y a pas de composants dans play) pour faciliter les choses, comme faire un tableau avec pagination sans utiliser le module CRUD… c’est pour ça que je trouve que Wicket a encore un intérêt, il offre la possibilité de créer des composants riches très facilement, cependant l’approche de Play est la bonne et il peut encore s’améliorer coté vue, le meilleur est surement à venir.
SInon un fwk qui semble intéressant, Apache Click, propose à la fois une approche stateless et une approche composant et événementiel. A creuser….
Un des problèmes majeurs est qu’il est vraiment difficile de trouver des leads développeurs Java qui comprennent vraiement le web côté client.
Les technos J2EE en sont un exemple flagrant (JSF), mais côté Spring aussi il ne sont pas très bon côté Front (Spring MVC).
Pour moi, au délà des frameworks actuels (Wicket, Play, Tapestry 5 …), je pense que le futur appartient à des solutions qui ne sont pas basées sur des frameworks MVC côté serveurs (cf. ce qu’on a commencé à faire sur RESThub).
Plutôt que de mettre en place des abstractions compliquées côté serveurs qu’on est systématiquement obligé de bypasser côté clients avec l’utilisation de frameworks Javascripts, autant faire du vrai SOA avec une couche serveurs qui se limite à la couche services + webservices REST.
On peut alors vraiment coder notre couche Front avec les technos du web.
> Cependant à trop vouloir imager et simplifier les choses, on transforme un
> sujet complexe en une pointe d’iceberg qui cache les vrais problèmes.
ah, y’a toujours une personne dans un débat pour montrer que tous le monde a faux car ne parlant pas des « vrais » problèmes, sous entendu pour dire « moi je sais de quoi je parle ».
> S’il était > simple de faire qqch de simple (sympa la formulation) ça se saurait.
Extraordinaire ! Les choses simples n’existent donc pas. Dans ton monde peut être…
> Tu sembles dire que ‘peu importe le type d’appli’, il devrait y avoir un fwk
> simple. Et s’il est pas simple, c’est qu’il faut passer au flex, pkoi ne pas
> tout déployer en eclipse RCP dès qu’il n’y a pas de fwk web simple???.
Ce n’est pas le propos de Nicolas.
> Mais le web est synonyme d’économie de déploiement, c’est la base de notre
> métier depuis 15 ans et ce pourquoi nous sommes confrontés en permanence aux
> problématiques qui rendent les choses compliquées.
Cette phrase vaut son pesant de cacahouetes.
> Tu ne peux comparer une appli vitrine qui ne fait rien à une appli de trading > qui va te demander de tenir une charge monstrueuse, de servir une sécurité
> énorme et garantir une robustesse dantesque.
On a donc d’un coté « une appli vitrine » et de l’autre « une appli de trading ». Bien sur, le monde s’arrête a ces 2 types de developpement. Et on devine qui peut faire quoi.
> Car il est bien là le problème, il faut savoir utiliser php quand c’est
> simple et basculer à l’artillerie lourde quand on a pas le choix.
Tu as deja fait du php pour dire ce genre de choses ? Yahoo, c’est un site vitrine ?
> Moi je suis désolé mais fort de mon expérience, sur de grosses applis
> d’entreprise,
Ah, c’est vrai que ton expérience est suffisant pour annoncer des vérités, n’est ce pas ? Et c’est ballot, Nico parle de web, pas d’application de « trading a 1500 tables qui doit supporter du reporting massif dans 2 ans ».
> Notre boulot, en tant qu’architectes, n’est pas de trouver le meilleur fwk
> mais bien de trouver la techno la plus viable, pérenne, robuste, productive
> EN FONCTION DE L’APPLI QU’ON NOUS DEMANDE DE REALISER.
Dans ce cas, combien de langages et de technos tu proposes a tes clients ?
De la même façon que la bonne longueur pour les jambes, c’est quand les pieds touchent par terre, le bon framework est celui qui répond au besoin.
Donc ne cherchez pas à trouver le meilleur : chacun rencontre des cas différents des autres.
Hors sujet : N’existerait-il d’ailleurs pas un endroit qui pourrait sortir le framework le mieux adapté à un ensemble de fonctionnalités projet requises ?. Ca pourrait être amusant …
Sinon, il y a un autre point qu’il ne faut pas oublier et qui relègue au second plan les qualités intraséques d’un framework : investire dans un framework coute cher et une SSII ne peut pas se payer le luxe de repartir à zéro sur un nouveau projet au pretexte qu’un framework qu’elle n’a encore jamais utilisé serait mieux adapté à son projet que celui qu’elle utlise habitellement. On aura donc toujours une inadéquation entre le besoin client et le framework utilisé. C’est pour ça que les entreprises investissent dans des frameworks plus lourds, soit, mais qui répondent à un spectre de besoins plus important …
@Sebastien
il me semble que tes propos sont assez agressifs mais peu importe, si tu ne sais nuancer la forme, c’est ton problème.
« moi je sais de quoi je parle », ce n’est pas du tout ce que j’ai dit. J’ai juste indiqué qu’il était dangereux de trop simplifier et je suis persuadé, mais je ne veux pas parler pour lui, que Nicolas à déjà expérimenté de mauvaises surprises en creusant sur une techno qui s’avérait a priori ultra prometteuse car simple et productive.
« Extraordinaire ! Les choses simples n’existent donc pas. Dans ton monde peut être… »
Ne déforme pas mes propos. Dans cet article, on reproche à la plateforme java de ne pas savoir faire assez simple en ce qui concerne le web. Je dis juste qu’après 2 décennies, s’il avait été possible d’avoir qqch de simple, on l’aurait, il faut juste encore plus de temps. Et si EE.web, JSF, blah blah sont massivement utilisés, malgré que ce soit incomplet et il est vrai parfois complexe, c’est bien qu’il faut de temps en temps une couche de complexité pour couvrir certains besoins.
Ce qu’il faut noter, c’est l’évolution de Java qui s’est bien dépouillé et amélioré au fil des années. C’est un cycle normal d’évolution et on arrivera pas du jour au lendemain à transformer un jeu de pré-requis web si large en un FWK super simple et ultra productif, ça me parait naïf. Avant de me basher irrespectueusement, merci de lire la suite de mes propos.
« Ce n’est pas le propos de Nicolas. »
La phrase qui m’a fait tilté, pour être exact est la suivante
« Bon sang, une application Web n’a rien à voir avec la vision à papa, avec des fenêtres et des boutons qui font pouet-pouet… Prenez dans ce cas une techno comme Flex par exemple, pour faire un client déporté »
Je suis à 4000% d’accord avec Nicolas sur le fait que les clients ne connaissent pas toujours la nature du Web et qu’ils demandent encore souvent des IHM type power builder ou autre. Mais aller leur dire qu’il faudrait switcher sur flex ou client déporté, c à d, clients plus lourds, c’est mal connaître le poids du coût du déploiement dans les budgets des clients. C’est d’ailleurs super contradictoire mais ce sont ces besoins type client un peu plus lourd qui ont fait exploser le web (je vous refais pas l’historique AJAX… WEB 2.0 buzz biz) donc maintenant aller dire au client, tu veux du lourd du prends pas le web… ça me parait un peu fort.
« Cette phrase vaut son pesant de cacahouetes. »
Merci, je peux te filer mon adresse pour m’envoyer les cacahuètes (uè, pas oue…). Sinon contre argumenter peut aussi parfois être plus constructif que balancer des pics de ce genre.
« On a donc d’un coté « une appli vitrine » et de l’autre « une appli de trading ». Bien sur, le monde s’arrête a ces 2 types de developpement. Et on devine qui peut faire quoi. »
Pour le seconde fois, merci de lire mes propos avant de dire n’importe quoi, je cite de nouveau mon propre poste, car tu choisis tes lignes apparemment:
« mais arrêtons de confondre une appli de pages perso, un blog, une appli moyenne, une appli qui doit supporter le failover, un appli qui doit gérer des accès concurrents en protégeant les données et les applis d’entreprises qui ont besoin de tout. »
Cours de Français; tu noteras que dans cette phrase, que tu n’as pas lue, j’ai employé l’énumération qui montre assez facilement et explicitement qu’il y a moult types d’application, j’en cite d’ailleurs un éventail assez représentatif, je trouve.
« Tu as deja fait du php pour dire ce genre de choses ? »
Si tu savais …
« Ah, c’est vrai que ton expérience est suffisant pour annoncer des vérités, n’est ce pas ? Et c’est ballot, Nico parle de web, pas d’application de « trading a 1500 tables qui doit supporter du reporting massif dans 2 ans ». »
Désolé si tu comprends tout de travers, mais tu ferais mieux de relire les propos à 2 fois. Je n’annonce pas de vérité, je nuance des généralités que je trouve ‘rapides’ et trompeuses. Quand je te parle d’appli de trading, ça peut être divers types d’appli. Toi tu nous balances « nico parle de web » mais mon garçon, le web c’est quoi? C’est aussi et surtout le front d’un back plus ou moins costaud responsable d’implémenter le business. Merci d’argumenter parce que si Nico parle de Web sans rien derrière, moi je ponds de l’HTML statique et je m’embête pas avec des FWK… !
« Dans ce cas, combien de langages et de technos tu proposes a tes clients ? »
1 seule, du delphi bien sûr.
Je tiens à répéter tout le respect que j’ai pour Nicolas et ce blog qui est toujours très intéressant. Je ne dis pas ça pour passer de la pommade après mes propos qui, apparemment, sont ‘méchants’ et ‘prétentieux’ pour certains (bisou Sébastien qui s’il me connaissait saurait que je suis qqun de constructif et non gratuitement caustique comme lui) mais parce que je le pense vraiment. De même, peu importe le FWK (à de rares exceptions près), j’ai un énorme respect pour tous ces projets, je dis juste que selon le type d’appli, on se retrouvera à devoir utiliser le mammouth EE qui a du mal à se défaire de sa réputation surfaite.
En passant, la reconnaissance ultime pour un FWK novateur, productif et robuste ne serait-elle pas bien souvent, de se voir un jour devenir standard de fait, puis spec lead and de se retrouver selon son spectre dans EE… c’est un débat, je le sais mais ça permet d’y réfléchir.
@Anthony et @Seb : bon les gars, y’a jamais eu de baston sur le blog, donc vous n’allez pas commencer hein ? :-)))) Ca serait une première.
Moi je vais vous dire, j’ai beaucoup apprécié vos commentaires à chacun que j’ai lu plusieurs fois. Je pense que je touche un sujet sensible. J’ai un passif de 6 ans chez Reuters, et mon boulot était pendant 3 ans de faire de la veille techno sur les différents frameworks Webs. Reuters est un éditeur de logiciel dans la finance. Côté Trading je connais. Pour Seb, oui tu es un poil un peu direct dans tes propos mais lorsque l’on te connait, on sait que tu es un gars entier, et qui a le mérite de remonter le courant dans l’autre sens.
Je partage le point de vue d’Anthony qui a le mérite d’exprimer ce qui fait notre boulot au quotidien : devoir travailler avec des Frameworks pas forcément très sexy. Je partage le point de vue de Sébastien : il n’est pas nécessaire d’avoir des frameworks « compliqués » pour résoudre des problèmes « compliqués » ou « sérieux ». Au contraire, il s’avère qu’avec le recul, des frameworks simples et surtout productifs comme Grails ou Play! Framework peuvent résoudre des problèmes compliqués.
Enfin dans l’article, j’ai un peu balancé sur toutes les technos, en disant aussi des bétises sur JSF2 (merci Damien de ne pas m’en tenir rigueur) et désolé pour ce côté « People ». Mais grâce à cela, nous avons une vraie discussion sur un sujet de fond :
Ne trouvez-vous pas que jusqu’à maintenant, les frameworks Webs dans le monde Java ne sont pas tops par rapport à d’autres langages ? Pourquoi faisons-nous parfois « compliqué » ? Est-ce que c’est un problème culturel de notre part ?
Allez les gars, on se prendra une bière au Paris JUG.
Merci pour votre retour, à chacun.
Je rejoins totalement @Anthony (et j’ai pas compris l’agression qui a suivi), je trouve que le discours actuel autour des frameworks à « haute-productivité » est souvent trop simpliste. Un framework simple ou compliqué, ça n’existe pas dans l’absolu. Il l’est au vu d’un type de projets voire d’un projet donné, voire de la phase de développement du projet (prototypage, dev, tests, maintenance, …), c’est tout. Celui qui n’a pas compris ça, ben c’est qu’il manque encore un peu d’expérience, non ? 😉
Et je reste toujours surpris de voir l’engouement autour de nouveaux frameworks type Grails, Wicket ou Play! Ca donne l’impression d’un buzz alimenté par un microcosme de geeks spécialistes en prototypage (et copinage), qui n’argumentent qu’accidentellement sur des utilisations opérationnelles. Le côté positif, c’est évidemment le foisonnement de bonnes idées dans lesquelles piocher, et le côté dynamitage de la concurrence qui gardent Java éveillé.
Maintenant, quand c’est porté par un discours puéril à la Play!, à savoir que tous les frameworks Java web c’est de la daube parce que leurs concepteurs ne connaissent pas le web (Lyon JUG du 20/04), ça ne participe pas vraiment à renforcer la crédibilité du mouvement…
En tout cas, toujours autant de plaisir à lire ce blog et ses commentaires. 🙂
Depuis un an, je publie dans GNU Linux Mag des articles dans la même veine (cf. mon blog). Je partage complètement cet avis. Pourquoi faire simple si on peut faire compliqué ? Ce qui compte c’est la ligne de plus sur le CV, pas la réussite du projet 😉
Jean-Pierre Troll
Ah excellent, j’aime beaucoup @Jean-Pierre Troll, je lis souvent tes articles dans Linux Mag 🙂
Et si une partie du pb venait de ces gentilles SSII et des ces editeurs – open source ou non – qui prétendent révolutioner le monde à chacune de leur création ?
Je m’explique : bien souvent on veut nous faire croire qu’on a besoin de gérer les mêmes problématiques techniques complexes pour construire une appli hautement transactionelle à 1000req/s et 100 millions de lignes que pour une « disposable app » qui va gérer qq centaines de documents pour l’intranet d’un département de 10 personnes pendant 1 an ? Croyez vous vraiment qu’on a besoin d’EJB, de n couches, de x serveurs, d’un Hudson/Maven/SVN/Ivy/Tartanpion de build pour faire un truc aussi « simple » ?
J’aime beaucoup les concepts d’application « situationelles » qui peuvent bien souvent être réalisées avec des fwk plus simples, le tout est de savoir passer a du plus lourd qd il faut.
J’aime aussi le concept de « good enough solutions » ou, en gros, ne pas toujours essayer de faire l’architecture de la mort qui tue mais de faire « juste ce qu’il faut »…mais évidement, avec ça, on vend moins de licence, moins de jour de consultant, moins de support…
Amen.
J’ai longtemps eu peur d’avoir été le seul à penser ce qui est décrit dans le billet. En tant que développeur web contrarié de faire du « Xnet », je suis aujourd’hui rassuré. 😉
Moi aussi j’ai été rassuré par cet article.
Jamais je n’ai été convaincu par les frameworks web (surtout pour faire du faux client lourd…)
Bref les derniers frameworks remettent un peu en cause le tout servlet.
Ca me plait bien.
Moi j’ai plutôt découvert Tapestry 5. Ce qui m’a convaincu à l’utiliser c’est ça : Tapestry Page Lifecycle
Et vous, vous en pensez quoi de Tapestry 5 ?
Désolé problème avec le lien :
http://tapestry.apache.org/tapestry5/guide/lifecycle.html
@Benoît @youen Je l’admets, je suis une quiche en HTML/CSS. Mais dans la 2e édition de mon livre, j’ai viré les table, td et tr pour faire plus hype ;o)
@Nicolas Dans JSF 2.0 les gars ont vraiment mis l’accent sur les composants et leur compatibilité. A Devoxx ils ont même dit qu’en JSF 2.0 un composant IceFaces pourrait dialoguer avec un composant RichFaces (via des évènements) de manière transparente. Ils ont créé JSF 2.0 aevc l’idée d’unifier les librairies de composants. Et puis maintenant, la création de composants est vraiment plus simple.
Dans la série application stateless/stateful, c’est incroyable ce qu’une appli stateful est plus simple à développer (en terme de perf, il faut être plus vigilent)
Disclaimer : je suis un back-end guy et je déteste tous les frameworks web (même ceux que je ne connais pas ;o)
salut tout le monde
Avant de répondre plus avant – il faut que je prenne le temps – j’aimerais savoir un truc.
Au départ jsf ça voulait dire « pas de tag html ». Il fallait écrire ses pages uniquement avec des tags jsf.
Maintenant par exemple lors de la conf du parisjug , ou dans le merveilleux livre de Monsieur Goncalves , les tags jsf et html étaient mélangés.
Quelle est la « préconisation » actuelle? La bonne pratique?
C’est assez crucial amha
Nicolas, je rêve que tu puisses commenter l’article [1] de David Pollack, revenant sur ces choix pour Lift. En particulier, le passage :
[[
One thing that has become very clear after spending lots of time with Lift and watching other folks adopt Lift: share nothing is fail. The share nothing architectures are thin layers on top of relational databases. The amount of work that it takes to build secure, complex apps in share nothing is amazingly high. Share nothing apps must either be primarily stateless or they must put the state someplace. Both choices lead to seriously suboptimal results in the goal is to build secure or interactive applications.
]]
Ça se démarque par exemple de ce que les implémenteurs de Play! disent 🙂
Et pour info, certains pontes aux W3C (je ne donnerai pas de noms 🙂 pensent que le plus important est d’avoir des URLs bookmarquables mais pas forcément du tout stateless.
[1] http://blog.lostlake.org/index.php?/archives/94-Lift,-Goat-Rodeo-and-Such.html
Hello,
Je suis d’accord avec Anthony, là où je bosse en ce moment on a cette dette technique qu’on ne peut pas balancer du jour au lendemain (sinon ça ferait la une des journaux).
Pour en ajouter une couche, voici le genre de problématiques rencontrées:
* appli qui reste en prod pdt 5-10ans
* entre 20 et 10 000 users simultanés
* entre 60 et 400 tables voire plus (fois 1,5 si on parle d’entitées)
* des applis (pas des sites) avec plusieurs centaines d’écrans…
* gérer des conversations (persistence contexte étendu etc.)
* gérer des équipes de développeurs qui tournent
* se dire qu’il y a des dizaines d’appli à faire sur ce modèle
* imaginer qu’il faut documenter tout ça: et là plus on se rapproche des standards, moins y a de docs à écrire…
* imaginer que la maintenance se fera probablement ailleurs… peut-être en Inde…
* Ah tiens… aussi faut rendre l’appli « accessible »… multi-lingue
et la gestion des droits… le sso, etc…
* Aussi il faut bosser avec les copains Européens (aussi grand que mon client)
Bref, avec une problématique pareil, quel Directeur Technique prendrait le risque de partir sur du Play! du Grails ou même du GWT.
Je parie que Sébastien répondrait: bah Google, etc… mais oui ces boites sont des OVNI…
Là ou je rejoins Nicolas, c’est qu’il n’y a pas eu d’Hibernate ou de Spring du front, probablement parce que c’est juste plus compliqué à traiter.
Maintenant, je suis persuadé que les fmk web hype du moment contribuent tous à faire avancer le Schimilibili. Je les vois comme des percées de la nature… les idées les plus adaptées à l’environnement survivront et se feront absorber par le standard.
@Antonio: débrouille toi stp pour que Spring Web Flow devienne un standard dans JEE7 😉
En tout cas, le choix d’un framework Web Java relève du parcours du combattant. Même si cela montre une certaine vivacité de la communauté opensource Java, le choix est surabondant et cela finit par nuire car il devient difficile de trouver des développeurs qui connaissent tel ou tel framework. Depuis le déclin de Struts c’est la jungle…
J’ai eu l’occasion de participer au développement d’un site Internet grand public en JSF (1.2). Je n’ai vraiment pas été convaincu par la technologie: trop d’abstraction du protocole, trop de hacks à utiliser (comme le composant saveState de tomahawk pour sauvegarder un état entre l’initial et la postback request), des bibliothèques de composants qui produisent du code hideux et rarement cross-navigateurs, les problèmes de scalabilité avec l’arbre de composant stocké en session, la trop grande complexité pour écrire des composants, la configuration trop verbeuse, la courbe d’apprentissage trop élevée (comprendre le cycle de vie de la requête n’est pas si aisé),etc. Si Seam a su corriger pas mal de problèmes profitant de l’aspect pluggable de JSF et JSF2 de son côté sur la configuration et l’écriture de composants, j’aurai du mal à préconiser cette technologie pour des sites grand public à large audience, où il faut être plus proche du protocole (pour des questions d’optimisation), maitriser le code produit et être scalable. Pour intranet avec un support navigateur limité, une charge maitrisée, un framework comme Seam avec Richfaces permet d’être assez productif en mettant plein la vue.
Ce qui est amusant aussi c’est de voir que le monde .Net a choisi le chemin inverse du monde Java et est passé d’un framework orienté composant (ASP .Net webforms équivalent de JSF) à un framework orienté actions (.Net MVC équivalent de Struts/Struts2/Spring MVC…)
En ce moment, comme Bouiaw je trouve aussi que construire une application web en suivant les principes REST dans une démarche SOA va dans le bon sens. Cela laisse une grande liberté dans le choix de la technologie pour la vue (GWT, Flex, html+jquery, voir android/iphone, bref tout client qui supporte le Http et Xml/Json ) et décharge une grande partie le serveur de la gestion d’état (pour la vue). Ça permet aussi de vraiment décorréler le développment de la vue de celle des services.
Pour Play!, ce framework est très instructif et productif. J’aurais par contre du mal à le préconiser surtout pour sa pérennité (on peut avoir des doutes) même si la base de code est assez légère. J’ai un faible pour Spring MVC qui gère aussi le REST et les conversations (Spring Webflow).
@LDEW : le pb de la pérénité est un vrai problème.
Outre Play! je pense qu’on peut s’interoger sur la pérénité de bcp de framework Java. Qd on pense que Struts 1, considéré y’a 5 ans comme le truc qu’il fallait faire, est maintenant vu comme une antiquité…le problèeme c’est que bcp de d’appli durent bien plus de 5 ans et qu’on ne peut pas les refondre sans cesse…
Qui nous dit que Wicket sera la dans 2 ans (actif j’entends, pas déja considéré comme hasbeen, donc difficile pour trouver des gens motivés pour bosser dessus etc…)
Je pense qu’il y a aussi une séparation entre 2 catégories de lecteurs ici : ceux qui, de part leur métier (formateur, employés chez des éditeurs open source) ou par gout font bcp de choses « up to date » et ceux qui bossent chez ou pour de gros clients où, il faut le reconnaitre – et c’est compréhensible – il existe une trés grande inertie dans les évolutions technologiques
Pour rebondir sur les commentaires de @Nicolas Romanetti et @Smicky, voici en qques lignes une expérience qui m’a vraiment marquée:
– une très grosse société, vraiment très grosse. Plutôt très jeune et dynamique, pas un dinosaure, fait appel à une boite de consulting pour les guider dans le choix d’une techno de persistance de données
– à l’époque Hibernate est standard de fait, on doit être à la veille de Hibernate 3
– accrochez-vous bien et ça rejoint les propos de @Micky ET l’expérience de @Nicolas, la SSII en question va leur proposer un FWK « d’un autre siècle » complètement déjà obsolète et très limité pour ceux qui s’y connaissent un peu. Bizarrement, ce FWK est implémenté par la SSII en question
– j’imagine très bien les enjeux pour la SSII mais laissons cela de côté
– peu importe, étant en mission sur place, j’ai eu toute la tristesse de constater les dégâts qu’allait cause ce FWK à long terme comparé à Hibernate (ou plus tard OpenJPA on s’en fout je ne fais pas de propagande ici)
– les arguments avancés au client par la SSII en question? Hibernate est bien trop compliqué, notre FWK est SIMPLE et PRODUCTIF, on peut générer le code initial en 2 clics, ça va très vite. Hibernate est bien trop COMPLEXE, il faut des développeurs qualifiés, ça va vous couter cher
– anecdote sympa, un jour en discutant avec un des archi de la SSII en question, je me rends compte qu’il est en train de forker Hibernate en renommant les packages avec le nom de la SSII… no comment
Un ami est resté là bas en mission longue à un poste très important. 7 ans après qu’en est-il?
– tous les développeurs restés là-bas en mission longue ont stagné, sont en retard d’une décennie sur ce qui se fait, à la limite c’est leur problème, pas celui du client
– la moindre mise à jour substantielle d’une appli coûte chère, car le code généré initialement ne supporte pas parfaitement l’incremental engineering (comme souvent, peu importe la techno), il faut être très vigilent et croiser les doigts pour que ça marche
– les nouveaux prestataires tombent la dessus et doivent acquérir la compétence de ce FWK qui est certes simples mais les bride carrément
Cette expérience est réelle, et je suis persuadé que je ne suis pas le seul à l’avoir vécu.
@Antonio, je te rejoins sur le stateful
une autre expérience dans une autre vie, EJB2 marche pas, on nous impose, probablement à juste raison, tomcat, struts, très vite, de part les besoins, on se retrouve a devoir implémenter une couche pour gérer le stateful: oui on se retrouve a réinventer la roue, j’ai HONTE de le dire.
Bien entendu le stateful apporte son lot de fonctionnalités Métier aisément implémentables et une économie de code énorme au coût d’une vigilance accrue sur la conso mémoire, et les perfs en général… plus important, la maintenance des ces parties de l’appli est moins couteuse, le code est bien plus lisible,…
Qques années plus tard arrive EJB3, et je redécouvre les session bean stateful, et là c’est l’extase.
Je ne saisis pas trop ce type de … appelons le idéologie à l’encontre du stateful. Si les développeurs et concepteurs font leur boulot et connaissent la vigilance à adopter en l’employant (comme c’est le cas pour tout), alors on peut dire que pour certains use case, les session beans stateful sont SIMPLES et PRODUCTIFS, même qu’il n’y a pas plus SIMPLE et PRODUCTIF
Merci Nicolas pour cet article retour aux sources. Suite au passage de Guillaume au Lyonjug, j’ai bien pris la même claque que toi sur la simplicité de l’outil Play! et son efficacité.
D’un autre côté, on aime bien cacher la complexité de la réalité et de l’historique parfois (javascript en tête) pour ne pas se prendre la tête et gagner du temps. Je n’aime pas GWT mais il serait malhonnête de nier l’intelligence de l’approche. Wicket est surement un meilleur compromis en la matière.
Pour finir, il va falloir remettre à l’ordre du jour les graphistes web digne de ce nom (depuis le temps que je dis ca moi …). Je suis mauvais designer/ergonome/graphiste et je suis sur de ne pas être le seul! Js + css + html5 + TheGimp: pas simple comme addition. La, c’est flex qui simplifie le graphisme complexe: très vite l’application a une tête très respectable, même par un techos comme moi.
Donc Play! c’est bien mais heureusement pour nous les applications Web resteront compliquées, qu’on le veuille ou pas et je ne parle même pas des besoins des utilisateurs.
Un sujet qui fait coller l’encre, je suis sur que nos amis qui travaillent dans le PHP pourrait encore faire couler de l’encre.
En tous cas même disclaimer que Antonio, je n’aime pas trop le web, je suis plutôt du coté back-end.
Tiens c’est marrant j’ai lu le Post consacré au « Développement Web ».
Du coup machinalement j’ai tapé une recherche « CMS » et là le résultat était nul.
Juste pour vous dire que vu de ma fenêtre de nombreux clients ne s’intéressent pas au fait de savoir si leur site est finalement en .php ou .jsp. Encore moins de savoir si c’est du Wicket ou du SpringMVC.
Les drivers notamment pour les gros sites corporate c’est un CMS simple et évolutif avec si possible la capacité plus tard de publier des applis pour l’extranet. Du coup les choix c’est eZpublish vs Drupal en monde LAMP et Jahia vs Liferay chez les amoureux de la JVM (j’en oublie délibérément).
Du coup les webdesigners et intégrateurs sont plutôt intéressés pour se mettre à un outil car c’est quand même plus simple fonctionnellement que du Java 1.6 dans Eclipse.
En parallèle, les fanas du spécifique montent souvent des CMS proprios difficilement maintenables et peu évolutifs. Là ils peuvent se faire plaisir en wicket, en JSF, en stripes et plus récemment en Play ;->
Chez Amazon c’est sympa et utile, dans la DSI lambda aucun intérêt,
Just my 2 cents;
Geoffray
@Geoffray : il y a le projet Sematic (http://forge.sematic.fr/projects/sematic) qui est un CMS light développé par dessus Play! Framework. Voici 2 sites qui tournent avec cet outil : http://www.seine-et-marne.fr/ ou http://www.gendi.fr/
Sympa Sematic , je connaissais pas!
Les sites qui tournent avec sont réactifs en tout cas!
La capacité qu’ont certains à déprécier le stateful m’émeuvra toujours. Même si j’aurais tendance à dire « Anthony +1 », la « vérité » est sans doute de retourner la phrase « merci de penser que Java et les frameworks Webs c’est simple » en « merci de penser qu’on doit faire simple pour les frameworks Webs en Java ». (Note : un framework web ça n’est pas forcément simple, surtout si on veut minifier/rationaliser CSS et JS). Les frameworks pour applications web (on ne va pas dire « framework web ») sont ceux qui ont permis les refontes massives des clients lourds vers le navigateur internet. En ce sens, ils remplissent (presque) bien leur tâche. Par contre, considérer que, parce que ces frameworks permettent de faire quelque chose de correct dans le terminal « VT-internet », alors ils devraient, ou seraient censés, être des framework web, ça n’est sans doute pas le propos.
Et si ça ne s’est pas développé côté Java, c’est aussi peut-être dû à un problème de « la demande ». Tout ça pour dire qu’il y a de la place pour faire des frameworks web en Java, et que ça doit être encouragé (le boulot de Play! avec le compilateur de JDT est très intéressant par exemple), ET ça peut être fait sans dénigrer des solutions techniques qui, quoi qu’on en pense, répondent correctement à des besoins réels.
Une remarque en passant :
Lors d’un épisode des Castcodeurs, un des créateur de Play! nous affirme, qu’en dehors des fwk Java typé web, il FAUT connaitre JS, CSS, HTML 5 si on veut faire du bon dev Web.
Et j’avoue que je suis d’accord avec lui !
J’ai un peu de mal a comprendre pourquoi certains framework Java web s’obtinnent a essayer de « masquer » le dev Javascript voir CSS.
Que certains aspect pratiques existent (du genre coder une UI en Java pour pouvoir la débuguer), ok. Mais cette « religion » de dire « javascript c’est le mal, faut pas toucher » me semble un peu trop radicale.
Bien joué Sematic,
C’est un projet vraiment intelligent et utile qui peut combler le fossé entre du CMS lourd et du spécifique pas « user friendly »,
Du coup on va y jeter un œil en détail,
A+
Geoffray
Interessant tout ca…
Difficile de s’y retrouver entre les avis de chacun…
RESTful?
Session HTTP?
Stateful session beans?
Que choisir?