Où va-t-on avec JavaScript ?

Citation:

---

Envoyé par dukej

Même pour un petit site d'un pote qui veut des effets "waouh", ...

---

juste en passant : en ce qui me concerne, dans ce genre de situation, il est parfois utile de faire un peu de "pédagogie" voire de "culture web" ( « Non, Bernard :nono:, je ne vais pas mettre une boite aux lettres animée pour le mailto. Ni en pied de page ce super bandeau clignotant que tu as trouvé sur chouettes-bandeaux-clignotants-gratuits.com. Je vais maintenant t'expliquer pourquoi je te rends service en refusant... etc. » )

Mais bon quand des effets sont effectivement souhaitables, c'est différent ^^

comme le lien dont le fonctionnement n'est pas très clair et qui ne change pas lorsqu'on clique dessus
le gars s'excite comme un malade dessus
appelle la hot ligne parce que ça ne marche pas.
le niveau un ne sais pas pourquoi lorsqu'on clique dessus il ne ce passe rien et renvois le pb au niveau deux
pendent ce temps l'utilisateur s'énerve sur le bouton et fini par abandonner
attendant que le niveau deux le rappelle
il fille en réunion
qui s'éternise comme toujours
et lorsqu'il revient à son poste tout semble bloqué
le poste semble comme figé ralenti à l'extrême.

en fait à chaque clic il a lancé un téléchargement de 20 Go sans le savoir et pendant sa réunion il a eu un file system full

au final un agent hot line monopolisé pendant quelques minutes, deux techniciens niveau deux pendant une heure un technicien d'intervention pour remettre le poste en état pendant 1 heure
un utilisateur au chaumage tout ce temps
alors qu'un simple effet visuel lors du click et ça passait comme une lettre à la poste.
et un réseau encombré pour rien

et on ne rit pas au fond de la salle c'est du vécu
A+JYT

Citation:

---

Envoyé par vermine

sekaijin, je suis d'accord avec toi sur le fait qu'on ne peut pas prétendre avoir un code plus performant en l'ayant écrit tout seul dans son coin que le code de dix développeurs réfléchis (mais comme dit précédemment, ce ne sont pas toujours des développeurs).

Cependant, ces dix développeurs ont pour but de créer quelque chose d'utilisable par tous. Ce n'est pas mon cas. Ce que je crée sert à très peu de personnes et la demande est réellement spécifique. Chaque métier étant différent. Un code n'a pas toujours besoin d'être réutilisé ou appliqué ailleurs. :?
Non, je ne prétends pas créer des codes ultra puissants (ça, ça se saurait :P), mais je pense pouvoir approcher de plus près la demande du client. ;)

---

Tu m'as pris de vitesse vermine, je suis tout-à-fait d'accord ^^

J'allais même faire cette métaphore dégoulinante :

Citation:

---

Envoyé par juste une parabole

MacDonald's possède une armée de nutritionnistes, de gouteurs, de consultants, etc.
Ca fait des années qu'ils affinent leurs "recettes".

Et sinon, en bas de chez moi, y'a un p'tit cuisinier qui improvise des plats originaux avec des ingrédients locaux et de saison. Il se débrouille d'ailleurs plutôt pas mal, avec une seule autre personne pour l'aider et des moyens financiers plus que limités.

Et chez qui on mange le mieux ? ^^

---

:mrgreen:

Citation:

---

Envoyé par sekaijin

Déjà je pense qu'avant de parler de lib ou de pas lib il faut se poser la question de l'approche générale.

on en distingue deux.
la première (et probablement celle par laquelle on commence tous) consiste à faire du HTML et à l'enrichir de fonctions (au sens large) JS
par exemple ajouter un bouton calendrier à un textfield pour avoir une saisie plus simple.
la seconde consiste à ne pas écrire de HTML et de construire les objets dont on a besoin en javascript. dans cette approche on va ajouter un datefield au form qu'on aura crée en javascript.

