Discussion :

[Arnaud F.]

Moi, ce qui me fait le plus rire dans l'histoire, c'est :

De tels pas en avant, si Microsoft acceptait en plus de les integrer et prendre en charge dans Internet Explorer, assureraient la première place en haut du podium pour JavaScript, selon Eich.

Le jour ou IE respectera certains standards JS et améliorera son moteur JS, là oui, on pourra, mais faire du jeu 3D avec le moteur actuel, autant se tirer une balle dans le pied.

IE a le moteur JS le plus lent de tous les navigateurs et c'est une vraie plaie de devoir toujours se demander "est-ce que ça fonctionnera sous IE" ?

Je crois que les promesses faites sont belles, mais pour ça, il faudrait aussi que certains navigateurs soient revus...

[Miss Trixie]

...........Java est mort ! C# est-il allé à son enterrement ?

celle ci m'a fais bien rire, je suis tout à fait d'accord, java n'est pas mort, loin de là ! De nouveaux jugs sont crées régulièrement !!!

personnellement je code en ce moment une appli en client léger avec java et wicket et je trouve ça nettement plus agréable que du code html pur, ce qui me réconcilie avec la programmation internet, comme quoi ... il n'est jamais trop tard pour évoluer =)

De toutes façons, vu le nombre d'entreprise qui ont investi sur des programmes en java, je le vois mal disparaître du jour au lendemain

Par contre ce qui me fais un peu peur c'est la multiplication du nombre de frameworks qui sont censés remplir les mêmes fonctions ... (ex avec les builders). Ca donne l'impression que la communauté s'éparpille un peu dans tous les sens. Pour quelqu'un qui débute, on est un peu effrayé par la masse et on se demande lesquels vont être utiles sur un cv par exemple ?

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

Juste pour la blague, je suis désolée mais je dois te contredire, je viens de passer 5 mois en formation, dont une semaine entière sur les applets ...

[siiZar]

IE a le moteur JS le plus lent de tous les navigateurs et c'est une vraie plaie de devoir toujours se demander "est-ce que ça fonctionnera sous IE" ?

Donc le problème ce n'est pas JS mais IE (je crois que l'on s'accorde tous là dessus)...

Personnellement, je découvre la programmation et JS... Et même si c'est sacrément présomptueux de penser que ça pourrait concurrencer Flash (à l'heure actuelle), les possibilités de ce langage me séduisent de jour en jour!
Flash (comme toutes technologies Adobe, même si elles sont bien) ce n'est pas gratuit (c'est un désavantage de taille).
Et puis, (avec W3C, DOM, html5, ...) JS ne peut qu'aller en s'améliorant ^^.
Quand à ceux qui trouvent que ce langage est "sale", c'est comme pour tout : tout dépend de la rigueur que s'impose le programmeur...

[Tommy31]

Et même si c'est sacrément présomptueux de penser que ça pourrait concurrencer Flash (à l'heure actuelle)

Et pourtant c'est déjà le cas, pour peu que le navigateur embarque un moteur js efficace. Jettes un coup d'oeil là :
http://www.chromeexperiments.com/

[alain.couthures]

XML est vraiment génial ... mais je ne le vois pas gérer un seul petit milliard de lignes..

Eh bien pourtant si ! MarkLogic Server est taillé pour gérer des TéraOctets de données !

Je ne vois pas d'intéret à lui faire remplacer une base de données

Tout simplement parce qu'un schéma XML est autrement plus riche qu'une table 2D !

XML a été ajouté un peu partout sous forme de méthodes ou de librairies mais il est (parfois trop) ouvert, pas très rapide et incapable de s'optimiser facilement .

Oui, et ORACLE obtient des performances lamentables en XML à côté de celles de Mark Logic...

Et comment scheduler une simple boite AJAX sans coder ?

XForms répond à celà! XForms, c'est de l'AJAX sans écrire du Javascript !

et les statistiques ? les rapports ?

XQuery n'a rien à envier à SQL en terme de puissance et il y a SVG pour faire tout ça très joliment côté client!

XForms et les bases XML sont réellement prévus pour les applications des grands comptes plutôt que pour les petites applications (ce qui est possible aussi, cependant). Et encore une fois, Javascript et Java sont relayés, alors, à la simple place de langages intermédiaires, pour écrire les moteurs...

-Alain

[Tommy31]

Eh bien pourtant si ! MarkLogic Server est taillé pour gérer des TéraOctets de données !

Perso, c'est pas la perf qui me gêne (j'ai déjà joué avec Exist et c'était très sympatique), mais plutot le manque d'acidité et la faiblesse de l'adoption XUpdate. A moins que c'est évlué ?

[batataw]

