Quand Java est-il un bon choix pour le développement Web? [fermé]


35

Quand Java est-il un bon choix pour le développement Web?

Veuillez ne pas dire "Quand vous avez une équipe de développement qui ne connait que Java."


5
Peut-on demander quelle fonctionnalité fait de Java mon langage de développement Web?
Abimaran Kugathasan

1
Un léger inconvénient de l’utilisation de Java est l’absence d’un cadre réellement dominant sur le marché. Aucun framework basé sur Java n'a encore atteint le sommet de la pile (à l'instar de Struts à l'époque). Personnellement, je me tourne vers Spring MVC si je travaille avec une application Spring ou Grails pour autre chose (comme vous pouvez appeler Java à tout moment).
Martijn Verburg le

Soudain eu 25 points de cette question!
Gulshan

prenons-nous en compte les logiciels opensource existants?
jonathan

2
"comme Struts l'avait dans la journée": Qu'est-ce qui ne va pas avec l'utilisation de jambes de force aujourd'hui (à part que ce n'est plus à la mode)?
Giorgio

Réponses:


35

Étant donné les nombreux cadres disponibles, la maturité de la plate-forme, etc., je suis tenté de dire "presque toujours". Voici donc quelques raisons pour lesquelles vous ne devriez pas utiliser Java:

  • en tant que pure boutique MS, vous préférez probablement le faire de la manière .net
  • si vous avez besoin de l'hébergeur Web le moins cher, vous n'avez probablement que PHP pour choix
  • si vous voulez le faire le plus rapidement possible, Ruby on Rails, Grails ou Django sont probablement mieux adaptés à vos besoins.
  • si votre équipe de développement ne connaît que XYZ, où XYZ! = Java, vous feriez mieux d'utiliser XYZ.

7
Nous utilisons donc Java si nous ne sommes pas un magasin MS, si nous avons l’intention de dépenser de l’argent pour l’hébergement, si nous avons suffisamment de temps pour développer à l’aide de Java et si nous avons des développeurs Java. Est-ce que c'est bon?
Gulshan

Gulshan: oui, vous pouvez le dire ainsi
user281377 le

3
Il y a de nombreuses autres raisons telles que: c'est gonflé, d'entreprise et c'est Java (la dernière peut être ignorée si vous utilisez Scala ou autre chose pour la JVM).
Raynos le

1
@Raynos donc vous recommandez quoi à la place?

2
@ ThorbjørnRavnAndersen dépend vraiment des exigences. Si les exigences sont génériques (non niches), utilisez la plate-forme la plus pratique pour vos développeurs et vos serveurs.
Raynos

19

Java est utilisé dans les sites Web de petite et moyenne taille. Le point crucial est qu’il existe beaucoup moins d’hébergement gratuit pour les sites Web Java que pour PHP, ce qui signifie que si vous ne disposez pas de suffisamment de ressources pour héberger votre propre serveur Web, vous ne choisirez probablement pas Java.

Notez qu'avec Java EE 6, en particulier le profil Web, de nombreuses technologies standard incluses permettent de créer des applications Web très puissantes sans devoir beaucoup coder. Ce n'est malheureusement pas encore assez courant.

Notez que cela a quelque peu changé récemment avec Google Application Engine, qui vous permet de déployer gratuitement des applications Web Java standard (avec quelques restrictions) dans le cloud pour les sites à trafic faible à moyen.


Dans tous les cas, je n'hébergerai pas mon site Web dans un hébergement gratuit. Mais la question existe-t-il un problème avec l'hébergement web payant java? Est-ce très cher par exemple?
Goma

1
@ Saeed, pas en tant que tel. La plupart des gens optent pour l'option la moins chère et codent en conséquence.

Jave est-il beaucoup plus cher que d'autres par exemple? Existe-t-il un hébergement partagé pour Java?
Goma

@ Saeed, il existe certaines raisons techniques pour lesquelles vous ne pouvez pas regrouper autant de machines virtuelles sur une seule machine Windows que de créer des instances LAMP partagées, ce qui signifie implicitement qu'une machine virtuelle hébergée est plus chère qu'une lampe hébergée. Google utilise une machine virtuelle Java différente, ce qui signifie qu'ils peuvent l'offrir gratuitement.

@ Thorbjörn: Avez-vous des liens sur la manière dont Google le fait? J'ai entendu dire qu'ils utilisaient Jetty, mais je n'en sais pas plus sur leur solution.
Jonas

12