ces deux approche sont pour moi fondamentalement différentes.

---

Je suis d'accord sur la distinction que tu fais.
Je me demandais, par contre, quelle était la répartition entre ces deux cas, sur l'ensemble des projets web... ?
Mon expérience sur le sujet est encore trop légère, en plus je ne bosse plus en ce moment sur du web, alors je dois avoir une vision déformée, mais il me semblait que la deuxième catégorie que tu décris (des RIA de moyenne ou grande envergure) doit quand même représenter, aujourd'hui encore, une faible proportion, non ? :?

si on regarde le Web au sens site ou application sur HTTP/HTML alors les webapp ayant un approche RIA sont ultra minoritaire.

les webapps sont de toute façon minoritaires.
le gros du web ce sont des sites. (depuis maintenant longtemps leur mise à jour se fait via des webapps) mais cela reste pour l'essentiel dans la partie publique des site au sens classique du terme. (même s'il sot dynamiques)

les webapps les plus fréquentes sont les webmail comme yahoo mail ou celui que propose la plus part des hébergeurs des outil comme ceux de google etc.

et là force est de constater que depuis quelques années l'approche webapp pure et simple enrichie de js tant à disparaitre au profit d'application RIA.

en entreprise aussi on constate cette migration. mais là le choix du moteur RIA est beaucoup plus concurrencé par des plateforme dédié comme celle de microsoft ou adobe.

on a donc peut de webapp parmi tout les sites internet
peut de webapp RIA parmi les webapp
et dans ces dernières la proportion utilisant une approche enrichie face à une approche constructive est très difficile à connaitre.

on voit d'ailleurs côté librairies que le nombre de lib proposant une approche pour ce type d'application est plus réduit que les lib destinées à toutes sorte de sites web. d'un autre côté les sponsors de ses librairies sont des poids lourd de l'industrie qui investissent beaucoup de dans.
voici une liste des principaux d'une lib que je connais bien

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67

* Adobe * ADP * Airbus * Alcatel-Lucent * Alliance Data Systems * Amazon.com * Applied Physics Laboratory * Atos Origin * Aviva * BAE Systems * Bell Canada * Blackberry * BNP Paribas * BNSF Railway * Boeing * Borland * Canon * Capgemini * China Systems Corp. * Cisco * Citi * CNA * CNN * Credit du Nord * CSC * Dow Jones & Co. * EMC * Encyclopaedia Britannica * Ericsson AB * File Maker * Fox Interactive Media * Fujitsu * General Electric * Harvard Business School * Hitachi * HP * IBM * ISO Software Systeme GmbH * Komatsu * Kronos * Lehman Brothers * Lockheed Martin * Microsoft * Motorola * NEC System Technology * Nortel * Northrop Grumman * New York ISO * Pacific Corp * Panasonic * Pixar Animation Studios * Qualcomm, Inc. * Samsung * SAP * Siemens * Sun * Sony * Sony BMG * Symantec * T-Mobile * Thomson Reuters * Unisys * US Army * Visa International * VMWare * Xero * Yahoo

---

J'ai volontairement réduit drastiquement la liste des acteurs de petite et moyenne envergure

Il ne faut donc pas trop se focaliser sur le nombre de sites utilisant telle ou telle librairie pour savoir si elle est pérenne soutenue etc.

il est clair que les librairie qui vont dans ce sens ne sont pas faites pour ajouter un truc qui fait joli
si vous survolez la liste ci dessus vous comprendrez vite que les acteurs cités cherchent l'efficacité et donc on y trouve pas ou peu de fioritures.
même si elle sont élégantes et ergonomique les composant sont avant tout fonctionnels.

A+JYT

Bonsoir

Vouloir utiliser un framework JavaScript sans connaître les bases est un non-sens absolu et une perte de temps.

J'en ai déjà parlé ici (http://www.developpez.net/forums/d89...y/#post5106006) et là (http://www.developpez.net/forums/d95...s/#post5392670).

