jQuery er den største åpne kilden, kryssbrowser, CSS3-kompatibel, JavaScript-biblioteket rundt, og det har gjort skript på siden av klienten en bris.
Syntaxen er enkel og jQuery kan produsere vakre, nesten Flash-lignende animasjoner. I motsetning til Flash er jQuery synlig på iOS, og det produserer dynamiske websider enkelt.
jQuery vokser raskt i popularitet, og med den siste jQuery-konferansen som ble holdt i San Francisco i slutten av juni, ser det ut til at det er en passende tid å starte en samtale om jQuery og spesielt noen av fordeler og ulemper med å bruke den til mer krevende arbeidsplasser.
Kanskje det beste med jQuery er at du ikke trenger å være et programmeringsgeni til wow-klienter.
Det er vanligvis mer enn én måte å skape en katt på, men muligheten til å legge til plugin-moduler på toppen av basebiblioteket gjør jQuery til en utrolig fleksibel og fremdeles rask løsning. Bruke CSS kan være det bedre valget i noen tilfeller (se nedenfor), men hvis programmeringsevnen din er mer begrenset, vil valg av jQuery hjelpe deg med å få jobben gjort.
Webutvikling er for ofte en prosess som er fastgjort for tid og sparer minutter eller til og med arbeidstid er ofte ikke en luksus, men en nødvendighet. John Resig og de andre utviklerne bak jQuery-prosjektet forstår virkelig tid / penger-ligningen som møter webutviklere daglig. Hurtig implementering betyr vanligvis flere dollar i lommen.
Ulempen med JavaScript, kompleksiteten ved å implementere CSS og de godt publiserte ulempene med Flash, gjør jQuery den mest praktiske løsningen til mange vanlige problemer, inkludert DOM-transverser, hendelseshåndtering, AJAX-interaksjoner og animasjon.
Microsoft og Nokia er begge bak jQuery og planlegger å pakke det inn i deres nye plattformer som tyder på en lys fremtid fremover. I tillegg er nesten alle i open source-fellesskapet bak jQuery fordi:
Åpen kilde gir rask og dynamisk vekst. Det er ingen lisenser å bekymre seg for, og det er gratis. Gratis faktisk oversetter til et samfunn av sinn som er langt bredere og smartere enn utviklerne holdt i fangenskap av ett selskap.
Kjernen i jQuery har blitt bygget av noen av de mest briljante sinnene i bransjen, og utviklingen er bokstavelig talt eksploderende.
Papirkutt av forretningsmann på gammel bok via Shutterstock
Åpen kilde har sine problemer: for eksempel er ikke alt bygget til en felles standard. Dette er greit hvis kunden din - eller mer sannsynlig, du - har tid og penger til å investere tilpasningskode. Men hvis tid, penger, evne eller alle tre er mangelfulle, vil ryggen være opp mot veggen når noe går galt.
Den siste stabile versjonen av jQuery (v1.7.2) ble utgitt 21. mars 2012, slik at evnen til å finne vanlige løsninger for ditt eksakte problem, trukket fra fellesskapets basseng, sannsynligvis vil være mangelfull i noen tid framover.
Et annet stort problem med jQuery er at det finnes flere versjoner der ute. Noen versjoner spiller bra med andre, og noen gjør det ikke. For eksempel har nettleserkompatibilitet med animasjoner vært et langvarig problem med jQuery-animasjoner. Å sørge for at du for øyeblikket kjører den nyeste jQuery-oppdateringen, løser mange av de kjente problemene som er relatert til jQuery-animasjoner, men du må velge mellom å være vert for biblioteket selv og kontinuerlig oppdatere eller laste inn biblioteket fra Google og risikere uforenelighet med koden din som Nye versjoner blir utgitt.
AJAX-kontrollverktøyet gir serverkontroller. Dette gir en utvikler mye mer kraft og fleksibilitet. Men AJAX-verktøyet er stort og omfangsrikt sammenlignet med jQuery. Som jQuery fortsetter å utvikle vil den lette koden sikkert vinne ut spesielt med Microsoft ombord - ved å støtte jQuery Microsoft dumper i hovedsak sin egen MicrosoftAjax.js. På overflaten er resultatene av å bruke jQuery for å håndtere XML, veldig kule; Det er så få linjer med kode, det virker bare så lett ...
Imidlertid er håndtering av AJAX og jQuery et felles område hvor ulemper om ikke å være programmerer ofte blir tydelige. For eksempel er forståelse av de grunnleggende forskjellene mellom GET og POST HTTP-forespørsler avgjørende, og likevel så mange designere som mangler denne kunnskapsploven, forventer at jQuery skal hente sin slakk. Det er fallgruver som designere kanskje ikke er oppmerksomme på, for eksempel kan GET-forespørsler begrenses i lengde og mange uerfarne programmerere skifter bare til POST for å løse problemet; Dette kan være en dårlig ide, GET gir ingen varige modifikasjoner på serveren mens POST kan. POST er ikke en kommando som skal gjentas vilkårlig, men den brukes uavhengig av og til.
Et annet vanlig server-sideproblem relatert til jQuery utgjør sitt stygge hode hvis $ .get brukes i stedet for $ .getJSON (javascriptobjektnotasjon). Ikke bruk $ .getJSON for data transport problemer kan forårsake alle slags ødeleggelse.
Ung gutt som utgir seg for å kjøre en gigantisk jordmester via Shutterstock
Det er lett å være kult med jQuery, det er ikke så lett å være kult og riktig.
Å bruke jQuery og spesielt kult jQuery krever vel en forpliktelse til samfunnet. Utviklingen er rask og det er spennende, men dette kan også lede igjen til problemer relatert til tid. Utviklingen er så fort i noen områder at hvis en utvikler ikke følger og deltar i samfunnet regelmessig, er det lett å komme igjen i støvet. Dette er en ekstra tidsperspektiv for utviklere som er festet for tid på å prøve å drive en bedrift, ta vare på flere kunder, implementere SEO og Content Marketing-kampanjer og fortsatt se barna sine.
Det er nødvendig å realistisk vurdere ditt ferdighetsnivå og tiden som kreves for å holde deg oppdatert på alle de nye jQuery-utviklingene.
De to store elefantene i skapet relatert til jQuery har blitt etterlatt sist: hastighet og spaghetti kode.
jQuery kan være treg, og for animasjon er det noen ganger mye tregere enn å bruke CSS. I et stort, komplekst område teller hver liten biter av et sekund. Årsaken til dette er todelt: flere DOM-manipulasjoner, en på toppen av en annen kan redusere et nettsted ned; For det andre bruker CSS browser-sideoverganger for animasjoner og er skrevet i C ++. Dette gjør det litt raskere enn JavaScript.
jQuery spaghetti, hvis du ikke har kommet over det ennå, i tide vil du. jQuery største attribut - hvor lett det er å bruke - er også dets achilles helbredelse. jQuery er et bibliotek som er designet for å hjelpe med DOM transverser og CSS selectors. Det gjør dette med fantastisk effektivitet. Det er ikke ment å bli brukt som ramme for kundeinteraksjon. Når det brukes feil, spesielt jQuery CSS selectors, kan sluttresultatet være kode som vokser og vokser i en monster-sized .js-fil til det blir umulig å vedlikeholde. Kast i tilbakeringinger, noen kosmetiske designendringer, og generisk navngi og nedover veien. Vedlikehold av et jQuery-nettsted kan bli et mareritt.
Vintagefoto av to unge gutter som spiser spaghetti med sine hender via Shutterstock
JQuery-samfunnet tar opp problemene rundt jQuery spaghetti. Cedric Dugas økte bevisstheten om jQuery spaghetti på Confoo. Han er blant annet dedikert til å minne programmerere om å bruke beste praksis med jQuery for å hindre mammutskåler av spaghetti. Som en frontend-designer kommenterte, å virkelig bruke jQuery, må du vite og forstå JavaScript. Kutting og liming har definitivt sine ulemper ved at det gir resultater uten forståelse. Selv om dette kan fungere en stund, kan det også forårsake alle slags langsiktige vedlikeholdsproblemer.
Å bruke et godt rammeverk kan bidra til å hindre noen av jQuery-spagettiene. Dessverre er rammeverk virkelig et nytt område, og det tar tid å velge riktig rammeverk og få dem til å leke pent med hverandre. Igjen må denne ekstra tiden bli innregnet i jQuery-ligningen. For øyeblikket er det mange rammer som ønsker å dominere klientsiden MVS Framework Space. Backbone.js er den mest populære for øyeblikket, men det har noen alvorlig konkurranse.
jQuery er et av de beste bibliotekene der ute, og det kan gjøre det enklere å skrive JavaScript. Men, som mange verktøy, er jQuery på sitt beste brukt av en ekspert håndverkere. Faller vi alle under denne kategorien? Selvfølgelig ikke. Betyr dette at vi ikke bør bruke jQuery? Selvfølgelig ikke. Det antyder bare at det er en god ide å ha nok mening å be om hjelp når du er ute av dybden.
Bruker du jQuery og kjenner du også JavaScript? Trenger du å forstå programmering for å implementere jQuery? Gi oss beskjed om hva du synes i kommentarene.