IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Où va-t-on avec JavaScript ?
Participez au débat sur l'orientation actuelle et le futur de JavaScript

Le , par le_chomeur
317 commentaires

40PARTAGES

4  1 
Bonjour a tous , cela faisait un moment que je n'avais pas posté

Depuis quelques temps , je remarque une évolution des comportements vis a vis de JS , de plus en plus d'utilisateurs viennent ici pour comprendre / modifier des scripts existant en fonction de leur besoins, et bien souvent ces scripts sont basé sur des librairies / framework.

d'ou ma question , concrètement pensez vous continuez à coder comme nous le faisons aujourd'hui en repartant de zéro ( Spaffy si tu m'entends ) ou vous même passer a du full librairie pour vos dev , même les plus minimes ?

en apparté pour ceux qui ont commencé a s'y intéresser , vos retours sur l'html 5 / css3 et toutes les nouvelles fonctionnalités introduites par ceci au seins de javascript.

cdt,

Le_chomeur

Une erreur dans cette actualité ? Signalez-nous-la !

317 commentaires
Commenter Signaler un problème
pomeh
Avatar de pomeh
Nouveau membre du Club https://www.developpez.com
Le 07/01/2011 à 1:06
Bonsoir à tous

Je viens de voir passer ce sujet dans mon lecteur de flus RSS seulement aujourd'hui alors qu'il a été créé depuis un petit moment, alors je suis désolé mais je vais reprendre quelques citations de commentaires plutôt anciens mais auquel j'ai envie de répondre.

Pour moi, Javascript est un langage qui parait être pour les "rigolos" mais qui mériterait vraiment que plus de développeurs s'y intéressent. Je vais essayer d'expliquer pourquoi je penses ça.

Citation Envoyé par SpaceFrog Voir le message
Pour le durable il vaut mieux maitriser le langage et le code afin de pouvoir apporter les modifications nécessaires en cas de besoin.
[...]
Le framework reste ou outil de confort et de simplification du code mais ne dispense pas la maitrise des bases.
Citation Envoyé par squelos Voir le message
Effectivement, l'utilisation d'un framework peut faire gagner du temps lors du développement, mais si après il faut maintenir l'application à jour, beaucoup plus de temps risque d'être perdu dans du deboggage à cause d'une erreur de documentation du framework ou autre problème dû à l'utilisation d'un framework.
Il vaut mieux maitriser le code, je suis d'accord. Mais rien ne t'empêche de maitriser une ou plusieurs librairies et de maitriser tout aussi bien le code De plus, c'est bien que TU (au sens général) maitrise ton code, mais si tu es en entreprise et que tu décide de changer d'entreprise (ou bien si tu te fais gentillement remercié), tu t'en va avec la maîtrise de ta librairie et le développeur qui va prendre le relais risque d'avoir du mal à s'y retrouver (au début en tout cas).

Je te rejoins sur le deuxième point. Les librairies JS rendent le Javascript plus facilement accessible, c'est très bien pour la démocratisation du langage, mais ça devient tellement accessible qu'on a plus besoin de connaître le langage pour faire du Javascript, ce qui mène rapidement et simplement vers du code vraiment pas beau. Il est primordial, à mon sens, d'avoir pratiqué le Javascript "pur" afin de comprendre les fondamentaux du langage, sans quoi il peut paraître "magique" ou "horrible" dans certains cas (magique quand ça fonctionne mais qu'on ne sais pas pourquoi, horrible quand ça ne fonctionne pas mais qu'on ne sais pas pourquoi non plus !!).

Citation Envoyé par dukej Voir le message
Chaque fois qu'on utilise $, on récupère un wrapper, qu'on ai 0, 1 ou N éléments ce n'est pas un soucis et on a pas à s'en soucier.
Si un peu quand même... T'es censé savoir dans la limite du possible si tu travaille avec 1 élément ou N éléments... Quant à 0 élément, si t'as du code qui travaille avec des collections vides, c'est généralement mauvais signe, et en cas de doute tu as un moyen simple de faire tes vérifications

Citation Envoyé par dukej Voir le message
Cette librairie n'étends pas les types primitifs de base comme Array ou String ou autre
Ça, c'est plutôt une bonne chose, et est une force de jQuery ! L'approche du wrapper est bien plus souple et propre
Pour ceux que ça intéresse, un petit article expliquant ce point de vue: http://perfectionkills.com/whats-wro...nding-the-dom/

Citation Envoyé par dukej Voir le message
Son gros défaut :
Il n'y a rien pour proposer la possibilité de faire de la Poo simple comme la création de classes, de l'héritage (extends) ou de l'implémentation (implements). c'est dommage.
C'est dommage, pas tant que ça au final. L'héritage c'est bien, mais Javascript propose des techniques qui permettent de s'en passer. Je vous laisse regarder cet article qui explique comment: http://javascriptweblog.wordpress.co...in-javascript/
Mais si tu tiens vraiment à faire de l'héritage avec Javascript, il y a quelques exemples sur le Web qui ne font pas pas plus de quelques lignes de codes et qui fonctionnent parfaitement

Citation Envoyé par dukej Voir le message
J'ai fait énormément de développements sans librairies, codé des effets, des libs ajax. Mais au final, on gagne un temps fou quand on développe un site avec une libraire.
Même si j'ai énormément d'expérience dans la compatibilités internavigateurs (surtout IE6 :/), au final une lib c'est le bonheur.
Tout à fait d'accord, les librairies te font gagner du temps.

Citation Envoyé par dukej Voir le message
Mais au final, j'écris mes objets de manière à ce qu'ils fonctionnent sans librairie.
C'est ce qui devrait être fais tout le temps ça, découpler au maximum son code afin de le rendre modulable. Un exemple de découplage, très orienté jQuery mais néanmoins intéressant, a été publié par Rebecca Murphey sur son blog.

Citation Envoyé par vermine Voir le message
Non, je ne prétends pas créer des codes ultra puissants (ça, ça se saurait ), mais je pense pouvoir approcher de plus près la demande du client.
Je ne vois pas en quoi l'utilisation d'une libraire t'empêche d'approcher également au plus près de la demande du client. Les libraires rajoutent des fonctionnalités ou les harmonisent, mais ça reste du Javascript, donc si quelquechose dans la librairie ne correspond exactement à ce que tu veux, tu peux toujours la refaire

Pour terminer sur le point des librairies, je dirais qu'il est bien de savoir les utiliser de manière correcte. Savoir quand on peut s'en passer, savoir quand cela nous fera gagner du temps et/ou nous permettra d'assurer la longévité d'un projet. Parce que la grande différence entre les libraires que chacun bricole de son côté, et les libraires tel jQuery, c'est quelles sont et resteront pérène pendant encore un sacré bout de temps. Il y a une communauté de développeurs et d'utilisateurs derrière tout ça, chacun amène ses idées, reporte ses bugs, donne son avis etc, et on sait bien que l'union fais la force. Les projets sont documentés et régulièrement mis à jour, c'est important aussi. D'une manière générale, si tout le monde fais sa propre librairie, ça peut vite devenir compliqué lorsque plusieurs développeurs travaillent ensemble. Ou bien même lorsqu'un développeur d'une libraire "perso" quitte son entreprise, il a intérêt a avoir bien documenté sa chose sinon c'est le casse-tête assuré pour ceux qui restent (j'en ai fais les frais, et croyez-moi, la perte (en temps, et donc en argent) peut vite être considérable selon la taille du projet). Les libraires sont un gain de développement certain, mais cela n'empêche pas de les utiliser avec parcimonie, et surtout, surtout, celà n'empêche pas d'apprendre le Javascript avant toute chose.
Je ne suis pas particulièrement pour que chacun écrive sa propre librairie, car peut-être que ca VOUS fera gagner du temps lorsque vous developperez, mais ça en fera surrement perdre beaucoup plus lorsque vous ne serez plus là et qu'il faudra débugger/maintenir la chose. L'avantage du framework sur ce point, c'est que tout le monde parle le même "langage" (pas au sens Javascript, au sens outil/framework), donc tout le monde peut comprendre relativement facilement le code qui a été écrit par un autre. Une exception à cette remarque quand même, lorsqu'il s'agit d'un développement vraiment spécifique, il peut-être mieux d'avoir son propre code plutôt que celui d'une librairie.

Pour moi, et pour beaucoup d'autres, l'année 2010 a été l'année du Javascript, et ce n'est pas fini. Des tas de projets ont été lancés ou propulsés au cours de cette année.
Je penses notamment à Node.js, qui permet d'amener Javascript côté serveur. Ce n'est pas le premier projet à faire ça, mais c'est le premier a avoir autant de succès. Et il est désormais possible et simple de créer un site Web / application Web uniquement grâce à Javascript.
Je penses ensuite aux nombreuses démos que l'on a vu sortir ici et là, montrant des utilisations de HTML5 et CSS3, avec le Canvas, l'audio, la vidéo et j'en passe.
La sortie d'IE 9 et les démos de Microsoft pour vanter son navigateur, toutes repoussant les limites du navigateur via Javascript.
Les navigateurs d'ailleurs, qui font tous de plus en plus d'efforts pour avoir des interpréteurs Javascript de plus en plus rapide. Les frabricants se concentrent de plus en plus sur 2 choses: le respect des standards, et la vitesse d'exécution du Javascript. Ce n'est pas pour rien.
La communauté Javascript ensuite, qui essaye de redorer l'image du langage via une campagne de Google bombing-like pacifique. Il y a également eu plusieurs concours Javascript et de nombreuses conférences durant l'année.
Le Web 2.0 fait naitre de partout des applications web, et non plus des simples sites web. C'est applications font pour la plupart appel au Javascript pour rendre les choses plus interactives.

Qui utilise la version HTML de Gmail ?

Liens divers concernant des applications Javascript:
http://blog.rebeccamurphey.com/on-jq...e-applications
http://blog.rebeccamurphey.com/on-rolling-your-own
Recommend Tools And Resources For JavaScript Developers: Issue 1
Building Large-Scale jQuery Applications
The Tech Behind the New Grooveshark
7  0 
sekaijin
Avatar de sekaijin
Expert éminent https://www.developpez.com
Le 23/07/2013 à 10:30
Bonjour.

Je ne suis pas entièrement d'accord quand je lit que JS ne c'est pas imposé grâce à ces caractéristiques techniques.

Je pense que au contraire ce sont ces caractéristiques qui on fait que JS c'est imposé.

Nous avons un peu trop tendance à juger JS par rapport au besoin d'aujourd'hui. A savoir construction d'IHM complexe, traitement plus ou moins lourd, manipulation de données structurées, etc.

Mais JS n'a pas été créé dans cette optique et là n'était pas le besoin. au départ JS est côté serveur et le besoin s'apparente plus à ce que permet sh/bash que python/C++. en effet l'usage principal d'un script (sh) c'est de positionner quelque variable appeler quelques exécutables de façon contrôlée. pas besoin de définir des structures complexe et répétitives. c'est bon pour un programme plus lourd que de devoir instancier une douzaines d'objet faire un ls -1 | tr 't' 'd'.
Mais est-ce une raison pour faire l'impasse sur les avancées dans le domaine des langages ? je pense que les ingénieurs de Netscape pensaient comme moi que non. Il ont donc cherché le meilleur modèle possible. les langage à base de classe c'est lourd c'est verbeux et ça ne réponds pas (mal) au besoin. Mais la notion d'objet est intéressante.
le monde de la théorie des langage est suffisamment vaste pour pouvoir faire son marcher et un langage à base de prototype est plutôt bienvenu. (même si aujourd'hui les développeurs ne le comprennent pas tous).

mettons nous dans le contexte nous avons des serveurs qui utilise cgi (ou dérivé) pour faire exécuter un script généralement du sh du perl ou du tcl. (php est venu juste après) le premier point à régler fut la séparation de cgi et du serveur. on a eut droit à pas mal de truc. il y a bien eu des gens pour faire ça en C ou C++ mais mise à part la compilation ça n'a rien apporté et dans le contexte mieux valais un shell qui appelle des execs C++ qu'un gros prog en compilé. plus souple à maintenir (le web est très volatile) pour quoi ni sh/bash/perl/python n'a pris l'ascendant ?
il fallait un langage qui embarque dans sa structure la capacité de s'adosser à un serveur. TCl de ce point de vu à été un bon candidat l'API C de TCL est simple légère à mettre en oeuvre et permet une interaction poussée entre le script et son hôte. Mais TCL est un langage ancien et même s'il reste très performant il ne connait pas la notion d'objet (bien qu'elle lui ai été ajouté)

bref js est techniquement un très bon compromis. l'histoire à montré que php (côté serveur) était un bon candidat.
on peut noter que la notion d'objet bien que radicalement différente entre php et JS a des similitudes. l'un est à base de classe l'autre à base de prototype. mais l'un comme l'autre on une structure d'objet construite sur une hashMap. et cela apporte beaucoup de souplesse (mais fait perdre des cheveux à certains)

Lorsque JS est passé côté client c'est une de ses caractéristique technique qui a fait son succès. le fait que JS est construit pour être adosser à une exe (le navigateur). cette caractéristique à permit très vite d'avoir accès de façon organisée (pas encore standardisé) à toutes les parties du navigateur. le navigateur lui-même, la fenêtre, la page, le document et tous les éléments qui le compose. et c'est là que pour moi JS de part ces caractéristiques techniques c'est imposé. le modèle prototype à là montré qu'il était très efficace. avec un noyau minuscule une empreinte sur le navigateur réduite JS à complètement ouvert le navigateur au script.

Il y a eut VB mais aussi bien d'autres. je pense que JS c'est imposé face à lui pour plusieurs raison. l'une d'elle est la faible empreinte dans le code de l'hote. l'autre son modèle objet très souple, et pour finir la relative concision de sont code (moins verbeux que VB)
pour ce qui ne relève pas de la technique JS a d'entré de jeu était implémentation par qui le voulait (il fallait tout de même écrire son moteur) VB est lui propriétaire. même si ce n'est pas très évident la syntaxe est simple et facile à apprendre (je parle ici de JS pas du DOM ni des objet du navigateur en gros ecmaScript) il ne nécessite pas d'outillage particulier un bête éditeur de texte.

après des années et l'évolution des besoins je lis bien trop souvent que JS à besoin de structure de classes de compilation de typage fort etc. si je reconnais que les besoin en termes d'IHM de structure de données ont changés. je ne suis pas d'accord avec ces assertions. Si vous pensez cela alors vous n'avez pas choisi le bon langage. Je pense au contraire que JS doit garder la souplesse de son modèle objet, maintenir et améliorer le transtypage. Je pense que passer du prototype aux classes de l'interprétation à la compilation (JS est déjà compilé à la volée par les moteur d’exécution) passer à un typage fort c'est la mort assurée pour JS.

Y a-t-il un nouvel espace qui se crée pour une autre technologie à côté de JS ? possible, Mais tout comme C/C++ n'a pas remplacé SH/BASH je pense que le besoin de script existera encore longtemps dans ce contexte et que ce ne sont pas les langages compilés au typage fort qui sont les mieux placé dans ce domaine.

A+JYT
5  0 
dtcSearch
Avatar de dtcSearch
Membre actif https://www.developpez.com
Le 05/01/2011 à 10:25
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).
4  0 
Willpower
Avatar de Willpower
Membre expérimenté https://www.developpez.com
Le 28/10/2011 à 13:55
Citation Envoyé par Lcf.vs Voir le message
Bien que je me doute que Bovino n'ai dit cette phrase dans ce sens, c'est vraiment l'argument (très souvent le seul) des fans de JQuery qui me hérisse le poil.

En effet, au niveau du nombre de ligne à coder soi-même, on constate une différence flagrante, néanmoins, ce à quoi ces fans pensent moins, c'est au nombre de lignes contenues dans leur bibliothèque/framework, afin de leur permettre de faire ceci ou cela.

Faites la somme du code de la lib' + celles pour l'utilisation que l'on veut en faire et on arrive généralement à bien plus qu'en codant en pur.

Pareillement, en terme d'optimisation de ressources nécessaires pour l'exécution d'une fonctionnalité, la lib' va tester et instancier plein de choses dont on se passerait très bien.

L'autre chose qui me fait bondir, c'est le fameux "bah, 50Mo de cache, de nos jours, c'est rien du tout".

Pourquoi? Les connexions internet sont de plus en plus rapides et on a de plus en plus de volume (voire illimité), ok... Néanmoins, ce n'est pas la seule réalité!

Perso, j'accède à internet via une connexion mobile (down : ~80Ko/s et volume : 2Go/mois). De plus, la plupart des développeurs sont en hébergement mutualisé où la gestion du cache est, dans la plupart des cas, hors des possibilités de personnalisations et, du coup, on se retrouve avec une lib' qui est intégralement chargée à chaque page!!!

Heureusement que nous ne sommes pas encore aux connexions en To/s, sinon, on aurait des lib' en gigas et je ne verrais jamais une page complète, avec un seul forfait.

Autre point non-évoqué, bien que JQuery soit connu pour ses optimisations, je remarque presque chaque jour sa grande faiblesse au niveau de la gestion des connexions internet faibles/instables. "le script ne réponds plus..."

Enfin, une anecdote assez cocasse qui illustre ce que certains font de JQuery. J'ai visité les réalisations d'une boîte de dev, dans le cadre de mes recherches d'emploi et suis tombé sur une lightbox, en plein milieu de l'écran m'avertissant que l'auteur du site web n'a pas payé la licence du plugin JQuery utilisé et me demandant de le contacter afin qu'il paie pour que je n'aie plus à voir ce message.

La méconnaissance de ce que les gens utilisent, ajoutée au caractère ésotérique souvent retrouvé en JQuery fait que les gens ne savent même pas ce qu'ils importent et, donc, s'il est possible de se retrouver dans ce genre de situations, il l'est tout autant pour du code dangereux (servant à du vol d'informations, de comptes, etc.).
Je crois que tu n'as jamais du coder de fichier de plus de 20 lignes de ta vie pour dire autant de *****.

Effectivement, pour les mini bout de code, tu peux t'amuser à faire du js pur et si tu utilises jquery tu auras autant voir plus de lignes en nombres.... sauf que tu n'auras du en écrire que quelques-unes toi-même et donc tu y auras passé 10 fois moins de temps pour un résultat aussi perfomant.

Tu parles de 50 mo puis de lib en giga .... jQuery fait 31 ko. Et non la lib n'est pas intégralement chargée sur chaque page, même sûr les smarphones, elle reste dans le cache, à mon que tu n'aies réglé le header expressement pour interdire le cache. Et si bien même tu avais un hebergeur mutualisé qui empeche le cache, tu peux lier la lib sur un lien externe comme le font beaucoup sur le site de google code par exemple.

Je n'ai non plus jamais vu jQuery faire planter une site, tout au mieux une mauvaise utilisation de jQuery faire planter le site, mais le gars incapable d'utiliser jQuery, fera encore plus d'erreurs en JS pur.

Enfin, ton anecdote n'a rien à voir avec jQuery, si tu vas sur des sites aux plugins douteux, merci de ne pas tout mélanger.

Bref, même si je reconnais que jQuery n'est pas l'outil indispensable, et d'ailleurs je ne l'utilise pas systèmatiquement, je n'ai vu aucun contre-argument valable dans ton paté. Dommage.
4  0 
Watilin
Avatar de Watilin
Expert éminent https://www.developpez.com
Le 23/07/2013 à 1:10
Citation Envoyé par ymoreau Voir le message
(coup de bol qu'on soit tombés sur Javascript plutôt qu'autre chose peut être ).
En effet, ça aurait pu être VBScript
4  0 
danielhagnoul
Avatar de danielhagnoul
Rédacteur https://www.developpez.com
Le 18/05/2014 à 1:18
Bonsoir

J'ai trouvé une opinion intéressante, malheureusement en anglais, sur l'inflation des "frameworks" et le devenir du JS

En bref (ce n'est pas une traduction du texte, juste un reflet, les opinions auxquelles j'adhère de plus en plus) :

Oublions les mésaventures provoquées par les navigateurs obsolètes et mettons à la poubelle les rustines développées pour pallier leurs insuffisances.

En 2014, avec l'évolution des codes (HTML5, CSS3, JS ES6) et l'évolution des navigateurs dignes de ce nom, il est devenu plus intéressant d'utiliser le JS que de s'enfermer dans le carcan d'un "framework" aussi bon soit-il.

Il faut bien distinguer une "library" (code effectuant une tâche précise), qui sera toujours utile, d'un "framework" qui vous impose une manière de penser donc de coder.

Idem pour l'UI, les nouveaux standards permettent la création d'éléments réutilisables (Web Components). Pour l'instant plusieurs techniques nécessitent encore l'usage de "polyfils".

Quelques liens utiles :





4  0 
SpaceFrog
Avatar de SpaceFrog
Rédacteur/Modérateur https://www.developpez.com
Le 08/12/2010 à 8:39
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.
3  0 
druith
Avatar de druith
Membre du Club https://www.developpez.com
Le 05/01/2011 à 11:50
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.
3  0 
Avatar de
https://www.developpez.com
Le 18/05/2011 à 11:08
un petit exemple de ou on vas avec javascript

une emulation d'un pc 486 sous linux directement dans le navigateur

http://bellard.org/jslinux/
3  0 
zevince
Avatar de zevince
Membre averti https://www.developpez.com
Le 25/10/2011 à 17:09
juste pour ajouter mon grain de sel dans l'histoire..

Pour moi les deux principaux avantages de jquery sont :
- ne pas ré-écrire des fonctions existantes et probablement mieux écrites que ce que je pourrais faire moi même
- avoir un comportement très proche sur toutes les plateformes, y compris mobiles et tablettes tactiles (mis a part les soucis d'event click / touch, mais si j'ai bien compris ça devrait être pris en compte bientôt aussi)

Pour le coup du plugin payant, c'est une énorme arnaque déjà, car la majorité des plugins payants sont des plugins gratuits avec une couche de design en plus.. ou quelques fonctionnalités qu'on peut ajouter soi même quand on comprend ce qu'on utilise.. Payer pour un plugin jquery me semble absurde.. !

Pour la qualité du framework en lui même, je l'utilise depuis 6 ans environ et a chaque fois que j'ai cru a des bugs venant de jquery, c’était en fait moi qui l'avait commise, l'erreur.. Alors oui, on a plus de contrôle quand on fait du js "pur", mais qui peut se permettre de prendre 2 mois pour une application complexe en javascript qui serait faite en 1 semaine avec jQuery ? D'autant que ca n'a jamais empêché les bugs, voire même au contraire, vu qu'il faut vraiment tester chaque navigateur / système / plateforme

Enfin bon, il y a des avis assez tranchés ici.. En php par exemple, je ne suis pas fan de frameworks, même si je travaille en MVC et qu'en théorie, ils devraient me convenir.. Mais prenez le recul et constatez le magnifique travail de l’équipe de jquery.. En toute objectivité, c'est dur de prétendre que c'est nul !

Quant à l'optimisation.. Oui, on la maitrise plus en javascript classique.. Encore faut il suffisamment expert pour en tirer profit ! Et ca ne garantit rien du tout au niveau des performances et de la rapidité de l'application, que ce soit jquery ou javascript

En tout cas pour avoir pratiqué js depuis 1998, je peux vous affirmer que jquery c'est quand même une belle évolution pour les développeurs webs et un souffle d'air pour les graphistes ! c'est une dynamique intéressante, qu'on utilise ou pas l'outil !

Ah et comme je répondais aux messages ci dessus plutôt qu'au sujet lui même..
Avec html5 et les avancées du langage depuis quelques années, ca ne m’étonnerait pas tant que ca que js devienne un langage de plus en plus populaire.. le remplacement de flash est en cours, et ca ne s’arrêtera pas la.. !
3  0 
Commenter Signaler un problème