Discussion :

[javatwister]

oui mais non parce que ce serait la fin du forum

la théorie oui, mais par l'exemple... et éventuellement une rubrique "cours" à rénover... ou un sous-forum, "pouvez-vous m'expliquer comment...?" qui alimenterait ces nouveaux cours! Avec un contrôle strict, évidemment, de la prose du répondant avant validation...;

du coup, plutôt que des rubriques mal garées "faq", "sources", contrib", etc., une sorte de grand livre animé qu'il faudrait gérer en permanence - paginer, quoi! - et qui deviendrait rapidement une bible du web

[franculo_caoulene]

du coup lorsque tu lit la doc tu sort de là t'as apris plein de choses et c'est une vrai mine
mais tu ne sais pas si c'est JS une techno liée, un truc de mozilla.

sans compter les exemples obsolètes qui comme dit plus haut utilise le document.write !

Alors je maintient ma position la doc de Mozilla est riche pleine d'infos et de défauts.

Je dois bien concéder cela.

edit : je rejoins javatwister, je n'aime pas beaucoup dvp.com, je passe mon temps sur dvp.net, car beaucoup plus clair. La vrai base de connaissances est le forum, le reste ne sert qu'à appâter l'internaute. C'est pour ça que j'essaie de fournir des exemples directement exécutables.

[le_chomeur]

En fait , je pensais a une véritable documentation comme celle de php ( que je trouve malgré le coté communautaire fouillis intéressante )