Les débutants qui commencent par jQuery sont non seulement une plaie (ils me découragent, car ils butent toujours dans les mêmes problèmes, généralement idiots), de plus ils nuisent à la réputation du langage et surtout à celle des interfaces utilisateurs "jQuery UI" et "UI jQuery Mobile" qui utilisées par eux ressemblent souvent à du grand n'importe quoi.

Dans un message récent, pour récupérer le jour de la semaine d'un UI Datepicker un utilisateur bien informé conseillait une transaction AJAX et du PHP ! http://www.developpez.net/forums/d10...v/#post5634820

En fait, on peut dire que HTML5 et CCS3 vont intégrer les bases d'un framework.

À mon avis, cela ne vous étonnera pas, l'avenir de jQuery est assuré.

je vais dans ton sens
je pense même que trop souvent on confond le langage et l'implémentation qui en est faite dans le navigateur

Oui Javascript est né du web et non il n'est pas né pour scripter le navigateur
Il est né côté serveur

mais Javascript est un langage et s'il est massivement utilisé pour scripter un navigateur et manipuler les pages HTML de celui-ci à travers le DOM, Il n'en reste pas moins un langage à part entière qui peut être utilisé dans de nombreux contexte.

ActionScript n'est rien d'autre que Javascript + des méthodes pour manipuler les objets flash
tout comme dans le navigateur on a javascript + le DOM binding
sous Windows Host Script nous avons javascript + JScript qui est un ensemble de méthodes et d'objets pour manipuler windows
Jaxer c'est javascript + des API pour manipuler les information d'un serveur web
Mod_js c'est javascript + des Api system pour manipuler les infos serveur sous apache (comme mod_php ou mod_tcl pour php et tcl)
etc.

bref javascript à un champ d'application bien plus large que le navigateur. et j'en ai mare de lire que javascript n'est pas fait pour ça. c'est comme dire que C++ n'est pas fait pour ...

javascript est un langage il peut donc s'appliquer à tout comme tout langage C et C++ on besoin de lib pour faire ci ou ça C# aussi pascal ada perl python php javascript java lisp aussi.

je dis à tous les débutant d'un langage quel qu'il soit. commencez par apprendre le langage lui-même.
puis penchez vous sur les librairies "Standard" fournies avec le contexte qui vous intéresse.
enfin penchez vous sur les framework qui s'appuient dessus.

Noté que le langage est normalisé par Ecma
la dernière version du langage http://www.ecmascript.org/docs/tc39-2009-043.pdf

alors que la liaison avec le dom est normalisé par le W3C

Javascript dans les produit adobe et pas seulement flash
http://www.ex-abstracto.com/index.ph...ement&rub=ECMA

javascript dans l'univers windows
http://msdn.microsoft.com/fr-fr/library/72bd815a.aspx

A+JYT

Ca me faisait penser à un truc durant certains entretient.

- "Alors tu dis avoir fait du JS ?"
- "Oui j'utilise jquery pour animer mes pages"
:calim2::calim2::calim2::aie::aie::aie:

Que voulez vous répondre à cela :aie: ?

Pour le PHP c'est un peu pareil, commencer un site from scratch (sans rien) avec le PHP c'est un peu suicidaire maintenant. Sauf si le mec veut coder de la merde. Mais si on veut du MVC ou autre, autant passer par un framework MVC

Bonjour,

Je ne suis pas d'accord avec le fait d'apprendre le JS avant le framework.
Au contraire.

