Je bosse depuis quelques années dans un SSII, et j'ai bossé sur divers projets, dans divers langages. J'ai aussi mes études derrière moi, et malgré tout cela, je ne suis toujours pas capable de justifier l'adoption de certains choix technologiques.
Pire, mes collègues n'en sont généralement pas capables non plus, quand ils n'assertent pas des monstruosités.
(exemples :
 - un projet php ne peut pas tenir la charge d'une appli destinée à 1000 users
ou encore
 - aucune BDD ne peut contenir notre flux quotidien de plusieurs giga)
 
Bref, je viens demander ici, j'espère que quelqu'un de particulièrement compétent saurait m'expliquer ...
 
La question, c'est pourquoi on utilise le java pour écrire des pages web ?
Le java, au naturel, c'est pas naturellement fait pour écrire des applications web. Preuve en est que l'on ajoute des dizaines d'outils en plus de java pour que l'ensemble devienne "industriel" : hibernate + struts + beans + jsp + ajax + maven ... pour ne citer que les principaux, parce que l'on va encore en avoir plein d'autres, au gré des envies...
(auxquels on ajoute les outils web : html, css et javascript, indispensables à la réalisation d'un machin web, quelle que soit la façon de faire.)
 
Alors, la première remarque à ce niveau, c'est que l'on déploie des dizaines de technologies pour un besoin simple. Donc que la moindre chose sera certes industrielle, mais lourde. Et donc une incompréhension éternelle de ceux qui demandent de faire et qui ne peuvent pas imaginer que ce soit si compliqué d'ajouter un petit bouton.
De plus, pour former un homme sachant faire ca ... Je ne sais même pas comment on fait. (mais les gens qui maitrisent tout ca, pour moi, ce sont des dieux ... Ils ne savent peut être pas calculer la trajectoire d'une fusée en calculant en binaire comme Von Neumann, mais je ne doute absolument pas que cela réussisse à être plus compliqué)
 
Enfin, on remarque que le modèle objet a totalement été vampirisé par les technologies qui requièrent un format définit (et donc abstrait relativement aux objectifs de l'application). (exemple : hibernate, c'est 2/3 classes pour chaque tables, struts c'est encore 4 classes de plus pour chaque page ...)
La plupart des classes d'une application web java se contentent de répliquer les entrées ou les sorties pour essayer de dialoguer avec elles. Alors, soit de désespoir, on les enrichie pour pouvoir aussi les utiliser pour le peu de code qu'on a à écrire, soit on s'en crée une ou deux supplémentaires, dont le cout est encore mécaniquement multiplié par N pour en créer autant d'interfaces logiques ...
On est très très très très loin du modèle "j'ai une voiture avec des roues, donc j'ai l'objet voiture et l'objet roue". (mais plutôt j'ai les objets "patron d'usine"/voiture/roue/vehicule et 3 objets "usine physique"/v/r/v ainsi que les modèles d'objet roue et voiture ... Et au final on construit 4 voitures avec chacune une roue différente - parce qu'on a pas le choix - mais on va dire que les voitures sont toutes les 4 au milieux des 4 roues, et ca marchera)
Donc, pour la praticité, la simplicité et la clarté d'un code objet, on repassera.
 
 
Mais une fois que l'on doit mettre en oeuvre toutes ses technologies, j'avoue que je ne comprend toujours pas.
J'ai eu l'occasion d'observer un code en cobol écrit il y a 30 ans, basé sur une technologie fichiers d'une époque où les bases de données n'existaient pas.
Et pour mettre un peu de piment dans l'histoire, chaque petit octet de place comptait.
Inutile d'en mettre des tartines pour vous convaincre que chaque petit module de la chaine de traitement passe entre 80% et 98% de son temps, de son code et de sa complexité à décoder, et recoder le format d'entrée sortie... Pour une plus value réelle allant de l'ajout d'une virgule pour le plus simple, au dé compactage d'un champs pour le plus complexe.
Ca à l'air très con aujourd'hui, quand on pense à la simplicité d'une requête en base, ou de la lecture d'un fichier xml ...
 
Et bien, aussi drôle que cela puisse-être, une application web en java fait exactement la même chose, avec des ratios de lecture/écriture débiles similaires :
le code javascript/html/css excepté (lequel peut être complexe), le reste de l'application web basique se contente d'aller piocher des infos en BDD, et de les écrire sur une page, et parfois d'aller reprendre ce qu'à saisi l'utilisateur pour le remettre dans la base.
Le problème, c'est que la grosse interface "java" entre le html et la base de donnée va largement couter deux fois le prix de la totalité de l'interface graphique + base de donnée.
Pour faire quoi ?
Au maximum, 15 requêtes différentes. 15 requêtes simples ! Car lorsqu'elles sont un peu trop compliquées, une vue est créée dans la base de donnée.
 
Et en pratique, cette grosse interface entre la base et l'affichage web, qu'offre-t-elle ?
- elle met les valeurs au bon endroit (parce qu'on peut aussi donner le html vide et un client BDD à l'utilisateur ... Qui s'en sortirait sans doute très bien comme ca .. Mais faut avouer que cela reste moche). Mais bon, c'est un simple remplacement clé-valeur ...  
- elle appelle quand même les requetes sur la base de donnée. (même si, avec 15 requêtes faisables par un 6ieme découvrant le sql dans la journée, on peut quasiment estimer cette complexité à nulle)
- elle garde en mémoire les valeurs choisies d'une page sur l'autre. (en gros, elle gère un panier d'info, sauf que comme c'est le bordel, on sait qu'en vrai le panier de critère est explosé dans 70 classes différentes, avec de la recopie à qui-mieux-mieux)
- elle gère l'internationalisation. C'est totalement inutile dans 95% des cas, mais faut reconnaitre que c'est pratique pour demander à un grammairien de corriger les fautes dans le fichier qui les contient toutes. (dommage que le fichier soit écrit en codes html, sinon, il aurait été lisible par notre ami)
- elle gère les logs en production. Sauf qu'en réalité, ce n'est pas réellement l'application qui est loggé, mais ses classes java internes. C'est sympa pour du débug lors du développement, mais au final, ce n'est pas l'exception du userFactoryRightsInterfaceExceptionGeneratorAccessModuleBean qui va expliquer que l'admin que Dupond avait déjà un homonyme dans la base, et que le cas n'était pas prévu. Des logs sympa donc, mais réservés aux développeurs. Ce n'est pas ca non plus qui apprendra que le filtre ne fonctionnait pas avec cette version d'IE, parce que la partie web n'est purement et simplement pas loguée.
- elle gère l'optimisation des accès base. (enfin, j'espère hibernate fait au moins ca). Donc, c'est pratique pour inviter un expert à venir optimiser en cas de besoin (quasiment jamais, donc, puisque vous vous basez sur 10 utilisateurs simultanés), mais c'est dommage puisque la partie accès base et utilisation étant justement découpés, il y a fort à parier qu'au moment d'utiliser les données, on n'ait plus du tout à l'esprit la façon dont on les appelle réellement. (cette fermeture d'esprit s'appelle "l'encapsulation", et c'est un facteur de qualité - reconnu)... Et puis de toute façon, comme on a généralement cédé sur la demande MOA de faire une liste de choix automatique à chaque caractère tapé ... Il n'y a plus grand chose d'optimisable derrière.
- c'est écrit en java. Et c'est certainement la première motivation, bien que cela n'en soit pas une.
 
Je crois avoir fait le tour de ce que je reconnais ce bousin faire.
Le problème, c'est que sur le projet total, il va y avoir 1 mois pour l'interface web (html/javascript/css), 2 jours pour savoir quoi demander à la base de donnée (+ n jours pour l'alimenter si cela fait partie du projet), et 2 mois pour écrire le truc en java au milieu.
Donc, ma question, c'est toujours :
- est-ce qu'il n'y a pas moyen de faire moins cher que 2mois pour bénéficier de la succession de bonus ci-dessus ?
(j'ai un peu envie de le faire en php par exemple ... Mais j'imagine que même en java, écrire une seule classe qui se contenterait de maintenir l'association des clés avec les bonnes valeurs, ayant ses 15 requêtes dans 15 méthodes à sa disposition ... Ou même en script bash tout con devrait pouvoir faire ca, avec sed pour remplacer les clés par les valeurs dans le code html !)
 
Et puisque le php est vraiment destiné à faire cela, pourquoi s'acharne-t-on absolument à écrire la plupart des ces applications en java ?
 
L'une des raisons les plus redondante est souvent le fait que le code java est plus maintenable, et surtout, plus solide pour évoluer...
Je comprends bien cela. Ces fichues applications sont toujours faites sur le même modèle rigide, qui ne contient plus aucune référence au métier ... Le métier peut évoluer tant qu'il veut, j'imagine bien que l'architecture ne s'y référent plus du tout, elle ne sera pas impactée.
Sauf que les applications web n'évoluent quasiment jamais ! Et quand bien même elles évolueraient, elle sont à la base d'une simplicité telle que n'importe quel débutant pourrait comprendre tout ce qu'elle fait en quelques minutes, à plus forte raison si le code réel (métier) n'est pas dispersé dans 90 classes différentes.
Et le meilleur argument serait peut-être que les vraies grosses applications, les logiciels d'éditeurs destinés au web, des applications développées et maintenues par une (des) équipe(s) complète(s) depuis des années, sont en majorité en php ... Si eux, ils peuvent maintenir leur application, faudrait vraiment être nul pour ne pas réussir à maintenir un simple passe-plateau entre une base et une page web !
 
Donc, voilà, je ne comprends toujours pas, et comme je sais que des tas de gens font cela depuis des années, j'espère que certain d'entre eux ont une réponse.
(surtout ceux qui ont déjà fait les grosses applications en php, ce qui n'est pas mon cas)
 
Par contre, pour reprendre un exemple réel, j'ai fait une petite application pour gérer des droits dans des listes avec des groupes, ce qui - avec les critères actuels d'ergonomie - aurait bien demandé 3 écrans, mais que j'ai réalisé avec 4 listes et 10 boutons sur une grosse page, m'a demandé 1 jour de dev en php avec mon niveau de débutant, alors que je pense que cela aurait a peine suffit à me permettre de réaliser la couche d'accès aux données avec le modèle standard en java.
 
Merci d'avance pour votre participation !

Sacré pavé les enfants !
Je ne suis pas expert dans cela donc pas assez de recul mais j'ai néanmoins quelques remarques.

Déjà je pense que tu confonds Java J2SE avec le Java J2EE quand tu dis que Java n'est pas fait pour le web. Le J2EE est fait pour le web justement !

Après c'est évident que pour une petite appli comme ta gestion de droits c'est inutile de faire ça en J2EE car ça va devenir une usine à gaz pour pas grand chose. Mais pour les vraiment grosses applis tu as un gain dans l'automatisation de plein de choses.
L'avantage aussi c'est que tu as un vrai modèle MVC. Tu peux quasiment avoir une équipe dédié à chaque partie alors qu'à mon avis (je suis pas un pro en php) tu dois te marcher sur les pieds avec du PHP. Et ça c'est un gros point fort.

Tu mélanges un peu tout là. JSP n'est pas un outil mais le langage qui va te permettre de réaliser les pages web. Ajax n'est pas lié au J2EE.
Après pour les Struts, Hibernate c'est juste pour faciliter certaines choses. Mais ce n'est pas parce que c'est "en plus" que cela veut dire que J2EE ne se suffit pas à lui même pour faire du web.

Ca s'apprend comme n'importe quel autre langage. C'est juste une question d'habitude. Mais je comprends que ça donne l'impression d'être inaccessible quand on y connait rien en J2EE.

Enfin ça permet aussi comme tu l'as dit de faire évoluer l'appli. Alors certes on est pas sur que l'appli évoluera par la suite mais on le fait quand même au cas où. C'est un investissement.

Wola putai*g le pavé!  
 
Ca va être difficile de démarrer une discussion structurée/constructive en partant dans autant de directions! Je vais tenter une réponse légère en ouverture.
 
1. Non, Java/JEE n'est pas la panacée ni la réponse unique au développement d'une application web. Oui, dans bien des cas, tu peux remplacer Java/JEE par PHP, C#/ASP .net, Django, ...
2. En tant que "duct-tape programmer" (développeur pragmatique), je ne suis pas fan de l'empilement de technologie et de l'ecosystème qui fait la richesse de Java. Les mavens et co m'apparaissent principalement comme des emplâtres sur une jambe de bois et j'ai souffert la rudesse hivernale d'Hibernate quand on arrive dans des cas tordus (et ça arrive).
3. En tant que freelance ou entrepreneur, le choix de PHP vs Java est souvent marginal sur l'ensemble du projet en ce qui me concerne (analyse fonctionnelle, front-end, trouver un collaborateur, contraintes opérationnelles, contact client, ...).
 
Qu'est-ce qui peut justifier Java? À peu près tous les arguments qui me viennent peuvent s'appliquer à PHP ou à d'autres technos pour autant qu'on les mette en œuvre correctement, je dois l'avouer.
 
Mais dans un environnement "enterprise", quand il s'agit de s'interconnecter avec je ne sais quel système, les ponts Java sont nombreux. Ce ne sont pas les librairies et les API financières / legacy / big system derrière qui manquent. Face à un SAP ou un autre brontosaure, je suis certain de mieux m'en tirer avec la hache Java en main. Idem pour des besoins plus spécifiques (cryptographie, ...). Le mutli-threading est assez costaud aussi. Ce n'est pas un monopole mais on en reparle si on va vers du PHP ou du Python.
 
Tu me diras que c'est un peu maigre, je te le concède.
 
Correctement utilisé, Java me semble plus solide que PHP par exemple. J'adore profiter du weak-typing, du duck-typing et autres joyeusetés pas offertes en Java mais au final, j'ai le sentiment que mon code PHP demande plus de tests de régressions et cassera plus facilement que mon code Java.
 
Je n'ai jamais trouvé d'équivalent à IntelliJ en dehors de Java non plus. Ca aide énormément un outil aussi puissant et bien calibré.
 
Ceci dit, pour pas mal d'applis "green field", un Grails ou un Django roolzera sa mère et laisseront PHP et le stack Java/JEE à la traîne.
 
Vala mes 2 centimes en ouverture.

Perso, je suis pas un fan de Java. Cela dit, il a des framework qui, effectivement, permettent de gérer des couches d'abstraction (par ex, pour être indépendant de la source des données : BD, xml, fichier txt...) et d'automatiser certains tâches (ex : les tâches CRUD). Java a un autre avantage quand il s'agit d'ouvrir au web une appli métier elle-même codée en Java. Si celle-ci a été bien faite, y'aura des EJB contenant la logique métier qui vont pouvoir être réutilisés pour l'appli web.
 
Maintenant, c'est comme tout, chaque techno a son champ d'action de prédilection et on utilise pas un rouleau compresseur pour écraser une mouche. Dans le cas de ta petite appli de gestion de listes, pas la peine de sortir Java/struts et tout le bouzin pour coder ça.
Mais on peut faire une site web en langage C (cf les CGI). Pourtant, aujourd'hui, ça viendrait à l'idée de très peu de monde de le faire. Donc certains langages sont plus adaptés pour faire du web et là encore, ça dépend de la taille de l'appli et de sa durée de vie prévue.
 
Par ailleurs, PHP s'est effectivement largement amélioré avec des frameworks genre symfony ou Zend permettant de faire du MVC. Et il supporte très bien du gros trafic (preuve en est, ce forum). Tu peux regarder aussi le code source du produit GPL Magento (soft de e-commerce) : c'est plutôt bien organisé et c'est très puissant comme produit. On trouve uassi pour PHP des produits GPL qui permettent la production automatique de code, typiquement pour gérer les tâches CRUD avec une BD.
 
Et pour l'aspect maintenabilité, peu importe le langage, si le ou les développeurs sont des cradaux, ben tu pourras rien maintenir. Au contraire, s'ils sont rigoureux, tu auras, même en PHP, un code maintenable

IntelliJ supporte PHP

Merci beaucoup pour vos réponses !!!
J'ai deux-trois mots clefs à creuser en profondeur parmi ce que vous avez pu me dire.
 
Par contre, il ne faut pas ignorer un point (bien qu'à force de creuser les motivations du java, on finisse par pouvoir le perdre de vue ...) :
Un bon nombre d'application web java sont totalement bateau ! Elles n'ont pas une complexité très supérieure à mon exemple débile en php :
- souvent, on commence par un écran de login
- ensuite, on a un écran pour choisir la fonction (sachant que toutes les fonctions sont quasi-identiques, et ne modifieront que le rendu final)
- ensuite, on a un premier écran de sélection de critère (genre : la ville)
- ensuite, on a un second écran de sélection de critère, dépendant ou non du premier (genre l'adresse)
- ensuite on a encore un écran de critère (genre, la date)
- enfin, on a la liste des résultats correspondant à la grosse requête en base
- et au final on clique sur l'un des résultats pour l'afficher ou l'éditer
 
(autre exemple : première page : la liste des forums, deuxième, la liste des sujets, et hop, résultat, avec un satellite pour choisir son smiley. - par contre, les trucs complexes comme l'inscription, la recherche ou l'administration, ne font pas partie de ce genre de projets)
 
Grosso modo, c'est souvent un truc aussi débile que ca : la création en client web d'une précédente interface lourde.
Ce n'est pas connecté à une autre application (c'est connecté à une simple BDD)
 
Ca va quasiment pas évoluer (au pire, on va ajouter une case à cocher, on va ajouter un champs, au pire une sous page ...), et le fonctionnement global est quasiment trivial à tester (au pire, un bouton local plante)... Il ne peut pas y avoir de réelle régression, parce que le peu de trame qui supporte l'ensemble est pratiquement définitive, on a très peu de chance d'avoir un effet de bord quelconque.
(si on en a, ce serait surtout sur la partie graphique) ...
 
Du coup, même si je peux imaginer que lorsque l'on a fait une application en php, on peut parfois s'autoriser des facilités suspectes, là où en 90 classes de java on construit une forteresse (parce que casser 90 classes d'un coup relève de l'exploit), en pratique, cette robustesse va être très peu utilisée ...
 
Par contre, je commence à comprendre ce choix à travers l'aspect systémique du projet ...
Le fait est que l'entreprise (en particulier ma S2II) a besoin d'être parée pour les projets géants aux fonctionnalités métiers complexes. Et dans ce cadre, a besoin de ressources java (parce qu'à partir d'une certaine complexité, j'admets qu'un coeur purement programmation soit quand même plus efficace). Et dans ce cadre, elle possède des équipes purement java qu'elle occupe avec des petits développement (en java) bien que ces derniers ne justifient pas la techno.
 
D'un autre coté, à quel point est-il possible techniquement de dépouiller le java ?
Est-ce qu'il serait possible de recoder l'exemple du forum sus-cité avec 4 jsp et 3 classes ? (classes session, forum et message)
Sans struts, sans hibernate (requêtes en base directement), etc. ?
 
Est-ce possible de faire une seule jsp et 0 classes pour faire l'exemple de ma mini-application faite en php ?
 
Si c'est le cas, alors il suffirait simplement de coder autrement, et briser les schémas systématiques dans les cas où ils ne s'imposent pas ...

Non mais là c'est comme si je te disais de faire un site php en utilisant que de l'html...

Ben, justement, on peut écrire du php dans le code html de la même façon que l'on peut écrire du java dans la jsp ....
Par contre, je ne sais pas du tout si il faut des classes pour que le serveur d'application exécute les jsp, ou est-ce qu'il peut le faire directement.
Et je ne sais pas non plus s'il est possible d'avoir une classe commune pour toute la session (pour que les jsp puissent partager des infos autrement qu'à coup de post) ... sans passer par struts ?

Struts déjà c'est facultatif pour le J2EE.
 
A mon avis il faut au moins une servlet mais ça fait quelques temps que je n'y ai pas touché donc pas sur.

J'ai fait un site en java, sans utiliser tout l'écosystème habituel (principalement parceque je le connais pas et qu'il est terrifiant). La base étant le petit serveur http que fournit sun "en cachette" (il fait pas partie de la lib java standard, mais est livré avec la jre sun et est open source, donc même si un jour ils le livrent plus, on peut quand même l'avoir en package séparé). J'ai tenté de faire un truc plutôt sympa à utiliser, sans répétition et configuration de partout, tartiné de réflexion et d'annotations, etc...

@DoPost @Path("/login" )
    public void login(
            final Redirection redirection,
            final Session session,
            final @FromPost("mail" ) String mail,
            final @FromPost("password" ) String password) {
        // XXX ugly lowercase here
        final Integer account = accountLibrary.fetchByMailPassword(mail.toLowerCase(Locale.ENGLISH), password);
        if (account != null) {
            session.start(60*60*24*30);
            sessionAuthenticator.associate(account, session.getIdentifier());
            redirection.to("/" );
        } else {
            final Arguments arguments = new Arguments();
            arguments.put("loginFailMessage", "Invalid mail or password" );
            arguments.put("mail", mail);
            redirection.to("/login?"+arguments.toURLEncoded());
        }
    }

C'est parfaitement faisable, pas désagréable à utiliser, j'ai pas fait de trucs tout crado ala php et c'est plutôt robuste. Malgrès ça, et même en empruntant leur style, ça reste plus pataud qu'un Django ou autre framework python quand on veut ajouter ou modifier rapidement quelque chose... Si on tient vraiment à avoir du statiquement typé ou qu'on a très très peur des languages "lents" c'est ptêtre viable...

peuwi: tu prends systématiquement le cas d'applications CRUD / admin green fields, qui sont peut-être celles que tu rencontres le plus souvent mais il ne faut pas généraliser : je n'ai pas eu cette chance récemment.
 
Et là on est tous d'accord : il existe des solutions plus agiles que Java pour le pur CRUD, mais Java n'est pas forcément lourdingue.    
 
Si tu as tu sais utiliser Maven, Hibernate, Stripes et les dernières annotions à la mode, ton application CRUD pourrait bien être torchée en deux coups de cuiller à pot avec Java. Tu me répondras qu'il faut déjà les maîtriser et la courbe d'apprentissage n'est pas forcément des plus plates non plus, j'en conviens, et dans ce cas, le défaut de maîtrise de l'outil plaide en faveur d'un autre choix. Ce qui ne veut pas dire que l'outil est mauvais en soi.

Ca c'est plus de la mauvaise habitude qu'une nécessité. Si tu penses YAGNI, ça n'arrivera pas.  
 

On aurait honte de torcher une JSP avec tout dedans, façon PHP cracra, par peur de s'attirer l'opprobre de collègues. Mais c'est techniquement faisable. Ceci dit, quand on connaît son framework, il est bien plus facile de mettre en oeuvre un Stripes ou un Tapestry que de gérer le tout à la main, donc est-il vraiment souhaitable de s'en passer?
 
 

Vraiment pas faux!

Tout de manière, le choix d'une technos tient à 99% d'une décision politique par des gens qui n'ont jamais tapé la moindre ligne de code.
 
Perso je sors d'une formation de chef de projet, mais contrairement à mes camarades je ne méprise pas le développement. Je jalousais ceux des autre filières, orienté codage J2EE et tout et tout.
Je suis tombé dans une boite où régnait le php. La boite se montait, il fallait des trucs faciles à coder et pas trop compliqué pour des informaticien pas très au fait des nouvelles technos objets. Je connaissait bien j2se, le php était une formalité. J'ai été étonné de toutes les saloperies qu'on pouvait faire en php, j'ai adopté la philosophie de coder en php comme je l'aurai codé en java se.
 
Je rongeais mon frein, en attendant de pouvoir faire comme les grands, passer à j2EE et tout ces hibernate, struts B)
 
Evidemment le temps est passé et je suis toujours au php. J'ai déjà tenté de me faire des serveurs sun, tester les tutoriaux. Bien sur j'ai du mal, beaucoup de notion à appréhender et comprendre mais je ne vois pas vraiment en quoi ça pourrait améliorer les performances et nos ressources. Au contraire, pour faire la même chose que notre vieux serveur principal j'ai l'impression qu'il en faudrait 4 en java ...
 
Alors voilà, dans les entretiens pour recruter, je m'en prends plein les dents. Des jeunes qui nous apprennent que le php n'est pas objet, ne fait pas de MVC, on des CV plein de struts et maven. Quand tu les vois bosser, ils codent avec les pieds et ne connaissent aucun design pattern ... même pas leur fameux MVC
 
Après ça tient surement à ça. Le j2ee a surement d'énormes qualités, mais souvent ce sont des jeunes développeurs qui l'utilise. Ils n'ont pas été habitués à imaginer des algo simples et efficaces. Le moindre script php simple devient horriblement compliqués, avec des tests absurdes et des multiples boucles imbriquées. Si maintenant ils font la même chose, bien camouflé derrière un bon framework j2EE bien compliqué, on peut prévoir le désastre.  
 
J'ai vu en billet sur un blog y'a pas longtemps, qui parlait du cycle de vie des développeurs. Ils commencent en basic, puis lorsqu'ils prennent confiance passent au technos à la mode, de haute voltige et bien compliqué, cool. Lorsqu'ils se sont bien cassé les temps il repassent au technos fiable et simples, genre le python. Ca me rappelle qu'il faudrait que je m'y mette

Il ne faut pas jalouser Java/JEE, en aucun cas! Je suis à fond du côté hype, gagnant ma croute principalement sur JEE et je ne crache pas dessus, mais je n'aurais aucun scrupule à lancer une appli en PHP voire en Python.

Tu n'as pas faux... Je viens de déployer une appli de taille modeste/medium sur un Tomcat et ça bouffe une partie incroyable des resources, au point de devenir en partie préoccupant. Et je n'ai rien fait de bien lourd. Seulement voilà, je suis habitué à déployer mes applis sur de gros serveurs applicatifs largement dimensionnés administrés par une équipe distincte, où l'éventuel gaspi ou surconso ne sont pas directement visibles. Ici, je paye mon serveur dédié et je grince des dents à l'idée de devoir faire un upgrade hardware précoce.  

Les a priori des développeurs JEE contre des technos "basiques" genre PHP sont énormes, même chez les seniors, tu n'as pas idée! Tout au plus un truc comme Python suscite parfois un regard curieux dans mon entourage. C'est un reflex assez naturel qui doit se retrouver dans tous les camps. Seule une minorité ne dénigre pas systématiquement les autres outils. Si tu as un candidat comme ça en face de toi, ça mérite de s'y attarder.

Marrant, je me retrouve en partie dans cette analyse, au stade terminal. Une nuance : j'en vois énormément qui restent au stade "hype", avec du Java enterprise et qui suivent les nouvelles modes tous les 6 mois. Comme s'il y avait un reflex de protection de l'investissement passé à maîtriser la techno.

 
Ben, oui, mais ca veut dire quoi "tout cracra" ?
Pour moi, "tout cracra", c'est quand pour faire quelque chose de simple, trivial, basique, (débile !), on a utilisé un gros machin à coté, qui ajoute ses propres contraintes et ses propres besoins ... En plus de la relative complexité de devoir aborder une nouveauté supplémentaire...
 
Exemple simple : Maven, c'est génial ... Oui-da, certes, mais si je copie mon projet quelque part pour mémoire, comment pourrais-je l'ouvrir dans 3 ans ? Comment puis-je travailler hors ligne ou tout simplement hors site ? L'idée initiale est louable. Les aboutissants sont abominables. Le résultat est au final bien plus "cracra" que le simple avis subjectif initial ...
Debuger une simple page où tout est écrit, on l'algorithme est en clair avec les accès, où tout est rassemblé, dans un unique langage, sur une même page résumant au mieux (car rien ne résume mieux qu'une écriture informatique), c'est finalement bien plus clair malgré l'apparente lourdeur que renvoie l'ensemble.
Alors, certes, il ne faut être trop excessif (de la même façon qu'on va ordonner un peu un texte en sections et chapitres). Mais le découpage actuel ressemble davantage à un roman ou chaque phrase serait découpée dans le plan global au titre de sous-sous-sous section avec des titres relatif au placement dans l'organisation plutôt qu'à l'histoire.
Donc, si, pour une application composée d'une seule page, il n'y a aucune raison de découper en module. Et c'est justement "l'opprobe" des collègues qu'il faudrait soigner :s
 
Par ailleurs, ce besoin d'évolution, d'utiliser toujours la technologie de niveau supérieure est une course sans fin !
J'imagine effectivement que l'on peut créer "en 3 coups de cuillère à pot" une belle architecture (au mépris total de celui qui devra reprendre et qui n'a pas la joie d'être tout aussi expert), mais celui qui pense comme cela voudra toujours tester une autre chose, une autre complexité, qui va de toute façon finir par le mettre en difficulté.
Et au final, on se retrouve à devoir passer 2 fois plus de temps sur le problème que sa simple complexité ne le nécessitait.
(et pour le repreneur, remonter la pente est bien souvent bien plus abominable que si tout avait été codé en dur)
 
Mais bon, je prends bonne note de vos arguments.
Par contre, force est de constater que malheureusement, beaucoup de personnes "techniques" ne visualisent pas la complexité de leur outil (par rapport à la démarche "cracra" ), et se retrouvent dans l'impossibilité de remonter l'info aux décideurs concernant ces choix absurdes.
 
 
Maintenant, la question, c'est : dans quel cas passer d'une méthode "primaire" à un "java+struts+compagnie" devient rentable dans le cas d'une application web ?
Ou inversement : quand est-ce que la méthode "primaire" devient couteuse ? (encore plus couteuse que la lourdeur de J2EE&Co)

Mon point de vue est qu'à moins qu'il ne soit nécessaire de devoir réutiliser un composant "logique métier" (écrit en java ou langage différent du php ou asp) ou s'interconnecter avec un progiciel ou système propriétaire, je pense que du php+framework+composants/libs en GPL ayant faits leur preuves sera toujours rentable en temps (cycle de vie complet de l'appli web produite) pour produire une appli web que du Java et tout son monde

Avoir une page (php ou jsp) qui mêle allégrement HTML, accès à la couche de persistence, métier et traitement de la requête est à mon sens déjà cracra, sans pour autant que cela soit ipso facto à proscrire.
 
Pour une page, c'est pas bien grave, mais il faut être sûr de savoir où on s'arrête. Allez, il faut un deuxième écran, on va continuer comme ça. Oh, un troisième? Hmmm, oui, j'aurais dû faire un peu modulaire mais bon, tout ce que je dois faire, c'est ajouter un troisième écran. La maintenance peut déjà devenir ridiculement compliquée sur une application modeste.
 
On tombe facilement dans une complexification pernicieuse d'une appli. Il est toujours temps de refactorer en théorie, mais dans la pratique, c'est "ajouter un écran" versus "refactoring des 5 écrans existants d'abord parce que ça devient ingérable", et là guess what, il est trop tard, on n'a pas le temps / le budget / la volonté (ajoutez n'importe quelle excuse qui ne tient pas la route mais conforme aux pratiques enterprise). Et même s'il a lieu, le refactoring a un coût.
 
Je ne plaide pas a contrario pour un stack complet JEE d'emblée!  
 
Mais il faut noter qu'utiliser dès la première page un JSF ou un Stripes n'est pas forcément pénalisant. La préparation est modérée. Même sans Maven, un éditeur comme IntelliJ va télécharger les JARs nécessaires pour du Struts ou du SpringMVC (en utilisant Maven en cachette, mais ça on s'en fiche) et il n'y a rien grand chose à faire pour commencer. On peut même réutiliser le canevas d'un précédent projet. Le bénéfice apparaît rapidement quand on ne se contorsionne plus à faire des request.getParameter avec vérification de nullité, et qu'on peut ajouter facilement des validations.
 
Peut-être est-ce rentable dès la première page.  
 

Je ne saisis pas tout mais j'ai pas l'impression que la question soit là. Evidemment il faut mieux commencer un projet php avec des framework, des couches d'abstractions etc ... Après il est tout autant capable qu'un autre de faire du MVC ou des front controller, du factory etc...
 
Il est communément admis qu'il y a une talle critique à partir de laquelle on est obligé de faire du J2EE et pas du php .... mais finalement qu'elles sont réellement ces limite ? Dans le cas d'énorme site web réparties ou autre ... et encore !  
 
En tout cas ça ne touche pas 90% des projet J2EE.

Souvent entendu ça mais c'est plus une légende urbaine qu'une réalité démontrée.
 
Quand je lis ce genre d'article, j'ai une impression d'approche biaisée par défaut de maîtrise de PHP, quand on n'a pas une pétition de principe :
 

 
Ouais... PHP = Personal Home Page, c'était il y a bien longtemps, hein. Et les auteurs de poursuivre en avançant des limitations qui se contournent en réalité facilement ou qui datent d'avant PHP 4.
 

Heu les gars, comment vous travaillez?!  
 
Ailleurs sur stackoverflow, des remarques plus pertinentes :

Ce dernier point est une triste réalité : la facilité de mise en oeuvre de PHP ne permet pas de filtrer les bozos et les bras cassés de manière efficace. Ca rejoint, à l'autre extrême, l'article The Perils of Java Schools de Spolsky (Java étant entendu ici par opposition à C/C++) :
 

Ma boite vend une grosse appli web, toute la partie serveur est faite exclusivement en Java. Ben ca utilise JSON et c'est tout. Pas de Hibernate, de Struts ou de je sais pas quoi, et c'est quand meme tout nickel et bien organisé.
 
 Je fais partie du camp de ceux qui aiment pas trop les frameworks: Hibernate j'm'en suis servi pendant deux ans sur un projet, ya des bon points mais aussi des mauvais (qu'ils ont surement amélioré depuis j'espère!), grosso modo ca marchait du tonnerre sur le proto mais dès qu'il a fallu multithreader sur la vraie appli les merdes ont commencé. Il y avait aussi des limitations dans l'optimisation de la récupération des données.
 
Struts, j'ai juste été en contact avec pour des projets clients, je trouve ca tout simplement immonde. Lourd, pas intuitif pour un sou, tu te retrouves avec des trucs dans tous les sens et c'est casse couilles pour faire les liens (bon les clients avaient ptetre foiré leurs projets aussi, ca reste une possibilité).
 
Spring, j'ai fait un gros TP de plusieur mois quand j'étais étudiant, j'me souviens juste de ma conclusion de l'époque: ca sert à rien. Plus tard au boulot c'était un des choix d'architecture, après examen par moi et un autre gusse de l'équipe, on était tous les deux arrivés à la meme conclusion: ca sert à rien, on choisit pas ca. Impossible de vous donner les raisons, j'ai oublié vu que pour moi ca sert à rien. Ca j'm'en souviens bien par contre.
 
'Fin bref pour moi les frameworks ca ne fait rien qui ne soit pas déjà faisable. Alors c'est sur j'en ai pas une grosse matrise, de ce que j'en ai vu certains sont pratiques mais amènent d'autres problèmes, d'autres sont lourds et mal branlés, d'autres servent à rien (devinez lequel), le seul point commun c'est que tous sont préconisés par les branle-couilles qui font de la veille technologique et des prototypes pourris et comprennent pas que sur un prototype pourri qui attaque une petite BD locale sur le meme PC ils auront JAMAIS aucun problème à faire marcher leurs trucs, du coup tout est génial et marche bien meme si ils savent pas pourquoi et sont infoutus de t'aider une fois qu'ils t'ont poussé à utiliser leurs technos de merde dans un vrai environnement et que ca alors, ca marche pas et/ou c'est tout lent.

Je viens de lire tout le topic, et je rejoins grandement l'avis du créateur du topic, ainsi que celui du dernier intervenant ci dessus (lasnoufle, la seule et la vraie lol).

Bon beh, puisque que le topok est déterré, autant en profiter pour répondre à lasnoufle.    
 

C'est comme pour tout : il faut savoir utiliser le bon outil au bon endroit. J'opte parfois pour du JDBC pur face à un PDM atrocement pourri sur lequel je ne peux rien changer et sur lequel je sens que je vais me casser les dents avec un ORM. Ca ne rend pas Hibernate mauvais dans l'absolu pour autant.
 

et tant mieux pour toi. Struts, c'est un peu l'anti-framework du web, un contre-exemple ou un exemple de ce qu'il ne faut *pas* faire. Mais bon, à l'époque, on vivait avec.

 

Ca c'est évident. C'est juste une question de savoir si tu parviens, dans un contexte donné, à être plus productif et plus robuste avec le(s) framework(s) en question.
   
 

(LOL)
Y'a du vrai là-dedans. C'est un travers assez agaçant, comme la sous-estimation systématique de la courbe d'apprentissage, voire parfois de courbes d'apprentissage qui se superposent. Faut laisser de côté ces gens bleeding edge, se contenter d'être à jour pour ne pas passer pour un ringard sans pour autant passer son temps à bidouiller avec la moindre nouveauté et le dernier gadget.
 
Il faut peut-être laisser de côté cette apparente dualité "Java lourd 40 classes pour 4 écrans" versus par exemple "PHP cracra script 100 lignes c'est torché" qui ne sont que des travers des développeurs qui utilisent les technos, pour toute une série de raisons.
 
Avec l'expérience, je ne vois aucune difficulté à écrire une petite appli en Java sans partir dans du rocket science. Je ne vois pas de difficulté à écrire du PHP propre et modulaire.
 
Bien sûr, pour une appli de deux petits écrans, Java/JEE va sembler un peu overkill, sans compter qu'il faut savoir le déployer et que les mutualisés abordables in ze cloud en Java ne sont pas encore monnaie courante.

C'est quand même fou le nombre de topics qui virent en troll en suivant le même patern :
- Question assez rhétorique sur un langage (Pourquoi utiliser X plutôt qu'Y pour une appli Z)
- Quelques (contre)arguments plus ou moins bien ficelés
- On sort les gros clichés (PHP c'est toujours mal, Java c'est lourd, Python/Ruby/autre-langage-a-la-mode ça sauve la mise mais c'est trop jeune)
- Du coup on compare ce qui n'est pas comparable (Appli mal écrites en PHP contre applis qui utilisent 4503 frameworks en Java)
- Y en a 1 qui arrive à une conclusion rien à voir (Le MVC c'est toujours le mal, les framework ça sert à rien, faudrait retourner aux CGI C parce que c'est la meilleure manière d'avoir la main sur les ressources, l'ASM c'est bien pour le web,...)
- On essaie de tirer des conclusions ... et on se retrouve plus ou moins au même point qu'au départ..
 
Une fois ou l'autre je sens que je vais répondre à un auteur en prenant direcgtement la conclusion du troll d'avant

Merci de nous faire bénéficier de ton puissant esprit de synthèse et de corriger les masses incultes
 

- Ca ne sert à rien de comparer ce qui n'est pas comparable
- Ca ne sert à rien de ré-inventer la roue (surtout si carrée). => Utiliser des bons FrameWorks à part cas spécifiques
- Et pis bon sang, ça sert à rien d'optimiser sans avoir réflechi, puis testé .. Le fait de dire "j'utilise pas XYZ parce que j'ai lu dans une boule de cristal que ça va être plus lent que si je me tapais un nouveau serveur en ASM moi même" ... Faut quand même arrêter.
 
Bref, rien de nouveau sous le soleil, c'est les mêmes conclusions à chaque fois ... pour ça que je préconise qu'on puisse directement copier/coller les conclusion du troll précédent

Tu viens d'identifier le Troll Design (Anti)Pattern    
A+,