- Liste de tous les mots clé pour commencer
- Sur chaque mot clé du langage :
-- L'appel / utilisation
-- Type de variable à passer à une méthode donnée
-- Retour de la méthode
-- exemple concret d'utilisation
-- section tips , pour certaines fonctions ( exemple les boucles , dont on doit initialiser la valeur de test si l'on travaille sur un tableau etc ... )

ce ne sont que des idées , mais une véritable documentation ou il serait facile de trouver une information RAPIDEMENT, donnerais également envie a de nombreuses personne d'ajouter dvp en favoris pour leur dev js

[EDIT] nous ne détenons pas la vérité absolue , mais depuis le temps que je développe et parcours le net, je pense ( et estime ) que nous avons un très bon niveau global qui nous permettrais d'apporter une véritable pierre @ l'édifice ...[/EDIT]

[franculo_caoulene]

Comme le dit sekaijin cette documentation existe : ECMAScript Language Specification.

[le_chomeur]

- Tu la trouves lisible ?
- Tu retrouves la liste des fonctions au premier coup d'oeil ?
- et point non négligeable : nous somme un forum francophone

de plus il s'agit plus de spécification que d'une réelle documentation a proprement parler sur l'utilisation du langage

[franculo_caoulene]

En effet, j'ai mal lu ta réponse.

Si je la trouve lisible? Comme toute spécification il faut avoir l'habitude de s'y coller. Donc, non pas de prime abord.

Si je retrouve la liste des fonctions au premier coup d'œil? Une recherche dans le document ou dans la table des matières à gauche du document aide grandement.

et point non négligeable : nous somme un forum francophone

C'est vrai.

[sekaijin]

faite comme moi une 1/2 heure de train par trajet
un spec W3c Ecma ou IETF sous le coude et en quelque année on les lits comme des romans

comme lecture de vacances

Interops1.0
Service Provisioning Markup Language
Security Assertion Markup Language

ou des norme de chez nous

le Référentiel Général d’Interopérabilité de la DGME est pas mal à connaitre
c'est une norme de chez nous ça!
ou encore PRESTO
https://www.ateliers.modernisation.g...chRef-1_FR.pdf


au passage la DGME Direction Générale de la Modernisation de l'Etat vous attends
http://www.modernisation.gouv.fr/
si vous avez des idées des propositions n'hésitez pas. allez voir Ensemble simplifions
si vous vous sentez l'âme d'un bâtisseur de la nation informatique
allez sur les ateliers https://www.ateliers.modernisation.gouv.fr/
mais là c'est l'artillerie lourde vous entrés dans un monde second

pour ce qui est d'ecmaScript téléchargez le PDF et lisez ça dans le train c'est instructif.

bon ceux qui sont sur l'autoroute avec la neige
regardez la route EcmaScript attendra

A+JYT

[dukej]

faite comme moi une 1/2 heure de train par trajet
un spec W3c Ecma ou IETF sous le coude et en quelque année on les lits comme des romans

comme lecture de vacances

Interops1.0
Service Provisioning Markup Language
Security Assertion Markup Language

ou des norme de chez nous

le Référentiel Général d’Interopérabilité de la DGME est pas mal à connaitre
c'est une norme de chez nous ça!
ou encore PRESTO
https://www.ateliers.modernisation.g...chRef-1_FR.pdf


au passage la DGME Direction Générale de la Modernisation de l'Etat vous attends
http://www.modernisation.gouv.fr/
si vous avez des idées des propositions n'hésitez pas. allez voir Ensemble simplifions
si vous vous sentez l'âme d'un bâtisseur de la nation informatique
allez sur les ateliers https://www.ateliers.modernisation.gouv.fr/
mais là c'est l'artillerie lourde vous entrés dans un monde second

pour ce qui est d'ecmaScript téléchargez le PDF et lisez ça dans le train c'est instructif.

bon ceux qui sont sur l'autoroute avec la neige
regardez la route EcmaScript attendra

A+JYT

Ici il y a des être humains, comment peux-tu nous imposer ça :o

[stailer]

Pour moi aucun développement n'est possible sans qu'immédiatement j'inclus JQuery à mes applis.
La communauté et le nombre d'outils sont tellement énormes que je ne compte pas refaire tout ce qui a été déjà fait et parfois au dela de ce que j'aurais réussi à faire (du moins impossible dans le temps qu'il m'était imposé).

Côté appli, je dev en Silverlight et je connais pas mal Flex3.
Donc quand je veux un équivalent (car équivalent il y a) il m'est impossible de dév un framework js ou un outil, tout seul, allant aussi loin.

Mon choix dans ce cas s'est porté sur ExtJS mais il y en a d'autres (notamment à base de JQuery ou encore le framework de Yahoo).

[dtcSearch]

Je trouve que les Librairies, en particulier jQuery et son jQueryUI, sont bien pratique car comble un vrai problème qu'on retrouve dans le Web dès lors qu'on veut faire une Application Web, le fait qu'il n'y ai pas de composante graphique pour des tâches récurrentes auquel nous sommes familiers, par exemple, saisir une date.
Le temps de développer un calendrier fonctionnant sur Internet Explorer et Firefox suffit à ce poser la question d'utiliser une librairie qui en propose sous forme de plugin.
Pourquoi plus une librairie qu'un composant dédié?
Je pense au fait que la librairie, jQuery en particulier, est un renouveau. Il est possible de faire de la RIA équivalente à du Silverlight en quelques minutes, sans que l'utilisateur est besoin de plugin, juste d'un navigateur (présent par défaut).

J'ai moi même fait du Javascript (car oui, en utilisant une librairie, j'ai plutôt l'impression de faire du jQuery que du Javascript), c'est pas bien sorcier de faire un WYSIWYG, des Drag&Drop ou encore des fenêtres modal en vanilla javascript, mais dès lors qu'on veut faire un calendrier, datagrid ou autres, c'est une autre paire de manche.

L'intérêt des librairies est faites pour moi, leurs tailles est sans importance, l'utilisations d'une URL commune en tant que source (http://www.google.com/jsapi) permet l'usage du cache sans s'en soucier. Et qui sait, peu être qu'un jour elles seront intégrées aux navigateurs (cas dans le mobile).

[druith]

Beaucoup de choses ont été dites. Je me contenterais donc de dresser deux constats :

- depuis que les frameworks sont utilisés en masse, on est passé d'effets flocons de neiges par dessus la page html ou des horloges dans un champ input à des effets réellement ergonomiques, esthétiques... et utiles !

- plus qu'en php en css/html, il m'est demandé de changer/ajouter/supprimer très souvent mes scripts JS dans les sites que je réalise. Or les frameworks sont plus rapides, certes mais surtout, je me sens beaucoup moins frustré (et donc aigri envers mon client !!) quand je dois me contenter de virer une librairie (même personnalisée) par une autre plutôt que de ne plus devoir utiliser le super-code-optimisé pondu le mois dernier.

Cette dimension de frustration n'a pas encore été abordée (ou je suis passé à côté), pourtant elle me semble très importante, plus on réalise un travail sur mesure et en langage pur, et plus l'idée de modifier ce travail est difficile à accepter. On se place dans un travail artisanal, et si c'est parfait pour un projet qui ne sera pas modifié pendant plusieurs mois / années, cela est très difficile à accepter sur des projets aux modifications et mises à jour régulières.

J'insiste sur le fait que je ne parle même pas de temps de travail ou d'optimisation du travail, juste du rapport intime que l'on entretient avec son code.

[dukej]

Beaucoup de choses ont été dites. Je me contenterais donc de dresser deux constats :

- depuis que les frameworks sont utilisés en masse, on est passé d'effets flocons de neiges par dessus la page html ou des horloges dans un champ input à des effets réellement ergonomiques, esthétiques... et utiles !

- plus qu'en php en css/html, il m'est demandé de changer/ajouter/supprimer très souvent mes scripts JS dans les sites que je réalise. Or les frameworks sont plus rapides, certes mais surtout, je me sens beaucoup moins frustré (et donc aigri envers mon client !!) quand je dois me contenter de virer une librairie (même personnalisée) par une autre plutôt que de ne plus devoir utiliser le super-code-optimisé pondu le mois dernier.

Cette dimension de frustration n'a pas encore été abordée (ou je suis passé à côté), pourtant elle me semble très importante, plus on réalise un travail sur mesure et en langage pur, et plus l'idée de modifier ce travail est difficile à accepter. On se place dans un travail artisanal, et si c'est parfait pour un projet qui ne sera pas modifier pendant plusieurs mois / années, cela est très difficile à accepter sur des projets aux modifications et mises à jour régulières.

J'insiste sur le fait que je ne parle même pas de temps de travail ou d'optimisation du travail, juste du rapport intime que l'on entretient avec son code.

Faut aussi coder de manière générique, les trucs que je code son quasiment génériques ou alors des gros morceaux sont génériques et utilisables dans n'importe quel contexte. Et là tu te fais moins chier à recoder oou modifier le code

[Killing Joke]

Soyons clair, je n'ai pas le choix : j'utilise forcément des librairies javascript (jquery notamment).
Pourquoi ?
Parce qu'après toutes ces années, je déteste toujours autant cet écosystème javascript qui n'a pas su évoluer et qui a toujours les mêmes (nombreux) défauts qu'aujourd'hui, et qui malheureusement n'est toujours pas remplacé par autre chose de crédible (dommage). Donc comme je n'ai pas le choix, je me débrouille pour faire le moins de javascript possible et donc réutiliser au maximim, c'est tout.
(non je ne suis pas un troll ...)

[druith]

Faut aussi coder de manière générique, les trucs que je code son quasiment génériques ou alors des gros morceaux sont génériques et utilisables dans n'importe quel contexte. Et là tu te fais moins chier à recoder oou modifier le code

Entièrement d'accord bien entendu ,

Mais en faisant ça de façon efficace ne se retrouve-t'on pas avec un framework maison à maintenir ? Et puis est-on réellement capable de ne pas jeter un oeil "rapide" à la partie générique à chaque projet pour vérifier si par hasard on pourrait pas l'optimiser un peu... avant de réaliser qu'on est dessus depuis 3 heures au moins

Je maintiens qu'avec un framework utilisé par tout le monde ou presque on fait un peu plus le bétail : on l'utilise sans se poser de question sur le core mais au moins on est soulagé de cette dérive de toujours vouloir faire du trop bon travail damned ! le mieux est l'ennemi du bien en informatique aussi.

(je pense à un graphiste que j'avais croisé qui travaillait depuis 2 ans sur son site perso en flash parce qu'il voulait tout scripter sans utiliser l'interface, jusqu'à la typo qu'il programmait lui-même... la chose était optimisée certes mais le site n'a jamais été mis en ligne : il s'était trop impliqué à tout faire parfaitement )

[RomainVALERI]

Parce qu'après toutes ces années, je déteste toujours autant cet écosystème javascript qui n'a pas su évoluer et qui a toujours les mêmes (nombreux) défauts qu'aujourd'hui, et qui malheureusement n'est toujours pas remplacé par autre chose de crédible (dommage).

...ah quand même.

"n'a pas su évoluer" ? Ca me semble aussi éxagéré que péremptoire.
Qu'est-ce que tu compares exactement pour en arriver à penser que les bidouilles JS du proto-web avaient quelque chose à voir avec les RIA d'aujourd'hui, l'AJAX, et les frameworks avancés sur lesquels de très grands nombres de sites ou d'applications JS s'appuient ?

Que le langage ait des caractéristiques qui te déplaisent, on a bien compris. ^^
Que le langage ne soit pas "quelque chose de crédible", pour l'instant, tu ne nous as pas encore expliqué pourquoi.

Mini-suggestion de nuance :

Donc comme je n'ai pas le choix comme je ne désire pas m'impliquer plus que ça dans la pratique de JS pour des raisons qui m'appartiennent, je me débrouille pour faire le moins de javascript possible et donc réutiliser au maximim, c'est tout.

(non je ne suis pas un troll ...)

[Bovino]

@druith et stailer : vos arguments sont tout à fait valables bien sûr. La seule chose, c'est que selon moi (et à priori je ne suis pas le seul à le penser), utiliser une lib ne devrait pas affranchir de connaitre le langage. Un framework doit permettre d'aider à développer plus rapidement, pas à cacher les lacunes comme c'est trop souvent le cas

@Killing Joke : +1 avec Romain !
Ne confonds pas ne pas aimer JavaScript et s'en faire de fausses idées

[druith]

@druith et stailer : vos arguments sont tout à fait valables bien sûr. La seule chose, c'est que selon moi (et à priori je ne suis pas le seul à le penser), utiliser une lib ne devrait pas affranchir de connaitre le langage. Un framework doit permettre d'aider à développer plus rapidement, pas à cacher les lacunes comme c'est trop souvent le cas

Difficile de ne pas être d'accord sur ce point. Après je suis pas convaincu que le problème de l'incompétence découle des frameworks. Avant on copiait collé bêtement les scripts JS et les applets java sans rien comprendre... rien ne change.

[r.othman]

S'il y a des cas où mieux vaut se passer d'une librairie ou framework, le contraire est aussi vrai ....quand il s'agit de développer un site "web 2.0" grand public compatible cross-browser, eh ben, bon courage à celui qui devra coder tout le javascript "pur"....car il faudra aussi tester derrière

L'avantage d'une librairie dans ce cas là est que justement c'est globalement bien testé et vous n'avez pas à écrire du code de colmatage a chaque bug sur un navigateur testé...rarement du moins .

[Invité]

avant tout je precise que comme je pratique javascript pour mon plaisir sans un patron au c*l je n'utilise et n'ai jamais utiliser de librairie

L'avantage d'une librairie dans ce cas là est que justement c'est globalement bien testé et vous n'avez pas à écrire du code de colmatage a chaque bug sur un navigateur testé...rarement du moins

c'est pas totalement vrais il m'est deja arrive de teste des truc fait avec jquery et j'ai put constater des default d'affichage qui concerne generalement ie 6 voir 7

[camus3]

JS (et HTML) souffre d’une « biosphère » de documentation (« documentosphère » ? ) bien trop vieille ; des sites qui parlent encore de DHTML et qui prônent l’utilisation de document.write,

Je signale juste que DHTML n'est pas un gros mot , c'est une alternative au DOM qui est bien trop lent.
Quand tu utilises innerHTML , c'est du DHTML , le DOM fonctionne avec les nodes.
Jquery utilise innerHTML par exemple.
Enfin , javascript c'est tout simplement un langage pas fini , avec de gros bugs ou " piège ", bref un truc mal pensé à la base qui est devenu populaire.
Contrairement à certains je pense que son avenir est en question sur le long terme.
Des choses apparaissent et disparaissent dans le WEB. Je pense que javascript laissera place à une alternative mieux pensée , du style ruby ou python par exemple avec un vrai choix sur la manière de programmer.

Enfin l'une des meilleurs ressource sur javascript est le site de microsoft :

http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx