Gross hat jedoch nicht nur das Frontend-Framework HTMX ersonnen - er hat auch die Skriptsprache Hyperscript erfunden, ist erfolgreicher Buchautor sowie der Kopf hinter der satirischen Dev-Kultfigur "The Grug Brained Developer". Darüber hinaus lehrt er als Professor für Software Engineering an der Montana State University.

Die Kollegen unserer US-Schwesterpublikation Infoworld.com hatten die Gelegenheit, sich mit dem vielbeschäftigten Softwareexperten über seine zahlreichen Projekte, das Scheitern von REST, die Bedeutung von JavaScript und die sozialen Zwänge der Softwarebranche auszutauschen.

"JavaScript hat zu viele Funktionen"

Starten wir mit "The Grug Brained Developer" - das Portal scheint auf nahezu alle programmierbezogenen Fragen die richtige Antwort zu haben?

Carson Gross: Danke, das Lob weiß ich zu schätzen. Ich denke auch, dass es für die allermeisten Entwickler lesenswert ist. Allerdings wollte ich mit diesem Projekt eher jüngere Entwickler ansprechen. Man sollte hier keine Perfektion erwarten - das ist auch schwer, wenn es um einen Höhlenmenschen-Dev geht, der auch ein bisschen witzig sein soll. Aber ich denke die meisten Ratschläge von 'The Grug Brained Developer' gehen als solide durch.

Vor allem ist es wahr, dass viele Probleme in der Softwareentwicklung darauf zurückzuführen sind, dass man sich als Entwickler für smart hält.

Gross: Ich glaube, jeder mit einem gewissen Maß an Entwicklungserfahrung kennt diese Situation, wenn man plötzlich merkt, dass man sich verfahren hat und einem das System über den Kopf wächst. Ich weiß nicht, ob das immer daran liegt, dass man sich für zu schlau hält - oder vielmehr daran, dass man einfach nicht erkennt, wann die Dinge anfangen, zu kompliziert zu werden. Dazu kommt die soziale Dynamik in technischen Berufen, die oft diejenigen abstraft, die ganz offen zugeben, wenn ihnen etwas zu kompliziert ist.

my slightly different take on this idea is that the primary dynamic here isn't posturing (although there is certainly some of that, esp. in tech marketing) but that rather it's fear:https://t.co/eKPafPFaO0 https://t.co/Aekv1pzP3R pic.twitter.com/nknLSaWeXf

— htmx.org / htmx.org (same thing) (@htmx_org) January 7, 2024

Wie ist das, als Software-Professor zu lehren?

Gross: Ich unterrichte sehr gerne, auch wenn das definitiv Nachteile mit sich bringt. Die miese Bezahlung und die Bürokratie zum Beispiel. Aber es bringt auch viele Vorteile - insbesondere macht es mir Spaß, meine Studenten so weit zu bringen, dass sie das Gefühl haben, selbständig programmieren zu können.

Teilen Sie mit uns Ihre Gedanken zu JavaScript?

Gross: JavaScript ist meiner Meinung nach eine gute Skriptsprache, aber keine tolle Allzwecksprache. Für mich fühlt sie sich auf eine etwas bizarre Art und Weise an wie C++. Es gibt in JavaScript zu viele Funktionen und Möglichkeiten, Dinge zu tun. Auf der anderen Seite bringt die Sprache ein überzeugendes Feature mit: Sie läuft im Browser. Das macht sie meiner Einschätzung nach auf absehbare Zeit zur führenden Skriptsprache im Web.

Apropos Skriptsprachen: Hyperscript ist ebenfalls ein beeindruckendes Projekt, das Sie auf den Weg gebracht haben. Allerdings wirkt es so, als sei das für Sie nur eine Art spaßige Nebenbeschäftigung. Was haben Sie diesbezüglich für technische Erfahrungen gesammelt - beispielsweise als es darum ging, den Parser zu implementieren?

Gross: Hyperscript ist eine Skriptsprache, die mit JavaScript "konkurriert". Sie basiert auf HyperTalk, der Skriptsprache für HyperCard, und verfügt über Funktionen, die meiner Meinung nach eine bessere Authoring-Erfahrung ermöglichen, wenn es darum geht Skripte auf einer Webseite zu erstellen. Beispielsweise löst die Hyperscript-Laufzeitumgebung automatisch 'Promises' auf, auf die sie stößt, damit die Entwickler sich nicht damit befassen müssen. Dabei nutzt Hyperscript eine natürliche, englischsprachige Syntax - die polarisiert. Es ist definitiv ein Projekt, in das ich viel Leidenschaft einbringe. Ich hoffe, dass ich es in diesem Jahr schaffen werde, Version 1.0 fertigzustellen - nachdem HTMX 2 ausgeliefert ist.

Was Ihre Frage angeht: Hyperscript ist in JavaScript als Lexer, Parser und eval-basierte Laufzeitumgebung implementiert. Ich war etwas überrascht, dass die JavaScript-Laufzeitumgebung dafür schnell genug ist. Ich würde zwar nicht unbedingt versuchen, einen Bitcoin-Miner in Hyperscript zu implementieren, aber es ist schnell genug für leichtes DOM-Scripting. Der Hyperscript-Parser und die Laufzeitumgebung liegen genau an der Grenze zu dem Level an Komplexität, das ich bereit wäre, mit JavaScript zu bewältigen.

