Welkom terug.
Dit gaat om een ​​korte video over de redenen dat u Jay Querrey en een aantal redenen die je niet zou willen Jake Querrey gebruiken moeten gebruiken.
Dus in de intro video die ik samengevat Jake Query als een JavaScript-bibliotheek die helpt ons doen veel van de dingen die we al doen.
En het maakt ze makkelijker.
Dus je zou jezelf de vraag stellen na het horen van dat wat is de reden waarom zouden we niet altijd gebruik maken van een query.
Het lijkt alsof het maakt het leven makkelijker en het helpt ons met alle gangbare dominante mutatie functies die we moeten gewoon altijd gebruiken.
De waarheid is dat het een beetje een debat in de gemeenschap van ontwikkelaars op dit moment, dus ik ga om te beginnen door te praten over een aantal van de redenen voor het gebruik van een query.
Dan zal ik praten over een aantal redenen waarom je niet zou willen om een ​​vraag te gebruiken en dan zal ik het ook hebben over mijn eigen mening en mijn ervaring mensen leren programmeren, waar Jay Querrey past best.
Voordat we beginnen hier ik wil wijzen op deze website u misschien niet nodig Jay Querrey ik dit laten zien aan u voor twee grote redenen.
De eerste daarvan is dat het aantoont dat alles wat we kunnen doen met Jay Querrey we kunnen doen zonder.
Dat is het punt van deze website is om gewone dingen te laten zien.
Jay Querrey als schuilplaats en Allaman hoe je zou ze doen zonder een vraag en je zult zien dat veel van hen zijn echt vergelijkbaar.
En veel van hen Jay curry is niet veel korter, maar op een aantal van de functies, zoals Ajax is dit een stuk hier langer zonder Jay query.
De tweede reden dat ik laten zien de site voor u is dat het feit dat er zelfs een site genaamd u misschien niet Jay-query nodig is een bewijs van het debat dat momenteel aan de gang in de gemeenschap van ontwikkelaars en dit is slechts één voorbeeld van een site dat is vragen dat u een query niet nodig zou kunnen hebben.
Er zijn honderden en duizenden blogs en artikelen en tutorials die er zijn dat zal u vertellen u een query gebruikt of u mag nooit een query te gebruiken en het is zeer omstreden.
Dus laten we duiken dieper in dat debat en praten over waarom je J queery dus moet gebruiken waarom je rustig blijven.
De originele reden dat het is gemaakt is dat Dom API alle methoden die we hebben gebruikt Document dot natuurlijk Lechter krijgen element door ID.
Dat alles gebruikte gebroken beschouwd.
Dus de hele doel van Jay vraag was om het gemakkelijker en sneller om de DOM API gebruiken met behulp van Jay Querrey die optrad als een interface naar de kapotte Dom API.
Het maakt ook de code duidelijker en korter als je hier zag.
Je weet dat zoiets als dit zonder een query te doen is drie of vier keer het bedrag van de code als het is met behulp van Jey vraag dus het maakt het duidelijker en korter.
Het is ook goed te gebruiken.
Het is gebouwd in de cross-browser ondersteuning dus dat betekent dat Jay vraag zal zorgen voor de verschillen tussen een eigenschap die werkt in Internet Explorer 9 en een die werkt in Internet Explorer 8 en het zal zorg dragen voor al dat cross-browser ondersteuning.
Die een soort rommelig.
En een van de slechtste delen van het zijn een web developer om eerlijk te zijn naar mijn mening tenminste het biedt ook AJAX die we later zullen praten over zijn.
Het is een subset van functies dat is echt handig.
En de laatste reden hier is dat veel mensen gebruik maken van een vraag en ik ben niet alleen maar te zeggen dat, omdat veel mensen gebruik maken van Jey query.
Je moet uiteraard gebruiken het ook.
Dat is helemaal niet wat ik zeg, maar het feit dat veel mensen gebruik maken van Jey vraag betekent dat er een sterke gemeenschap die er zijn.
Er zijn tal van tutorials en blog posts en stack overflow vragen.
Mensen gebruiken het allemaal over de plaats en dus is er een groot aantal materialen en middelen die betrekking hebben op Jay Querrey die is geweldig als je probeert om iets te doen en je hulp nodig hebt.
OK.
Dus spraken we over de reden waarom Jay queery is geweldig en het klinkt wellicht een beetje als Americorp op dit punt.
Dus waarom zouden we niet gebruiken.
En de eerste en belangrijkste antwoord is dat de Dom API niet meer kapot dus het heeft dingen die zij niet gebruikt te hebben.
Dus bijvoorbeeld queery selector querySelector alle niet vroeger bestond kader van Saddam Adamu API is veel gemakkelijker te gebruiken.
En we hebben het gebruik van het tot nu toe geweest en we hebben gedaan prima zonder een query.
De tweede reden is dat het niet alles wat je niet kunt doen op uw eigen dat is het hele punt van deze site doet.
We kunnen alles wat je met een vraag zou doen zonder het te doen.
En samen met dat als we maar wilden twee of drie methoden of zelfs 10 methodes query gebruiken we nog steeds met inbegrip van een bekende 100 of 200 plus verschillende methoden.
Dus soms mensen noemen het een onnodige afhankelijkheid.
Ze zouden zeggen dat het gebruik van j Curry is te zwaar een hulpmiddel voor wat je doet.
Dus als je alleen met behulp van Jay-query voor animaties bijvoorbeeld dat is een beetje overdreven, want er zijn andere tools die er zijn die u zullen helpen alleen met animatie, terwijl Jay queery doet animatie Plus je weet honderd andere dingen.
En en het is gewoon niet nodig te hebben dat veel gewicht is wat de mensen zouden zeggen.
Zodat de prestaties kan een probleem zijn.
Het zal niet in ons geval zullen we niets doen, dat is echt duwen Jay Curry hard, maar het idee achter dat is dat als iemand met behulp van Jay-query en ze niet weten dat ze niet vertrouwd bent met de code en de broncode van Jay query en hoe de dingen zijn geschreven dat ze misschien een methode te gebruiken ze misschien een stukje code dat is inefficiënt te schrijven.
Dat is eigenlijk langzamer dan als ze het net had gedaan zonder een query.
Maar zoals ik al zei, dat is een beetje een lang schot voor ons.
En de laatste reden is dat veel mensen weg te gaan van J.
Cory en dat is niet om te zeggen dat alleen maar omdat andere mensen geen gebruik maakt van Jay query die moet je niet gebruiken het is dezelfde reden die ik noemde voor Jay query.
Er is grote middelen en tutorials en video's veel informatie die er zijn.
Dus kan je eigenlijk niet fout gaan.
Dus nu gaan we wat tijd besteden aan het bespreken van mijn eigen mening over deze en in het bijzonder mijn ervaring mensen leren te programmeren met Jay Querrey en zonder.
Toen ik voor het eerst begonnen met mensen te leren programmeren en mensen leren om webontwikkelaars Ik zou beginnen met H Tim L geworden en vervolgens C S ons en dan zou ik direct naar Jacqui.
Dus ik zou niet een van de dingen die we hebben gesproken over de afgelopen eenheden doen.
Ik zou gebeurtenissen leren.
Ik zou leren te selecteren en te manipuleren door middel van Jay-query, maar ik zou niet de studenten te laten zien hoe dat te doen met vanille Javascript.
Dus vanille Agellius of gewoon G-S alleen verwijst naar het schrijven van javascript zonder een query.
Dus ik heb niet gebruikt om het even welk van dat te doen in de cursus.
Ik zou beginnen met een vraag en wat ik realiseerde is dat de ontwikkelaars die ik produceerde in de klas waren geweldig, ontwikkelaars, maar als je nam Jay Querrey weg als ze naar een bedrijf dat was de beslissing dat ze niet van plan om een ​​query te gebruiken die gebeurde meer en meer en meer studenten zou naar me toe en vertel me dat je weet dat mijn nieuwe baan is geweldig behalve dat ze geen Jay Querrey gebruiken gewoon zo u weet.
En ik heb dat feedback veel en ik realiseerde me dat de studenten afhankelijk zijn van Jay queery uiteraard tegen het einde van de les waren ze goed genoeg waren, waren ze konden gaan leren Fenella Ja, en zij konden ze konden code zonder Jay-query te schrijven.
Maar het punt is dat hun kennis was gecentreerd rond een query centric manier van schrijven code.
Dus na het onderwijzen van mensen Jay Querrey eerst voor een paar klassen ik dingen veranderen rond en ik begon door hen vanille javascript Dom manipulatie eerste.
Dus de dingen die we hebben gedaan tot op dit punt en vervolgens ingebracht I J-query achteraf eens had ze een solide conceptuele basis van hoe gebeurtenissen werken en hoe het selecteren en manipuleren van werken en dat alles dat Jay Querrey ons kan helpen.
Ik wilde de studenten om te begrijpen hoe Jay Querrey al deze dingen achter de schermen aan het doen was.
Na het onderwijzen van deze benadering van vanille-ijs en vervolgens Jay queery later en om dat te doen voor een paar klassen en het kijken naar de studenten afstuderen realiseerde ik me dat we produceren nog veel sterker javascript ontwikkelaars.
Het was niet alleen het feit dat mijn leerlingen een code zou kunnen nemen en schrijf het in een query en ook schrijf de gelijkwaardige code zonder een query.
Maar nog belangrijker merkte ik dat mijn studenten had een veel sterkere conceptuele basis van de Dom en Dom en schending zodat hun fundering niet werd gebouwd op Jay Querrey dat is een manier van doen.
Hun stichting is gebouwd op de opzet van het J-query onderliggende analogie.
Ja.
Dus het is een meer uniforme aanpak waar studenten begrepen op een dieper niveau hoe de dingen werkten en ze zagen aan de ene kant kunnen we dit doen met een query en aan de andere kant kunnen we het doen zonder een query in plaats van het structureren van hun conceptuele kader rond Jay-query .
Ze opgebouwd rond de algemene Dom en het begrip DOM manipulatie.
Dus dat was een omslachtige manier van het delen mijn mening over dit onderwerp.
Ik heb nog belangrijker is tot de conclusie gekomen als ontwikkelaar te komen en ook als opvoeder die de moeite waard te weten hoe ze dingen doen zonder een query en ook hoe je ze moet doen met een vraag.