Warum Inhaltsmenschen etwas über JavaScript wissen sollten

In der letzten Woche des Semesters habe ich in unserer Lehrveranstaltung Webbasiertes Arbeiten versucht, die Erstsemester unseres Journalismus-und-PR-Erstsemester in JavaScript einzuführen. Ich wollte

• erklären, warum man JavaScript verwendet,
• zeigen, was die Verwendung von JavaScript über die Besonderheiten des WWW sagt.

Ich hatte nicht die Zeit, mich gründlich genug vorzubereiten. Leider ist es auch sehr lange her, dass ich selbst wenigstens etwas JavaScript gelernt habe. Ich habe trotzdem versucht, einige Basics zu vermitteln. Im Nachhinein denke, dass ich die Studenten und auch mich selbst hoffnungslos überfordert habe. Der Hauptgrund dafür war wohl, dass das Ziel dieser Lehrveranstaltung nicht klar war—mir nicht und deshalb auch den Studenten nicht. Warum müssen angehende Journalisten und Kommunikatoren überhaupt wissen, was JavaScript ist?
Eine ganz grobe Analogie: Ein Journalist heute, der nicht weiss, was JavaScript ist, ähnelt einem Printjournalisten, der Papier und Druckerschwärze kennt, aber nicht weiss, was eine Druckmaschine ist. Er kennt eine wichtige Rahmenbedingung seiner Arbeit nicht. Er mag dann dazu in der Lage sein, Papier mit Texten oder Bildern zu befüllen, aber er versteht seine eigene Rolle, seine Aufgabe, höchstens unvollständig.
Im Kern begreift man, wenn man die Bedeutung von JavaScript nicht kennt, nur einen Teil des Web, vor allem nicht seine Dynamik und seine Erweiterbarkeit. Inhaltsverantwortliche müssen nicht mit JavaScript programmieren können. Sie sollten aber den Zusammenhang zwischen JavaScript, HTML und CSS verstehen.
Was ist der Kern von JavaScript (im Browser)? Was sollten Inhaltsmenschen darüber wissen?

• Hypermediale Inhalte haben ein Verhalten. Zu hypermedialen Inhalten gehört, anders als zu gedruckten Inhalten oder digitalen Reproduktionen digitaler Inhalte, ein Verhalten. Die Benutzer können etwas mit ihnen machen, und dieses Verhalten ist Teil der Publikation, es bezieht sich nicht nur auf einen Container, in dem der Inhalt enthalten ist. Eine Überschrift in einem hypermedialen Inhaltsverzeichnis lässt sich mit dem Finger berühren oder anklicken, und das entsprechende Kapitel öffnet sich. In einem nicht-hypermedialen Medium, z.B. in einem gedruckten Buch, muss ich diese Handlung selbst ausführen (oder jemand ausführen lassen, z.B. einen Bibliotheksangestellten, der mir ein Buch holt, dass ich in einem Katalog gefunden habe.)
  Wie sich in einer hypertextuellen Reportage wie Snow Fall ein Video öffnet, ist Bestandteil des Inhalts und der Erfahrung dieses einzelnen Texts. Das Präsentationslayer ist, wie es bei Roy Fielding heisst, auch ein Steuerlayer:

Hypermedia ist durch das Vorhandensein von Anwendungungsinformation definiert, entweder eingebettet in die Präsentation von Information oder als eine Schicht darüber.¹

Für Hypermedia brauche ich kein JavaScript, aber der hypermediale Charakter von Inhalten ist die Voraussetzung dafür, dass JavaScript überhaupt nötig ist.