HTMX ist ein weiteres Ihrer Projekte - das zudem zumindest die Möglichkeit einer echten REST-Architektur wiederherzustellen scheint?

Gross: Es war ein wildes Jahr für HTMX. Für alle Leser, die noch nichts davon gehört haben: Es handelt sich um eine JavaScript-Bibliothek, mit der man Attribute hinzufügen kann, die den href- und action-Attributen von Links und Formularen in Standard-HTML sehr ähnlich sind. Mit diesen Attributen lassen sich AJAX-Requests auslösen und dann Teile des DOM durch das HTML ersetzen, mit dem der Server antwortet.

Könnte man sagen, dass HTMX das Vokabular des altehrwürdigen HTML, um einige moderne Anwendungsfälle erweitert - insbesondere AJAX?

Gross: Eine gute Erklärung. Ich sage manchmal auch, dass HTMX 'HTML als Hypermedia vervollständigt', da es jedem Element auf der Seite erlaubt, als Antwort auf ein Ereignis eine HTTP-Anfrage zu stellen und diese Antwort dann irgendwo im DOM zu platzieren.

Das mag nun ziemlich simpel klingen - ist es auch - aber mit dieser kleinen HTML-Generalisierung werden viele UX-Patterns möglich, die bislang JavaScript vorbehalten waren. Beispiele sind etwa 'Infinite Scrolling', 'Lazy Loading' oder serverseitige As-You-Type-Validierung.

"Es kann der Karriere schaden, wenn man nicht smart genug wirkt"

Könnten Sie unseren Lesern bei dieser Gelegenheit den Unterschied zwischen REST, wie es beabsichtigt ist, und REST, wie es üblicherweise implementiert wird, näher erläutern?

Gross: Heute bedeutet dieser Begriff im Wesentlichen 'JSON-APIs über http' - und das wird vermutlich auch noch lange so bleiben. Ursprünglich war REST eine Beschreibung der Funktionsweise des World Wide Web, respektive seiner Netzwerkarchitektur. Dabei spielten JSON-APIs keine Rolle, weil es die noch nicht gab. Die Browser-Interaktionen liefen lediglich über Links und Formulare. Der Begriff selbst entstammt einer berühmten Dissertation von Roy Fielding, der eine Reihe von Einschränkungen definierte, denen ein RESTful-System entsprechen muss.

Die meisten JSON-APIs, die heutzutage als 'RESTful' bezeichnet werden, erfüllen diese Anforderungen nicht. Noch verrückter ist, dass eine einfache statische Website mit ein paar HTML-Seiten, die miteinander verlinkt sind, all diese Anforderungen erfüllt. Jemand, der ersteres erstellt, ist also in gewisser Hinsicht ein besserer REST-Ingenieur als ein 'RESTful'-JSON-API-Engineer. Ich denke, es lohnt sich, die ursprüngliche Bedeutung des Begriffs zu durchdringen, um zu verstehen, warum das Web so flexibel ist, wie es ist.

Sie sind Co-Autor von "Hypermedia Systems". In dem Buch vertreten Sie die These, dass die Art und Weise, wie das Web gestaltet ist, eine Anwendungsarchitektur bietet, auf der wir aufbauen können - wenn wir sie richtig betrachten. Können Sie das näher erläutern?

Gross: Zunächst ist das korrekt wiedergegeben. HTMX versucht nun, auf dieser Netzwerkarchitektur aufzubauen - statt sie durch eine neue ersetzen zu wollen. In meinem Beitrag zum Buch versuche ich, die systemische Natur von gut funktionierenden Hypermedien zu skizzieren. So habe ich beispielsweise lange Zeit nicht erkannt, wie wichtig der Hypermedia-Client ist, damit das 'Uniform Interface' reibungslos funktionieren kann. Man braucht dazu tatsächlich ein ganzes System - Hypermedia wie HTML, ein Netzwerkprotokoll wie HTTP, Hypermedia-Server und Hypermedia-Clients -, damit das klappt.

Wie kommt es, dass wir wissen, dass Komplexität schlecht für uns ist, wir aber dennoch einen Hang zu ihr aufweisen?

Gross: Nun, ich denke, auch hier ist der Druck der Industrie im Spiel. Software ist eine brutale Branche - es kann der Karriere schaden, wenn man nicht 'smart genug wirkt'. Wir alle verspüren diesen Druck zu beweisen, dass wir klug sind und es möglichst nicht zuzugeben, wenn Code von jemand anderem verwirrend ist oder zu komplex erscheint.

Ich habe Verständnis für diese Dynamik und die Engineers, die diesem Druck erliegen. Das ist auch ein Grund, warum ich erfahrene Software-Ingenieure, die eine sichere Position innerhalb einer technischen Organisation innehaben, dazu ermutige, es lautstark zu verkünden, wenn ihnen die Dinge zu kompliziert erscheinen. Das befähigt dann die jüngeren Engineers, ihre Bedenken ebenfalls zu äußern und der Druck wird - zumindest bis zu einem gewissen Grad - herausgenommen. (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.