Quels sont les avantages du développement JavaScript natif?
Compte tenu de la simplicité du développement de jQuery, par rapport au JavaScript natif, qu'est-ce qui pousse les gens à renoncer à des bibliothèques comme jQuery?
Est-ce parce que jQuery a des limites ou est lent? Je veux dire, si jQuery est si facile par rapport au javascript natif, quelles sont les raisons pour lesquelles les gens doivent toujours utiliser du javascript pur?
Parlons des voitures.
Oh, attendez, nous l'avons déjà fait - rappelez-vous cette fois où nous nous sommes rencontrés, il y a quelque temps? Nous avons parlé des voitures. En fait, vous sembliez être un grand expert des voitures. Vous avez pu expliquer, en détail, tout ce qui est bien, mal et passionnant à propos de la dernière course de Formule 1. Vous connaissiez par cœur tous les modèles Lamborghini, y compris leur prix et leur disponibilité. Vous avez même pensé à acheter votre propre Ferrari 599 GTB Fiorano et vous économisiez pour cela (je parie que le dîner de steak n'a pas beaucoup aidé).
Tout en expliquant les défauts de Toyota d'une grande voix excitée, vous avez soudainement sauté de votre chaise et hurlé dans les airs en agitant les poings: "Merde, je suis un magnifique expert de tout ce qui touche aux voitures! Je ' je vais devenir mécanicien! "
Et vous y êtes donc allé. Vous avez eu une interview, le Boss Man a été tout aussi impressionné que moi par vos connaissances et vous avez été embauché. Le premier client est entré. Son embrayage était cassé. Vous l'avez inspecté et ne saviez pas quoi faire. En fait, vous ne saviez absolument pas comment suivre les conseils du Boss Man. Vous avez été viré.
Mais comment est-ce possible!? Vous savez tout sur les voitures! Sauf pour ... tout sur les voitures. Vous pouvez très bien savoir que votre voiture de rêve a un moteur V12, mais vous ne savez pas ce que cela signifie réellement.
Vous n'êtes donc pas un mécanicien automobile, vraiment - vous êtes un passionné de voitures. Et jusqu'à ce que vous appreniez comment fonctionnent les voitures , vous resterez un passionné.
Maintenant, laissez-moi vous demander. Comment fonctionne $.fn.text? Et qu'en est-il de $.fn? Que signifient-ils vraiment? Comment $(something) renvoie-t-il un truc gigantesque contenant des choses, et quel est ce truc exactement? Pouvez-vous reproduire leur fonctionnalité, au moins un peu, en théorie même? Pouvez-vous faire face sans jQuery?
Dire que "JavaScript natif est difficile" est juste ... faux. D'abord et avant tout, parce que JavaScript en tant que langage n'a rien à voir avec le DOM , qui est principalement ce que jQuery résume. Deuxièmement, une fois que vous en apprendrez un peu sur le DOM, vous pouvez déjà parcourir les bogues les plus courants entre les navigateurs. Mais juste un petit secret - tout est difficile au début. La longue division était une chienne en 5e année.
Comme deuxième analogie pour cette réponse: jQuery est à JavaScript-DOM (pas JavaScript la langue, juste le DOM) comme Array.prototype.forEach Est à for. Cela fonctionne, pour 99% des cas. Et ça marche bien. Mais pour ce 1% qui n'est pas couvert, vous avez besoin de savoir comment utiliser la boucle for, ne serait-ce que pour être pratique . Toute cette réponse est basée sur le côté "plus pur" de la question, et pas même sur le côté technique (la taille de la bibliothèque, par exemple, et plusieurs autres choses comme expliqué dans la réponse de Michael Dorrant). Parce que j'aime JavaScript et que les gens semblent le mettre de côté avec désinvolture en disant "pah, ces javascriptians idiots" et en agitant des gants blancs fantaisistes, cela revient à la morale.
Si vous pouvez accepter le fait que vous serez toujours un passionné de JavaScript, alors qui suis-je pour vous arrêter? Mais si vous voulez être un programmeur JavaScript, vous devez d'abord avoir la connaissance d'au moins choisir entre utiliser jQuery (ou toute autre bibliothèque) et non en utilisant une bibliothèque. Apprenez le DOM. Apprendre comment l'utiliser. Écrivez votre propre petite bibliothèque ou juste une collection de fonctions d'assistance. Et une fois que vous connaissez le DOM et que vous choisissez d'utiliser jQuery - godspeed. La paresse est décernée à ceux qui ont travaillé dur.
Raisons que je connais:
Lorsque le besoin est extrêmement minime, disons 1 clic.
Lorsque la vitesse de téléchargement est critique et que la bibliothèque jQuery est trop grande ET que vous n'avez pas besoin d'écrire beaucoup de code (personnalisé) pour le remplacer.
Lors de l'intégration avec d'autres technologies, le js brut est parfois meilleur.
Lorsque vous travaillez sur un système hérité (alias "production") déjà écrit en js avec des modèles établis.
jQuery est simplement un framework - un ensemble d'outils écrits en JavaScript. En utilisant cet ensemble d'outils, vous utilisez toujours JavaScript. Certaines personnes préfèrent écrire JavaScript à l'aide des outils fournis par jQuery, d'autres choisissent de ne pas le faire, d'autres choisissent d'autres ensembles d'outils.
Quelques raisons pour lesquelles vous voudrez peut-être écrire du JavaScript "pur" sans jQuery:
- Les pages se chargent plus rapidement sans inclure de fichiers jQuery supplémentaires
- Certains frameworks peuvent être incompatibles avec jQuery
- Le code en cours d'écriture ne fait rien que jQuery aide à
- Le code est en cours d'écriture pour que d'autres l'utilisent, et exiger jQuery comme dépendance rendrait le partage plus difficile
- L'auteur du code veut plus de contrôle que jQuery ne le fournit
jQuery, comme toute bibliothèque ou framework, en ajoute un autre couche de bugs . J'adore ça, mais j'ai aussi perdu une journée à chercher un bug qui s'est avéré être dans le noyau jQuery et non mon code (une rare occasion, mais pas si rare).
A part ça, je ne trouve aucune autre raison de ne pas l'utiliser:
- Les frais généraux sont minimes, surtout si vous optez pour la version Google hébergée ,
- Il aide les développeurs Javascript moins expérimentés à écrire du code plus propre et plus efficace,
- C'est principalement multiplateforme, ce qui peut vous sauver la vie lorsque vous devez gérer des navigateurs plus anciens,
- L'énorme galerie de plugins m'aide à écrire des prototypes en très peu de temps,
- Le DOM a du sens,
- bla bla bla ...
MAIS il ne doit jamais être utilisé comme substitut de la connaissance Javascript. Si vous ne savez pas comment le faire en Javascript pur, vous pouvez vous en sortir avec une bibliothèque au départ, mais à long terme, vous allez payer pour cela.
Et bien sûr, nous sommes tous impliqués dans des combats mortels avec IE6 depuis plusieurs années et ne lâcherons pas facilement nos trucs de la vieille école en faveur d'un nouveau jouet brillant.
Dans l'environnement du navigateur, vous avez besoin d'un outil de normalisation multi-navigateur. Un tel outil se décline en deux versions
- encapsule les objets Host avec de nouveaux objets qui se comportent de la même manière dans les navigateurs
- étendre les objets Host pour implémenter l'API DOM.
En général, vous pouvez utiliser ces utilitaires de trois manières
- utilisez de petites fonctions comme
addClassousetTextdans tout votre code quand et où vous en avez besoin - écrire votre propre bibliothèque de normalisation multi-navigateurs
- utiliser un existant.
Vous avez besoin d'un mécanisme de normalisation, sinon vous ne bénéficiez d'aucune prise en charge multi-navigateurs.
Quant à utiliser un existant, c'est très bien. Je n'utiliserais simplement pas jQuery. Personnellement, j'écris actuellement ma propre bibliothèque ( DOM-shim il corrige les navigateurs sans exposer une API de propriété étrangère. Il transforme vos navigateurs en un seul navigateur normalisé bien comporté).
Si vous n'avez pas besoin de l'abstraction DOM, de la prise en charge de plusieurs navigateurs et de navigateurs hérités - vous pouvez facilement vous passer de jQuery.
C'est le cas lorsque vous développez des extensions de navigateur, des scripts greasemonkey (parfois), des trucs chiffrés, que vous développez pour Node.js ou d'autres environnements sans navigateur.
Je dois préfacer ma réponse avec une honnêteté ouverte. J'adore jQuery. Cela me facilite énormément la vie et rend le code JavaScript plus déclaratif, c'est ainsi que je pense que les choses devraient fonctionner.
jQuery fait beaucoup de choses…
Oui vous pouvez ajouter des plugins
Oui vous pouvez étendre les sélecteurs
Oui cela simplifie l'animation
mais jQuery ne fait pas tout
Avez-vous déjà essayé de travailler dans plusieurs contextes de fenêtre avec jQuery? jQuery aspire à gérer différents contextes de fenêtre car il conserve le contexte window et document d'origine de la fenêtre dans laquelle ça s'appelait.
J'ai écrit du code ici et là pour faire des popouts *, et jQuery peut simplement entraver ce que j'essaie d'accomplir. L'ajout d'une nouvelle référence à jQuery dans la fenêtre enfant peut souvent aggraver les choses en rendant plus difficile de savoir quel contexte jQuery est utilisé.
* pensez au pop-up de Gmail pour avoir composé un e-mail dans une nouvelle fenêtre, pas de publicité spam
Utilisez-le quand il simplifie le code
Le moment d'utiliser jQuery est le moment où vous pouvez rendre votre code plus simple, plus court, plus lisible et plus rapide.
Le temps pour pas utiliser jQuery est quand il ne rendra pas votre code plus simple, plus court, plus lisible ou plus rapide. Si vous devez affiner les horaires de chargement, vous ne souhaiterez peut-être pas utiliser jQuery en raison de la surcharge de l'événement.
Comme vous le savez, jQuery est un framework à usage général qui fournit de nombreuses méthodes que beaucoup d'entre nous n'utilisent pas dans nos projets. (Certains d'entre eux, je ne les ai pas utilisés du tout.)
Il y a deux raisons principales pour ne pas utiliser jQuery ou tout autre framework bien établi.
1. Le projet n'est pas assez grand ou complexe pour utiliser un tel framework: Dans ce cas, le codeur prend une décision éclairée basée sur son expérience et ses connaissances en JavaScript. Cela l'aidera à réduire le poids de la page et à mieux contrôler le code.
2. Le codeur développe son propre framework J'ai vu un projet dans mon entreprise qui a son propre framework JavaScript. La raison pour laquelle ils citent est que s'ils utilisent jQuery et qu'il y a un bug à corriger, ils doivent attendre la prochaine version. De plus, s'il y a une fonctionnalité à ajouter, ils doivent en demander à l'équipe jQuery ou ajouter un plugin même si en faire un plugin ne sera pas une bonne idée (ils ont donné l'exemple d'avoir utilisé un .live chose similaire dans leur framework avant même qu'il ne soit officiellement ajouté à JQuery). Avoir votre propre framework vous donne plus de contrôle sur le code. L'inconvénient est que vous devez réinventer la roue en ce qui concerne les problèmes de compatibilité des navigateurs, etc.
Avec les autres réponses ici, en particulier Michael Durrant's , je verrais la vitesse est une raison majeure pour laquelle je choisis de temps en temps d'utiliser JavaScript brut.
Dernièrement, j'ai travaillé sur beaucoup d'animations ou d'autres tâches gourmandes en CPU et parfois le JavaScript brut est beaucoup, beaucoup plus rapide que si je passais par jQuery.
Un exemple est où je voulais changer l'opacité d'un position: fixed élément par rapport à la distance parcourue par un utilisateur sur une page. L'effet était beaucoup trop lent lorsque j'ai utilisé jQuery pour cela, ce qui a rendu le défilement saccadé et l'effet de fondu a été ruiné. Je suis passé à l'utilisation de JavaScript simple et tout était parfaitement lisse, sauf IE <= 8.
Mike
Je pense que les gens se cachent contre l'utilisation de certaines bibliothèques sont dus à la dépendance à l'égard de cette solution d'infrastructure/bibliothèque pour effectuer certaines tâches.
Mais attention à ne pas oublier que les langues vont et viennent à la longue comme les bibliothèques.
Alors peut-être que c'est une portée temporelle. Peut-être que les gens hésitent à investir dans une bibliothèque qui n'est peut-être pas là - ou ont autant d'élan derrière à long terme.
Moi même? Je n'ai aucune objection à utiliser JQuery en particulier. Je regarde également disons Box2d.js ou three.js et je préférerais de loin les embrasser même si leur durée de conservation à court terme plutôt que de manquer quels fruits ils ont à offrir.
En fin de compte, Mike a un risque dans la durée de vie d'une bibliothèque que vous choisissez, et je pense que certains membres de la communauté javascript peuvent avoir subi une perte en raison de la fin d'une bibliothèque ou d'un projet, et peuvent l'avoir dit - plus jamais.
Je peux ajouter deux autres raisons qui n'ont pas été mentionnées:
Lorsque je prends une toute nouvelle technologie, souvent, je commence par des constructions de niveau inférieur avant de passer à des constructions de niveau supérieur. Je suis principalement un développeur C++/C #, mais il y a quelque temps, lorsque j'ai commencé à jouer avec HTML/CSS/JavaScript, j'ai choisi de ne pas utiliser de framework car je voulais d'abord comprendre la technologie (c'est-à-dire le JavaScript langue elle-même) que ces cadres sont construits sur.
- Cela dit, j'ai depuis découvert jQuery et je ne voudrais plus jamais revenir au codage manuel de ce que jQuery peut faire pour vous en 1-2 lignes de code.
Je ne sais pas à quel point c'est courant, mais il me semble qu'il y a beaucoup de gens qui, quand ils voient le prochain framework/technologie/langage, leur première réponse est, "pas une autre API pour moi d'apprendre!" Ils ne se soucient pas de la facilité avec laquelle jQuery est, mais ils le voient simplement comme s'interposer entre eux et fournir du travail en utilisant leurs méthodes "vraies et éprouvées". Il s'agit de la même catégorie de personnes qui refusent d'utiliser la bibliothèque Boost ou l'une des STL et continuent d'utiliser malloc pour à peu près tout. Vous avez demandé pourquoi ils choisissent du JavaScript pur sur jQuery et en réalité, ils n'ont jamais fait le choix parce que la plupart du temps, ils ont refusé d'évaluer jQuery en premier lieu et sont parfaitement satisfaits de leur rythme de développement actuel, quelle que soit sa lenteur.
Je dirais que le principal problème est que de plus en plus de personnes (la grande majorité?) Ne savent plus coder en JavaScript. Si jQuery ne peut pas faire quelque chose, ils ne peuvent pas le faire.
Il arrive au point que les exemples javascript simples deviennent difficiles à trouver. Rien contre jQuery; c'est un excellent cadre. J'en ai eu beaucoup de bonnes idées, mais les gens devraient d'abord apprendre JavaScript, puis apprendre un cadre. Personnellement, je trouve mon propre cadre plus flexible et mieux adapté à mes besoins, et oui je réinvente parfois la roue, mais le contrôle total et le contrôle des corrections de bogues sont un énorme avantage à condition que vous soyez prêt à mettre le travail dans l'apprentissage de JavaScript.
Non seulement que. Connaître Vanilla JavaScript le rend beaucoup plus amusant à jouer et à expérimenter avec les nouvelles fonctionnalités au lieu d'attendre une implémentation basée sur un framework. De plus, je ne blâme pas jQuery pour cela car c'est principalement une bibliothèque DOM , mais cela peut être pénible à l'échelle avec de grands projets. D'autres cadres réussissent mieux à cet égard; Prototype vient à l'esprit.
En bref, c'est un cadre formidable, mais pas tout le monde ne le prétend.