On type les variables pour faire au design-time ce que le processeur fera au run-time sinon.
Au bout du compte, tout sera typé dans les deux cas, mais si on le fait soi même, ça va beaucoup plus vite au moment critique (execution)

Donc un language qui ne compile pas et ne type pas est lent par nature. Même ultra optimisé, il devra résoudre son p-code et ses types de données avant toute execution. Voilà

Je sais tout cela mais on est plus dans les années 80 ou il fallait tout coder en assembleur pour optimiser la vitesse et l'utilisation de la mémoire. Franchement si tu as besoin d'un code ultra rapide tu ne vas pas te tourner vers un language interprété quel qu'il soit. Certains developpeurs font du typage presque une affaire d'honneur alors que je trouve que le scripting est une délivrance.

Pour info tu as des optimisations qui permettent de tenir en mémoire la version binaire du code, même si c'est toujours pas au niveau du compilé ca tient largement la route.

[deadalnix]

Certains compilos javascript sont capable de « retyper » le langage.

[siiZar]

Et pourtant c'est déjà le cas, pour peu que le navigateur embarque un moteur js efficace. Jettes un coup d'oeil là :
http://www.chromeexperiments.com/

trop fort!!!!!!!!
J'aime JS!!!

[Invité]

Citation:
Envoyé par unBonGars
Je ne vois pas d'intéret à lui faire remplacer une base de données

Tout simplement parce qu'un schéma XML est autrement plus riche qu'une table 2D !

C'est effectivement un peu tout simple dit comme ça.
Une table 2D est le dernier petit bout d'un schema de BDD, cette phrase est bizarre : les deux archi gèrent d'excellents schemas..

La table 2D n'existe pas vraiment en XML(qui peut + peut -) mais en SGBD , elle est issue d'une longue lignée de découvertes en matière de performance et de "durcissement". Quiconque a écrit des moteurs de données en C me comprendra : les traiteurs de signal également.
Ton approche est résolument celle d'un utilisateur de file system mais tu dois comprendre qu'un sgbdr à 120k€ peut parfaitement zapper le file system et descendre "plus bas" dans la stack de disque pour gérér ses contraintes.
Le petit sqlite désactive le filesystem et écrit toutes ses données avant de mettre à jour le répertoire (avec un risque de crash énorme)!!
Qu'esperes-tu avec XML ? Cela reste un fichier texte ! à la moindre insertion , il faut le réécrire entièrement, il n'y a pas d'index en natif, le tri se fait probablement en ram.

Tu ne peux pas opposer xml et les sgbd car chacun apporte des choses à l'autre mais xml n'est pas capable de tenir la charge comme un sgbd et ce n'est pas près de changer .. assènerais-tu des phrases-calembourre dans l'ordre que tu veux. Jette un coup d'oeil aux sources de mySql, PostGre, sqLite.
Tu y trouveras des perles issues de Berkeley publiées dans les années 50 et des merveilles plus récentes qui s'appuient sur 30 années d'innovations

Encore une fois : si ton truc est de rabacher qu'un schema xml fait mieux qu'une grille excel , tant mieux mais n'en espere pas trop, quant à tuer java avec ton bidulle, ca risque plutot de mettre tout le monde en pétard d'entendre des choses pareilles

[Invité]

Je sais tout cela mais on est plus dans les années 80 ou il fallait tout coder en assembleur pour optimiser la vitesse et l'utilisation de la mémoire. Franchement si tu as besoin d'un code ultra rapide tu ne vas pas te tourner vers un language interprété quel qu'il soit. Certains developpeurs font du typage presque une affaire d'honneur alors que je trouve que le scripting est une délivrance.

Pour info tu as des optimisations qui permettent de tenir en mémoire la version binaire du code, même si c'est toujours pas au niveau du compilé ca tient largement la route.

On n'est plus non plus dans les années 2000 où on pensait que la performance des clients croitrait à l'infini.... maintenant , on a des centaines d'architectures différentes qui s'éxécutent en même temps et il est normal qu'on cherche à optimiser les plus lentes. Javascript et php typent leurs données trop tardivement et à chaque exécution ce qui doit repréenter des megawatts d'énergie gaspillée dans le monde ....
Par contre, ils permettent le JIT qui autorise la génération de code, les compilos butent régulièrement là dessus et peinent à s'imposer (comprendre : se ramassent commercialement)

DONC : déduction toute bète : on peut optimiser le typage mais pas le JIT
Conséquence secondaire : soit on précompile javascript en laissant un programme faire ce que le dev a eu la flemme de faire : mettre des types en dur
Soit on demande au dev de se remuer ce qui , d'expérience , annonce des temps difficiles

[batataw]

On n'est plus non plus dans les années 2000 où on pensait que la performance des clients croitrait à l'infini....

Je sais pas qui pensait cela mais il faut pas croire tout ce que les gens racontent.