• Das Verhalten digitalter hypermedialer Inhalte wird algorithmisch gesteuert. Hypermedia setzen nicht unbedingt Computer voraus. Die ersten Konzepte von Hypermedia wurden unabhängig von Computern entwickelt (allerdings zur selben Zeit). Realisiert wurden und werden Hypermedia aber immer als digitale Medien, deren Präsentation und Verhalten von Software, von Computerprogrammen gesteuert werden, und deren Verhalten sich deshalb auch verändern lässt, indem man die Software hinter ihnen verändert. Software wird programmiert, sie verwendet Algorithmen also Rechenregeln. Algorithmen sorgen z.B. dafür, dass sich eine bestimmte Seite im Web öffnet, wenn ich auf ein Link tippe.
  Das Web ist eine Umgebung, die von Software und Softwarenentwicklern abhängig ist. Um diese Umgebung zu verstehen, muss man auch verstehen, wie Software entwickelt wird. Dazu bietet JavaScript einen verhältnismäßig einfachen Zugang.
  Für Leute, die Inhalte machen, bedeutet die Softwareabhängigkeit, dass es von einem aktuellen Stand der Technik abhängt, was sie erstellen können. Damit ist zum einen die Frage verbunden, wie man sichert, dass die eigenen Inhalte genutzt werden können, auch wenn sich die Technik verändert (ein Problem, mit dem sich Jeremy Keith intensiv beschäftigt. Zum anderen muss man aber die technische Entwicklung kennen und oft mit Software-Entwicklern zusammenarbeiten, wenn man Inhalte produziert. Das bedeutet u.a., dass Webpublikationen in einer anderen Weise kollaborativ entstehen, als es z.B. in den Printmedien der Fall war.

• Im Web lässt sich verändern und erweitern, wie sich Inhalte verhalten. Dass Webinhalte auf Software angewiesen sind, um überhaupt hypermedial zu funktionieren, bedeutet nicht, dass man JavaScript braucht, um sie zu publizieren oder abzurufen. Es ist kein JavaScript dafür nötig, dass ich auf ein Link tippen kann. Browser und Webserver sind ganz unabhängig von JavaScript so programmiert, dass Hyperlinks funktionieren. JavaScript wird erst da relevant, wo das festgelegte Verhalten des Browsers nicht mehr ausreicht, wo es erweitert oder verändert werden muss. Moderne Browser sorgen z.B. dafür, dass Videos gestartet werden können, indem man einen Button bedient. Wenn ich will, dass — wie bei Snowfall— ein Video farbig wird, wenn man beim Lesen in seine Nähe kommt, brauche ich zusätzlich JavaScript.² Durch JavaScript werden nicht nur Inhalte, sondern es wird auch das Verhalten von Inhalten durch Informationen aus dem Netz erweiterbar. Ich kann nicht nur Texte und Bilder aus dem Web laden oder nachladen, sondern auch Programmcode, der beeinflusst, wie sie sich verhalten.
  Der Rahmen für das Verhalten von Webinhalten liegt nicht ein für alle Mal fest, sondern er lässt sich verändern. Verändern können sowohl die Anbieter von Inhalten wie die Rezipienten.
  Roy Fielding schreibt in seiner Dissertation über den architektonischen Stil des Webs, den er als Representational State Transfer oder REST bezeichnet:

Die Ergänzung zu unserer für REST definierten Menge an Einschränkungen ergibt sich durch den code-on-demand-Stil aus Abschnitt 3.5.3 (Abb. 5-8). REST erlaubt es, dass die Funktionalität des Clients erweitert wird, in dem Code in der Form von Applets oder Skripten heruntergelanden und ausgeführt wird. Das vereinfacht die Clients, weil es die Anzahl der Fähigkeiten verringert, die bereits in sie eingebaut werden müssen. Das Zulassen von Eigenschaften, die nach der Installation heruntergeladen werden können, verbessert die Erweiterbarkeit des Systems.³

• Mit JavaScript lässt sich in einer webgemäßen, nämlich offenen und standardisierten Weise erweitern, wie sich hypermediale Inhalte verhalten. Damit ich das Verhalten von Webinhalten modifizieren und erweitern, also Funktionalitäten hinzuladen kann, brauche ich einen Standard. Wenn solche Erweiterungen nur in einem bestimmten Browser funktionieren, sind sie nicht webgemäß. Außerdem stellen solche Erweiterungen ein Risiko dar, wenn sich nicht kontrollieren lässt, was sie tun. JavaScript stellt einen solchen Standard für Code dar, der im Web verteilt wird und mit dem sich Webinhalte steuern lassen. Dabei ist der Code offen—wer ihn herunterlädt kann auch hineinschauen. Das bietet den weiteren Vorteil, dass er sich leicht weiterverwenden und mit anderem JavaScript-Code verbinden lässt—ganz ähnlich, wie sich das mit HTML- und CSS-Code machen lässt. Für JavaScript als Webtechnologie ist charakteristisch, dass es offen und standardisiert ist. Dadurch lässt sich einerseits vom User kontrollieren, was passiert. Andererseits ist es leicht, Code weiterzuverwenden.

Das hätte ich den Studierenden erklären sollen—sicher ist es für eine anderthalbstündige Unterrichtseinheit viel zu viel.
Ein Problem besteht dabei darin, dass man eine minimale Literacy hinsichtlich des Programmierens braucht, um überhaupt zu verstehen, wie JavaScript funktioniert. Man kann nicht begreifen, was JavaScript ist, wenn man nicht weiss, was Scripting und Open Source ist. Ich habe versucht, auch das in meinen Vortrag zu packen. Nötig wäre etwas anderes, nämlich ein Basiskurs zur Informatik für alle unsere Studierenden.