Transcript
Lucas Dohmen: Hallo und herzlich Willkommen zu einer neuen Folge des INNOQ Podcasts! Heute habe ich mir den Lars eingeladen. Hallo Lars!
Lars Hupel: Hallo Lucas!
Lucas Dohmen: Und heute machen wir mal etwas Neues, wir probieren mal eine kleine Diskussion aus. Also wir haben heute kein Interview, wie wir das üblicherweise haben, sondern wir haben eine Diskussion und wollen… Eine Diskussion, die wir in einer internen Schulung angefangen haben, mal im Podcast weiterführen. Und das war so, dass wir eine Webarchitektur Schulung intern gehalten haben und der Lars hat ein bisschen Anstoß genommen an unserem Verherrlichen von Postel‘s Law und da wollten wir einfach mal drüber diskutieren. Also wie wir Postel‘s Law einordnen und welche anderen Laws es sonst noch so gibt, die das vielleicht beeinflussen. Genau und um damit zu starten, starten wir erstmal damit: Was ist Postel‘s Law? Weil sonst können wir das schlecht diskutieren. Postel‘s Law ist auch als das Robustness Principle bekannt und ist zusammengefasst mit dem Satz: ‚Be conservative in what you do, be liberal in what you accept.‘. Und das kam aus diesen ganzen AFCs am Start von dem TCP AFC stand das mit drin und das hat halt ein Mensch darein geschrieben, der hieß John Postel. Genau, und auf diesem Prinzip bauen sehr viele Protokolle und Ideen, gerade so im Web Bereich, auf. Und genau, irgendwas stört den Lars daran. Was stört dich denn da dran?
Lars Hupel: Ja also, wenn ich das vielleicht gleich mal sehr zugespitzt zusammenfassen kann, also Postel‘s Law sagt im Prinzip: Du kannst mehr oder weniger jeden Unsinn auf irgendeinen Service oder auf irgendein Protokoll draufwerfen und du hast quasi Erwartungen, dass dein Gegenüber das dann irgendwie interpretieren kann. Also was vielleicht die Allermeisten kennen ist halt HTML. In HTML kann man mehr oder weniger beliebige Syntax Errors machen und die Browser versuchen auf Biegen und Brechen da irgendwie was dann zu rendern. Also das ist extrem selten, dass der Browser einen Syntax Error anzeigt, eigentlich nur wenn man irgendwie malform XML oder malform JSON oder sowas sendet. Aber wenn der Server irgendetwas mit dem Content-type HTML ausliefert, dann kann da eigentlich mehr oder weniger jeder Unsinn drinstehen und irgendetwas wird immer angezeigt, also wenigstens der Text ist dann zu mindestens zu sehen, Layout kann halt kaputt sein, aber ja… Also der Browser versucht halt immer irgendetwas zu parsen.
Lucas Dohmen: Genau. Also ein Beispiel dafür wäre jetzt: Wir haben eine unsorted list und die geht auf und da drin haben wir ein list item, das geht auf, da kommt irgendwie Text und dann geht direkt die unsorted list zu und das einzelne list item ist nicht zugegangen. Das wäre etwas was der Browser einfach akzeptiert und dann sich selber überlegt: Ach, da hat die Person, die das geschrieben hat, bestimmt gedacht: Ich mache mal… Habe das list item vergessen, deswegen füge ich das jetzt für dich ein. Das wäre jetzt so ein Beispiel dafür, richtig?
Lars Hupel: Genau! Und so… Ich weiß nicht genau ob dieser Begriff so noch üblich ist, aber so als ich angefangen habe, so HTML Seiten zu bauen, schon sehr lange her, da wurde das unter dem Begriff Tag soup, also Markup Suppe irgendwie zusammengefasst und dann gab es da dann so parser dafür, also wenn man irgendwie HTML Maschinen verarbeiten wollte, dann musste man halt irgendwie so Tag soup parser benutzen. Da gibt es zum Beispiel bei Python einen, der heißt beautiful soup und man musste da ziemliche Handstände machen, um irgendwie zu versuchen, was da so im Internet rumschwirrt, sinnvoll verarbeiten zu können, weil dadurch, dass die Browser alles akzeptieren, dadurch dann halt die Leute, die Webseiten bauen dann halt auch alles Mögliche machen und da kommen wir glaube ich schon in den Kernpunkt meiner Kritik rein. Dadurch, dass Postel‘s Law quasi konstatiert, dass man liberal sein soll, was man annimmt, dann machen das Leute einfach auch. Postels Law hat ja eigentlich zwei Teile. Das ist nicht nur be liberal in what you accept, sondern auch be conservative in what you sent und dieser Teil wird halt sehr oft ignoriert. Das heißt Leute senden dann auch jeden Unsinn. Und ich glaube, was das Problem auch so ein bisschen verschärft hat, ist, dass dazumal bei HTML, bis einschließlich HTML4, die Syntax von HTML selbst schon sehr freizügig war. Also HTML selber war ja früher basierend auf SGML, das heißt glaube ich Standardized Generalized, irgend sowas, Markup Language und das SGML selbst hat auch ganz viele Möglichkeiten gelassen. Also das so ganz viel was eigentlich nach Tag soup aussieht, ist eigentlich gar keine Tag soup, weil das irgendwie komische agcases von der Syntax benutzt und viele Browser hatten auch Probleme mit der richtigen SGML Syntax und hatten dann auch korrekte Syntax teilweise falsch interpretiert, weil das auch super schwer ist das richtig zu parsen. Und diese zwei Faktoren zusammen, nämlich einerseits, dass Browser versuchen irgendwie alles zu interpretieren und dass SGML eben auch sehr flexibel ist haben eben dazu geführt, dass Leute eben halt auch alles Mögliche tun. Und dann zum Beispiel die Maschinenlesbarkeit sehr schwer geworden ist dadurch.
Lucas Dohmen: Also da wäre jetzt auch ein Beispiel vermutlich self-closing Tags, die sich selbst schließen, obwohl sie nicht mit diesem Slash aufhören wie bei XHTML, also den HR.
Lars Hupel: Genau, also da gibt es noch ganz andere Sachen. Da gibt es zum Beispiel im SGML diese short tags, wo man zum Beispiel einen schließenden Tag machen kann indem jemand zum Beispiel so etwas schreibt wie: </> ohne den Tag Namen zu wiederholen, also so etwas gibt es da auch in bestimmten Fällen. Und da haben sich viele Browser damit sehr schwergetan und ich glaube tun sich noch immer schwer damit.
Lucas Dohmen: Genau, also grundsätzlich macht das natürlich die Arbeit für jemanden der einen Browser Engine schreiben will auf jeden Fall schwerer, macht auch die Arbeit schwerer für jemanden der vielleicht einen HTML parser aus irgendeinen anderen Grund schreiben will, aber es ist natürlich so, dass wenn ich jetzt anfange mit Web Entwicklung und alles was ich habe ist irgendwie so ein Hetzner Webspace, wo ein Apache und ein FTP Programm wie Cyberduck oder sowas und halt irgendwie ein Text Editor, dann kann ich schon relativ einfach anfangen meine erste Webseite zu bauen. Ich brauch nicht… Also diese Angst davor vor Fehlermeldungen kommt halt nicht so sehr auf. Also ich habe mit verschiedenen Programmieranfängern und Anfängerinnen, vor allem mit Kindern, erste Webseiten gebaut und dieses einfach was zu bauen und das funktioniert direkt, macht halt viel von den Frust, was bei vielen von denen Programmiersprachen aufkommt, entfernt den halt. Also wenn ich eine Programmiersprache habe und das erste was passiert ist irgendwie es fliegt eine exception, alles ist rot, dann ist das so ein frustrierendes Erlebnis was viele davon abschreckt weiterzumachen. Aber die erste HTML Webseite zu bauen ist halt ein sehr, sehr schönes Erlebnis, weil es funktioniert meistens halt einfach. Selbst wenn man einen Fehler macht versteht das der Browser und ich habe es ganz, ganz oft gesehen, wie halt jetzt ein Kind dasitzt und macht halt den Tag nicht zu und nachher funktioniert es trotzdem. Und es sieht so aus, wie das Kind das halt haben wollte und ich finde, dass ist halt auch etwas was vielleicht gar nicht bei Postel‘s Law so sehr der Fokus war, dass das so Einsteigerfreundlich ist, aber für mich macht das viel aus, gerade auf so einer Ebene wie HTML. Also jetzt, keinen Anfänger erkläre ich jetzt irgendwie, wie man HTTP von Hand irgendwie baut, aber bei HTML ist das, finde ich, ein ganz, ganz wichtiger Faktor, der da diese barrier to entry, also diese Einstiegshürde extrem senkt, dass ich nicht überall Fehlermeldungen sehe und alles ist kaputt.
Lars Hupel: Ja, absolut! Und wie gesagt, bin ich auch ganz bei dir. Beziehungsweise, da wäre ich bis vor einigen Jahren bei dir gewesen, mittlerweile sehe ich das wieder ein bisschen anders. Letztendlich habe ich auch so angefangen, also ich habe damals mit meiner ersten privaten Website, die dann glücklicherweise nie das Licht der Welt erblickt hat, die komplizierten Frames und sowas dann gebaut und das war wahrscheinlich alles ganz kaputt und da war auch so ein bisschen JavaScript mit drinnen und funktioniert halt trotzdem irgendwie, auf irgendeine Art und Weise. Und das ist natürlich auch das was den Ursprünglichen Reiz des Webs ausgemacht hat, dass quasi jeder einfach hergehen kann und irgendetwas publizieren kann, ohne da irgendwie groß was tun zu müssen dafür. Also wie gesagt, einfach irgendein Webspace, ein FTP Client, fertig. Ich bin mittlerweile von dieser Vision wieder ein bisschen abgerückt, einfach aus dem Grund, weil das heutzutage einfach gar nicht mehr so einfach ist eine vernünftige Website zu hosten, also mittlerweile sind da Sachen sehr viel komplizierter geworden. Sowas wie shared hosting ist eigentlich meiner Erfahrung nach komplett aus der Mode gekommen und heutzutage müsstest du halt schonmal ganz viele Sachen lernen, um überhaupt loslegen zu können. Also ich meine wir beide kennen das, wenn du irgendwie ein Front-end Projekt startest, dann musst du erstmal drei layers von Pools irgendwie verstehen und damit der Browser nicht rummeckert mit Sicherheitswarnungen musst du das auf eine HTTPS Seite deployen, weil sonst wir rumgemeckert und sowas. Also ich glaube, diese Vision von…, diese egalitäre Vision von, dass da irgendwie alle mitmachen können, die ist einfach nicht mehr gegeben. Das merkt man zum Beispiel daran, dass die Browser mittlerweile eben ganz, ganz hohe Standards an HTTPS Verbindungen ansetzen. Also wenn ich mir da irgendwie selber einen Apache baue oder was auch immer, dann ist es sehr unwahrscheinlich, dass das über lange Zeit hinweg funktioniert, weil halt man da ständig up to date bleiben muss. Das heißt, heute bleibt einen nur noch übrig sowas wie vielleicht GitHub Pages zu benutzen oder keine Ahnung irgendwie Netlify oder sonst irgendwelche von den Diensten. Da hat man halt schonmal eine ziemliche Hürde, um dann da überhaupt reinzukommen damit. Also die Idee wäre halt, wenn man sagt: Okay, ich muss eh solche Tools benutzen. Dann müsste ich halt die Tools entsprechend so bauen, dass es immer noch Einsteiger/-innen freundlich ist.
Lucas Dohmen: Aber… Also ich verstehe was du sagst, aber auf der anderen Seite denke ich, wenn du halt quasi die barrier to entry quasi in anderen Teilen sowieso schon hast, dann ist es ja für mich kein gutes Argument zu sagen: Wenn wir die eh schon haben, dann können wir die ruhig auch bei HTML haben, weißt du? Ich glaube, dass es durchaus möglich ist, wenn wir jetzt…, also wenn ich jetzt an so alte Webhoster denke, also vielleicht wirklich mal nur HTML konnte und vielleicht noch PAP, da ist es jetzt für diese Hoster heutzutage kein Problem mehr jetzt irgendwie Let’s Encrypt automatisch daran zu klicken. Also dass das automatisch mit Let’s Encrypt TLS Kommunikation aufmacht. Und natürlich wird eine Seite, die jemand so von Hand runtercoded, keine Ahnung hat, die wird vielleicht nicht die besten Performance Zahlen bekommen, das besten Ranking, weil das JavaScript ist vielleicht nicht gebundled, das sind vielleicht alles einzelne JavaScript Dateien, die von überall her kopiert sind, aber das ist für mich nicht so schlimm. Natürlich ich, als jemand der professionelle Webentwicklung macht, möchte ich natürlich diese Sachen haben. Ich möchte dafür sorgen, dass das quasi die optimale Auslieferung ist und ich werde mein HTML auch garantiert valide schreiben. Ich werde das auch validieren, aber das zu erfordern von jemanden finde ich eine andere Sache. Also ich bin persönlich ein Fan davon, dass halt quasi…, dass der Browser das alles erstmal grundsätzlich akzeptiert, aber dass ich halt so etwas wie ein Linter, also eine Software, die das halt prüft, ob das gut gemacht ist, gibt, damit jemand der diesen Anspruch daran hat, den auch erfüllen kann. Das man halt nicht erzwingt, dass das super valide und was weiß ich ist, sondern dass man halt Tools baut, die einen dabei helfen können, das zu tun, aber ohne das zu erzwingen, um eine Webseite machen zu können.
Lars Hupel: Also mein Punkt ist halt… geht halt sehr in die Richtung, wir müssen uns eh auf Tools verlassen. Also ohne Tools können wir heutzutage keine Webseiten mehr bauen, wir können sie auch ohne Tools nicht deployen. Warum nutzen wir dann nicht die Tools dann eben auch voll aus? Zum Beispiel, wenn ich… angenommen ich würde jetzt auf GitHub Pages deployen wollen, das ist glaube ich etwas, dass man durchaus Einsteiger/-innen zumuten kann. Dass sie sich ein GitHub Account klicken und irgendwie vielleicht ein git-Repo oder sowas und dann nutzen sie vielleicht VS Code, weil VS Code ist halt ganz nett, weil da die ganzen Plug-Ins und sowas drin sind, dann kann ich halt mit wenigen klicken auf Commit und Push und fertig. In VS Code, wenn ich da einen HTML Editor benutzte, dann ist es nicht so schwierig validen HTML Code zu produzieren. Wenn ich zum Beispiel einen öffnenden Tag eintippen, dann wird halt gleich der schließende Tag miteingefügt. Dann muss eigentlich… dann muss ich mich schon ein bisschen anstrengen, um dieses Zeug kaputt zu machen. Und ich kriege dann eben auch die entsprechenden Unterringelungen und ich persönlich glaube auch nicht, dass die HTML Syntax so extrem schwierig ist, also es gibt ja nicht mal so ein type checkout und sowas. Also es kann halt sein, dass das Layout dann vielleicht kaputt ist, weil ich irgendetwas falsch gemacht habe, aber was jetzt per se erstmal kein Syntax Error ist. Ich glaube also tatsächlich, wenn man eben das Tooling benutzt, was man hat, also zum Beispiel einen vernünftigen Editor, dann kriegt man das schon gut hin und ich würde mich halt vielleicht von der Vorstellung lösen, dass man Webseiten mit Notepad.exe halt irgendwie bauen kann. Weil dann ist es natürlich sehr schwierig, denn es ist halt auch so, dass gerade jetzt Leute, die neu anfangen, die müssen sich halt auch Sachen zusammenkopieren, weil niemand der neu anfängt weiß, dass man in Notepad.exe dann halt irgendwie mit ‚!DOCTYPE html‘ anfängt und wie zum Geier jetzt der Style Tag aussieht. Also gerade für so etwas verlässt man sich eh auf Stack Overflow oder auf irgendwelche Tutorials oder vielleicht auf Mentor/-innen. Und gerade dann könnte man halt auch das Tooling sehr schön mit dazunehmen und könnte halt sagen: ‘Ja, okay, dann mache ich halt code completion und sowas, weil das macht es halt auch noch einmal einfacher und dann kann ich das auch akzeptieren, dass dann VS Code mir vielleicht irgendetwas umkringelt und mich dann frühzeitig halt drauf aufmerksam macht, dass da irgendetwas faul ist. Letztendlich ist es halt wirklich eine Abwägung, also sehe das voll ein, dass man halt wenn der Browser irgendwie rummeckert, dass das ein barrier to entry ist, auf der anderen Seite ist das natürlich nicht alles worauf wir unseren Fokus legen müssen. Sondern wir müssen unseren Fokus darauflegen, wie komplex auch die Browser sind und wie komplex unser anderweitiges Tooling ist, was HTML konsumiert. Weil einerseits ist es natürlich schön, wenn wir mehr Leute in das Web reinkriegen, aber wenn wir jetzt wirklich da ausschließlich unseren Fokus draufliegen, haben wir an anderer Stelle ganz, ganz viel zu bezahlen dafür. Und ich glaube da muss man halt einfach irgendwie eine Abwägung machen und im Web ist meiner Meinung nach die Abwägung momentan zu sehr negativ gegenüber anderen Tooling, also wo die Komplexität dann eben halt ausgelagert wird. Und ja, ich denke halt wie gesagt nicht, dass HTML so eine superkomplexe Sprache ist, dass man da nicht mit einen guten Editor das hinkriegen kann.
Lucas Dohmen: Also grundsätzlich… ich verstehe deinen Punkt absolut. Ich glaube, dass es aber trotzdem halt…, also die Leute, die du beschreibst, sind ja nicht die Leute, die Web machen, sondern die Leute, die diese Standards bauen. Weil wenn man das jetzt vergleich mit Leuten, die JavaScript intensiv nutzen, da sind die Tools ja eher sehr komplex, da wird sich sehr, sehr viel auf Tools verlassen. Da legt ja keiner los bevor irgendwie Babel installiert ist mit 15 webpack Konfigurationen zusammen kopiert. Also das ist für mich schon so ein Gegenpol dazu, diese sehr Toolzentrischen Denken, sage ich mal.
Lars Hupel: Aber also ich weiß nicht, wie du das wahrnimmst, in meiner, ich sage mal Twitter-Blase, ist es schon so, dass ganz viele Leute auch die neu in der Entwicklung sind mit react und so etwas anfangen. Also die sagen dann einfach: Hier installier dir mal notets, dann kriegst du NPN, dann hast du die create-react app und dann hast du hier so ein schönes Template, dann nutzt du dieses Code Ding und dann machst du irgendwie one-click Deployment zu netlify oder heroku oder was auch immer. Und es scheint ja zu funktionieren, also wir wissen ja beide, dass die create-react app irgendwie wahnsinnig riesig ist und da auch wahnsinnige Komplexität reinzieht, aber irgendwie scheinen es ja die Leute dahinter geschafft zu haben, dass das halt Anfänger/-innen freundlich ist. Und wenn man solche Tools benutzt, dann muss man auch gültigen Code schreiben. Also react lässt sich das auch nicht bauen, wenn da irgendwie ein Syntax Fehler in deinen JFX drinnen ist, aber trotzdem scheint das irgendwie mit dem richtigen Tooling, also mit den Editor oder sowas, halt einfach zu funktionieren. Jetzt kann man natürlich drüber streiten, wie gut das funktioniert, ob es da irgendwelche… ob das irgendwie akademisch messbar ist. Aber ich glaube zumindest, dass da auch ganz viele Leute drüber reinkommen und sich dann auch auf das Tooling halt eben verlassen und eben dann nicht mit notepad.exe ihre ersten HTML Versuche machen.
Lucas Dohmen: Ja aber… Ich finde das ist eigentlich auch ein ganz gutes Beispiel, wo man dann aber auch merkt, dass dieses komplexe Tooling dann aber auch so zur Selbstverständlichkeit wird. Also wenn jemand quasi damit aufwächst in Anführungsstrichen mit create-react app seine Anwendungen zu bauen oder ihre Anwendungen zu bauen, dann ist es halt oft so, dass diese Leute sehr lange auch nur das machen. Also auch nur sich auf dieses extrem komplexe Tooling verlassen und wenig auf die vermutlich einfacheren Grundlagen wie HTML schauen, weil das halt so selbstverständlich ist, dass man sowas wie create-react app einfach sagt wie: Hier, mach mal Bild. Und was das im Hintergrund alles macht, dass wird man wahrscheinlich erst nach 5 Jahren oder so Programmiererfahrung verstehen können, weil es so viel tut. Und da ist für mich dann auch schon doch die Frage: Ist es dann sinnvoll, dass wir… Weil dann haben wir ja quasi viel von diesen HTML Kram und so weiter wegabstrahiert. Klar, dadurch werden wir gezwungen quasi gültige Syntax zu schreiben und so weiter, aber wir verlassen uns dann auch auf unglaublich viel Tooling, um das zu erreichen. Jemand der quasi nicht mit HTML auf eine FTP Server anfängt, sondern mit react, wird viele Dinge, die jemand, der mit diesem HTML Kram anfängt, sehr spät lernen. Also wie zum Beispiel man einen Button macht. Wenn du mit react anfängst, dann hat ein Button keine besondere Bedeutung, da kannst du genauso ein beliebiges div nehmen, um das anklickbar zu machen. Weil diese Dinge dich nicht interessieren, du sagst halt einfach, machst da so einen all-click-handler dran und fertig. Ich weiß halt nicht…
Lars Hupel: Also ich habe da…, ich habe da gleich mal zwei Punkte dazu. Also der erste Punkt ist: Auch wenn du mit notepad und einen FTP Client arbeitest, hast du Abstraktion, die du im Kauf nimmst, die du nicht lernst. Zum Beispiel, was du auch gesagt hast, HTTP, das erkläre ich den Leuten dann halt nicht. Und die wissen dann halt auch sehr lange nicht, was HTTP eigentlich macht und um dann eben sich zu professionalisieren, muss ich das dann auch lernen. Deswegen haben wir ja auch die Webarchitektur Schulung gemacht oder du hast sie gemacht und ich habe zugehört, um eben zu lernen wie HTTP2 funktioniert und so weiter. Also ich kann auch HTML Seiten schreiben, die irgendwas tun, aber wenn ich dann mit denen irgendetwas sinnvolles anfangen will, muss ich das dann halt auch irgendwie lernen. Und was dann da irgendwie mitreinspielt, was halt das schöne an react ist, also ohne jetzt irgendwie react groß verteidigen zu wollen, ich bin jetzt auch nicht so der react Superfan, du kannst halt sehr viel einfacher auch dynamischen Content auf Webseiten machen, die irgendwas tun. Wenn ich jetzt mit einen FTP Dingens da, also ich benutzt das einfach mal als Platzhalter für diesen Workflow da, wenn ich da irgendwie dynamische Dinge tun will, dann muss ich halt gleichzeitig auch noch irgendwelchen Server-Side code schreiben und muss mich dann irgendwie mit forms auseinandersetzen und vielleicht mit PAP und sowas, das spare ich mir halt bei react schon auch. Und der Punkt, auf den ich hinauswill, ist in Prinzip: Wir haben unterschiedlich Abstraktionsschichten und es gibt sicherlich mehrere gültige Wege, wie man in die Abstraktion reinkommt, aber ich würde mich jetzt echt nicht hinstellen und sagen: Ja. Das Eine ist jetzt inhärent besser als das Andere. Wir machen halt überall irgendwie trade-offs und klar, ich habe dann bei react einen Haufen Tooling, was ich brauche oder keine Ahnung, kann auch irgendwie Angular oder Svelte oder irgendwas sein, ist ja jetzt egal. Andererseits spare ich mir aber auch an anderer Stelle etwas und ich muss halt zum Beispiel, wenn ich jetzt halt eine form oder irgendetwas machen will, einen Button, der irgendetwas animiert oder keine Ahnung, müsste ich halt mit einem normalen HTML Standard Workflow halt auch ein bisschen mehr arbeiten, um das hinzukriegen und was dann halt auch wiederum nicht so einfach für Einsteiger/-innen ist.
Lucas Dohmen: Da gebe ich dir Recht! Also klar, das ist auf jeden Fall ein trade-off, also bestimmte Dinge wird die Einstiegshürde auf jeden Fall wesentlich niedriger sein, wenn du dieses Tooling benutzt, da stimme ich dir zu. Aber vielleicht sind wir an der Stelle schon weg von Postel‘s Law, also ich glaube einen Aspekt, also auch wenn mir dieser Anfängeraspekt sehr, sehr wichtig ist, ein anderer Aspekt, der Postel‘s Law für mich sehr wichtig macht ist halt dies Zukunftskompatibilität. Wenn du beispielsweise ein Input Feld hast und das Input Feld hat den Type Text, dann kann das jeder Browser seit…, weiß ich nicht, immer schon, anzeigen, kann da so ein Text Feld hin anzeigen, in dem du Sachen eintippen kannst. Irgendwann haben die Leute gemerkt, okay die Leute wollen da auch so Date Picker haben. Dann wurde das erst mit JavaScript dazu gehackt und so weiter und irgendwann wurde das standardisiert mit <input type="date">. Wenn jetzt die Browser so programmiert wären, dass sie einfach gucken: Ich habe hier ein festes Set an Types für den Input Field, nämlich text und was weiß ich, was es noch gab und fertig. Dann würde jetzt der alte Browser dieses neu <input type="date"> sehen und sagen: Oh, exception, das erkenne ich nicht, das ist ein zu neues HTML, das kann ich nicht. Weil dann stände da irgendwie HTML Version 14.6 und da wurde das mit eingeführt, das kann ich nicht, also zeige ich die gesamte Webseite nicht an. Was aber jetzt ein normaler Browser stattdessen tun würde ist, dass er an das Input Feld ran läuft, sieht: diesen type kenne ich nicht, dann nehme ich einfach den Standard, nämlich Input type text und rendere hier ein Text Feld hin. Und dann kann jemand einfach trotzdem die Webseite sehen und benutzen. Und ich glaube das ist schon… Also das ist für mich die zweite Säule aus dem dieses Postel‘s Law so viel wert hat. Nämlich dass man halt mit Dingen, die in der Zukunft kommen werden, umgehen kann. Wie siehst du das?
Lars Hupel: Also da habe ich wieder zwei Punkt dazu. Der erste Punkt ist so ein bisschen eine Relativierung: Ich sehe schon einen qualitativen Unterschied zwischen tech soup und irgendwie einen unbekannten Input type. Also nur weil ich jetzt irgendwie tech soup ablehne und sage …(23:25), würde ich mich jetzt nicht auf den Standpunkt stellen: Ja der Browser soll jetzt irgendwie hart einen Error werfen, wenn er den Input nicht kennt. Und letztendlich ist das ja auch schon bei JavaScript so, also wenn ich jetzt irgendein JavaScript Feature benutze, was der Browser nicht kennt, dann wird der auch ein Error werfen. Dann muss ich halt irgendwie durch Transpilation oder sonst irgendetwas, muss sorgen, dass das halt entsprechen funktioniert. Da bin ich also jetzt nicht so der totale Hardliner, dass ich sage, wenn da irgendwas Neues drin ist, sollte das nicht gehen. Und der zweite Aspekt auf den ich noch eingehen wollte, ist das Zusammenspiel von dem was du gerade eben gesagt hat, dem anderen Law. Und zwar heißt dieses Law ‚hyrom’s Law‘, ich weiß nicht genau ob das hyrom oder hirom genau heißt. Und das sagt in Prinzip aus: Egal was… Also du hast irgendeine API oder irgendein Protokoll oder Kontrakt und egal was du in diesem Protokoll reinschriebst, den Kontrakt sagst, was du tun wirst, Leute werden das ignorieren und werden sich darauf verlassen, dass du tatsächlich tust. Also wenn du zum Beispiel sagst: Ich werde immer Werte zwischen 0 und 10 geben, du musst mit allen Werten zwischen 0 und 10 umgehen. In der Realität gibst du aber nur 3 und 4 aus und ignorierst die anderen Werte, dann werden Leute damit rechnen, dass du nur 3 und 4 ausgibst. Dann gibst du irgendwann mal 5 aus und dann knallt alles, weil Leute sich halt eben darauf verlassen. Und wenn man das halt jetzt in Zusammenspiel bringt, dann kriegt man sowas raus, wie jetzt zum Beispiel Vendor Prefixes bei CSS, das haben Leute mal für eine gute Idee gehalten. Und dann gibt es zum Beispiel ein Webkit Vendor Prefix, um jetzt irgendwelche neuen Features zu selektieren. Und jetzt ist es so, dass die in Unendlichkeit unterstützt werden müssen und zusätzlich jetzt noch andere Browser jetzt noch ihre fremden Vendor Prefixes auch noch mit interpretieren müssen, weil Leute sich einfach drauf verlassen haben: Ja, das geht irgendwie. Und dann hat halt jemand eine Webseite ausgerollt, wo ein CSS drinsteht: Webkit irgendwas, und dann wird das halt in Firefox und in den anderen auch noch irgendwie interpretiert, weil halt man jetzt sagt: Sind wir mal liberal und die Leute die liefern das aus dem Rechner mit, dann machen wir das jetzt einfach mal. Und wir werden mit diesen Vendor Prefixes wahrscheinlich, also mittlerweile werden die ja nicht mehr benutzt, wenn ich das richtig verstanden habe…
Lucas Dohmen: Ja, also sie werden so langsam ausgefädelt, ja.
Lars Hupel: Genau, aber wir werden trotzdem noch über Jahrzehnte hinweg wahrscheinlich das sehen. Genau wie wir dann auch irgendwelche uralten Hacks sehen, um irgendwas mit der History API was zu machen, die es da noch gar nicht gab und so Späße. Also, wir sind dann halt einfach so eingeloggt in so einen Zyklus von endlosen Rückwärtskompatibilität und das macht natürlich auch die ganze Sache wahnsinnig komplex.
Lucas Dohmen: Da stimme ich dir zu, klar das erhöht die Komplexität auf jeden Fall, aber mir würde nicht einfallen, wie man das halt anders lösen kann. Weil wenn wir jetzt… Also nehmen wir jetzt einfach das Beispiel von Vendor Prefixing, wenn wir das verhindern wollen würden, dass man das kann. Also dass man jetzt einfach als Browserhersteller sich hinstellt und sagt: So, ich füll jetzt irgendwie -webkit-border-radius ein als neues Attribut, obwohl das nirgendwo standardisiert wurde. Dann würde das ja nur gehen, indem ich die Browser zwinge zu sagen: Ihr dürft nur Sachen interpretieren, die standardisiert sind. Und wenn wir das tun würden, dann würden wir aber wiederum eine tolle Eigenschaft von CSS verlieren, nämlich das wenn da jetzt border-radius steht und der Browser kann das noch nicht, dass er das einfach überspringt und weitermacht und einfach ohne border-radius die tolle Box anzeigt. Wie würdest du das denn verhindern wollen? Also mir würde gar kein Weg einfallen, wie man solch Hacks in Anführungsstrichen verbietet.
Lars Hupel: Ja, verbieten kann man das ja nicht, weil Browser Vendors, die machen halt so was Browser Vendors so tun. Also das ist halt eher so ein… Also Postel‘s Law ist ja auch eigentlich mehr oder weniger so ein sozialer Kontrakt. Also Browser Vendors sind auch nicht dazu gezwungen tech soup zu parsen, anzuzeigen, das ist halt einfach was was man von ihnen erwartet. Und ich würde da jetzt auch überhaupt nicht dogmatisch sein, also ich würde jetzt auch nicht irgendwie sagen: Ja, wie schreiben wir die HTM…(27:24)rein, wenn da irgendwie ein Anführungszeichen falsch gesetzt ist, dann musst du den User irgendwie eine fette Fehlermeldung anzeigen oder irgend sowas. Genauso wenig, wie der Browser dazu gezwungen ist bei TLS 1.1 eine Warning anzuzeigen. Also das sind halt einfach soziale Aspekte und da müssen wir halt einfach als Community irgendwie uns einigen. Anderseits sehe ich natürlich ein, dass jetzt gerade im Web mein Missfallen von dem Postel‘s Law, da stehe ich eigentlich total auf verlorenen Posten, das lässt sich nicht ändern. Also die Tradition reiche einfach sehr lange zurück. Wenn, dann würde ich da immer für argumentieren, wenn man irgendwelche APIs baut oder sowas. Wenn man halt eher in einem kontrollierten Ökosystem ist, wir bauen zum Beispiel irgendeine rest API oder sowas, dann würde ich rest API sollte halt, wenn da irgendwie Unsinn reingekippt wird, schon viel früher sagen, dass Unsinn eingekippt wurden ist. Und ich würde jetzt nicht mich auf den Standpunkt stellen: Ja wir müssen jetzt mal die Browser reformieren und eigentlich gehört da mal überall ein Syntax Error hin. Es ist halt ein schönes Beispiel, aus meiner Sicht, zu illustrieren was halt da der trade-off ist und warum meiner Ansicht nach dieser trade-off nicht der optimale. Aber das ist natürlich extrem subjektiv und ich sehe halt auch die Punkte ein, dass das Web halt auch ganz viel gebracht hat. Andererseits denke ich halt auch, das Web hat sich auch sehr professionalisiert und diese Einstiegshürden sind einfach viel größer. Wenn wir aber versuchen, dass wenn wir eben in unseren… Keine Ahnung wir haben eben eine Micro Service Architektur oder sowas, dann können wir schon nochmal neu verhandeln darüber, wie sehr wir da mit Postel‘s Law, wie weit wir da gehen wollen. Also welche Menge an Unsinn wir verkraften wollen.
Lucas Dohmen: Ja, für mich… Also ich glaube da sind wir ähnlicher Meinung. Ich glaube, dass wenn wir in einem Environment sind, das wir kontrollieren, dann sollten wir natürlich gucken, dass wir vor allem in be conservative in what you do quasi investieren. Dass wir möglichst konform sind.
Lars Hupel: Absolut, ja!
Lucas Dohmen: Und das… Aber ich glaube sobald wir halt in dieses offene Web gehen, wird das halt schwierig werden. Also wenn… Ein Beispiel für mich wäre HTTP, als HTTP 1.1 rausgekommen sind, das lief halt weiterhin durch jeden HTTP Intermediator durch. Egal ob das irgendwie caching proxy oder sonst irgendwas war, da sind nur weitere HTTP Header dazu gekommen, da ist nichts kaputt gegangen und die haben das halt weiter akzeptiert. Mit HTTP/2 war das auf einmal nicht mehr der Fall, bei HTTP/2 musste man halt auf einen Trick zurückgreifen, dass man alles immer verschlüsselt im Prinzip im offenen Web damit da keiner reingucken kann, um damit Unsinn zu machen, da es ja auf einmal ein ganz anderes Format war. Jetzt könnte man daraus schließen: Hm, das mit den binary Format von dem HTTP/2 war nicht so eine tolle Idee. Aber es gab gute Gründe, warum man wirklich eine ganz neue Protokollversion habe wollte, aber da sehe ich auf jeden Fall die Kosten, die wir bezahlen dafür, dass wir sagen: Komm, hier kann jeder Intermediaries kann hiermit irgendwelchen Unsinn machen und wird natürlich auch viel Schindluder getrieben und irgendwelche…
Lars Hupel: Wollte ich gerade sagen. Also die eine Schlussfolgerung ist: Braucht es das HTTP/2? Und die andere ist: Braucht es die Intermediaries? Klar, wir haben irgendwie eine ganz große Träge Masse von Mittelboxen, die irgendwas machen, aber ob das nun wirklich eine gute Idee war ist halt auf einem anderen Blatt. Und ich glaube da sehen wir das dann auch wieder, wir werden halt durch die Rückwärtskompatibilität dazu gezwungen diesen Ballast mitzuschleppen und ob dieser Ballast heutzutage wirklich noch einen Wert, einen Nährwert bringt, steht halt wieder auf einem anderen Blatt.
Lucas Dohmen: Ja, aber ich meine so Intermediaries, die existieren ja auch aus einem Grund. Also das jetzt irgendwie ein HTTP cache sein und der hat ja einen Wert, den wollen wir ja auch weiterhin haben. Natürlich, dadurch, dass wir jetzt alles verschlüsseln funktioniert das mit dem Intermediaries nicht mehr so gut. Aber ein Intermediary, der… also es gibt durchaus welche die wir haben wollen und wir gehen halt den trade-off ein, dass wir dann auch welche bekommen, die wir eigentlich nicht so gerne haben wollen, glaube ich. Ich glaube schon, dass wir uns… Also ich glaube wir sind uns einig, dass ist kein Gesetz, was quasi sagt: Ja, wenn du das machst ist alles gut. Sondern das ist ein trade-off, den wir eingehen. Das ist der trade-off, dass wir dann auch Dinge bekommen, die für uns dann vielleicht unangenehm sind. Aber…
Lars Hupel: Vielleicht müsste es stattdessen Postel‘s suggestion heißen.
Lucas Dohmen: Ja. Genau, Postel‘s ungefährer Leitsatz. Genau, aber solche Sachen kommen immer nicht so gut an, man muss das immer Law nennen, damit das auch Signifikanz hat. Aber ja, ich glaube das ist, wenn man Postel‘s Law nicht an ganz vielen, in ganz vielen Standards gefolgt wäre, also vor allem sehe ich da HTML, aber HTTP, dann wäre das vermutlich heute nicht so verbreitet, wie es das ist. Weil das hat sich auch dadurch verbreitet, dass die Leute da verschiedensten Schindluder treiben, konnten und Dinge tun konnten, die vielleicht nicht so toll waren. Und auch wenn das doof ist, dass Leute dann schlecht Dinge getan haben, entweder weil sie es nicht besser wussten oder vielleicht weil so auch etwas Böses machen wollten, also kann ja auch durchaus sein. Leute, die da ihre Ads rein injizieren wollten in Code oder was auch immer. Ist es glaube ich trotzdem so auf der Gesamtrechnung ein positives Ergebnis, weil sonst hätten wir das Web wahrscheinlich nicht, würde ich jetzt vermuten.
Lars Hupel: Ja, absolut! Ich meine das ist natürlich jetzt Spekulation, wir können das nicht messen. Aber genau das meinte ich auch, da bin ich auch bei dir und ich sehe halt jetzt eher so die Tendenz dazu, dass sich das zunehmend professionalisiert und selbst die Profis teilweise nicht mehr so genau wissen, was getan werden muss. Also wenn ich mir halt überlege, dass ein Chrome einen riesigen Marktanteil hat, dann kann halt Google einfach festlegen: Wir wollen das jetzt irgendwie so machen. Und wenn Google der Meinung ist, dass dein SSL Zertifikat nicht gut ist, dann hast du halt ein Problem. Oder wenn Google der Meinung ist, dass dein Seiten Ranking irgendwie schlecht ist, dann hast du auch ein Problem. Und wenn wir jetzt irgendwie… Ja, da kommen wir jetzt wahrscheinlich wieder in die Diskussion rein, wie viele Browser wollen wir, die irgendwie verschiedene Sachen implementieren? Aber mein größerer Punkt ist halt, dass das heutzutage halt sehr anders funktioniert. Also wir haben halt heute nicht mehr so ein MySpace und ein GeoCities oder sowas, sondern wir haben halt Content von Twitter, Facebook, Google, sonst irgendetwas. Wir haben irgendwie Google AMP oder sowas, was die Dinge ausliefert und da funktioniert das Web halt mittlerweile komplett anders als damals. Ich will jetzt nicht sagen, ob das gut oder schlecht ist. Wahrscheinlich will ich es schon sagen, dass es gut ist. Aber diese Idee, dass da irgendwie so Jede hergehen kann und dann irgendwelches Zeug bauen kann und dann läuft das, dass haben wir halt heute nicht mehr.
Lucas Dohmen: Ja, okay. Ja Lars, ich glaube wir haben beide unsere Perspektive da ganz gut dargelegt oder liegt dir noch etwas anderes auf dem Herzen?
Lars Hupel: Nö, ich glaube eigentlich so unterschiedlicher Meinung sind wir überhaupt nicht.
Lucas Dohmen: Ja, ich glaube auch. Ich glaube auch. Also ich glaube wir sind beide der Meinung, dass man in einer kontrollierten Umgebung vielleicht sogar…, also garantiert viel mit Validierung und so weiter arbeiten sollte. Genauso, wie wenn man professionelle JavaScript Entwicklung macht, dass man dann halt ESLint und so weiter benutzt, einfach um halt bestimmte, komische Eigenheiten der Sprache, die auch unter anderem durch dieses ‚wir wollen möglichst viele Input akzeptieren‘, ich sag jetzt einfach mal als Beispiel: automatic type conversions von JavaScript ist ja auch so ein Feature, dass eigentlich auch nur da ist, damit halt möglichst viel JavaScript verstanden wird. Also es ist so jetzt vielleicht nicht direkt Postel‘s Law, aber verwand mit Postel‘s Law.
Lars Hupel: Ja, das Argument habe ich total vergessen. Danke, dass du das für mich argumentiert hast!
Lucas Dohmen: Ja, gerne. Du kannst das auch gerne noch ausführen!
Lars Hupel: Ne, du hast eigentlich alles gesagt… Wir nehmen halt im JavaScript hin, dass irgendwelche Sachen sich total bizarr verhalten, damit wir möglichst viele Inputs verarbeiten können, genau.
Lucas Dohmen: Genau, also das bedeutet halt, dass Dinge schief gehen und ich würde auch sagen, dass das Design von JavaScript sich auch an manchen Stellen nicht davon profitiert hat, dass es so superliberal in allem was es versteht ist. Weil wenn ich da wieder auf meine Anfänger und Anfängerinnen zurückgreife, dann sehe ich bei JavaScript diese Vorteile nicht, die ich bei HTML, CSS sehe, weil das dann nämlich ganz schnell passiert, dass am Anfang alles funktioniert, weil alles automatisch irgendwie einigermaßen verstanden wird. Aber irgendwann bricht halt alles auseinander und dann weiß man überhaupt nicht mehr was los ist, weil es überhaupt nichts mehr wiederzufinden gibt und du hast globale Variablen und was weiß nicht. Und da sehe ich ganz klar eine Rolle für sowas wie einen Linter, aber ob ich jetzt sagen würde: Der Browser sollte quasi das JavaScript strenge behandeln. Glaube ich, würde ich nicht sagen. Ich glaube das würde nicht helfen, sage ich mal.
Lars Hupel: Dafür haben wir dann TypeScript.
Lucas Dohmen: Genau, dafür haben wir dann TypeScript. Genau, wenn der Browser dann irgendwann TypeScript versteht, dann…
Lars Hupel: Ja, bin ich dafür!
Lucas Dohmen: Gut Lars. Dann danke ich dir für dieses schöne Gespräch und ja…
Lars Hupel: Dir auch!
Lucas Dohmen: Und den Hörerinnen und Hörern, wenn ihr Feedback dazu habt, wenn ihr sagt: Hey, an dieser Diskussion, das und das ist totaler Quatsch und das habt ihr total rausgelassen, freuen wir uns total drüber. Wenn ihr sagt: So Diskussionen sind doof, wir wollen lieber Interviews. Gibt uns gerne Feedback! Und ja, sonst sage ich: Bis zum nächsten Mal. Auf Wiedersehen!
Lars Hupel: Bis bald! Ciao!
Lucas Dohmen: Ciao!