Lorsque votre plate-forme est UNIX / Linux et que vous avez besoin d’un ensemble complet d’outils, tels que mappage objet / relationnel, sécurité, orchestration complexe de services Web, etc.
(Nous ne parlons pas de sites Web simples, n'est-ce pas?)


1
Vous pouvez également obtenir ces informations à partir de langages de script - consultez Python et SQLAlchemy. Even Rails utilise un ORM (ActiveRecord) et dispose d'une bonne sécurité.
Brian D.

3
En effet, mais je ne pense pas qu'ils soient aussi puissants que Hibernate, Spring Framework, les frameworks BPEL le sont.
Sorantis

1
Quel problème avec Java sur non-UNIX / Windows.
Tom Hawtin - tackline le

2
Rien. Mais sur Windows, vous avez .NET
Sorantis le

2
-1 Vous donnez l'impression que l'une des solutions de rechange ne dispose pas d'outils décents.
Raynos le

9

Chaque fois encore une autre équipe Java me fait chier, je m'essouffle en cherchant des questions comme celle-ci. Permettez-moi de répéter. Je suis un client et je le suis depuis près de 5 ans maintenant. J'ai travaillé sur des sites allant de microsites uniques au contenu principalement, à des sites aussi gigantesques que Sears, à des sites de type application plus sophistiqués nécessitant une expertise approfondie de l'interface utilisateur. Je me suis occupé de Rails, PHP, formulaires Web .net (ew), .net MVC (bien mieux) et d’un bouquet de solutions Java pour le développement Web accompagné de développeurs et d’équipes qui ont toutes vécu des catastrophes catastrophiques. J'écris aussi un peu de Python et je commence à creuser Django.

Mon expérience avec les équipes Java a été terriblement mauvaise. Les outils sont toujours un PITA. Les développeurs ne veulent jamais croire qu’ils ont fait quelque chose de mal et les amener à ré-enquêter sur leur propre terrain une fois que vous avez éliminé un problème de votre côté, c’est comme s’arracher les dents. D'après mon expérience, la première victime à avoir eu affaire à des équipes de Java est le temps de développement converti en temps de courrier électronique et la rédaction de nombreuses explications longues sur les raisons pour lesquelles le problème est définitivement résolu. HTML n’est généralement pas leur problème à moins que vous ne souhaitiez réellement le contrôler. Ensuite, tout finira par aller au diable, car vous voulez réellement déplacer des divs de niveau supérieur.

Il y a des choses sur le langage que je n'aime pas mais je pense que le vrai problème est la culture et le fait que l'acceptation soit si répandue, vous avez une tonne de médiocrité au milieu. La culture que je soupçonne découle de la manière dont Java est commercialisé. Ecrivez une fois, déployez-vous partout. Traduction: "Vous n'avez besoin d'apprendre qu'une seule chose!" Les personnes qui trouvent cela attrayant veulent essentiellement utiliser Java comme un marteau gigantesque pour chaque clou avec un minimum de perfectionnement de leur savoir-faire en matière de développement Web.

Donc, si vous avez des développeurs qui connaissent Java et d’autres langages, mais préfèrent tout de même Java, je dirais que oui, allez-y, si cela vous semble la bonne solution. Mais si vous avez des développeurs Java qui connaissent Java et que tout le reste satisfait à peine aux critères pour en faire un élément essentiel de leur CV, demandez-leur de créer une application simple avec une variété de pages semi-complexes sur l'extrémité HTML et essayez ceci. test simple. Casser du HTML. Essayez de leur faire comprendre ce qui ne va pas. Si le problème immédiat qu'ils commencent à résoudre est de détourner le blâme d'eux-mêmes, éloignez-les du développement Web! Le développement Web est multidisciplinaire et nécessite un intérêt actif dans le domaine pour réussir. Ce n'est pas un endroit pour ceux qui veulent seulement garder la connaissance d'une seule langue et qui sont plus horrifiés par les problèmes que ceux qui sont intéressés à les résoudre.

Je n'affirme pas que Java est en soi la source de l'incompétence et j'ai entendu dire que le printemps était bon. Je suis sûr qu'il existe des équipes Java compétentes. Je n'en ai pas encore rencontré un et je ne pense pas que ce soit une coïncidence. Je pense que Sun a beaucoup à voir avec cela. Je pense également que la gestion d’équipes Web appartenant à des départements informatiques ou sous celle-ci y est pour beaucoup.


1
J'ai les mêmes problèmes que vous décrivez, mais je n'ai jamais pensé que cela pouvait dépendre du langage de programmation. Pensez-vous que les personnes qui programment en PHP, par exemple, sont plus ouvertes et plus flexibles?
Виталий Олегович

PHP concerne à 100% le développeur et moins la culture qui l’entoure. Je n'aime pas son manque de cohérence au cœur, mais je ferais confiance au travail d'une équipe PHP de niveau intermédiaire pour le développement Web, d'une manière qui ne me ferait pas confiance à une équipe Java. Cela aide qu’un développeur PHP expérimenté ait peu de chances d’avoir travaillé avec autre chose que le Web et qu’il ait probablement été embauché pour acquérir de l’expérience au-delà des diplômes / qualifications. Le problème de Java est peut-être en partie dû à la rigidité inhérente au langage, mais honnêtement, je pense qu'il s'agit davantage de la nature de la formation des développeurs Java, de l'adoption des solutions Java et de l'embauche de développeurs Java.
Erik Reppen

1
@ Erik Reppen: Je pense que votre expérience est sur-généralisée: je ne pense pas que les équipes Java soient pires que celles qui travaillent dans d'autres langues, ou du moins pas moins que la moyenne. Je connais deux très bons magasins qui travaillent beaucoup avec Java. Le premier, fait des projets en Java et en Ruby (environ 50% chacun). La seconde travaille principalement en Java mais a réalisé des projets individuels à Scala et à Common Lisp.
Giorgio

@Giorgio Cela m'a échappé, mais j'ai travaillé avec d'autres personnes gérant le back-end via .NET, Rails, Java et PHP. Je ne compte pas les expériences uniques avec d'autres langues et les développeurs de merde ne sont certainement pas propres à Java. En outre, comme je l’ai dit, je suis certain à 100% que des équipes Java très compétentes sont disponibles. Quelqu'un ne doit pas craquer mais IMO, je ne suis pas trop généraliser. Il existe un problème avec les développeurs Java au niveau médian. C'est un phénomène culturel dans mon expérience. Un tel méchant que j'ai cessé de travailler avec les magasins Java sauf si je connais les développeurs en question.
Erik Reppen

5

Java convient parfaitement aux petits sites Web. Vous pouvez faire fonctionner les pages JSP très rapidement avec un serveur Web Java tel que Tomcat , par exemple.

D'après mon expérience, Java est plus courant pour les grands sites Web où le traitement complexe côté serveur est plus important. Dans ce cas, vous trouverez des infrastructures Java plus sophistiquées utilisées telles que JavaServer Faces (JSF).

Il est important de noter qu'une installation complète de Java n'était pas disponible dans de nombreuses configurations d'hébergement Web bon marché, ce qui peut expliquer la prédominance d'autres langages tels que PHP dans ces environnements.


Est-ce que cela signifie que l'hébergement d'applications Web Java est trop coûteux? ou n'est-ce pas aussi bon marché que PHP par exemple? pouvez-vous me donner un bon lien hôte pour Java afin que je puisse voir les prix? J'ai fait une recherche mais je ne sais pas lequel a les prix standards, donc je peux avoir une vue d'ensemble à ce sujet.
Goma

1
l'hébergement d'applications Web Java n'est pas cher, vous avez simplement besoin d'un fournisseur d'hébergement qui vous permet d'exécuter des applications Java. Tout environnement d’hébergement Linux dans lequel vous aurez un compte de connexion à la machine suffira - j’utilise personnellement Ubuntu sur Amazon Web Services pour mon hébergement Java.
Mikera

2

Les principales raisons d'utiliser Java dans le développement Web se résument comme suit:

  • Le client le demande. Pour le meilleur ou pour le pire, certains clients ont "des listes de technologies acceptées", et si vous proposez quelque chose qui ne figure pas sur cette liste, vous feriez bien de vraiment expliquer pourquoi - et pourquoi quelque chose sur la liste ne pourrait pas être utilisé.
  • Développer sous Windows, déployer sous Unix. La plupart des machines de développement sont Windows, certaines Mac et très peu Linux, comme on peut s'y attendre avec des machines clientes classiques. Cependant, sur le serveur, vous êtes tout aussi susceptible de voir une forme d’Unix que vous êtes un serveur Windows. Java est probablement le plus proche pour écrire une fois déployer n'importe où (ce n'est pas parfait, mais mieux que certaines alternatives).
  • Choix de gestion. Regardons les choses en face, le choix de Java sur un autre langage aura plus à voir avec la possibilité de trouver des programmeurs et de remplacer les membres de l'équipe qui quittent le projet que d'être basé uniquement sur les mérites du langage.

À propos de # 2: veuillez configurer votre IDE correctement. Eclipse a cette idée stupide de passer par défaut à un encodage de fichier Windowish qui peut causer des dégâts sur un serveur Linux.
Eldelshell

En fait, je faisais référence aux hypothèses sur l'emplacement de certains fichiers et à chaque fois que vous devez interagir avec le système d'exploitation.
Berin Loritsch le

"C est probablement le plus proche pour écrire une fois déployer n'importe où" J'ai corrigé cela pour vous.
Raynos le

@ Raynos, si seulement c'était vrai. Malheureusement, sauf si vous avez les mêmes bibliothèques standard sur toutes les plateformes, cela ne peut pas être vrai. Le langage de base C est très portable, je vous le dis. Cependant, tout ce qui est spécifique au système d'exploitation (comme la création d'un thread, l'ouverture d'un socket ou la création d'un élément d'interface utilisateur) a quelque chose dans l'API qui ne peut pas être porté avec une simple recompilation. Avec Java, aucune recompilation n'est nécessaire, encore moins de changer le code pour utiliser la nouvelle API système.
Berin Loritsch

@BerinLoritsch, vous voulez dire qu'après 40 ans, nous n'avons plus d'API générique pour des éléments spécifiques à un système d'exploitation qui fonctionne simplement sur plusieurs plates-formes avec une simple recompilation? Je peux imaginer que cela soit vrai dans les années 80 cependant.
Raynos le

2

Techniquement parlant:

  • Si vous pouvez définir une architecture compatible avec l'optimiseur de points chauds.
  • Si vous anticipez le besoin de la surcharge massive imposée par Java, Java l’impose.

Si je commençais une application Web, j'utiliserais Ruby on Rails et concevoirais de manière à ce que les zones sensibles puissent être permutées lorsque RoR atteindrait sa limite de performance.

Java a une odeur définie de COBOL et les "développeurs bas de gamme utilisent Java", et les fiascos d’Oracle n’aident en rien la réputation. Si vous avez le choix , choisissez une langue qui attire les meilleurs développeurs.


"choisissez une langue qui attire les meilleurs développeurs." Exemple?
Eldelshell le

1
@Ubersoldat: Go, Ruby, Clojure, Haskell, Python sont tous des langages qui le font.
Paul Nathan

Python est bien parce qu’il réussit à bien des choses que Java prétend faire. Et ce n'est pas difficile de le faire bien jouer avec les autres quand vous devez résoudre un problème avec une autre langue. Je ne sais pas à propos de Ruby, mais les développeurs de Rails sont un peu un jeu d'enfant dans mon expérience. C'est l'effet JQuery. Les gens qui savent ce qu’ils font aiment le faire parce que c’est rapide et efficace entre de bonnes mains. Les gens qui ne savent pas ce qu'ils font aiment le faire parce qu'ils n'ont pas besoin d'en savoir autant.
Erik Reppen le

@Erik Reppen: D'autre part, Ruby en tant que langage a une conception plus agréable et plus cohérente que Python. Je pense vraiment que ces comparaisons de langues sont souvent une question de goût et on a tendance à privilégier les langues qu’elles maîtrisent mieux.
Giorgio

0

C'est simple: utilisez Java lorsque les performances de votre ordinateur sont une préoccupation majeure. Il y a plus de temps lors du codage, mais le code s'exécute dans 1 / 200ème à 1 / 500ème du temps - littéralement. Php, Ruby et d’autres langages à typage dynamique seront toujours beaucoup plus lents que les serveurs java ou .net.

La plupart des solutions Web n’auront pas besoin de cela. Twitter n'a pas abandonné Rails jusqu'à ce qu'ils atteignent un sommet de popularité, par exemple.


-1

Pas la seule raison, mais avec la popularité croissante de la construction de sites Web avec des frontaux sophistiqués ressemblant à des applications tout en conservant une logique qui «restitue» sur le serveur - aucune raison ne devrait être nécessaire pour expliquer pourquoi Java est au moins égal à un autre. option sur le serveur. Mais du côté du client, si du javascript va rapidement se transformer en cauchemar de maintenance du code et en utilisant GWT pour le garder à portée de main afin que vous puissiez coder en Java, vous pouvez obtenir le meilleur des deux mondes avec votre serveur. faire le gros du travail et le processeur d'un client en lui donnant l'expérience. Apprenez à l’intégrer à quelque chose comme jQuery et vous pouvez avoir tout le plaisir que vous voulez.

Pas un expert des alternatives, mais si quelqu'un d'autre peut en proposer une avec la même souplesse et la même ampleur, je suis ravi de l'entendre.


+1 pour jQuery :)
abel

2
-1 pour "javascript se transforme en cauchemar de maintenance du code", il ne s'agit que d'un effet secondaire qui permet aux développeurs Java d'écrire du javascript sans formation ou apprentissage de JavaScript. L'inconvénient majeur de GWT est qu'il s'agit d'une abstraction qui fuit. Bonne chance pour qu'elle fonctionne correctement sur les appareils mobiles.
Raynos le

Le problème avec la rigidité de Java, IMO, est que vous vous retrouvez avec beaucoup de développeurs qui ne comprennent pas pourquoi leur code est forcé de la même manière qu’il est au départ. Lorsque tout doit ressembler à la programmation orientée objet, le résultat inévitable est parfois que rien ne l’est réellement.
Erik Reppen

-1

La principale raison pour laquelle je choisirais Java est si vous devez utiliser des transactions distribuées, ce qui peut être une préoccupation majeure pour de nombreuses entreprises. Cependant, vous pouvez toujours utiliser votre langage de script favori pour le développement Web et ne déléguer le travail en java que lorsque vous avez besoin de transactions rapides / distribuées.


-1

Je pense que cela se produirait lorsque votre application sera très complexe et sera développée par de nombreuses personnes, avec de nombreux modules complexes, une logique métier complexe et la communication avec de nombreuses autres applications d'entreprise.

Quoi qu'il en soit, vous pouvez également développer Grails, qui offre de nombreuses fonctionnalités intéressantes, facilite beaucoup le développement et mûrit très rapidement.


-1

Java est ok, mais si les performances ne sont pas d'une importance cruciale, vous pouvez obtenir les mêmes résultats avec moins d'effort dans d'autres langues.


2
"les performances ne sont pas d'une importance cruciale", alors que vous devriez écrire en C et que l'assembly n'est pas Java.
Raynos le

Benchmarks vs. experience, les sites Java ont sans conteste été les pires de mon expérience en tant que développeur côté client. C’est peut-être un problème de niveau de talent médian plus qu’un problème de langage.
Erik Reppen le

2
@ErikReppen: Certainement une chose de talent. La vitesse Java sur un serveur est la deuxième après C / C ++. PHP ou Rails ne peuvent tout simplement pas comparer. Mais les bibliothèques de Java et certains des outils facilitent trop facilement la perte de vitesse en effectuant des tâches inutilement compliquées.
Zan Lynx

-1

Java est un langage à typage statique, qui est moins cher que les autres langages à typage statique utilisés pour le développement Web, à savoir C # et VB.net, si votre société ne possède pas d'abonnement MSDN. Les langages à saisie statique conviennent aux projets de moyenne à grande taille, aux règles de domaine complexes et à beaucoup de code back-end, car vous pouvez mieux organiser vos classes et les IDE vous aideront à trouver des erreurs dans votre code.

Avec des langages à typage dynamique, tels que PHP, Python, Ruby, votre développement sera beaucoup plus rapide, mais vous devrez tester votre code beaucoup mieux. Si vous avez peu de temps et d'argent et que vos exigences changent très rapidement et que vous n'avez pas à faire de calculs très complexes, les langages dynamiques sont bien meilleurs.


-2

Sécurité

La raison principale invoquée par les grandes entreprises pour choisir Java par rapport à d’autres solutions est qu’elle est considérée comme beaucoup plus sûre.

Ceci est principalement dû au fait qu’il est soutenu par une si grande entreprise (maintenant Oracle).

Il convient de noter que Java offre un très haut niveau de sécurité et un excellent support et analyse (bien que cela ait un prix).


7
Euh ... et la sécurité vient comme par magie de la langue elle-même ou quoi?
Mchl

1
Vous savez qu'Oracle N'EST PAS le seul fournisseur de conteneurs de servlets Java, n'est-ce pas?
Mchl

6
La guerre sainte! Combat combat!
Abel

2
@Mchl Une partie provient du langage ou plutôt de sa machine virtuelle. Combien de fois avez-vous vu des piratages de saturation de la mémoire tampon destinés aux serveurs d'applications Java? Cela ne vaut tout simplement pas la peine. Cela dit, "le secteur" considère que Java est plus sécurisé que le nôtre, et un faux sentiment de sécurité peut être difficile à maîtriser.
biziclop

1
Ce que je voulais dire ici, c'est que vous devez différencier Java en tant que langage et les environnements d'exécution Java. Rien ne rend le langage Java plus ou moins sécurisé que tout autre langage. Les machines virtuelles sont quant à elles conçues (entre autres) pour l'exécution du bytecode Java en mode "bac à sable", mais leur sécurité dépend de l'implémentation spécifique. Bon point sur le faux sentiment de sécurité cependant.
Mchl
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.