J'ai commencé à la mano (sans aucune connaissance j'étais juste lycéen), donc c'est simple. Le code était moche (etc etc).
Plus tard, apparait jQuery que j'emploie donc sans grosse connaissance JS. Je ne connais pas les évènements, les objets qu'en c++like (en js c'est quand même pas pareil)...
Toujours est-il que le framework permet d'avoir un résultat rapidement. Ce qu'il faut soulever au delà de la rapidité, c'est qu'on peut voir que ce qu'on fait est à peu pres satisfaisant. Il ne tient qu'à approfondir les détails.

Si c'est pour apprendre les document.machin, les fonctions anonymes et tout avant d'arriver à un résultat, ca en rebute plus d'un.

Certains ici semblent vouloir comprendre ce qu'ils font. Personnellement, et je pense pas être le seul, certains préfèrent savoir ce que ca fait, quitte à éventuellement comprendre comment ultérieurement.

Pour revenir à la question : framework? ou composant mano?
Je pense que nous allons avoir droit à des composants js en interne, réutilisables. Mais je vois mal des composants génériques dispo pour tout le monde. Il y a trop de dev spécifiques pour une interface. Quand je vois extJS, c'est bien (enfin...) quand ca passe, mais bon, quand ca bloque, ca fait mal.
Eventuellement, à la manière des composants de framework, on peut imaginer des composants js.

Citation:

---

Envoyé par galerien69

J'ai commencé à la mano (sans aucune connaissance j'étais juste lycéen), donc c'est simple. Le code était moche (etc etc).

Plus tard, apparait jQuery que j'emploie donc sans grosse connaissance JS. Je ne connais pas les évènements, les objets qu'en c++like (en js c'est quand même pas pareil)...

Toujours est-il que le framework permet d'avoir un résultat rapidement. Ce qu'il faut soulever au delà de la rapidité, c'est qu'on peut voir que ce qu'on fait est à peu pres satisfaisant. Il ne tient qu'à approfondir les détails

---

Exactement ce que l'on ne doit pas faire ! Pour la rapidité et l'à peu près satisfaisant ! :fessee: :furieux:

Pauvre jQuery, comme on te maltraite et qu'elle réputation ont te fait ! :pleure:

Citation:

---

Envoyé par galerien69

Certains ici semblent vouloir comprendre ce qu'ils font. Personnellement, et je pense pas être le seul, certains préfèrent savoir ce que ca fait, quitte à éventuellement comprendre comment ultérieurement

---

Quand on est dans cet état d'esprit, le "ultérieurement" dont tu parles n'existe pas. Il y aura toujours une bonne raison de fuir en avant vers la prochaine idée... puis la prochaine. :no:

J'ai l'impression de lire dans ton post l'idée que :

Citation:

---

bricoler/bidouiller/tester (et hop ! c'est tombé en marche ne touchez plus à rien) sans comprendre les causes des phénomènes observés

---

serait plus rapide que :

Citation:

---

se référer aux docs et apprendre patiemment un certains nombre de fondamentaux liés à une technologie définie

---

?

Si c'est le cas, je te souhaite bonne chance mais j'en doute fort ^^ à la moindre difficulté inattendue, ça te laisse totalement démuni, à moins bien entendu de faire appel à... ? :roll: ... ceux qui ont construit leur maison correctement : les fondations en premier, les murs ensuite, et le toit à la fin :mrgreen:

Assez souvent le soir je raconte "les 3 ptits cochons" à mes filles... ben là tout d'un coup j'y pense à la morale de cette histoire, je ne sais pas pourquoi... :mouarf: ;)

Citation:

---

Envoyé par RomainVALERI

[...] Si c'est le cas, je te souhaite bonne chance mais j'en doute fort ^^ à la moindre difficulté inattendue, ça te laisse totalement démuni, à moins bien entendu de faire appel à... ? :roll: ... ceux qui ont construit leur maison correctement : les fondations en premier, les murs ensuite, et le toit à la fin :mrgreen:

Assez souvent le soir je raconte "les 3 ptits cochons" à mes filles... ben là tout d'un coup j'y pense à la morale de cette histoire, je ne sais pas pourquoi... :mouarf: ;)

---

Bonsoir Romain

Où alors ils ont la chance de tomber sur une bonne poire dans un forum !

