Eine Einführung in Hitch.js und das erweiterbare Web

Der folgende Beitrag ist ein Gastbeitrag von Brian Kardell. Brian schrieb mir, nachdem ich vor ein paar Wochen Hitch.js verlinkt hatte, um mir mehr Einblick zu geben. Es ist ziemlich interessantes Zeug, also dachte ich, wir sollten das hier teilen. Hitch ist ein Artefakt einer größeren "Extensible Web"-Bewegung, die ein Manifesto, eine Community-Gruppe und ein lustiges Wort umfasst.

Was genau ist Hitch.js?

Hitch ist eine "Prollyfill Engine" (das werden wir später definieren), die sich auf CSS-Selektoren spezialisiert. Es bietet Ihnen jQuery-ähnliche Selektor-Plugins direkt in CSS selbst. Es basiert auf Vorschlägen aus der CSS-Arbeitsgruppe, die vor einigen Jahren von Yehuda Katz, mir und einigen anderen gemacht wurden, sowie auf einigen sehr langen E-Mail-Threads mit Tab Atkins von Google und Boris Zbarsky von Mozilla. Während der Diskussionen wollte ich etwas beweisen, also schrieb ich ein kleines Stück Code. Am Ende arbeitete ich mit meinem Freund Clint Hill zusammen, um es zusammenzufügen und in ein nutzbares Open-Source-Projekt umzuwandeln, das Entwicklern sofortigen Nutzen bringen könnte. Das ist Hitch.js.

Hat es das getan?

Ich glaube schon. Es hat ein paar Dinge getan: Erstens, es beleuchtet ein weiteres Beispiel dafür, worüber Alex Russell und Yehuda Katz in der Technical Architecture Group sprechen: die Notwendigkeit, das Design von Dingen zu schichten, und wie Entwickler oft Dinge neu implementieren, die der Browser bereits viel besser kann, weil wir auf hoher Ebene abgeschnitten sind und nur ein Stück ändern können. In CSS fehlen uns einige grundlegende Elemente und gute Erweiterungspunkte. Es ist überraschend schwierig, so etwas hinzuzufügen. Es hat auch dazu beigetragen, einige wichtige Mitglieder der CSS Working Group davon zu überzeugen, dass CSS so etwas braucht. Tab schrieb darüber auf seinem Blog in einem Neujahrs-Vorsatz-Post. Ich bin ziemlich zuversichtlich, dass wir in den nächsten Jahren einige gute neue Fähigkeiten in CSS haben werden. Bis dahin haben wir Hitch.

Wofür würde man es wirklich verwenden?

Das ist die entscheidende Frage: Ob es nun über Hitch oder nativ bereitgestellt wird, was könnte man mit dieser neu gewonnenen Macht tun? Ich denke, wir könnten helfen, das Web für immer zu verändern. Ich weiß, das klingt groß, aber ich glaube, es ist so. Wir könnten es nutzen, um das gesamte Modell der Standardisierung zu verbessern. Betrachten Sie dies: CSS 2 wurde im Mai 1998 zu einer W3C-Empfehlung. Wir denken vielleicht immer noch, "CSS 3" sei etwas relativ Neues – aber tatsächlich wurde der erste Entwurf für CSS 3 bereits im August 1999 veröffentlicht. Damals diskutierten sie über viel *mehr* Selektorleistung als im heutigen CSS Selectors Level 3. Denken Sie einen Moment darüber nach. Wenn Sie ein Kleinkind waren, als sie CSS 3 begannen, würden Sie jetzt Ihren Schulabschluss machen. Dafür gibt es viele Gründe, aber selbst wenn das künstlich um das Fünffache verlängert ist, bedeutet das immer noch, dass man ein paar *Jahre* warten muss, bis etwas den Prozess durchläuft, bis es wirklich jemand nutzen kann. Dann ist es manchmal nur in Nightlies oder hinter einem Flag versteckt, so dass man es für nichts "Echtes" nutzen kann. Historisch gesehen würde es dann hinter einem Präfix hinzugefügt und einige wagemutige Seelen würden beginnen, es zu nutzen, aber es ist schwierig, weil es nur in wenigen Browsern funktioniert. Das bedeutete, dass es realistisch noch ein paar *weitere* Jahre dauerte, bis es von einer ausreichend großen Zielgruppe genutzt werden konnte, um festzustellen: "Eigentlich mag ich die Hälfte dieser Selektoren nicht und warum haben sie nicht stattdessen X gemacht?" Dies wird dadurch verschärft, dass es, wenn es so weit fortgeschritten ist, *wirklich* schwierig ist, jemanden davon zu überzeugen, es zu ändern, da dies potenziell "das Web brechen" könnte, wie sie gerne sagen. Mit einem Wort, das ist *Mist*.

