Discussion :

[eclesia]

Un veritable sujet a troll. Je vois que les anti-Java s'en donne a coeur joie avec le vieil argument qui date de Java 1.2 "Java c'est lent et c'est lourd".
Je conseil donc a ces personnes d'aller troller intelligement sur les forum dédié : Java vs C++ et Java vs .net dans lesquelles vous trouverez tous les arguments necessaire a démonter les préjugés ci dessus.

De mon coté je ne pense pas que Java soit fini pour la partie client web. Javascript reste un simple bonus pour le developpement de site web a utiliser a ses risques et péril au vu de tous les différences qui nous tombe dessus d'un navigateur a l'autre (firefox, opera, safari, chrome sans parler d'IE).

Alors qu'une application JavaWebStart, un applet, du flash, du javafx ou autre, ca marche ou ca ne marche pas point a la ligne.

L'avenir est aux RIA comme JavaWebStart, JavaFX, Flash et Silverlight, dans cet avenir les navigateurs ne seront plus que des conteneurs de micro application.

Meme si beaucoup pense que l'avenir de javafx est assez peu certain, c'est le seul language (avec les applet Java et JavaWebStart) a permettre le deploiement d'une application lourde sans contrainte de plateforme ni de navigateur.
Ce qui rend ces application encore plus attirant depuis java 1.6, cest l'arrivé de la compression pack200 (36Mo de Jar devient 9Mo compressé).

JavaScript reste de la manipulation de tag xml avant tout, rien de plus.

[FloMo]

Pensez-vous que le JavaScript pourra détrôner la technologie Flash d'Adobe, en terme d'usage ?

En terme de capacités techniques, sans aucun problème. Les moteurs JavaScript des navigateurs sont hyper-optimisés et s'intègrent vraiment bien au système, offrant donc des performances accrues.
D'un point de vue multiplateforme, on profite des performances des terminaux. Il n'y a qu'à regarder l'iPhone : avec WebKit, on peut faire de chouettes animations (http://www.macplus.net/iphone/ par exemple) alors que Flash rame trop pour être intégré.
Il y a aussi des options intéressantes, comme la possibilité d'avoir une base sqlite côté client.

Considèrez-vous Java comme mort ?

Java est clairement mort du côté client : c'est moche, c'est lent.
Du côté serveur, c'est encore assez performant, même si ça n'évolue plus. Ce qui risque d'être problématique à terme est l'intégration de technologies comme Grand Central ou OpenCL. On en est encore loin avec Java.

[Graffito]

La mort ou le succès d'un langage a malheureusement peu à voir avec ses qualités.
Si c'était vrai, plus personne n'utiliserait C++ aujourd'hui .

eclesia : L'avenir est aux RIA comme JavaWebStart, JavaFX, Flash et Silverlight, dans cet avenir les navigateurs ne seront plus que des conteneurs de micro application

+1, surtout quand l'implémentation des objets remote sera normalisée/stabilisée.

[pip1000]

Dire que les applets sont mortes en disant que Java est mort ca risque de ramener les troller antiJava ;-)

L'avenir est pour moi ce que fait google, utiliser la syntaxe Java pour générer du Javascript optimisé illisible (et limite incompréhensible) mais ultra efficace. Coder en javascript sera autant abérant que de coder en binaire.

Si de plus l'avenir est au cloud (il faut voir ce que va faire chrome OS) le browser risque d'eclater en miriades de petites applications connectées, pourquoi tout faire avec le browser? et dans ce cas il y a fort a parier que ces application (semi lourdres ;-) ) seront codées en Java (ou peut etre en NOOP).

[nicorama]

J'ai utilisé Javascript+Extjs pour faire commencer une appli pas si compliquée de qcm (http://edupassion.com:8080/xseditor/).
Le langage non typé, non merci, je préfère GWT. Avec les ide modernes, on gagne un temps fou avec le langage typé !

[deadalnix]

Par contre je suis désolé mais personne n'utilise plus d'applet java pour le web.

Je le fait pour lire les vidéo par exemple. Ça marche nettement mieux que flash.

Mais c'est vrai qu'avec la balise video . . .

Enfin c'est pas plus mal, tous ces plugins c'est vraiment pas la joie.

[lcfseth]

La parano des anti antijava en plein actions

Je vois que les anti-Java s'en donne a coeur joie avec le vieil argument qui date de Java 1.2 "Java c'est lent et c'est lourd".

Personne n'a dis qu'il était lourd. En tout cas pas moi, d'abord parce que je vois comment un langage ou une technologie peut être lourde? Un framework,une appli peut être, mais un langage?

Pour ce qui est de la rapidité, j'ai parcouru les 200 pages du forum (vite fait, j'ai pas que ca à faire). Franchement j'aurais aimé avoir tort sur ce point mais rien ne semble l'indiqué. Pas même les dizaines de liens qui traite du sujet ( comparaison .net c++ java niveau performance ) à part un qui prétend qu'il serait plus 2x rapide que le c++.

Cela ne veut pas dire que java est pire que .net ou c++. Il est juste plus lent.

Si c'était vrai, plus personne n'utiliserait C++ aujourd'hui

