Share
De flesta av oss är bekant med jQuery JavaScript-biblioteket, och brukar använda det i åtminstone några av våra projekt. Men hur mycket vet vi om de människor som otvivelaktigt ger sin tid för att behålla webbens mest populära JavaScript-bibliotek? Jag fick nyligen chansen att intervjua jQuery Core Team-ledare, Dave Methvin, och diskutera hur han blev involverad i projektet och där han ser framsidans utveckling på väg. Han har bidragit till jQuery sedan 2006 och är också ordförande för jQuery Foundation.
jQuerys framgång har gjort det svårt för oss att ändra någonting.
Jag började min karriär som en heltidsanställd C-programmerare som gjorde inbyggda system saker som ombord navigering, robotik, fabriksautomatisering och telekommunikation. Därefter flyttade jag in i datorjournalistik och skrev en JavaScript-kolumn medan jag var i Windows Magazine. När WinMag stängde dörrarna grundade jag en start som byggde ett JavaScript- och HTML-baserat systemverktyg för Windows som automatiserat mycket av de råd vi brukade ge i tidningen.
När jag var igång, letade jag efter ett bättre sätt att organisera JavaScript och HTML vi skrev. Jag såg John Resigs 2005-bloggpost som beskriver vad som så småningom blev jQuery. Jag skickade honom ett mail och han svarade att han satte upp en adresslista för intresserade personer.
Så plötsligt finns det denna grupp av mycket begåvade människor som diskuterar biblioteket.
Många av dem är fortfarande med projektet till denna dag. Detta är en av Johns lilla kända talanger och en stor anledning till jQuerys tidiga framgång; Han är mycket inkluderande och öppen för inmatning från alla.
Jag tog officiellt jQuery Cores tyglar i juli 2011, även om jag hade jobbat lite med det tidigare. När det gäller varför? Jag tycker att John letade efter sin nästa stora utmaning, en som han verkar ha hittat på Khan Academy.
jQuerys framgång har gjort det svårt för oss att ändra någonting, även om det är en förändring till det bättre, till exempel en buggfix eller förbättrad överensstämmelse i API: n. Eftersom ungefär hälften av alla webbplatser använder jQuery, kan vi vara ganska säkra på det några Ändra vi gör till biblioteket kommer att vara en brytande förändring för någon. Trots att vi gör betas, väntar de allra flesta av användarna tills det är sista innan vi försöker den nya koden - vilket innebär att vi ofta flyger blind när det gäller att veta effekten av en förändring.
jQuery Core är ett bibliotek för att förenkla traversal, manipulation och hämtning av HTML-dokument.
När jQuery anlände 2006 visste webutvecklare webbläsarnas quirks och var glada att ha jQuery få dem till 90 procent-märket för kompatibilitet med webbläsare. Många av dagens utvecklare bodde aldrig i den världen och är förvånade över att jQuery inte kan göra varje liten skillnad försvinn över webbläsare. Men det finns gränser för hur bra vi kan arbeta kring webbläsarproblem. utvecklare behöver förstå det. Många gånger använder lösningen en enkel åtgärd på applikationsnivån, eller för att använda ett plugin som behandlar ett visst sällsynt fall.
Buggar prioriteras av om de är en regression, deras övergripande påverkan på samhället, deras svårighetsgrad och komplexiteten hos en fix. De flesta av de icke-regressionsproblemen är kantfall eller webbläsarfel som blödar till jQuery API. Vår utmaning är att fixa dessa utan att skapa en massa komplexa lösningar som de flesta inte behöver och introducera ytterligare buggar i processen.
Eftersom jQuery gör det enkelt att sätta några fantastiska effekter tillsammans med bara några rader av kod och vissa jQuery-plugins från tredje part, är det oundvikligt att icke-professionella kommer att försöka att använda sig av det. Ibland lyckas de, och andra gånger kommer de att göra en stor röra att någon behöver komma in och städa upp. Jag ser inte någon lösning på det "problemet" annat än att göra jQuery mer obetydlig så att bara professionella programmerare kan räkna ut det. Det kommer inte att hända.
Även om du tar ut IE 6/7/8 finns det en hel del kod i jQuery för att släta ut webbläsarfel och inkonsekvenser. Jag var lite deprimerad för att se hur många av dessa linjer som var kvar för jQuery 2.0. Det verkar som om alla webbläsare är upptagna att genomföra glänsande nya funktioner som CSS3 för att gå tillbaka och fixa grundläggande funktionalitet. Och varför borde de stör det, eftersom jQuery fixar det och därför klagar ingen på dem?
MV * -ramarna är där DOM-bibliotek var sex eller sju år sedan när jQuery anlände till scenen. Det finns mycket mångfald i deras inställning till design, vilket är en bra sak. De flesta av dessa ramar är glada att låta jQuery ta över DOM-problem på tv-webbläsare så att de kan fokusera på problem med applikationsdesign på högre nivå. Vi är definitivt komplementära till deras ansträngningar.
Jag gillar att skämta på att "Kärnan är inte färdig tills användargränssnittet inte kommer att springa."
jQuery Core är ett bibliotek för att förenkla traversal, manipulation och hämtning av HTML-dokument. Ibland vill folk driva gränserna och fråga varför vi inte stöder SVG, VML eller annan webbish-teknik, men det är vad plugins är för. Vi vill hålla jQuery's API inriktat på DOM-operationer. Att gå utöver det i kärnbiblioteket skulle lägga till mycket uppblåsa som få människor behöver.
jQuery Core har förmågan att användas som en AMD-namngiven modul och laddas dynamiskt. Generellt kallas namngivna moduler, men så många jQuery-plugins förväntar sig att dela ett globalt jQuery-objekt. Jag är inte nöjd med det nuvarande läget för JavaScript-modulen, och jag föredrar en enkel kombinera och minska process för det mesta av det arbete jag gör. Ändå är AMD populärt nog att vi ville ha jQuery Core att stödja det så att AMD-användare kan ladda jQuery från en CDN till exempel.
Lösningarna för IE 6/7/8 står för mer än tio procent av den totala jQuery 1.9-biblioteksstorleken, och dessa lösningar påverkar också prestanda. Det finns många platser där dessa lösningar inte behövs, till exempel Windows 8-appar, Chrome- och Firefox-plugins, PhoneGap / Cordova-appar på en specifik mobilplattform eller node.js-program där ett bibliotek som Cheerio används för att ladda jQuery.
Det är den primära publiken för jQuery 2.0 för tillfället; De flesta webbplatser på internet borde fortsätta att stödja de äldre versionerna av IE genom att använda jQuery 1.9.
Till exempel kan jag inte se Target eller Wal-Mart webbplatser med jQuery 2.0 i minst några år. IE8-användare har pengar också! Eftersom de två API-erna synkroniseras är det möjligt att använda villkorade kommentarer för att inkludera den ena eller den andra för en viss webbläsare, men för att vara ärlig tror jag inte att det är värt ansträngningen.
Eftersom jQuery UI och Mobile beror på Core, konsulterar vi dem om färdplaner där det behövs. De här projekten kör även sina testningar mot vår senaste byggnad direkt från Github så att vi omedelbart vet om vi bröt något. Ändå gillar jag att skämta på att "kärnan inte är färdig tills användargränssnittet inte kommer att springa" och det finns vanligtvis några glitches vi hittar efter varje release. QUnit är lite annorlunda; vi är deras klient. Vi frågar ibland dem om funktioner, och ibland bryter deras uppdateringar våra enhetstester. Så vi får en smak av vår egen medicin.
Vi ser jQuery Conference som en samling för utvecklare som skapar webbplatser och webbapplikationer. Några av vad de vill veta är om jQuery, men vi vill inte stanna där. Varje bra utvecklare bör expandera sin horisont och fortsätta att lära sig verktyg och tekniker som kan hjälpa dem att förbättra sig.
Innovationer kommer från alla håll. MV * -krigskriget kommer sannolikt att ge några mycket bättre och snabbare tillvägagångssätt för att utveckla webbapps och webbplatser. ingen tvekan kommer vi se någon konsolidering där, liknande vad som hände med jQuery.
Responsiv design är ett annat stort ämne, och jag hoppas att förbättringar i CSS och responsiva bilder kommer att underlätta genomförandet under det kommande året.
På den sista punkten arbetar jQuery med standardgrupperna på W3C och ECMA för att se till att webbutvecklare i grävarna är representerade när de fattar beslut.
Accentsconagua