Wie würde es helfen, das zu ändern? Hat das etwas mit dem "Extensible Web" zu tun?

Was wäre, wenn ich Ihnen stattdessen erlauben könnte, CSS Selectors Level 4 oder 5 – oder *beliebige vorgeschlagene Selektoren jetzt* – auf eine Weise zu verwenden, die vernünftig performant ist und Sie wissen, dass die Implementierung sich nicht unter Ihnen ändert? Das sollte doch möglich sein, oder? Wenn wir *Polyfills* verwenden, um "Lücken zu füllen" und vernünftige Implementierungen für *Standards* in den am wenigsten fähigen älteren Browsern bereitzustellen, warum nicht gleich vernünftige Implementierungen der *Vorschläge* bauen, die in modernen Browsern funktionieren – **Prollyfills** – damit wir sie bewerten, iterieren und konkurrieren können? Wenn wir das täten, könnten wir direkt zum Punkt kommen, oder? Sie könnten sich jetzt beschweren, dass sie nicht gut sind, bevor sie weitergehen. Wenn wir das öffentlich auf GitHub tun würden, könnten Sie sie sogar forken und verbessern – und das würden Sie wahrscheinlich auch tun, denn seien wir ehrlich: Viel mehr Leute nutzen GitHub als sich an Web-Standards-Diskussionen beteiligen. Wir könnten sogar Daten über Nutzung, Beschwerden, Stabilität und Anbieterbewertungen sammeln, um zu entscheiden, wann etwas "reif" genug ist, um sich mit nativen Implementierungen zu befassen und diese schnell zu priorisieren.

Können Sie mir einige Beispiele geben?

Nehmen wir an, es gibt etwas im Selectors Level 4-Vorschlag, das nützlich sein könnte, wie die :local-link-Pseudoklasse, die es Ihnen ermöglicht, Links innerhalb Ihrer Domain und auf verschiedenen URL-Ebenen auszuwählen (wie Sie es oft in Navigationslinks haben). Ist es das? Sind Sie sicher, dass Sie es überhaupt verstehen? Mit Hitch können wir einen Prollyfill dafür entwickeln und teilen – tatsächlich haben wir das getan – Sie können eine Demo davon sehen. Das bedeutet, Sie können es heute tatsächlich für etwas Reales nutzen. Sie können auch helfen, es besser zu machen, forken Sie es auf GitHub und verbessern Sie es, Sie können mir einen Pull-Request senden, Ihre Anwendungsfälle teilen, Issues eröffnen oder Reftests hinzufügen. Jedes Feedback, das Sie senden, werden wir an die CSS Working Group weiterleiten.

Hier ist ein noch einfacheres Beispiel. Wir erstellen einen Selektor, der nur *externe* Links auswählt. Verlinken Sie zuerst Hitch.js

<script src="http://hitchjs.com/dist/hitch-0.6.3.js"></script>

Verwenden Sie dann die Hitch-Syntax zum Hinzufügen eines neuen Selektors. Wir stellen sicher, dass der Hostname des href mit dem Hostname des Fensters übereinstimmt.

Hitch.add([{
  
  type: 'selector',
  name: '-links-external', 
  base: '[href]',
  filter: function (match, argsString, o) {
    if (!match.hostname) {  
      return false;
    }
    return match.hostname !== window.location.hostname;
  }
  
}]);

Dann können wir den dort eingerichteten `name` in unserem CSS verwenden. Beachten Sie das spezielle Attribut im CSS, das sicherstellt, dass Hitch es parst.

<style data-hitch-interpret>
  a:-links-external() {
    background-color: yellow;
  }
