Share
De meesten van ons zijn bekend met de jQuery JavaScript-bibliotheek en gebruiken deze waarschijnlijk in ten minste enkele van onze projecten. Maar hoeveel weten we van de mensen die onvermoeibaar tijd besteden aan het onderhouden van de populairste JavaScript-bibliotheek op het web? Ik heb onlangs de kans gehad om jQuery Core Teamleider, Dave Methvin, te interviewen en bespreek hoe hij betrokken raakte bij het project en waar hij de front-end ontwikkeling zag leiden. Hij levert al sinds 2006 bijdragen aan jQuery en is ook voorzitter van de jQuery Foundation.
Het succes van jQuery heeft het voor ons moeilijk gemaakt om iets te veranderen.
Ik begon mijn carrière als een fulltime C-programmeur die embedded systemen deed, zoals navigatie aan boord, robotica, fabrieksautomatisering en telecommunicatie. Daarna ging ik naar computerjournalistiek en schreef ik een JavaScript-kolom terwijl ik bij Windows Magazine was. Toen WinMag zijn deuren sloot, ben ik mede-oprichter van een startup die een JavaScript- en HTML-gebaseerd systeemhulpprogramma voor Windows bouwde dat in feite veel van de adviezen automatiseerde die we in het tijdschrift gaven.
Toen ik bij de start was, was ik op zoek naar een betere manier om de JavaScript-code en HTML die we aan het schrijven waren te ordenen. Ik zag de blogpost van John Resig in 2005 waarin beschreven werd wat uiteindelijk jQuery werd. Ik stuurde hem een e-mail en hij antwoordde dat hij bezig was met het opzetten van een mailinglijst voor geïnteresseerde mensen.
Zo plotseling is er een groep zeer getalenteerde mensen die de bibliotheek bespreken.
Veel van hen zijn nog steeds bij het project tot op de dag van vandaag. Dit is een van John's weinig bekende talenten en een grote reden voor het vroege succes van jQuery; hij is zeer inclusief en open voor iedereen.
Ik nam officieel de leiding over de leiding van jQuery Core in juli 2011, hoewel ik daarvoor al behoorlijk wat werk had verzet. Waarom? Ik denk dat John op zoek was naar zijn volgende grote uitdaging, een die hij lijkt te hebben gevonden op de Khan Academy.
Het succes van jQuery heeft het voor ons moeilijk gemaakt om iets te veranderen, zelfs als het een verbetering ten goede is, zoals een bugfix of het verbeteren van de consistentie van de API. Omdat ongeveer de helft van alle internetsites jQuery gebruikt, kunnen we daar vrij zeker van zijn ieder verandering die we in de bibliotheek aanbrengen, zal voor iemand een brekende verandering zijn. Hoewel we bèta's doen, willen de overgrote meerderheid van gebruikers wachten tot het definitief is voordat ze de nieuwe code proberen - wat betekent dat we vaak blindelings vliegen als het gaat om het kennen van de impact van een verandering.
jQuery Core is een bibliotheek om het traversal, manipulatie en ophalen van HTML-documenten te vereenvoudigen.
Toen jQuery in 2006 arriveerde, kenden webontwikkelaars de eigenaardigheden van de browser en waren ze blij dat jQuery ze tot 90 procent kon bereiken voor compatibiliteit met andere browsers. Veel van de ontwikkelaars van vandaag hebben nooit in die wereld gewoond en zijn verrast dat jQuery niet elk klein verschil in browsers kan laten verdwijnen. Maar er zijn grenzen aan hoe goed we browserproblemen kunnen oplossen; ontwikkelaars moeten dat begrijpen. Vaak maakt de oplossing gebruik van een eenvoudige oplossing op applicatieniveau, of van een plug-in die een specifiek geval behandelt.
Bugs krijgen prioriteit door of ze een regressie zijn, hun algemene impact op de community, hun ernst en de complexiteit van een fix. De meeste niet-regressieproblemen zijn randgevallen of browserbugs die doorlopen naar de jQuery API. Onze uitdaging is om deze op te lossen zonder een massa complexe oplossingen te hoeven maken die de meeste mensen niet nodig hebben, en om nog meer bugs in het proces te introduceren..
Omdat jQuery het gemakkelijk maakt om een aantal geweldige effecten samen te stellen met slechts een paar regels code en een aantal jQuery-plug-ins van derden, is het onvermijdelijk dat niet-professionals het proberen te gebruiken. Soms zullen ze slagen en soms maken ze een grote puinhoop dat iemand binnen moet komen om op te ruimen. Ik zie geen enkele oplossing voor dat "probleem" anders dan het maken van jQuery meer stomp, zodat alleen professionele programmeurs het kunnen achterhalen. Dat gaat niet gebeuren.
Zelfs als u IE 6/7/8 afsluit, is er een heleboel code in jQuery om bugs en inconsistenties in de browser weg te werken. Ik was enigszins depressief om te zien hoeveel van die regels er moesten blijven voor jQuery 2.0. Het lijkt erop dat alle browsermakers het te druk hebben met het implementeren van glimmende nieuwe functies zoals CSS3 om terug te gaan en de basisfunctionaliteit te herstellen. En waarom zouden ze de moeite nemen om het te repareren, aangezien jQuery het repareert en daarom niemand klaagt hen?
De MV * -frameworks zijn waar DOM-bibliotheken zes of zeven jaar geleden waren toen jQuery ter plaatse verscheen. Er is veel diversiteit in hun ontwerpbenadering, wat een goede zaak is. De meeste van deze frameworks laten jQuery graag de cross-browser DOM-problemen overnemen, zodat ze zich kunnen concentreren op toepassingsproblemen op het hoogste niveau. We zijn zeker een aanvulling op hun inspanningen.
Ik hou ervan om te grappen dat "Core niet is gedaan totdat UI niet zal worden uitgevoerd."
jQuery Core is een bibliotheek om het traversal, manipulatie en ophalen van HTML-documenten te vereenvoudigen. Soms willen mensen de grenzen verleggen en vragen waarom we SVG, VML of andere webbish-technologieën niet ondersteunen, maar daar zijn plug-ins voor. We willen de API van jQuery gericht houden op DOM-operaties. Verder gaan dan dat in de kernbibliotheek zou veel opgeblazen gevoel toevoegen dat maar weinig mensen nodig hebben.
jQuery Core heeft de mogelijkheid om te worden gebruikt als een AMD-named module en dynamisch te worden geladen. Over het algemeen worden named-modules afgekeurd, maar zoveel jQuery-plug-ins verwachten een globaal jQuery-object te delen. Ik ben niet tevreden met de huidige status van het laden van JavaScript-modules en ik geef de voorkeur aan een eenvoudig samenvoegen en verkleinen voor het meeste werk dat ik doe. Toch is AMD populair genoeg dat we jQuery Core wilden ondersteunen, zodat AMD-gebruikers jQuery van een CDN kunnen laden, bijvoorbeeld.
De tijdelijke oplossingen voor IE 6/7/8 zijn goed voor meer dan tien procent van de totale jQuery 1.9-bibliotheek, en deze oplossingen hebben ook invloed op de prestaties. Er zijn veel plaatsen waar deze tijdelijke oplossingen niet nodig zijn, zoals Windows 8-apps, Chrome- en Firefox-plug-ins, PhoneGap / Cordova-apps op een specifiek mobiel platform of node.js-programma's waarbij een bibliotheek zoals Cheerio wordt gebruikt om jQuery te laden.
Dat is het primaire publiek voor jQuery 2.0 op dit moment; de meeste internetwebsites zouden die oudere versies van IE moeten blijven ondersteunen met behulp van jQuery 1.9.
Ik kan bijvoorbeeld de Target- of Wal-Mart-websites niet zien met jQuery 2.0 voor minimaal een paar jaar; IE8-gebruikers hebben ook geld! Omdat de twee API's gesynchroniseerd zijn, is het mogelijk om voorwaardelijke opmerkingen te gebruiken voor een specifieke browser, maar om eerlijk te zijn denk ik niet dat het de moeite waard is.
Omdat jQuery UI en Mobile afhankelijk zijn van Core, raadplegen we ze waar nodig met routekaartproblemen. Die projecten voeren ook hun unit tests tegen onze meest recente build rechtstreeks uit Github uit, zodat we meteen weten of we iets gebroken hebben. Toch hou ik ervan om te grappen dat "Core niet klaar is totdat UI niet draait" en dat er meestal na elke release een paar foutjes zijn. QUnit is een beetje anders; wij zijn hun cliënt. We vragen ze soms om functies en bij gelegenheid breken onze updates onze unit tests. Dus we proeven van ons eigen medicijn.
We zien de jQuery-conferentie als een bijeenkomst voor ontwikkelaars die websites en webtoepassingen maken. Sommige dingen die ze willen weten, gaan over jQuery, maar we willen daar niet stoppen. Elke goede ontwikkelaar moet zijn horizon verruimen en doorgaan met het leren van hulpmiddelen en technieken die hem kunnen helpen verbeteren.
Innovaties komen uit alle richtingen. De MV * framework-oorlogen zullen waarschijnlijk een aantal veel betere en snellere benaderingen opleveren voor het ontwikkelen van web-apps en -sites; ongetwijfeld zullen we daar wat consolidatie zien, vergelijkbaar met wat er met jQuery gebeurde.
Responsive design is een ander groot onderwerp en ik hoop dat verbeteringen in CSS en responsieve afbeeldingen het gemakkelijker zullen maken om het komend jaar te implementeren.
Op dat laatste punt werkt jQuery met de standaardgroepen op W3C en ECMA om ervoor te zorgen dat de webontwikkelaars in de loopgraven worden vertegenwoordigd bij het nemen van beslissingen.
Accentsconagua