Discussion :

[heinquoi]

Je connais vraiment pas la problématique.
Cependant je m'interroge sur le temps d’exécution. Dans ma representation le JS est lent, voir très lent du fait qu'il est interpréter notamment. Faudra-t-il un octo-processeur survitaminer pour faire un simple jeu de console ?

[Uther]

Je connais vraiment pas la problématique.
Cependant je m'interroge sur le temps d’exécution. Dans ma representation le JS est lent, voir très lent du fait qu'il est interpréter notamment. Faudra-t-il un octo-processeur survitaminer pour faire un simple jeu de console ?

Le JS est certes globalement plus lent que le C, mais maintenant que les moteurs JS récent font du JIT, la différence n'est plus aussi énorme. Pour scripter les action d'un GUI, c'est très largement suffisant.

Quant à faire un jeu complet, c'est faisable avec des performance certes moindres, mais ce n'est pas le sujet ici.

[tiloup367]

Pas la pour m'obstiner, mais j'avais bien stipulé : Il y a beaucoup de différence. Donc s'il y a beaucoup de différence, il y a quelque ressemblance. Comme a dit vermine : JavasScript s'est inspiré de beaucoup de langage dont JAVA. Il a des ressemblances faibles. Par expérience, je peux dire qu'en abordant l'un des deux en premiers, il est plus facile de comprendre le deuxième(JavaScript <--> JAVA).

[Uther]

Le seul vrai point commun c'est la syntaxe qui s'inspire dans les deux cas du C.
Mais vu que, le C à 40 ans et que les langages qui se sont inspirés de sa syntaxe, il y en a des dizaines, parler de ressemblance Java/Javascript, c'est un peu prendre le problème à l'envers.

La syntaxe mise à part, je dirais, au contraire, que ces deux langages n'ont vraiment rien en commun : quasiment toutes les mécaniques fondamentales sont différentes. Essayer de faire des rapprochement entre les deux est surtout source de confusion. Autant les comparer au C.

Le Javascript devait à la base s'appeler Livescript. S'il s'est retrouvé affublé de ce nom, c'est seulement à cause des gens du marketing de chez Netscape, qui ont voulu bénéficier du "hype" qu'avait Java à l'époque.

[poringkiller]

Moi j'essaye d'éviter ca le plus possible. Parce que quand tu voit que la moindre selection d'un champs/div/etc... tu doit te taper un document.getElementById(<id_element>)

Non, tu ne DOIS pas ... tu peux aussi te coder un sélecteur si tu veux éviter de charger jquery mais que tu veux des raccourcis d'écriture.
Javascript est souple, on peut le modifier dans tous les sens, il est fait pour ça, profites en.

[eomer212]

certes, javascript permet de faire des choses, mais de la a parler de langage pour applications.?
et l'accés materiel, l'interface avec les peripheriques.?
javascript permet de faire des choses interressantes, mais une vrie appli, ca communique, javascript a IO lib) , mais ca ecrit des infos sur le disque, ca peut le manipuler, ca communique avec des peripheriques.. et je vois mal javascript gerer ca sans devenir un espece de monstre.

alors ils rajoutent des bibliotheques spécifiques, des plugs ins..
ca va devenir une belle salade tout ca.
moi j'ai besoin de maitriser les impressions, depuis l'appli, comment on poura faire ca en javascript.?
comment aller modifier le comportement du systéme on faire un editeur de proriétés systéme à partir de javascript.
faut pas confondre applications et applets....

[tiloup367]

en faisant des bibliothèques spécifiques (donc réécrit de zéro) avec un langage native et l'appel de c'est fonction native pourra être faite avec le langage javascript si un interpréteur est conçu avec ces bibliothèques. Un peu comme le style avec JAVA et JAVA Android, d'un point de vu c'est le même langage, mais pas le même "interprêteur". Je me souviens d'un élève dans mes cours d'info, lui il avait fait un "interprêteur PHP". En gros, les méthodes qu'il avait créer appelait les méthodes de PHP, mais si on se servait de sont "interprêteur" on ne voyait pas de PHP, seulement son langage qu'il venait d'écrire.

[tiloup367]

en gros : une sorte de "redéfinition de fonction".

[Bovino]

Il semble que tu confondes plusieurs choses.
JavaScript est un langage dépendant de l'interface lui fournissant une API.
Là, tu parles manifestement de porter l'API fournie par le navigateur au niveau d'un OS, ce qui n'a évidemment pas de sens...
Mais si tu regardes d'autres API, comme par exemple celle d'Adobe, voire l'API de l'application navigateur (que ce soit Firefox ou Chrome) à destination des extensions et non celle de la page Web, tu comprends que beaucoup de choses sont possibles avec JavaScript.

[tiloup367]

Ça revient pas mal à ce que je disais.... vous dites que JavaScript est dépendant de l'interface qui la fourni.... Dans le cas d'un navigateur web, c'est le moteur Web(ex : Modzilla = Gecko qui à un module JavaScript) qui la fourni, or le moteur Web est compilé natif (d'où la bibliothèque native). Et si on parle de JavaScript pour GNOME, GNOME est un gestionnaire de fenêtre, donc lourdement lier a un OS, donc fort probablement compilé nativement..... Bien-sûr, et là je m'éloigne du sujet, maintenant il y a le "cloud" qui apparaît tranquillement, natif risque de disparaître un jour ou l'autre, mais pour l'instant, du 100% ou même 90% "cloud" : j'ai rien vu. T'en que l'OS sera sur notre machine avec les applications sur notre machine, ce n'est pas du "cloud".