Share
Die meisten von uns sind mit der jQuery-JavaScript-Bibliothek vertraut und verwenden sie wahrscheinlich in einigen unserer Projekte. Aber wie viel wissen wir über die Menschen, die sich unermüdlich für die Pflege der beliebtesten JavaScript-Bibliothek des Webs einsetzen? Ich hatte kürzlich die Gelegenheit, den Chef des jQuery-Kernteams, Dave Methvin, zu interviewen und zu besprechen, wie er in das Projekt involviert wurde und wo er die Entwicklung des Front-End sieht. Er ist seit 2006 für jQuery tätig und ist auch Präsident der jQuery Foundation.
Der Erfolg von jQuery hat es uns schwer gemacht, etwas zu ändern.
Ich begann meine Karriere als Vollzeit-C-Programmierer und beschäftigte mich mit Embedded-Systemen wie Schiffsnavigation, Robotik, Fabrikautomation und Telekommunikation. Danach wechselte ich zum Computerjournalismus und schrieb während des Windows-Magazins eine JavaScript-Kolumne. Als WinMag seine Türen schloss, war ich Mitbegründer eines Startups, das ein auf JavaScript und HTML basierendes Systemdienstprogramm für Windows aufbaute, das einen Großteil der Ratschläge automatisierte, die wir in der Zeitschrift gaben.
Als ich beim Startup war, suchte ich nach einem besseren Weg, das von uns geschriebene JavaScript und HTML zu organisieren. Ich sah den Blogbeitrag von John Resig aus dem Jahr 2005, in dem beschrieben wurde, was später zu jQuery wurde. Ich schickte ihm eine E-Mail und er antwortete, er habe eine Mailingliste für interessierte Leute eingerichtet.
Plötzlich gibt es eine Gruppe sehr talentierter Leute, die über die Bibliothek diskutieren.
Viele von ihnen sind bis heute mit dem Projekt beschäftigt. Dies ist eines von Johns wenig bekannten Talenten und ein wichtiger Grund für den frühen Erfolg von jQuery. er ist sehr inklusiv und offen für jeden.
Ich habe im Juli 2011 offiziell die Zügel von jQuery Core übernommen, obwohl ich vorher schon einiges daran gearbeitet hatte. Warum? Ich glaube, John suchte nach seiner nächsten großen Herausforderung, die er an der Khan Academy gefunden zu haben scheint.
Der Erfolg von jQuery hat es uns schwer gemacht, irgendetwas zu ändern, selbst wenn es sich um eine Verbesserung zum Besseren handelt, beispielsweise einen Bugfix oder die Verbesserung der Konsistenz der API. Da etwa die Hälfte aller Internetseiten jQuery verwenden, können wir uns ziemlich sicher sein irgendein Eine Änderung, die wir an der Bibliothek vornehmen, wird für jemanden eine grundlegende Änderung sein. Obwohl wir Betas machen, wartet die große Mehrheit der Benutzer gerne bis zum endgültigen Abschluss, bevor sie den neuen Code ausprobieren. Das bedeutet, dass wir oft blind fliegen, wenn es um die Auswirkungen einer Änderung geht.
jQuery Core ist eine Bibliothek, die das Durchlaufen, Bearbeiten und Abrufen von HTML-Dokumenten vereinfacht.
Als jQuery 2006 ankam, kannten Webentwickler die Macken der Browser und waren froh, dass sie mit jQuery die 90-Prozent-Marke für Cross-Browser-Kompatibilität erreicht haben. Viele der heutigen Entwickler haben nie in dieser Welt gelebt und sind überrascht, dass jQuery keinen kleinen Unterschied zwischen Browsern verursachen kann. Es gibt jedoch Grenzen, wie gut wir Browserprobleme umgehen können. Entwickler müssen das verstehen. In vielen Fällen verwendet die Lösung eine einfache Korrektur auf Anwendungsebene oder ein Plugin, das bestimmte seltene Fälle anspricht.
Bugs haben Priorität, ob sie eine Regression darstellen, welche Auswirkungen sie insgesamt auf die Community haben, wie schwerwiegend sie sind und wie komplex ein Fix ist. Die meisten Nichtregressionsprobleme sind Randfälle oder Browserfehler, die in die jQuery-API übergehen. Unsere Herausforderung besteht darin, diese zu beheben, ohne eine Vielzahl von komplexen Problemumgehungen zu schaffen, die die meisten Menschen nicht benötigen, und weitere Fehler in den Prozess einzuführen.
Da es mit jQuery einfach ist, einige fantastische Effekte mit nur wenigen Codezeilen und einigen jQuery-Plug-Ins von Drittanbietern zusammenzustellen, ist es unumgänglich, dass Nicht-Profis es ausprobieren werden. Manchmal werden sie erfolgreich sein, und manchmal machen sie ein großes Durcheinander, das jemand braucht, um aufzuräumen. Ich sehe keine Lösung für dieses "Problem", außer dass jQuery stumpfer gemacht wird, sodass nur professionelle Programmierer es herausfinden können. Das wird nicht passieren.
Selbst wenn Sie den IE 6/7/8 herausnehmen, gibt es in jQuery eine Menge Code, um Browserfehler und Inkonsistenzen zu beseitigen. Ich war etwas deprimiert zu sehen, wie viele dieser Zeilen für jQuery 2.0 bleiben mussten. Es scheint, dass alle Browser-Hersteller zu beschäftigt sind, glänzende neue Funktionen wie CSS3 zu implementieren, um die grundlegenden Funktionen zu korrigieren. Und warum sollten sie sich darum kümmern, das Problem zu beheben, da jQuery es behebt und sich daher niemand beschwert Sie?
In den MV * -Frameworks befanden sich DOM-Bibliotheken vor sechs oder sieben Jahren, als jQuery auf den Markt kam. Es gibt eine große Vielfalt an Gestaltungsmöglichkeiten, was eine gute Sache ist. Die meisten dieser Frameworks sind froh, dass jQuery sich mit den browserübergreifenden DOM-Problemen befassen kann, sodass sie sich auf das Design von Anwendungen auf höherer Ebene konzentrieren können. Wir ergänzen uns auf jeden Fall.
Ich scherze gern, dass "Core nicht fertig ist, bis die Benutzeroberfläche nicht ausgeführt wird."
jQuery Core ist eine Bibliothek, die das Durchlaufen, Bearbeiten und Abrufen von HTML-Dokumenten vereinfacht. Manchmal möchten die Leute die Grenzen verschieben und fragen, warum wir SVG-, VML- oder andere Webbish-Technologien nicht unterstützen. Dies ist jedoch der Zweck von Plugins. Wir möchten, dass die API von jQuery auf DOM-Vorgänge konzentriert bleibt. Wenn Sie darüber hinaus in der Kernbibliothek vorgehen, würde dies zu einer Aufblähung führen, die nur wenige Menschen benötigen.
jQuery Core kann als AMD-Modul mit Namen verwendet und dynamisch geladen werden. Im Allgemeinen sind benannte Module nicht gern gesehen, aber so viele jQuery-Plugins erwarten, dass sie ein globales jQuery-Objekt gemeinsam nutzen. Ich bin mit dem aktuellen Stand des JavaScript-Moduls nicht zufrieden, und ich bevorzuge einen einfachen Kombinations- und Minimierungsprozess für die meisten meiner Arbeiten. Dennoch ist AMD so populär, dass wir wollten, dass jQuery Core dies unterstützt, damit AMD-Benutzer jQuery beispielsweise von einem CDN laden können.
Die Problemumgehungen für den IE 6/7/8 machen mehr als zehn Prozent der Gesamtgröße der jQuery 1.9-Bibliothek aus. Diese Problemumgehungen wirken sich auch auf die Leistung aus. Es gibt viele Orte, an denen diese Problemumgehungen nicht benötigt werden, wie z. B. Windows 8-Apps, Chrome- und Firefox-Plugins, PhoneGap / Cordova-Apps auf einer bestimmten mobilen Plattform oder node.js-Programme, bei denen eine Bibliothek wie Cheerio zum Laden von jQuery verwendet wird.
Dies ist das Hauptpublikum für jQuery 2.0 im Moment. Die meisten Internet-Websites sollten diese älteren IE-Versionen mithilfe von jQuery 1.9 weiterhin unterstützen.
Zum Beispiel sehe ich die Target- oder Wal-Mart-Websites, die jQuery 2.0 verwenden, mindestens einige Jahre lang nicht. IE8 Benutzer haben auch Geld! Da die beiden APIs synchron sind, ist es möglich, bedingte Kommentare zu verwenden, um die eine oder andere für einen bestimmten Browser einzubeziehen. Aber um ehrlich zu sein, ich glaube nicht, dass es den Aufwand wert ist.
Da jQuery UI und Mobile von Core abhängig sind, konsultieren wir sie bei Bedarf zu Roadmap-Fragen. Diese Projekte führen auch ihre Unit-Tests mit unserem neuesten Build direkt von Github durch, sodass wir sofort wissen, ob wir etwas kaputtgemacht haben. Trotzdem möchte ich gerne scherzen, dass "Core nicht gemacht wird, bis die Benutzeroberfläche nicht ausgeführt wird", und es gibt in der Regel einige Störungen, die wir nach jeder Veröffentlichung feststellen können. QUnit ist ein bisschen anders; wir sind ihr Klient. Manchmal fragen wir sie nach Funktionen, und gelegentlich durchbrechen ihre Aktualisierungen unsere Komponententests. So bekommen wir einen Vorgeschmack auf unsere eigene Medizin.
Wir betrachten die jQuery-Konferenz als eine Zusammenkunft für Entwickler, die Websites und Webanwendungen erstellen. Einiges von dem, was sie wissen wollen, ist über jQuery, aber wir wollen dort nicht aufhören. Jeder gute Entwickler sollte seinen Horizont erweitern und weiterhin Werkzeuge und Techniken erlernen, mit denen er sich verbessern kann.
Innovationen kommen aus allen Richtungen. Die MV * -Konfliktkriege führen wahrscheinlich zu viel besseren und schnelleren Ansätzen bei der Entwicklung von Web-Apps und Websites. Zweifellos sehen wir dort eine Konsolidierung, ähnlich wie bei jQuery.
Responsive Design ist ein weiteres großes Thema, und ich hoffe, dass Verbesserungen in CSS und Responsive Images die Implementierung im kommenden Jahr erleichtern werden.
Zu diesem letzten Punkt arbeitet jQuery mit den Standardgruppen von W3C und ECMA zusammen, um sicherzustellen, dass die Webentwickler in den Gräben bei der Entscheidungsfindung vertreten sind.
Accentsconagua