Share
De fleste av oss er kjent med jQuery JavaScript-biblioteket, og sannsynligvis bruker det i minst noen av våre prosjekter. Men hvor mye vet vi om de menneskene som utrættelig gir sin tid til å opprettholde webens mest populære JavaScript-bibliotek? Jeg har nylig hatt muligheten til å intervjue jQuery Core Team-leder, Dave Methvin, og diskutere hvordan han ble involvert i prosjektet og hvor han ser frontend-utviklingen på vei. Han har vært en bidragsyter til jQuery siden 2006, og er også president for jQuery Foundation.
jQuerys suksess har gjort det vanskelig for oss å endre noe.
Jeg startet karrieren min som en heltids C-programmør som gjorde innebygde systemer ting som navigasjon på skip, robotteknikk, fabrikkautomatisering og telekommunikasjon. Deretter flyttet jeg inn i datalogistikk og skrev en JavaScript-kolonne mens jeg var på Windows Magazine. Da WinMag lukkede sine dører, grunnla jeg en oppstart som bygget et JavaScript- og HTML-basert systemverktøy for Windows, som automatisert mye av de rådene vi pleide å gi i magasinet.
Da jeg var i oppstarten, var jeg på utkikk etter en bedre måte å organisere JavaScript og HTML vi skrev. Jeg så John Resigs 2005 blogginnlegg som beskriver hva som til slutt ble jQuery. Jeg sendte ham en e-post, og han svarte å si at han hadde satt opp en adresseliste for interesserte personer.
Så plutselig er det denne gruppen av svært talentfulle folk som diskuterer biblioteket.
Mange av dem er fortsatt med prosjektet til denne dagen. Dette er en av Johns lite kjente talenter og en stor grunn til jQuerys tidlige suksess; Han er veldig inkluderende og åpen for input fra alle.
Jeg tok offisielt JQuery Core sine tøyler i juli 2011, selv om jeg hadde gjort litt arbeid på det før da. Hva med hvorfor? Jeg tror John var på utkikk etter sin neste store utfordring, en som han synes å ha funnet på Khan-akademiet.
jQuerys suksess har gjort det vanskelig for oss å endre noe, selv om det er en forandring til det bedre, for eksempel en feilretting eller forbedring av konsistensen til API. Fordi omtrent halvparten av alle Internett-sider bruker jQuery, kan vi være ganske sikre på at noen endre vi gjør til biblioteket vil være en bryte forandring for noen. Selv om vi gjør betas, vil det store flertallet av brukere vente til det er endelige før vi prøver den nye koden - noe som betyr at vi ofte flyr blinde når det gjelder å kjenne effekten av en endring.
jQuery Core er et bibliotek for å forenkle traversal, manipulering og gjenfinning av HTML-dokumenter.
Når jQuery ankom i 2006, kjente webutviklere nettlesernes quirks og var glad for at jQuery fikk dem til 90 prosent-merket for kompatibilitet med nettleseren. Mange av dagens utviklere levde aldri i den verden og er overrasket over at jQuery ikke kan gjøre hver eneste liten forskjell forsvunnet over nettlesere. Men det er grenser for hvor godt vi kan arbeide rundt nettleserproblemer; utviklere trenger å forstå det. Mange ganger bruker løsningen en enkel løsning på applikasjonsnivået, eller å bruke et plugin som adresserer noen spesifikke sjeldne tilfeller.
Bugs prioriteres av om de er en regresjon, deres generelle innvirkning på samfunnet, deres alvorlighetsgrad og kompleksiteten til en løsning. De fleste ikke-regresjonsproblemer er kantsaker eller nettleserbugs som bløder gjennom jQuery API. Vår utfordring er å fikse disse uten å skape en masse komplekse løsningsmuligheter som de fleste ikke trenger, og introdusere ytterligere feil i prosessen.
Siden jQuery gjør det enkelt å sette noen fantastiske effekter sammen ved hjelp av bare noen få linjer med kode og noen tredjeparts jQuery-plugins, er det uunngåelig at ikke-profesjonelle vil prøve seg på å bruke den. Noen ganger lykkes det, og andre ganger vil de gjøre et stort rot som noen trenger å komme inn og rydde opp. Jeg ser ikke noen løsning på det "problemet" annet enn å gjøre jQuery mer urokkelig, så bare profesjonelle programmerere kan finne ut det. Det kommer ikke til å skje.
Selv om du tar ut IE 6/7/8, er det en masse kode i jQuery for å jevne ut nettleserfeil og inkonsekvenser. Jeg var litt deprimert for å se hvor mange av linjene som måtte forbli for jQuery 2.0. Det ser ut til at alle nettlesere er opptatt med å implementere skinnende nye funksjoner som CSS3 for å gå tilbake og fikse grunnleggende funksjonalitet. Og hvorfor burde de plage å fikse det, siden jQuery fikser det og derfor klager ingen på dem?
MV * -rammene er hvor DOM-biblioteker var seks eller syv år siden da jQuery kom fram på scenen. Det er mye mangfold i deres tilnærming til design, noe som er en god ting. De fleste av disse rammene er glade for å la jQuery ta på DOM-problemene på tvers av nettleseren, slik at de kan fokusere på høyere nivå applikasjonsdesign bekymringer. Vi er definitivt komplementære til deres innsats.
Jeg liker å joke at "Kjerne er ikke ferdig før brukergrensesnittet ikke løper."
jQuery Core er et bibliotek for å forenkle traversal, manipulering og gjenfinning av HTML-dokumenter. Noen ganger vil folk skyve grensene og spørre hvorfor vi ikke støtter SVG, VML eller andre webish-teknologier, men det er plugins for. Vi ønsker å holde jQuery's API fokusert på DOM-operasjoner. Å gå utover det i kjernebiblioteket, vil legge til mye oppblåsing som få mennesker trenger.
jQuery Core har muligheten til å bli brukt som en AMD-navngitt modul og lastes dynamisk. Generelt kalles navngitte moduler på, men så mange jQuery-plugins forventer å dele et globalt jQuery-objekt. Jeg er ikke fornøyd med dagens status for JavaScript-modulen lasting, og jeg foretrekker en enkel kombinere og minifisere prosess for det meste av arbeidet jeg gjør. Imidlertid er AMD populært nok at vi ønsket jQuery Core å støtte det slik at AMD-brukere kan laste jQuery fra en CDN for eksempel.
Løsningene for IE 6/7/8 står for mer enn ti prosent av den totale jQuery 1.9-biblioteksstørrelsen, og disse løsningene påvirker også ytelsen. Det er mange steder der disse løsningene bare ikke er nødvendige, for eksempel Windows 8-apper, Chrome- og Firefox-plugins, PhoneGap / Cordova-apper på en bestemt mobilplattform eller node.js-programmer der et bibliotek som Cheerio brukes til å laste jQuery.
Det er det primære publikum for jQuery 2.0 for øyeblikket; De fleste Internett-nettsteder bør fortsette å støtte de eldre versjonene av IE ved hjelp av jQuery 1.9.
For eksempel kan jeg ikke se Target eller Wal-Mart nettsteder ved hjelp av jQuery 2.0 i minst noen år. IE8-brukere har også penger! Siden de to APIene er synkroniserte, er det mulig å bruke betingede kommentarer for å inkludere den ene eller den andre for en bestemt nettleser, men for å være ærlig tror jeg ikke det er verdt innsatsen.
Siden jQuery UI og Mobile er avhengige av Core, konsulterer vi dem på veikartsprosjekter når det er nødvendig. Disse prosjektene kjører også enhetstestene sine mot vår nyeste bygge direkte fra Github, slik at vi umiddelbart vet om vi brøt noe. Likevel, jeg liker å joke at "Kjernen er ikke ferdig før brukergrensesnittet ikke løper," og det er vanligvis noen få glitches vi finner etter hver utgivelse. QUnit er litt annerledes; vi er deres klient. Noen ganger spør vi dem om funksjoner, og noen ganger bryter deres oppdateringer våre enhetstester. Så vi får en smak av vår egen medisin.
Vi ser jQuery Conference som en samling for utviklere som lager nettsider og webapplikasjoner. Noen av det de vil vite er om jQuery, men vi vil ikke stoppe der. Enhver god utvikler bør utvide sine horisonter og fortsette å lære verktøy og teknikker som kan hjelpe dem med å forbedre seg.
Innovasjoner kommer fra alle retninger. MV * rammekrigene vil trolig gi noen mye bedre og raskere tilnærminger for å utvikle webapps og nettsteder; Ingen tvil om at vi ser noe konsolidering der, ligner på hva som skjedde med jQuery.
Responsive design er et annet stort tema, og jeg håper at forbedringer i CSS og lydhør bilder vil gjøre det enklere å implementere det kommende året.
På det siste punktet jobber jQuery med standardgruppene på W3C og ECMA for å sikre at webutviklere i grendene er representert når de tar beslutninger.
Accentsconagua