Je suis certain que ce genre de forumeurs pensent qu'un forum s’est uniquement fait pour aider les débutants. Et que les modérateurs trouvent leur bonheur dans cette tâche ! Alors pour quoi prendre la peine d'apprendre !

À la lecture de ce genre de discours, la bonne poire se révolte, elle va se transformer en dragon cracheur de feu multicolore ! :furax:

On s'éloigne du débat de fond, mais cette attitude explique le pourquoi de mes réponses souvent laconiques ou minimalistes.
Le but de mes réponses étant de pousser le forumeur à chercher par lui même la solution en le mettant sur la voie ...
Apprends à l'affamé à pécher, il se nourrira toute sa vie, donne lui un poisson, il t'en redemandera toute sa vie !

Pour en revenir au débat qui nous intéresse, je pense que la différence principale réside en fait entre intégrateur et développeur.
Le premier se contentera d'avoir un truc bricolé qui fait illusion, le second poussera jusqu'a obtenir un résultat efficace et conforme.

Citation:

---

Envoyé par SpaceFrog

On s'éloigne du débat de fond, mais cette attitude explique le pourquoi de mes réponses souvent laconiques ou minimalistes.
Le but de mes réponses étant de pousser le forumeur à chercher par lui même la solution en le mettant sur la voie ...
Apprends à l'affamé à pécher, il se nourrira toute sa vie, donne lui un poisson, il t'en redemandera toute sa vie !

Pour en revenir au débat qui nous intéresse, je pense que la différence principale réside en fait entre intégrateur et développeur.
Le premier se contentera d'avoir un truc bricolé qui fait illusion, le second poussera jusqu'a obtenir un résultat efficace et conforme.

---

Je ne vois pas grand chose a ajouter , on se rejoint totalement sur ces derniers points :)

Citation:

---

Envoyé par SpaceFrog

Apprends à l'affamé à pécher, il se nourrira toute sa vie, donne lui un poisson, il t'en redemandera toute sa vie !

---

ça fait des temps que n'as plus cité celle la sur le fofo. :hola:

Citation:

---

Exactement ce que l'on ne doit pas faire ! Pour la rapidité et l'à peu près satisfaisant !

---

Parce qu'on pond forcément quelque chose de parfait du premier coup:lol:

Citation:

---

Pauvre jQuery, comme on te maltraite et qu'elle réputation ont te fait !

---

J'ai dit que jQuery permet d'obtenir des résultats acceptables sans grande connaissance du langage. Je n'ai pas dit qu'elle ne fournit que des résultats acceptables.
Pour la maltraitance, je reviens dessus après.

Citation:

---

Quand on est dans cet état d'esprit, le "ultérieurement" dont tu parles n'existe pas. Il y aura toujours une bonne raison de fuir en avant vers la prochaine idée... puis la prochaine.

---

Quel est le problème.
Si t'as pas besoin de comprendre ce que tu fais mais que c'est fait? Et de manière correcte (vu que déléguée à un framework).
Un exemple typique auquel j'ai été confronté :
Un composant extjs, avec un affichage à peu pres dynamique d'un combobox. Mon kiffe c'est pas extJS (comprendre je l'utilise parce qu'il faut, mais de manière locale (temporellement)).
Bon, jenquille un exemple à peu pres correct et après je look si ya des exemples qui me vont bien! Et sinon ben j'adapte.
Quelle idée d'apprendre les events extJS, les héritages des composants, etc...
Quand au problème du retour sur le code non compris, ben il ne reste plus qu'à le comprendre. Ce n'est que différer l'apprentissage de points NON fondamentaux à plus tard.

Et une dernière parenthèse:

Citation:

---

Le but de mes réponses étant de pousser le forumeur à chercher par lui même la solution en le mettant sur la voie ...

---