maintenant , on a des centaines d'architectures différentes qui s'éxécutent en même temps et il est normal qu'on cherche à optimiser les plus lentes. Javascript et php typent leurs données trop tardivement

Ca c'est ton opinion, moi je pense que le C type ses données trop tot. Il devrait attendre un peu avant de le faire. J'ironise car c'est vraiment des débats de techniciens qui sont tres loin de la réalité du marché.

et à chaque exécution ce qui doit repréenter des megawatts d'énergie gaspillée dans le monde ....

Il faut pas tout mélanger, que vient faire l'écologie la dedans???
Te rends-tu en vélo en métro ou en auto a ton boulot?

Par contre, ils permettent le JIT qui autorise la génération de code, les compilos butent régulièrement là dessus et peinent à s'imposer (comprendre : se ramassent commercialement)
DONC : déduction toute bète : on peut optimiser le typage mais pas le JIT
Conséquence secondaire : soit on précompile javascript en laissant un programme faire ce que le dev a eu la flemme de faire : mettre des types en dur
Soit on demande au dev de se remuer ce qui , d'expérience , annonce des temps difficiles

Tu veux a tout prix optimiser alors que les architectures d'aujourd'hui dual core, quad core et compagnie tiennent tres largement la charge. Je ne dis pas qui ne faut pas optimiser mais ce n'est plus une priorité comme ca l'a été jadis.

[Invité]

Ta rétorique ne fait pas avancer qui que ce soit. Ton "réponse à tout" ne mène nulle part.

Mozilla 3 annonce un javascript optimisé
Chrome annonce un Javascipt optimisé

Optimiser javascript est une issue majeure apparue avec ajax. Il y a des discussions récurrentes dans ce job et d'autres qui font perdre son temps.
Tu viens sur un forum technique pour dire que la technique est nulle, je ne partage pas cette opinion. je ne répondrai plus à tes messages.

[GanYoshi]

Et même si Java venait dans un scénario catastrophe à mourir entièrement aujourd'hui.

Combien de temps faudrait t'il pour que des développeur Java ne trouvent plus de boulot ?
Personnellement je pense que même les plus jeunes d'entre nous pourraient encore trouver un travail à faire du Java.

[batataw]

Ta rétorique ne fait pas avancer qui que ce soit. Ton "réponse à tout" ne mène nulle part.

Mozilla 3 annonce un javascript optimisé
Chrome annonce un Javascipt optimisé

Optimiser javascript est une issue majeure apparue avec ajax. Il y a des discussions récurrentes dans ce job et d'autres qui font perdre son temps.
Tu viens sur un forum technique pour dire que la technique est nulle, je ne partage pas cette opinion. je ne répondrai plus à tes messages.

OOOh, du calme, qu'est-ce que c'est que ce message???
Alors je suis pas daccord avec ta vision sur un sujet, j'ironise un peu et tu te faches? Pffffffff...Je ne viens pas sur un forum technique pour dire que la technique est nulle. Juste pour exprimer mon désaccord face aux techno-rigide de tout bord. Je te laisse dans ta croisade pour supprimer tous les langages a script qui ne déclarent pas explicitement leurs variables ou qui les type trop tard.

[apieum]

Conséquence secondaire : soit on précompile javascript en laissant un programme faire ce que le dev a eu la flemme de faire : mettre des types en dur
Soit on demande au dev de se remuer ce qui , d'expérience , annonce des temps difficiles

Je trouve ta position un peu fermée comme beaucoup d'autres "techniciens" qui ne raisonnent qu'en terme de performance.

Ça fait des années qu'il a deux écoles sur ce terrain là.
Soit c'est la machine qui s'adapte à l'Homme soit c'est le contraire.

Il y a pas de position qui prévale.

Personnellement je développe des librairies dans le but de m'approcher le plus possible d'un langage humain, c'est ce que j'attends de l'avenir en ce qui concerne les langages informatiques.
Donc vive le W3C et le XQUERY, vive les scripts !!!
Parce je parle pas encore comme une machine avec des (char 4) mots et des concepts précédés de leur type et que c'est le cas de la majorité des gens.