corrompu va :p

L'avenir est aux RIA comme JavaWebStart, JavaFX, Flash et Silverlight, dans cet avenir les navigateurs ne seront plus que des conteneurs de micro application.

Tout a fait d'accord.

Dans le folklore d’Internet et d’Usenet, certains sujets polémiques sont réputés pour les débats sans fin qu’ils engendrent. Ceux-ci, généralement fondés sur des préférences personnelles sur lesquelles il est impossible de trouver un compromis, peuvent être utilisés afin de lancer un troll

Tient je troll sans le vouloir Ok j'arrete.

[xtope]

Personnellement voici ce que j'en pense :

- le javascript ne devancera jamais le flash, tout simplement parce qu'il n'offre pas autant de fonctionnalités et qu'il n'est pas aussi rapide (cela dépend grandement aussi des navigateurs).
Le jour où vous me montrerez un youtube en javascript ou des jeux corrects (j'ai déjà vu quelques essais mais bon..), je changerai peut-être d'avis.

- d'ailleurs en parlant de ces deux-là faites un petit tour sur deux sites concurrents : www.deezer.com et www.jiwa.fr. Le premier a fait le choix du "tout flash" et est rapide et agréable à naviguer. Le deuxième est agréable aussi mais est beaucoup plus lourd, suite à son concept "tout javascript" (d'ailleurs il me semble que le player est le seul élément en flash, comme quoi...).

- concernant java, même si je pense qu'effectivement les applets sont en cours de disparition, le java en lui-même est *très* loin d'être mort. Vous avez vu le nombre d'entreprises qui l'utilisent ? Ces derniers temps-ci j'ai même failli participer à un projet qui consistait à de la migration .NET vers le java...
Sinon pour ceux qui ralent à propos de la vitesse, je vous renvoie à la page "about" d'un émulateur psp écrit en java... les développeurs prétendent que les dernières versions de java sont aussi rapides que du C (et non ce ne sont pas des trolls puisqu'ils ont aussi developpé pcsx2, un émulateur ps2 en C++..) :
http://jpcsp.org/index.php?p=About

[kmdkaci]

Bonjour,
Ce genre de titre est trompeur... Et la news est loin d'être crédible. Je pense qu'il est généraliste.
Je suis surpris que dans la news on a survolé superficiellement le fait qu'il s'agit du coté client.
Sinon pour donner mon avis, je pense que Javascript remplacera peut-être Falsh et compagnie, mais pas Java surtout que maintenant il existe des framworks ecrit en Java qui génèrent JavaScript, je pense par exemple au GWT. Aussi certains programmes coté client ne peuvent être écrit en Javascript, je pense par exemple aux Applets (malgré certains défaut de cette technologie) qui restent très utilisés quand il s'agit des traitement complexe comme calcul ou industriel.

Cordialement

[batataw]

C'est bluffant :
http://www.megidish.net/awjs/

Franchement personne ne sait ce que sera l'avenir. J'espère juste que ce ne sera pas au bénéfice d'un framework fermé. Et puis les entreprises ne changent pas aussi facilement de technologie.

[Mens Pervincet]

Un veritable sujet a troll. Je vois que les anti-Java s'en donne a coeur joie avec le vieil argument qui date de Java 1.2 "Java c'est lent et c'est lourd".
Je conseil donc a ces personnes d'aller troller intelligement sur les forum dédié : Java vs C++ et Java vs .net dans lesquelles vous trouverez tous les arguments necessaire a démonter les préjugés ci dessus.

Totalement d'accord. On peut dire que le tritre racoleur "Java est mort" y est pour beaucoup. Dans l'article, on y parle spécifiquement de la partie cliente, ce qui est déjà moins contestable.

Du côté serveur, c'est encore assez performant, même si ça n'évolue plus. Ce qui risque d'être problématique à terme est l'intégration de technologies comme Grand Central ou OpenCL. On en est encore loin avec Java.

Disons plutôt que les évolutions ne se font pas dans le même sens. Avec JEE 5 et les EJB 3.0, on peut parler d'évolution.

Le Javascript est vraiment dégueulasse, je n'ai jamais aimé coder en Javascript, et le fait qu'il soit plus ou moins accepté selon les navigateurs n'arrange rien. Pour qu'il prenne une place plus importante, pourquoi pas, mais il faudra faire des changements.

Il faut aller voir du côté des frameworks javascript orientés objets, tels que Dojo, pour commencer à avoir un VRAI langage de programmation.

[jayfaze]

Les applets java ne sont pas mort ! Regardez simplement la maginfique lib pulpcore, qui j'avais etendu dire devait etre porte sur android !

[Alesque]

Je partage l'idée que JavaScript et HTML doivent devenir le bytecode de Java losrqu'il est utilisé en mode client web. Donc un grand merci à Google pour avoir fait un grand pas dans cette direction avec GWT.

[jmini]

Ce genre de titre est trompeur...

+1

Surtout très racoleur...

Il aurait au moins fallu :
Java est mort coté client et JavaScript pourrait remplacer Flash...

Voir même dans l'autre sens (puisque l'article est aussi construit comme cela) :
JavaScript pourrait remplacer Flash alors que Java serait mort coté client...