Celui qui poste sur un forum veut généralement un moyen pour trouver la solution. Tant qu'il a de quoi chercher il est généralement content. Sauf lycéen, éventuellement. C'est un point de vue que je partage particulièrement. Je le nuance néanmoins par la forme. "Les réponses minimalistes" ca présente une connotation péjorative. Si c'est pour brusquer le posteur (aussi con son poste soit-il), c'est anti-pédagogique, mais ca ne s'adresse pas à toi, c'est juste en guise de rappel.

Dernier PS:

Citation:

---

Apprends à l'affamé à pécher, il se nourrira toute sa vie, donne lui un poisson, il t'en redemandera toute sa vie !

---

La variante étant
Si tu donnes un poisson à un homme, il mangera un jour.
Si tu lui apprends à pêcher, il mangera toujours.
De lao tseu avec un accent circonflexe je crois mais chui pas sûr.

Salut à tous,

Pour répondre à la question originale. Le comportement du développeur Javascript lambda n'a pas changé d'un poil en dix ans. On a tous commencé à faire du Javascript copier/coller. Ce sont les sources disponibles qui ont changés. Avant nous n'avions que des snippets à disposition, maintenant les frameworks ont pignon sur rue, ce sont donc eux qu'on copie ou utilise à mauvais escient aujourd'hui.
Je ne sais plus qui a dit ça, mais Javascript est le seul langage de programmation qu'on n'apprend pas! Si vous avez correctement appris Javascript à l'école, c'est que vous en faite, je pense, depuis moins de quatre ans (estimation à vue de nez). Ce n'est que ces dernières années que le développement Javascript s'est professionnalisé, la création des frameworks en est justement l'illustration.

Comment développer? Cela dépend du projet. Un framework est fait pour industrialiser le développement et accessoirement pour lisser les comportements entre navigateurs. Il est bon d'industrialiser le développement sur de gros projets ou sur une quantité de petits projets. Même si, pour les petits projets, on peut parfois considérer l'utilisation d'un framework comme un luxe.
J'ai déjà vu certaines personnes utiliser un framework et sa surcouche graphique uniquement pour bénéficier d'un simple effet. Alors que tout le reste des scripts de l'application était développé sans tenir compte de ces frameworks! Dans ce cas là, je me dis que c'est comme acheter une librairie entière pour pouvoir lire un livre.
D'un autre coté, pourquoi se prendre la tête à réinventer la roue si on n'a aucune contrainte de performance et si ça ne fait pas de mal au client? Un développeur expérimenté aura, très probablement, déjà ses propres snippets sous la main et ne fera peut-être au final qu'un copier/coller (la boucle est bouclée) alors pourquoi pas utiliser un framework?

Ce qui compte finalement, je pense, c'est la compréhension de Javascript et du développement web en général. Ceci permettant de faire les bons choix.

Pour répondre à la suite du débat, le développement web est peut-être le type de développement le plus ouvert au "grand public". On aura donc toujours dans le forum des développeurs lambda rendant service à une association le temps d'un week-end. On ne peut décemment pas leur demander de tout comprendre du développement web avant de poster un message. Enfin je dis ça, mais je suis le dernier à répondre à ce genre de message. Curieusement, je me trompe peut-être, dans ce forum j'ai l'impression qu'il n'y a que des gens qui posent des questions et des anciens "désabusés" pour y répondre. Il manque la tranche du milieu, celle du développeur intermédiaire qui apprend et qui veut tester ses connaissances en répondant aux questions.

PS : galerien69 si tu fais ça de façon professionnelle, tu es sur la mauvaise voie. Si c'est de façon personnelle et pour le plaisir, fait comme bon te semble.

Citation:

---

Envoyé par galerien69

Si t'as pas besoin de comprendre ce que tu fais mais que c'est fait? Et de manière correcte (vu que déléguée à un framework).

---