</style> 

Check out this Pen!

Oder nehmen wir an, Sie hatten einen Vorschlag für einen Selektor, der in keinem Entwurf enthalten ist: Sie könnten einen Prollyfill schreiben und einen Entwurf einreichen, indem Sie ein Git wie das obige erstellen und es mit der CSS Working Group teilen. Tatsächlich ist das bereits passiert und Sie können es in unserem Beitrag "About :time – Taming the standards process." lesen. Noch besser, was wäre, wenn Browserhersteller dieses gleiche Muster wann immer möglich befolgen würden? Nun, das ist auch passiert: Adobe tat etwas Ähnliches mit einem Regions-Vorschlag – sie benutzten Hitch nicht, weil sie nichts davon wussten, aber sie schrieben eine Art One-Off, die etwas Ähnliches tut. Mozilla tat dies mit X-Tags und Google mit Polymer – beide können sich freier entwickeln, in jedem modernen Browser verwendet werden und vielleicht sogar ein wenig außerhalb des Browsers konkurrieren, bevor wir uns eilig damit befassen und uns festlegen. Wir sind der gleichen Grundidee mit Futures/Promises und Navigation Controller gefolgt. Ich betrachte all dies als große Erfolge, die uns geholfen haben, viele Gruppen zu koordinieren und viele Köpfe auf neue Weise zusammenzubringen.

Wie bezieht sich Hitch auf Web Components?

Es gibt einige Dinge zu Web Components, aber diese basierten auf einem früheren Entwurf. Es datiert Mozilla's X-Tags oder Google's Polymer vor und wir haben kein wirkliches Interesse daran, mit ihnen zu konkurrieren. Tatsächlich würden wir gerne zusammenarbeiten. Beide sind erheblich besser und basieren auf aktualisierter Arbeit. Es stellte sich heraus, dass wir intern 95% der Dinge taten, die notwendig sind, um ein einfaches Element "Upgrade" leicht zu machen, also haben wir es freigelegt. Wenn Sie nur in modulare "Widgets" zerlegen wollen, können Sie wahrscheinlich ohne mehr auskommen. Aber darum geht es nicht.

Sie erwähnten, dass Hitch kein Präprozessor war, warum nicht?

Wie es heute steht, enthält Hitch einige Aspekte eines CSS-Präprozessors, ist aber kein Präprozessor. Es ist nicht als Ersatz für Dinge wie Sass gedacht, es stellt sich nur heraus, dass die interne Freigabe einer einfachen Vorverarbeitung einfach ist, also geben wir sie frei. Wenn Sie nur eine einfache Token-Ersetzung benötigen, kommen Sie wahrscheinlich ohne mehr aus, aber darum geht es nicht. Tatsächlich ist die Eingabe für die eigentliche "Engine" in Hitch nicht einmal CSS, sondern eine Art von Parse-Baum. Sie ist so geschichtet, dass wir das Vorverarbeitungsstück auslagern können, wenn wir mit bestehenden Dingen wie Sass zusammenarbeiten. Wir haben es vorerst einfach gehalten, weil einige Leute keinen robusten Präprozessor haben und keinen wollen, und wir wollen ehrlich gesagt nicht versuchen, mit diesen Leuten zu konkurrieren. Es ist besser für uns, mit ihnen für diesen Teil als Optimierung zusammenzuarbeiten.

Wie hängt all das mit dem "Extensible Web" zusammen?

Darum geht es in The Extensible Web Manifesto – darum, die Art und Weise zu ändern, wie wir über Standards denken. Hitch ist älter als das, daher kann ich nicht ehrlich sagen, dass es das "perfekte" Beispiel für all das ist. Mehrere von uns kamen etwa zur gleichen Zeit zu sehr ähnlichen Schlussfolgerungen, und wir diskutieren nun schon lange und feilen daran. Aber es veranschaulicht, zumindest auf hoher Ebene, einige der Wege, wie wir das Modell ändern und es guten Entwicklern ermöglichen wollen, #extendthewebforward zu unterstützen. Wenn Ihnen das alles zusagt, ermutige ich Sie, es zu lesen. Und hoffentlich auch zu unterzeichnen. Dann erzählen Sie es einem Freund!