Sinon la discussion est intéressante...

[Invité]

Java tient encore une sacrée forme. Mais il a vieilli sur 2 points :
1. il reflete le dogmatisme du marché fin 90's
2. il souffre de trop nombreuses versions et de + en + de forks qui annulent son intéret

Le dogmatisme des nineties concernant l'objet et l'interopérabilité : notion abstraite pour le client et lucrative pour le prestataire
Pas de court-circuit au dogme : ni compilateur natif, ni infraction à la hierarchie (dotNet permet tout cela - d'autres ne font que ça)

Le multi-pateforme est résolu au moment de l'éxécution et non à la compilation : lenteur inéluctable, optimisation impossible, mais aussi grande simplicité d'installation

Trop nombreuses versions et google qui s'y colle avec un fork très destabilisant...

[Orvinfait]

Bonjour,

Je ne suis pas d'accord. C'est SVG+ qui va s'imposer. J'en parle longuement à : http://www.orvinfait.fr/svg_rapide.html

Je parle de SVG+ pour bien montrer qu'il s'agit de SVG plus d'autres langages. Dans une même application SVG+ il est possible de faire fonctionner SVG bien sûr en relation avec Javascript, Java, Smil, CSS, HTML...

Quant à la lenteur des applets Java cela est du au fait que la plupart des navigateurs ne lisent pas encore Java sans programme additionnel mais les choses devraient changer. Opera 10 lit maintenant Java sans programme additionnel.

J''utilise Javascript mais je ne sais pas encore utiliser Java. Pourtant il me semble que Java, peut-être une évolution (NOOP), sera de plus en plus utilisé pour la simple raison qu'il peut fonctionner aussi bien du côté serveur que du côté client.

Au niveau de Javascript c'est ECMAScript (Javascript standard) qui devrait s'imposer.

Internet Exploreur n'est plus aujourd'hui un obstacle à l'évolution du web grâce au plugin de Google, qui n'est pas encore finalisé mais qui me permet déjà de faire fonctionner des SVG+ voir :
http://www.orvinfait.fr/internet_exp..._probleme.html

A mon avis c'est donc SVG+ qui va remplacer Flash et Java va être de plus en plus utilisé.

[deadalnix]

Je sais pas si c'est ce qui va se passer, mais c'est ce qui est souhaitable en tout cas

[spidermario]

Pour ma part, étant donné que je déteste utiliser directement JavaScript, j'utilise OBrowser, c'est un interpréteur de bytecode OCaml en JavaScript et une réécriture de la bibliothèque standard OCaml pour permettre l'intéraction avec le navigateur.

Exemple :

Code OCaml :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
(* fichier : test.ml *)
Js.alert "Test"

La compilation se fait en deux temps :

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
CAMLLIB='chemin jusqu'à la bibliothèque standard de OBrowser' ocamlc test.ml -o test.byte
uuencode test.byte stdout > test.byte.uue

1. D'abord, on compile le(s) fichier(s) source(s) en indiquant au compilateur le chemin à utiliser pour la bibliothèque standard.
2. Puis, dans la mesure où certains interpréteurs Javascript ne permettent le chargement que de fichiers ASCII 7 bits, on lance uuencode sur le fichier résultant.

Pour l'utiliser dans la page HTML :

Code HTML :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="Content-Type" content="application/xhtml+xml;charset=UTF-8" />
    <title>OBrowser test</title>
    <script type="text/javascript" src="vm.js"></script>
    <script type="text/javascript">
      exec_caml("test.byte.uue");
    </script>
  </head>
  <body>
  </body>
</html>

Note : les arguments supplémentaires passés à exec_caml sont récupérables dans le code OCaml par l'intermédiaire de Sys.argv.

[deadalnix]

J'ai du mal à voir l'intérêt de la chose si ce n'est éviter à tout prix de faire du javascript.

Ceci dit, j'aime autant que ce soir fait comme ça qu'en flash, au moins ça ne plante pas.

[Psykocrash]

Je participe à cette discussion car il me semble qu'un point très important doit être pris en compte, à savoir l'obsolescence du html. Ce n'est pas pour faire dans le troll, je m'explique.

Aujourd'hui, on essaye de remplacer le logiciel "traditionnel" par des applications accessibles depuis un webbrowser. Les RIA sont l'avenir, mais elles sont bâties sur de mauvaises technos. Voyez le XUL par exemple, il apporte des réponses à des problématiques récurrentes. Pourquoi s'embêter à écrire, à coups d'html et de js, je ne sais combien de lignes de code pour implémenter de A à Z une liste ou un menu ? C'est du temps de perdu pour le programmeur et des opérations lourdes (car non intégrées nativement dans le langage, comme Swing). C'est cher payé. Si vous voulez, j'ai l'impression qu'on fait du système D, on fait ce qu'on peut avec ce qu'on a au lieu de repenser les technologies. Je sais que c'est un investissement important d'apprendre de nouveaux langages, mais c'est un mal pour un bien. Avec quelques efforts, demain, nous aurons un Internet plus évolué, permettant de faire beaucoup plus de choses plus facilement.