Comment es-tu sûr que c'est correcte or que tu ne comprends pas même si ça marche (ça tombe en marche plutôt :aie:)? Il se peut que tu as des erreurs caché et qui ne seront découvert qu'au mauvais moment (c'est souvent comme ça les bug).

Citation:

---

Envoyé par galerien69

Quand au problème du retour sur le code non compris, ben il ne reste plus qu'à le comprendre. Ce n'est que différer l'apprentissage de points NON fondamentaux à plus tard.

---

Le truc que tu n'as pas pensé c'est que les corrections des defect sont plus couteux que de prendre le temps d'apprendre et/ou de comprendre ce qu'on va utiliser dans un projet. Bien que ça marche pour le moment, demain tu ne sais pas, et encore pire, il se peut que ce ne serait pas toi qui ferra la correction.

PS: je parle de façon général mais pas seulement au niveau javascript.

Ben typiquement, l'API dit que une fonction fait ca, on va pas chercher à savoir ce que fait la fonction. Si l'API de ton framework est merdique, bon ben faut changer de framework et mieux le choisir...
Même chose pour un exemple fournit. On prend pas les exemples qui viennent de nulle part.

Citation:

---

Le truc que tu n'as pas pensé c'est que les corrections des defect sont plus couteux que de prendre le temps d'apprendre et/ou de comprendre ce qu'on va utiliser dans un projet. Bien que ça marche pour le moment, demain tu ne sais pas, et encore pire, il se peut que ce ne serait pas toi qui ferra la correction.

---

ben ui, mais bon, je ne vois pas trop l'intérêt d'utiliser un framework si c'est pour le tester...
Perso, je préfère donner crédit à un exemple pompé du net qu'à un code non testé de quelqu'un qui connait le langage...

Toutefois une question : A qui s'adresse-t-on?
A celui qui n'a jamais codé donc du dev personnel, apprendre les rudiments, c'est long. Très long. Un framework, des exemples, c'est lui permettre d'avoir des résultats rapides!

Quid de votre première IHM. Codée mano? Quid de votre premier "vrai" programme, entièrement codé mano?

Enfin de manière générale, il faudrait définir ce que c'est apprendre le javascript.
A partir du moment ou on respecte les boites noires que sont les frameworks. Ou est le probleme???

OK, si vous dites que les frameworks peuvent merder, je passe mon tour.

Citation:

---

PS : galerien69 si tu fais ça de façon professionnelle, tu es sur la mauvaise voie. Si c'est de façon personnelle et pour le plaisir, fait comme bon te semble.

---

Tu as bien soulevé la différence dev personnel/professionnel.
Bientot je ferai ca de manière professionnelle. Et j'apprends un langage succintement avant de manipuler des choses plus complexes.

J'insiste sur le succintement.

Citation:

---

Envoyé par franculo_caoulene

Curieusement, je me trompe peut-être, dans ce forum j'ai l'impression qu'il n'y a que des gens qui posent des questions et des anciens "désabusés" pour y répondre. Il manque la tranche du milieu, celle du développeur intermédiaire qui apprend et qui veut tester ses connaissances en répondant aux questions.

---

Comment ? 8O :evilred:
>>> et moi alors ?! :mrgreen:
Je passe pas mal de temps à répondre aux messages quand je le peux, et ça représente finalement assez peu parmi tous les posts que je lis. Je suis très loin d'être un "ancien" voire un spécialiste, et ma motivation à 95% est effectivement d'en profiter pour apprendre un maximum (je ne suis d'ailleurs pas le seul*, mais même si je plaisante j'ai moi aussi observé la tendance que tu décris ^^)

* edit : tiens, la preuve que je ne suis pas le seul dans ce cas ^^ juste en dessous de ce post ;) salut vermine

Citation:

---

Envoyé par franculo_caoulene

Je ne sais plus qui a dit ça, mais Javascript est le seul langage de programmation qu'on n'apprend pas!

---

Peut-être, il n'empêche que ce n'est vrai que pour les gens qui ont étudié d'autres langages (je pense au C et ou au Java dans mon cas) avant de se lancer dans le Javascript. Il y a une logique à apprendre.