Donc si vous voulez mon avis, les langages de demain seront ceux qui s'adressent à tout le monde, c'est à dire ouverts (exit flash) et proche du langage humain (exit les langages ou l'on déclare les types en dur comme java ou C) .
C'est donc pas une question de flemme, ni de compétences, ni même d'aimer ou pas la technique.
Les temps risquent en effet d'être difficiles pour certains mais on est pas pressé.

[spidermario]

Parce je parle pas encore comme une machine avec des (char 4) mots et des concepts précédés de leur type et que c'est le cas de la majorité des gens.

OCaml dispose d'un typage fort et statique mais inféré, ce qui permet de ne pas indiquer les types, le compilateur et l'interpréteur les devinent d'après le contexte. Cela permet tout de même une bonne rigueur.

[Invité]

jeunes gens,

Soyés encouragés de faire de belles choses avec le language qui vous plait le plus. Envoyez des liens qu'on puisse voir .. Java est le premier language au monde , javascript le plus gros mangeur de cpu et pète une santé extraordinaire, d'où son appétit gargantuesque.

Je (premiere personne du singulier) m'intéresse au phénomène archi nouveau qui fait de l'atom un succès commercial malgré ses benchmarks, windows vient de réduire sa consommation dans des proportions impressionnantes. Bref on veut faire plus avec moins de watts, moins de cpu, passer une journée à jaser sur facebook sur une batterie 6 cellules. Pendant ce temps là mon navigateur affiche 10 onglets dont chacun a chargé au moins une video promotionnelle de 4Mo en moyenne : résultat 10 boucles infinies en javascript pour ajax, 10 fois 6% de cpu, 10 fois 30Mo de ram occupée le tout sur un écran HD. Voilà mon purpose, ma quète, mon graal.

Que cela ne vous empèche pas de faire des merveilles de votre coté , je suis impatient de m'en délecter. Internet est un succès majeur et ni java ni javascript , ni flash ne disparaitront de sitôt : profitez en.

Ma vérité est ailleurs simplement

Bonne continuation

[kimjoa]

Je suis tout à fait d'accord avec l'article.

Les applets java, le flash ,flex ou silverlight n'ont d'avenir qu'à court terme.

Avec l'émergence des nouvelles normes (html5, webgl) plus les anciennes qui mettent du temps à s'imposer(canvas, svg, css3), presque tout ce qui est possible de faire en java ou flash, est possible en js.

Mais le problème est bien le support de ses normes par les browsers, et je pense qu'il faudrait bien une dizaine d'année avant qu'une grande majorité des utilisateurs puissent en profiter.


Pour moi le système de classe en javascript est le meilleur que j'ai pu utiliser (hé oui )

allé faire ca en php ou java

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
var class1 = function(){
    ...traitement
}

var class2 = function(){
    ...traitement
}

var class3 = function(){
    class1.call(this); 
    class2.call(this); 
}

En js, on peux faire de l'héritage, de l'héritage multiple, et même plus grâce a certaine méthode native qui en invoque d'autre dans un contexte précis (call et apply).
Mais le problème de cette souplesse est qu'elle demande bien plus de méthodologie de la part du programmeur, ce qui peux être parfois un inconvénient.

J'ai l'impression que beaucoup pensent encore que le js, est un petit langage , surtout justement quand on parle de classe. Il ont des préjugées, et s'imagine que un vrai langage POO, ca signifie, classes abstraite, interfaces, encapsulations de données.
Hors ses spécificités de la POO ne sont pas forcement nécessaire, l'important c'est les classes en elle même , l'héritage et gestion des type des instances.

En js , on peux simuler tout ces spécificités, mais personne ne le fais, car l'intérêt et presque nul.

Cependant , c'est sur qu'il manque beaucoup de chose au javascript, la gestion du types des variables en est une, pour permettre une meilleur exécution, et sans doute bien d'autre....

Un mot que l'article ne mensionne pas, c'est le projet google, native client, qui devrait révolutionner le web en exécutant du code natif dans le navigateur, du coup le java aurait vraiment encore moin d'intérêt ...

[nicorama]

En js, on peux faire de l'héritage, de l'héritage multiple(...)
Mais le problème de cette souplesse est qu'elle demande bien plus de méthodologie de la part du programmeur(...)
J'ai l'impression que beaucoup pensent encore que le js, est un petit langage , surtout justement quand on parle de classe. Il ont des préjugées (...)

T'en fais pas un peu beaucoup ?
Tu voudrais rajouter le typage à Javascript, ce qui est une excellente idée : le typage permet d'utiliser facilement plusieurs librairies avec les ide modernes.

Mais regarde ton code : il rend impossible le typage d'un objet puisqu'il peut acquérir dynamiquement le type d'une classe ou d'une autre. Comment ton ide pourrait connaitre le type de ton objet quand sa définition varie au cours du programme ?

OK, l'héritage dynamique, ca a l'ar cool. Mais dans 99% des programmes complexes, cela ne sert à rien.
C'est bien pour débuter - j'en ai fait avec des lycéens, pour faire un petit truc rapide, et certainement dans certains cas que je n'ai jamais rencontré. On peut aussi tout faire avec Javascript, mais merci la galère !

Mais ne va pas dire que je n'aime pas JS parce que je ne le connais pas ou que je suis un développeur fainéant et désorganisé.