Tout d'abord merci Etienne, tes dépêches sur Gnome sont toujours passionnantes !
A titre personnel, je connais peu JS, même si j'essaie de m'y mettre, notamment en faisant quelques scripts shell avec NodeJs.
Il y a quelques mois, il y avait eu une longue discussion sur le net, sur un blog anglophone, concernant le dev d'applications Gnome et mon commentaire avait été repris concernant l'environnement global de développement. (voir ici http://jewelfox.dreamwidth.org/33061.html)
Aujourd'hui, je ne sais pas trop comment cela a évolué, je salue néanmoins cette décision de l'équipe Gnome, mais…
je trouve dommage que Gnome fasse du "faux" Js, tout du moins du Js que l'on est pas habitué à manipuler. Exemples :
-- la librairie standard Js de Gnome n'a rien à voir avec la librairie standard que l'on trouve partout ailleurs. Truc tout con, et vraiment basique, l'objet "console" n'existe pas, il faut appeler la fonction globale "print". C'est tout bête, mais le développeur Js un peu "newbie" comme moi qui débarque avec la doc du MDN dans la tête, bne il est perdu.
-- même remarque pour le "packaging", avec GJS la gestion des espaces de noms se fait avec "import" et l'organisation physique de fichiers dans des dossiers, mais pourquoi ne pas reprendre les principes de CommonJs, avec par exemple le mot clé "require", qui sont maintenant largement répandus et maîtrisés ?
-- contrairement à @liberforce, je trouve justement dommage qu'il existe 50 manières de faire les choses (un peu moins en fait hein !). Rien que pour écrire une classe, ça change. Soit on fait du "vrai" Js :
function MaClasse() {...}
Soit on fait du "Gnome" :
const MaClasse = new Lang.Class({...})
Sauf que cette 2é méthode n'est pas documenté, qu'il faut lire le code de Gnome-shell pour comprendre qu'il y a des fonctions héritées comme "_init" pour le constructeur (d'après ce que j'ai compris du code), qu'il y a des champs plus ou moins implicites comme "Name" dont on ne sait pas vraiment à quoi ils servent, etc.
Il y a clairement un souci avec la doc qui est faite pour le C. Une approche certainement intéressante serait de reprendre les principes du MSDN avec des onglets par langage
Enfin, il y a un vrai souci d'environnement de développement, Anjuta est juste une souffrance pour du Js, et MonoDevelop ne le supporte pas, du moins la 3.0.3, ça marchait toujours pas, ou alors je suis une bille ce qui est toujours possible.
Le monde Js évolue très vite, notamment grâce (ou à cause de) à l'explosion du JS côté serveur, de nouvelles API apparaissent. Ca n'engage bien sur que moi, mais je trouverais intelligent de la part de l'équipe Gnome de reprendre ces APIs à leur compte pour vraiment faciliter la vie des développeurs, après, tout ne sera bien sur pas possible, mais ce serait déjà un bon début.
# Merci Etienne
Posté par romu . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 9. Dernière modification le 07 février 2013 à 10:22.
Tout d'abord merci Etienne, tes dépêches sur Gnome sont toujours passionnantes !
A titre personnel, je connais peu JS, même si j'essaie de m'y mettre, notamment en faisant quelques scripts shell avec NodeJs.
Il y a quelques mois, il y avait eu une longue discussion sur le net, sur un blog anglophone, concernant le dev d'applications Gnome et mon commentaire avait été repris concernant l'environnement global de développement. (voir ici http://jewelfox.dreamwidth.org/33061.html)
Aujourd'hui, je ne sais pas trop comment cela a évolué, je salue néanmoins cette décision de l'équipe Gnome, mais…
-- la librairie standard Js de Gnome n'a rien à voir avec la librairie standard que l'on trouve partout ailleurs. Truc tout con, et vraiment basique, l'objet "console" n'existe pas, il faut appeler la fonction globale "print". C'est tout bête, mais le développeur Js un peu "newbie" comme moi qui débarque avec la doc du MDN dans la tête, bne il est perdu.
-- même remarque pour le "packaging", avec GJS la gestion des espaces de noms se fait avec "import" et l'organisation physique de fichiers dans des dossiers, mais pourquoi ne pas reprendre les principes de CommonJs, avec par exemple le mot clé "require", qui sont maintenant largement répandus et maîtrisés ?
-- contrairement à @liberforce, je trouve justement dommage qu'il existe 50 manières de faire les choses (un peu moins en fait hein !). Rien que pour écrire une classe, ça change. Soit on fait du "vrai" Js :
Soit on fait du "Gnome" :
Sauf que cette 2é méthode n'est pas documenté, qu'il faut lire le code de Gnome-shell pour comprendre qu'il y a des fonctions héritées comme "_init" pour le constructeur (d'après ce que j'ai compris du code), qu'il y a des champs plus ou moins implicites comme "Name" dont on ne sait pas vraiment à quoi ils servent, etc.
Il y a clairement un souci avec la doc qui est faite pour le C. Une approche certainement intéressante serait de reprendre les principes du MSDN avec des onglets par langage
Enfin, il y a un vrai souci d'environnement de développement, Anjuta est juste une souffrance pour du Js, et MonoDevelop ne le supporte pas, du moins la 3.0.3, ça marchait toujours pas, ou alors je suis une bille ce qui est toujours possible.
Le monde Js évolue très vite, notamment grâce (ou à cause de) à l'explosion du JS côté serveur, de nouvelles API apparaissent. Ca n'engage bien sur que moi, mais je trouverais intelligent de la part de l'équipe Gnome de reprendre ces APIs à leur compte pour vraiment faciliter la vie des développeurs, après, tout ne sera bien sur pas possible, mais ce serait déjà un bon début.