#84 Die Evolution von JavaScript: Vom Ducktyping zum Monopol im Browser mit Peter Kröner

JavaScript: Eine multiparadigmatische Skriptsprache mit einem schwachen dynamischen Ducktyping-System.

Um die Sprache JavaScript kommt man im Web nicht mehr vorbei. Die meisten kennen sie durch Frameworks wie React, Angular, Vue.js, Next und Co. Doch wie viel weißt du über die Hintergründe und die Weiterentwicklung dieser Sprache?

In dieser Episode geht es nicht um das nächste hippe JavaScript-Framework, sondern wir sprechen mit Peter Kröner darüber, wie JavaScript erfunden wurde, was ECMAScript ist, wie TypeScript in den Mix spielt, warum die Sprache so beliebt ist, wie neue Features den Weg in die Sprache finden, was das TC39 ist, über das Monopol im Browser, verschiedene JavaScript-Engines und viel mehr.

Bonus: Wenn Hamburg im Süden liegt.

**** Diese Episode wird gesponsert vom Open-Source Förderprogramm Media Tech Lab: Bewirb dich jetzt und erhalte bis zu 50.000€ Fördersumme für dein Open-Source Projekt https://www.media-lab.de/de/media-tech-lab

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Sprungmarken

(00:00:00) Intro

(00:01:01) Unser Gast: Peter Kröner

(00:04:48) Die Media Tech Lab Förderung von Open Source Projekten (Werbung)

(00:06:26) Was ist JavaScript für eine Sprache und was macht sie aus?

(00:08:36) JavaScript als Verbindungs-Sprache zwischen den Welten

(00:10:28) JavaScript auf Textil-Verarbeitungsmaschinen

(00:12:42) Ein npm install nach 10 Jahren

(00:17:02) JavaScript ist Prototyp-basiert, kann aber auch OOP und Funktional

(00:21:45) Was ist der Grund für die große Beliebtheit der Sprache?

(00:23:00) Woher kommt TypeScript?

(00:28:06) Was ist ECMAScript und wie wurde JavaScript erschaffen?

(00:32:10) JavaScript-Features: Deprecation und der Prozess und Einführung von neue Features

(00:43:24) Herausforderungen bei JavaScript auf dem Client vs. auf dem Server

(00:46:00) Warum gibt es so viele Frameworks und Libraries?

(00:48:46) Das verstreute Ökosystem als Einstiegsbarriere

(00:52:01) Wird die JavaScript-Entwicklung immer komplexer?

(01:03:00) Wird die Sprache JavaScript in die richtige Richtung weiterentwickelt?

(01:06:56) Programmiersprachen kopieren Features

(01:10:34) Das Monopol im Browser und fehlende Konkurrenz

(01:16:14) JavaScript Engines

Hosts

Wolfgang Gassler (https://mastodon.social/@woolf)
Andy Grunwald (https://twitter.com/andygrunwald)

Feedback (gerne auch als Voice Message)

EngKiosk Community: https://engineeringkiosk.dev/join-discord
Email: stehtisch@engineeringkiosk.dev
Mastodon: https://podcasts.social/@engkiosk
Twitter: https://twitter.com/EngKiosk
WhatsApp +49 15678 136776

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Peter Kröner (00:00:02 - 00:00:24)

Also meine Internet-Experience besteht ja darin, dass ich 99,9% von allem, was an mir vorbei scrollt, ignoriere. Und das machen die meisten so und die kommen damit super klar, warum das gerade im Fall von JavaScript-Frameworks unmöglich sein soll, dass man da irgendwie zu all diesen Dingern eine Meinung haben muss und von wegen, das ist jetzt aber eins zu viel, das verstehe ich nicht so ganz. Es ist halt eben tatsächlich so eine Verbindungssprache oder halt eben auch eine Scharniersprache zwischen allen möglichen Welten.

Andy Grunwald (00:00:28 - 00:00:56)

Die Sprache JavaScript ist für alle Webleute ein Begriff. Auch der Running Gag, dass jeden Tag ein neues Framework rauskommt, ist nicht neu. In dieser Episode geht es um JavaScript. Aber nicht um Frameworks, sondern um die Hintergründe und den aktuellen Stand der Programmiersprache. Warum ist JavaScript so beliebt? Wie wurde es erfunden? Was ist ECMAScript und was ist das CC39? Wie finden neue Features den Weg in die Sprache? Ist das Monopol von JavaScript im Browser ein Problem? Über all das und noch viel mehr sprechen wir heute mit unserem Gast Peter Kröner.

Wolfi Gassler (00:01:01 - 00:01:03)

Andi, was ist deine Go-To-Sprache?

Andy Grunwald (00:01:03 - 00:01:03)

Du hast es schon gesagt.

Wolfi Gassler (00:01:03 - 00:01:05)

Ist es schon Go in Go-To, oder?

Andy Grunwald (00:01:05 - 00:01:10)

Das ist mit hoher Wahrscheinlichkeit aktuell Go, wenn ich selbst aussuchen kann.

Wolfi Gassler (00:01:10 - 00:01:49)

Meine Sprache ist ja mittlerweile eigentlich fast JavaScript. Ich komme ja von der PHP-Seite und bin eigentlich jetzt fast so im JavaScript-Bereich immer drinnen. Und ich wundere mich eigentlich immer, wie wenig Ahnung ich über JavaScript habe, obwohl ich, wenn ich programmiere, mal den Hauptteil meiner Zeit eigentlich JavaScript widme. Und genau darum haben wir uns heute mal einen absoluten Spezialisten geholt, der uns hoffentlich wesentlich mehr erzählen kann, was denn so hinter diesem ganzen JavaScript-Type-Script-Hype steckt. Und auch für mich als Entwickler, der tagtäglich mit JavaScript arbeitet, vielleicht auch die eine oder andere News uns vorstellen kann oder auch ein bisschen Background geben kann, was denn so hinter den Vorhängen abläuft. Willkommen Peter!

Peter Kröner (00:01:50 - 00:01:51)

Moin! Freut mich hier zu sein.

Andy Grunwald (00:01:51 - 00:01:58)

Du hast es schon gesagt, moin. Du kommst aus dem nordigsten Nordens Deutschlands, aus Kiel.

Peter Kröner (00:01:58 - 00:01:59)

Mittlerweile ja, das stimmt.

Wolfi Gassler (00:01:59 - 00:02:06)

Darf ich jetzt endlich mal sagen, Norden? Für mich ist ja Andi aus Duisburg auch schon Norden, aber jetzt ist es wirklich der Norden, oder?

Peter Kröner (00:02:06 - 00:02:16)

Ich glaube, Schleswig-Holstein bezeichnet sich offiziell als der echte Norden. Stark abzugrenzen von dem Ganzen, was da so südlich von Hamburg und Gdöns da ist. Ich glaube, Norden ist eine sehr relative Angelegenheit.

Andy Grunwald (00:02:16 - 00:02:35)

Ich find das schon schön, wenn Hamburg als südlich bezeichnet wird, aber okay. Du bist selbstständiger Web-Technologie-Erklärbär. Das bedeutet, du kümmerst dich primär um Schulungen, Workshops und Talks zu den Themen JavaScript, HTML5, TypeScript, CSS und allen anderen Arealen der Frontend-Technologie.

Peter Kröner (00:02:36 - 00:02:55)

Den Arealen der Frontend-Technologie, die standardisiert und nativ im Browser sind. Also Frameworks und so weniger, aber wenn eure werten Zuhörer irgendwie eine Aufschlauung brauchen, wieso die Wurst wirklich, wirklich gemacht wird da unten auf der Ebene der Standards und in den nativen Browser-APIs, dann bin ich euer Mann. Passend zum Thema bist du auch noch.

Andy Grunwald (00:02:55 - 00:03:21)

Selbst Podcaster im Working Draft Podcast. Und was mich sehr überrascht hat, als ich deinen Namen gegoogelt habe, hat deine Webseite im Sinne der Suchmaschinenoptimierung gegen eine Metallverarbeitungsunternehmen aus Rheinland-Pfalz verloren. Du bist bei mir nur als Zweiter im Suchergebnis aufgetaucht. Und die Peter Kröner GmbH mit der Spezialisierung um Partikelschaumtechnik hat leider den ersten Platz ergattert.

Peter Kröner (00:03:21 - 00:03:25)

Ja, das ist aber okay, mir gehören die meisten Domains und ich bekomme sehr viele von den E-Mails, die eigentlich an die gehen sollen.

Andy Grunwald (00:03:28 - 00:03:29)

Wie beantwortest du diese?

Wolfi Gassler (00:03:29 - 00:03:34)

Senden die Kunden dir dann auch Geld, wenigstens für die Aufträge für Partikelschaumprodukte?

Peter Kröner (00:03:34 - 00:04:07)

Ich will jetzt da meinen Namensvetter nicht irgendwie in Schwierigkeiten bringen, aber ich bekomme, sagen wir mal, E-Mails aller Art und wenn ich Also je nachdem, wie ich so drauf bin, sage ich denen halt Bescheid, dass sie sich lieber an diese wenden sollen, an jene wenden sollen. Ich habe halt so eine Catch-all-E-Mail-Adresse und es gibt halt mehrere Möglichkeiten, Peter Kröner, gerade mit dem Umlaut, zu schreiben. Und denen gehört halt eine von vier Domains und die anderen drei sind meine und deswegen kriege ich halt alles Mögliche von wegen, kannst du mal die Rechnung korrigieren, bisschen justier dieses Produkt nach oder ich lade dich halt hier zum ehemaligen Treffen von einem Abi-Jahrgang ein und so. Das kommt alles hin und wieder mal bei mir an.

Andy Grunwald (00:04:07 - 00:04:19)

Ich hätte nicht gedacht, dass du das auf dem Schirm hast, aber die Story ist fast viel geiler, als dass der Web-Technologie-Clairvoyeur auf Platz 2 ist. Und dann... Wahnsinn. Bringst du die eigentlich so als Running Gag eigentlich auch in Talks, oder?

Peter Kröner (00:04:19 - 00:04:40)

Ach, selten. Das ist ja meistens nicht themenrelevant. Das ist halt mehr so eine belustigende Nebenher-Geschichte. Also ich meine, Partikelschaumtechnologie klingt, glaub ich, sehr viel spannender, wenn jetzt so wir als Fachfremde darüber nachdenken. Am Ende sind's halt irgendwelche Rechnungen, Sachen, die wohin geliefert werden müssen, Exportbeschränkungen. Das hab ich alles gar nicht gelesen, deswegen wisst ihr davon nichts. Aber so sieht's halt aus.

Wolfi Gassler (00:04:40 - 00:04:45)

Dann bleiben wir mal eher bei der richtigen Domäne und bei dem interessanten Thema rund um JavaScript.

Peter Kröner (00:04:45 - 00:04:46)

Besser ist es.

Wolfi Gassler (00:04:46 - 00:04:48)

Jetzt gleich mal meine erste Frage.

Andy Grunwald (00:04:49 - 00:05:09)

Unser Episodensponsor, das Media Lab Bayern, bietet hier eine einzigartige Möglichkeit für ganz Deutschland. Eine finanzielle Unterstützung von bis zu 50.000 Euro, um deine Projektidee in der Medienlandschaft als Open Source Projekt zu realisieren. Wolfgang selbst hat bereits letztes Jahr an diesem Programm teilgenommen. Erzähl mir doch mal bitte, wie läuft denn das Ganze eigentlich ab?

Wolfi Gassler (00:05:09 - 00:05:51)

Klar. Gemeinsam mit einem Programmierkollegen haben wir eine kurze Beschreibung von unserer Idee im Bereich Podcast Analytics eingereicht. Und das Schöne daran ist, man kann als Zweierteam oder als Einzelperson die Ideen umsetzen. Und wenn die Idee dann ausgewählt ist, erhält man großzügige 50.000 Euro Förderung für die Projektlaufzeit von nur sechs Monaten. Und was ich besonders geschätzt habe, ist auch die Flexibilität. Ihr könnt das Projekt entweder in Vollzeit oder so, wie wir es gemacht haben, in Teilzeit umsetzen. Zusätzlich zu den 50.000 Euro bekommt man auch Zugang zu Medienunternehmen über das umfangreiche Netzwerk des Media Labs. Denn euer Projekt soll nicht nur umgesetzt, sondern im Idealfall auch von der Medienlandschaft erfolgreich verwendet werden. Die langfristige Perspektive ist ebenso wichtig wie die Initialförderung. Wir bauen zum Beispiel gerade eine Firma um unser Open Source Projekt auf.

Andy Grunwald (00:05:52 - 00:06:26)

Euer Projekt muss jedoch nicht im Bereich Podcasting sein. Eine Idee im Bereich Medienlandschaft kann eigentlich alles sein, zum Beispiel Video Streaming, Augmented und Mixed Reality, Semantic Tagging, AI für Audio Transcriptions oder, oder, oder. Falls euer Interesse geweckt ist und ihr mehr über dieses Förderprogramm erfahren wollt, besucht doch einfach mal die Webseite des Media Lab Bayern. Dort findet ihr auch Informationen über bereits abgeschlossene Projekte und alles, was ihr für die Einreichung benötigt. Die Bewerbungsphase läuft übrigens vom 1. September bis zum 13. Oktober. Also hopp hopp und ran mit deiner Idee. Links wie immer in den Shownotes. Werbung Ende.

Wolfi Gassler (00:06:26 - 00:06:46)

Jetzt gleich mal meine erste Frage. Es gibt ja in unserer Hörerschaft wahrscheinlich auch Leute, die irgendwie ganz tief im Java-Bereich drin sind oder im Embedded Linux, keine Ahnung. Und vielleicht sogar extrem wenig Kontakt bisher hatten mit JavaScript, außer dass man das vielleicht mal im Browser irgendwo gesehen hat oder so wie Andi da mal früher jQuery oder Mutools programmiert hat, das wo.

Peter Kröner (00:06:46 - 00:06:48)

Andi so stehen geblieben ist.

Wolfi Gassler (00:06:48 - 00:07:08)

Oder XJS haben wir gerade im Vorgespräch auch besprochen. Ich hab noch eine Software laufen, die mit CooksDuo läuft, mit dieser Library, falls die jemand noch kennt. Aber für alle, die jetzt keine Ahnung haben, was eigentlich JavaScript ist, wie würdest du denn ganz kurz in drei Sätzen beschreiben, was JavaScript ausmacht und was das denn eigentlich für eine Sprache ist?

Peter Kröner (00:07:09 - 00:08:35)

Also, wenn ich jetzt die beschreiben würde, nach dem, was sie ausmacht, würde ich sagen, ist die sicherlich am meisten verbreitete Programmiersprache der Welt, wenn es jetzt wirklich so nach Installationen von Engines geht. Also klar, alles, was Bits und Bytes macht, kann irgendwie C. Aber die wenigsten haben einen C-Compiler bei sich installiert. Aber sehr viele haben mehr als einen Browser am Start. Mehrere Geräte mit mehr als einem Browser am Start. Und das ist, glaube ich, so das Wichtigste für auch die Frage, warum das so beliebt und viel genutzt wird. Es ist halt eben einfach ultraweit verbreitet. Es gibt halt durch das Web einen direkten Kanal, Programme auszuspielen, dass jeder sofort auf sie zugreifen kann. Das Programm kann entweder im Webbrowser stattfinden oder auf dem Server. Und wenn ich die Sprache jetzt beschreiben müsste und ich jetzt mal so die Wikipedia-Definition rauskramme, danach habe ich mich nämlich jetzt mal in meiner Vorbereitung gerichtet. Eine multiparadigmische Skriptsprache mit schwachem dynamischen Duck-Typing-System. Aus den 90ern und relativ vielseitig, relativ formenreich auch, würde ich sagen. Gibt allerlei Varianten davon. allerlei Umgebungen, wo es existieren kann. Es kann im Browser laufen, es kann auf dem Server laufen, es kann ein Shell Script sein. Es kann halt eben alles Mögliche sein. Und deswegen ist es auch so, gibt's halt nicht so irgendwie die klassische JavaScript-Entwicklerschaft, sondern je nachdem, in welcher Umgebung man sich da bewegt, hat man da teilweise sehr, sehr unterschiedliche User Experiences, was das angeht. Man arbeitet mit sehr unterschiedlichen APIs, an unterschiedlichen Problemen, unter unterschiedlichen Bedingungen, mit unterschiedlichen Tools. Und deswegen kann man das nicht alles so bequem unter einen Hut kriegen, würde ich behaupten.

Andy Grunwald (00:08:36 - 00:09:05)

Vor circa anderthalb Jahren wurdest du auf den JavaScript Days interviewt und da wurde dir die Frage gestellt, was dich an JavaScript begeistert. Und deine Antwort war, dass mehr und mehr Zugriff auf Low-Level-RPIs gegeben wird, also auch im Browser. Und da hattest du unter anderem das Anwendungsfeld IoT als Beispiel angeführt und hast JavaScript als Verbindungssprache zwischen den verschiedenen Welten bezeichnet. Deine Definition gerade, die kam deiner initialen Begeisterung relativ nahe.

Peter Kröner (00:09:06 - 00:10:28)

Naja, es ist halt eben tatsächlich so eine Verbindungssprache oder halt eben auch eine Scharniersprache zwischen allen möglichen Welten, würde ich halt schon sagen. Also zum Beispiel, weiß ich nicht, du kannst deine ersten Raspberry Pi-Experimente, wenn es um dein klassisches Hallo Welt geht, ich will eine LED zum Leuchten bringen, das kannst du mit JavaScript machen. Oder du kannst irgendwie Google Mail und Facebook bauen und das aus JavaScript machen. Und alles zwischendrin ist irgendwo möglich. Und du kannst damit, keine Ahnung, also Beispiele noch und nöcher fallen mir ein, als wenn du irgendwie in einem ICE der Deutschen Bahn sitzt und du guckst dir da so den Bildschirm an, der da von der Decke hängt, wo dran steht, wie stark du verspätet bist. Das ist halt ein Chrome-Browser, der halt eine Webseite abfeuert. Das nutzen die halt eben einfach so als ihren Rendering-Mechanismus für ihre ganzen Informationen da unterwegs. Es ist halt wirklich super vielseitig und kann mit allem möglichen verbunden werden. Du kannst das irgendwie auf so einen Elektron draufpflanzen, an das Elektron irgendwelche Plugins dran basteln und dann kannst du das irgendwie an einer Maschine dran basteln, die dann irgendwie, keine Ahnung, Textilverarbeitung macht oder so. All sowas hab ich halt schon gesehen und das sind alles so Kontexte, wo das vorkommt und deswegen so Was ist JavaScript? Ist halt dann doch wirklich schon so eine sehr individuelle Frage, je nachdem, was du halt machst. Also bist du halt irgendwie so reformierte C-Entwicklerin, musst jetzt in so einem Crashkurs plötzlich Angular lernen und halt eben so eine Textilverarbeitungsmaschine, die dann auch eine Lebensspanne von irgendwie 30 Jahren hat, bevor sie zum ersten Mal weiterverkauft wird, machen. Oder bist du in irgendeinem Startup und musst halt nur schnell irgendwie so ein React-Ding zusammenklappeln, indem du einfach 17 Libraries miteinander kombinierst. Das sind alles sehr unterschiedliche Sachen. Und das gehört halt alles irgendwie dazu.

Wolfi Gassler (00:10:28 - 00:10:33)

Was ist denn die schrägste Plattform, die du jemals erlebt hast, wo JavaScript gelaufen ist?

Peter Kröner (00:10:33 - 00:12:03)

Ich würde sagen ICE sicherlich, aber ich glaube wirklich die von mir angesprochenen Textilverarbeitungsmaschinen fand ich am schrägsten. Also folgendes Szenario. Du hast so eine Maschine und die produziert halt irgendwelche Textilfasern. Und ich weiß ja nicht, wie sehr ihr so in dem Bereich drin steckt, aber diese Dinger haben ja Lebensdauern, die echt ultra krass sind. Also die werden ja wirklich weiterverkauft und nochmal weiterverkauft und nochmal weiterverkauft und die können ja ewig funktionieren, weil die halt eben einfach bloß ein Haufen sich schnell drehendes Metall sind. Also ich war mal bei so einem Startup dabei, die haben was mit Papier gemacht und die hatten halt so mehrere Geräte zum Zuschneiden von Papier und ein von den Dingern war halt eben aus den 30ern. und hat immer noch funktioniert. Da war jetzt keine Software drin. Aber trotzdem, stell dir das Szenario vor, du hast halt irgendwie so eine Maschine, und du baust die auf, und dann ist da nachher so ein kleines Bedienfeld drin, wo du halt irgendwie einstellen kannst, was für eine Art von Textil da am Ende rausfallen soll. Und das ist umgesetzt mit Electron. Electron ist folgendes, erstmal eine JavaScript-Engine, die macht das Backend, und die spricht Node.js, und da oben draufgetackert ist noch eine JavaScript-Engine, die macht dann das Frontend, ist quasi ein Browser mehr oder minder, und das rendert das Bedienfeld. Ist eine etwas seltsame Konstruktion, aber die hat so diverse Vorteile. Nur, ich stelle mir halt eben vor, wie dieses Ding dreimal weiterverkauft wird und in 60 Jahren muss irgendwer auf dem Ding irgendwas umbauen, macht den Deckel auf und findet zwei aneinandergetaktete JavaScript-Engines vor, mit einer Angular-Version von vor 60 Jahren. Ich wäre ja zu gern dabei. Ich will das jetzt auch nicht irgendwie schlecht finden oder so Zeug, weil ich keine Ahnung, irgendwie der programmiert Dialekt von vor 60 Jahren, mit dem halt irgendeine andere Maschine gebaut wurde, ist heutzutage sicherlich auch schräg. Aber wenn du mich jetzt fragst, wo ich jetzt JavaScript vor 10 Jahren nicht erwartet hätte, dann dort.

Wolfi Gassler (00:12:04 - 00:12:30)

Andis Lieblingsspruch ist immer, Legacy verdient das Geld. Und er spricht ja immer von diesen Black Boxes, die in irgendeiner Ecke stehen und Geld verdienen. Oder gerade so Steuerungssoftware, die irgendwie mit Hardware spricht. Da hat man ja durchaus mit so Software Legacy zu tun, die dann irgendwie 20, 30 Jahre alt ist. Also das kann ja durchaus passieren. Das heißt, du würdest jetzt JavaScript in diesem Umfeld nicht empfehlen? Oder würdest du sagen, naja, es ist gleich schwierig, wie wenn ich jetzt C verwenden würde?

Peter Kröner (00:12:31 - 00:12:36)

Also um da jetzt zu sagen, ob das eine gute Entscheidung gewesen ist oder nicht, müsste ich ja 60 Jahre in die Zukunft gucken. Kann ich jetzt nicht sagen.

Wolfi Gassler (00:12:36 - 00:12:39)

Und das kannst du gar nicht. Wo ist denn deine Glaskugel?

Peter Kröner (00:12:39 - 00:12:40)

Die ist in der Werkstatt.

Andy Grunwald (00:12:41 - 00:13:00)

Also, bei dem Use-Case und bei dem Szenario, was du gerne in zehn Jahren miterleben würdest, oder vielleicht auch in 30, 40 Jahren, wenn niemand mal irgendwann diese Blackbox wieder aufmacht, wäre meine erste Frage gewesen, okay, das Versionskontrollsystem, haben die die JavaScript-Libraries hoffentlich mit eingecheckt? Weil ich bezweifle, dass in zehn Jahren da noch ein NPM-Install möglich wäre.

Peter Kröner (00:13:01 - 00:13:01)

Wohl wahr.

Andy Grunwald (00:13:01 - 00:13:06)

Das war der einzige Vorteil von, glaub ich, den alten Sprachen C und so weiter, wo die Libraries wirklich einfach hart einkopiert wurden.

Peter Kröner (00:13:07 - 00:14:19)

Das ist, glaube ich, kein Faktor der Sprache. Das kannst du heutzutage immer noch machen. Also meine persönliche Software, auf die ich so aufbaue. Ich mache halt viele Workshops und so weiter. Ich habe mein eigenes Slidesystem. Ich benutze da nicht NPM für. Das ist alles runtergeladen und in minifizierter Form im Foldersystem mit der Versionskontrolle mit eingecheckt, weil ich halt das Ding nicht in 60 Jahren benutzen möchte, aber in 5 schon noch. Und ich will das Risiko gar nicht erst eingehen, dass da mit NPM irgendwie so was schief geht. Also solche Sachen halt auch wie so Package Manager oder sowas, ist ja auch ein Teil vom JavaScript-Ökosystem und so das Problem, das du jetzt gerade aufgemacht hast, das kriegst du ja auch schon in sehr viel kürzeren Zeiträumen. Also einer von meinen Kollegen da aus dem Working Draft Podcast, der Stefan Baumgartner, der ja sehr viel zu TypeScript und mittlerweile zu Rust macht, Der hatte vor der Pandemie mal angefangen, eine TypeScript-Konferenz bei sich zu Hause in Linz anzuschieben. Dann kam die Pest. Das ganze Ding ist pausiert worden. Er hat versucht, das wiederzubeleben und konnte halt eine Pandemie später einfach die Seite nicht mehr bauen. Weil NPM-Dependencies, Security-Inkompatibel, zirkuläre Dependencies, irgendwie sowas. Und dann hat er es halt eben einfach sein gelassen. Also nicht nur deswegen, aber das kann halt eben tatsächlich schon passieren. Nur das ist halt eben kein Feature der Sprache. Das kann man machen, indem man sich halt so in dieses Ökosystem reinbegibt, dass man dieses Risiko eingeht. Aber man kann es halt eben auch sein lassen.

Andy Grunwald (00:14:20 - 00:14:46)

Was ich meine, nicht, dass das jetzt abhängig von JavaScript ist, sondern dass die Community, wir alle Entwickler, sagen, oh nee, das muss ja alles dynamisch und die Daten liegen ja im Package-Repository und warum soll ich die denn jetzt hier alle reinkopieren? Aber bei C war das ja früher oder ist vielleicht heute immer noch so der Standard. Weil ich hab das Gefühl, viele Programmierer sagen, oh, das ist aber bad practice, wenn wir jetzt das Vendor-Dir oder wie nennt sich das? Das NPM-Modules, Node-Modules heißt's. Node-Modules. Mit reinkopieren und so weiter.

Peter Kröner (00:14:46 - 00:15:19)

Ja, aber das ist halt auch die Frage, wo ist da jetzt Ursache und Wirkung? Weil so Package Manager, wie du sie heutzutage hast und wie du sie ja heutzutage erwartest, tatsächlich auch, das gab's ja früher nicht. Also du kannst ja heutzutage auch keine Programmiersprache irgendwie mehr neu erfinden. Da gehört ja mittlerweile zur Grundausstattung dazu, dass du halt sowas wie ein Package Manager hast. Also so ein Rust hat sein Cargo, ein JavaScript hat sein NPM und alles, was dazugehört. Go hat auch so ein Ding, wenn ich mich nicht täusche, und ist halt von Anfang an mit im Funktionsumfang drin gewesen. Das ist halt, als würdest du heutzutage ein neues Auto ohne, weiß ich nicht, eine Klimaanlage verkaufen wollen.

Wolfi Gassler (00:15:20 - 00:15:42)

Wobei man natürlich schon auch sagen muss, dass so Package Manager grundlegend das Problem sind, weil wenn du im Linux-Umfeld bist und einen Package-Manager hast und da irgendwie, keine Ahnung, OpenSSL upgraden musst oder willst und du hast eine Dependency, dann läufst du genau in dasselbe Problem rein. Also ich glaube, das grundsätzliche Problem von Dependency ist, dass du natürlich immer haben kannst und dann kommt es natürlich darauf an, wie schnelllebig ist eine Sprache.

Peter Kröner (00:15:43 - 00:16:59)

Oder wie gehst du damit um? Ich glaub, der wichtigste Faktor bei solchen Entscheidungen, wie geh ich mit Dependencies um, ist, da gucken die Leute halt eben, wird das aktiv maintained oder so was? Na toll, wird halt heute noch aktiv maintained und morgen kann der einzige Maintainer von einem Bus überfahren werden. Das ist halt eben nicht wirklich sinnvoll, um die Zukunft vorherzusehen, sondern das einzig wirklich Relevante ist die persönliche Risikoeinschätzung. Also, was muss ich tun oder wie sehr am Arsch bin ich, wenn mit dem Ding irgendwas passiert, das es für mich nicht mehr benutzbar macht? Es kann ja alles mögliche sein. Und auf Basis von dem muss man halt eben entscheiden, ob man irgendwie sein Vendor Directory mit eincheckt oder nicht. Aber das passiert halt irgendwie nicht so recht, weil die Leute halt eben entweder stumpf der Best Practice folgen, was ja wahrscheinlich irgendwie ein sinnvoller Default ist für die meisten, aber trotzdem kann man darüber hinaus ja auch nochmal nachdenken und überlegen, wie gehe ich denn jetzt wirklich damit um, wenn ich in Schwierigkeiten komme? Und solche Abwägungen kann man ja machen, ne? Es ist halt nur so, durch diese Möglichkeiten, dass diese Package Manager existieren, dass sie einem als Default überall nahegelegt werden, dass der schnellste Weg zu Angular halt eben durch sowas durchführt, das macht's halt irgendwie leicht, aber trotzdem entlässt das ja die individuellen Entwicklerinnen und Entwickler nicht aus der Verantwortung. Im Zweifelsfall, wenn man wirklich was baut, was jetzt irgendwie mission-critical ist oder ewig lange halten muss, da auch mal drüber nachzudenken und vielleicht zu sagen, so, jetzt machen wir das mal wie zu Opas Zeiten und checken den ganzen Krempel mit ein, das kann man ja machen.

Andy Grunwald (00:17:00 - 00:17:09)

Wie zu Opas Zeiten. Kommen wir noch mal einmal ganz kurz zu den Grundlagen. Du hast JavaScript als die meistverbreitete Programmiersprache bezeichnet.

Peter Kröner (00:17:09 - 00:17:11)

Das ist meine Behauptung. Ich hab's nicht nachgemessen.

Andy Grunwald (00:17:11 - 00:17:51)

Und ich stell mir immer die Frage, das Programmiermodell von JavaScript mit dem prototypbasierten Ansatz ist ja ein bisschen anders als das, was man klassisch an der Universität oder im Informatikstudium, im Informatikgrundkurs oder Ähnliches lernt, wo man meist über Objekt orientiert, spricht und vielleicht sogar noch mal funktionale Sprachen. Wie siehst du das? Wie denkst du darüber nach, dass das zusammenpasst? Denn ich denke, es wird nicht so oft gelehrt, ah, das ist eine prototyp-basierte Sprache und ist keine objektorientierte Sprache, aber dennoch ist es halt sehr weit verbreitet. Siehst du da zum Beispiel in deiner Arbeit auch sehr viele Verständnisprobleme? In Bezug zur Objektorientierung zum Beispiel?

Peter Kröner (00:17:51 - 00:21:44)

Also erstmal würde ich behaupten, dass dieser Umstand, dass JavaScript mit Prototypen arbeitet und nicht mit klassischem OOP, ein Implementierungsdetail ist, das heutzutage man eigentlich kaum mitbekommt. Weil du kannst ja in JavaScript schreiben, Klass A extends B. Wenn du TypeScript hast, kannst du sogar schreiben, Class A, Extents B, Implements C. Das kannst du alles machen. Und du merkst nicht, dass das unter der Haube mit Prototypen zusammengestöpselt wird. Außer wenn du halt irgendwie mal das Brecheisen rausholst und irgendwas hacken willst, was eigentlich nicht funktionieren sollte. Deswegen würde ich sagen, ist das nicht so das große Problem an sich. Und generell ist es so, dass meiner Erfahrung nach im Web-Entwicklungsumfeld, da wo ich unterwegs bin, also im Frontend, tendenziell ziemlich viele Leute rumhüpfen, die mehr so in die Kategorie Quereinsteiger reinpassen. Da gehöre ich selber auch zu. Ich habe Geschichte, Film und allen möglichen anderen Blödsinn studiert, aber von Computern habe ich mich halt zu der Zeit, als Lernen mein Job gewesen ist, noch extrem weit fern gehalten. Also das ist, glaube ich, jetzt nicht so das Problem. Wenn ich jetzt so Verständnisprobleme oder generell so Alltagsprobleme mal irgendwie rausholen möchte, dann ist das mehr so daran. Darin begründet das JavaScript, also was jetzt prototypenbasiert gesagt, es ist halt eher eine multiparademische Sprache. Also man kann all in OOP gehen, indem man alles mit Klassen bestreitet. Es fehlen da so ein paar Sprachmittel. Es gibt keinen Protected Keyboard zum Beispiel, aber so die generellen Ideen von OOP und die ganzen Patterns und den ganzen Krempel kann man umsetzen. Das klappt halt nicht so hundertprozentig gut, weil JavaScript nicht all in OOP ist, aber hat das halt eben auch mit drin. Oder man kann halt komplett funktional arbeiten und irgendwie alles mit Funktionen und Currying und so weiter machen, wie man möchte. Das kann es auch nicht so richtig optimal, weil JavaScript halt eben vieles ist und unter anderem auch funktional. Aber es gibt halt eben diese ganzen verschiedenen Aspekte. Und Knirschen tut's halt eben immer dann, wenn diese Welten zusammenstoßen, ohne dass sie sich darüber im Klaren sind, dass hier zwei Welten aufeinanderstoßen. Ich hatte zum Beispiel mal den Fall, dass ich so eine kleine Entwicklertruppe hatte und die haben was mit Vue.js, einem von den bekannten Frontend-Frameworks, gebaut in TypeScript. und die kamen mehr so aus dem Backend und haben sich so gesagt, ich bin's gewohnt, Class A, Extents B zu programmieren, und das kann man in JavaScript auch machen, also haben sie sich mit Class A, Extents B was zusammen programmiert und haben das dann in Vue.js reingesteckt. Da, wo Vue.js sagte, gib mir die Daten. Jetzt sind hier im klassischen OOP die Klassen, die im Prinzip Vereinigung von Daten mit den relevanten Funktionen dazu. Alles unter einem Dach, damit das, was zusammengehört, auch zusammen da ist. Aber es sind trotzdem dann halt eben, sagen wir mal, Objekte, wo mehr drin ist als nur die Daten. Und wenn du etwas hast, was unter der Prämisse agiert, dass OOP im Sinne von Klassen ein sehr, sehr marginaler Use Case ist, weil der normale JavaScriptler wird das ja nicht machen, der schreibt einfach normale so Record-Objekte, einfach so Key-Value-Paare, und gibt die mir, dann kann es da halt schon mal zu sehr interessanten Effekten kommen, gerade wenn du halt sowas hast wie TypeScript, noch on top, ist ja eine JavaScript-Variante mit einem statischen Typsystem obendrauf, die unter anderem auch Dinge machen kann, wie Typen transformieren. Also du kannst Programmierung auf Type-Ebene machen. Und wenn halt so diese ganzen Aspekte zusammenstoßen, du hast irgendwie Leute, die sagen, ah, okay, das ist UOP, nur so arbeitet man, ich kenn das so, ich mach das so, ich wende meine Best Practices aus Feld 1 an, Feld 2 sagt, Ich bin Vue.js, wir machen hier so Javascript, mehr so am klassischen Frontend orientiert. Wir sind jQuery 2.0 und mir gibt man einfach nur diese Plain Objects und dann packen wir noch TypeScript in den Mix rein, rühren das einmal gut um und lassen das über Nacht im Kühlschrank stehen. Dann fallen da Fehler raus, deren Ursache nicht immer unbedingt klar erkennbar ist. die halt eben auch teilweise sehr, sehr lange Quasi-Stacktraces auswerfen. Und wo man dann halt auch so Dinge hat wie TypeScript Mods, da aber irgendwie zur Laufzeit funktioniert's, meistens, außer wenn dieses eine Feld gesetzt ist, aber der Fehler wird halt nicht wesentlich länger oder kürzer dadurch, da sehe ich halt öfter mal die Probleme. Aber das liegt halt eben einfach daran, dass JavaScript mittlerweile ja auch steinalt ist und Features akkumuliert, wie sonst was, und halt eben immer komplexer wird. Und du kannst halt, wenn du eine API designst und sagst, hier ist der Punkt, wo du mir Daten reingibst, und du definierst nicht sehr genau, was du unter Daten verstehst, Dann wird das halt eben unter Umständen sehr knifflig, weil die Leute dir halt irgendwelche Klasseninstanzen reinschaufeln und unter aus irgendwelchen Gründen in der Interaktion mit TypeScript geht es dann irgendwie schief.

Wolfi Gassler (00:21:45 - 00:22:04)

Du hast jetzt auch erwähnt, dass sehr viele Paradigmen zusammengeworfen werden in der Sprache. Glaubst du, dass das ein Grund ist, warum JavaScript auch so beliebt ist, dass jeder sofort seinen Weg findet und was er auch immer gelernt hat, sei es Funktional, sei es Objektorientierung, dass er da einfach extrem schnell damit was machen kann, weil JavaScript einfach fast alles kann.

Peter Kröner (00:22:04 - 00:22:59)

Ja, es schadet auf jeden Fall nicht. Also du kannst halt die besagte Vue.js TypeScript Klassentruppe. Die haben ja am Ende was gebaut, was funktioniert hat. Es ist halt nur so, man musste dem TypeScript Compiler am Ende immer sagen, halt die Klappe, halt die Klappe, ignoriere diesen Fehler. Aber es lief ja. und sie haben damit ihr Unternehmen vorangebracht, und das war ein funktionierendes Produkt oder so, es war halt nur nicht sehr schön, wie die Wurst am Ende gemacht wurde, und aus dem Grund bin ich da bei denen vorbeigekommen und hab ein bisschen versucht, die Fehler zu diagnostizieren und zu reparieren mit denen. Hat auch wunderbar geklappt. Aber es ist wirklich super, dass man heutzutage einfach so sagen kann, hey Java-Entwickler, ich muss euch jetzt nicht irgendwie beibringen, wie man mit jQuery Event Delegation macht, sondern hier hast du TypeScript, ja, das Typsystem ist ein bisschen anders, aber du kannst Interfaces schreiben, und du kannst Klassen schreiben, die diese Interfaces implementieren, Da ist man schon wirklich den Leuten sehr weit entgegen gekommen. Und das hilft, glaube ich, echt, wenn es darum geht, die Leute, die woanders herkommen, instantan produktiv zu machen. Das Problem ist, du hast Einsteiger, die von null aufkommen und die sagen, ich will jetzt programmieren lernen mit JavaScript. Holla die Waldweh, wo fangen wir denn da an?

Wolfi Gassler (00:22:59 - 00:23:12)

Du hast jetzt schon ganz viele Dinge erwähnt, Typescript. JavaScript an sich. Kannst du vielleicht erstmal ganz kurz einordnen, was ist Typescript für all diejenigen, die das wirklich noch nie gehört haben, beziehungsweise nicht so genau wissen, was es ist?

Peter Kröner (00:23:12 - 00:23:43)

JavaScript ist ja eine dynamisch typisierte Programmiersprache. Generell gilt, alles kannst du mit allem irgendwie machen und es kommt halt dann eine Antwort raus. Wenn du halt Blödsinn machst, kommt Blödsinn raus. Also, du kannst halt so Operationen schreiben wie 42 geteilt durch ein leeres Array. Und da wird JavaScript nicht sagen, TypeError, das geht nicht, sondern wird dir eine Antwort liefern. Die Antwort in dem Fall ist der Zahlenwert infinity, aus Gründen, die ich jetzt nicht verrate, aber das macht in dem Universum von JavaScript alles Sinn. Nur, ich kann jetzt, ich hab ja ein Webcam-Feed, euren Gesichtern anerkennen, dass irgendwie so eine Zahl geteilt durch ein leeres Array ergibt den Zahlenwert infinity, nicht auf universelle Gegenliebe stößt.

Andy Grunwald (00:23:45 - 00:24:07)

Also, ich hoffe, das kann jeder verstehen. Ich hatte auch in einer Vorbereitung ein Interview von dir gefunden, da wurde gefragt, welches denn dein Lieblings-JavaScript-Meme ist. Und da hattest du dieses zehn Minuten lange Video genannt, wo jemand verschiedene Typ-Konversationen und Additionen und Multiplikationen macht, und dann dieses Batman-mit-Watt-Video. Ist das immer noch dein Lieblingsmeme? Du sprichst ja schon wieder drauf an.

Peter Kröner (00:24:07 - 00:24:12)

Es ist halt ein billiger Witz, der gut funktioniert. Also muss man halt eben ganz einfach sagen. Also mein Liebster.

Wolfi Gassler (00:24:12 - 00:24:15)

Darum kommst du bei Andi immer gut an.

Andy Grunwald (00:24:15 - 00:24:17)

Flache Witze, mein Ding.

Peter Kröner (00:24:17 - 00:26:41)

Ja, also ich meine, das ist jetzt mein spezifisch schon JavaScript. Das ist halt eben einfach ein Klassiker. Das ist halt irgendwie so, als würde man dir, wenn ich jetzt sage, finde ich halt nicht so gut, ist halt irgendwie, als würde ich jetzt über Loreal schlecht reden. Das macht man halt eben einfach nicht. Aber wenn's jetzt so um Webentwicklung geht, ist eigentlich mein liebster Scherz, den ich halt gerne anbringe, der Umstand, dass in HTML Chuck Norris ne gültige Hintergrundfarbdefinition ist. Also wenn man ne Webseite hat und man gibt dem Body Tag das bgColor-Attribut und schreibt da Chuck Norris rein, kommt da ne Farbe raus und auch, das ist nicht hardcoded, das ist jetzt nicht ein Chuck Norris-Witz, der irgendwie in Chrome reingecodet ist, sondern das ist halt ein Effekt aus ner ganzen Reihe von Gründen, das ist so mein persönliches Lieblingsding tatsächlich. Aber wir wollten ja eigentlich nicht über Chuck Norris, sondern über Typescript reden. Also, 42 vielleicht durch ein leeres Array ergibt den Zahlenwert Infinity. Haben sie sich bei Microsoft gedacht, ist vielleicht nicht so gut, wenn wir jetzt irgendwie sagen, wir schalten jetzt Silverlight ab. Die Älteren erinnern sich vielleicht, das war ja so quasi das Flash von Microsoft. Und als der heilige Steve Jobs mithilfe des iPhones Flash abgesägt hat, musste ja Microsoft mitgehen und auch Silverlight absägen und den Leuten sagen, jau, jetzt macht ihr HTML5. HTML5 zu dem Zeitpunkt war ultra primitiv. Ich habe ja damals schon HTML5-Workshops gemacht und die Leute, die halt eben so aus dem Silverlight-Background zu mir gekommen sind, sind halt eben nach fünf Minuten auch schon wieder gegangen, weil die dachten, der kleine Zwerg da vorne will uns wohl einen vom Pferd erzählen. Das kann doch nicht angehen, dass ich jetzt irgendwie erstmal für die Internet Explorer irgendwelche JavaScript-Beschwörungsformeln murmeln muss. Ehe ich ein neues HTML-Tag, wie irgendwie Section, verwenden kann, das dann keinerlei sichtbaren Effekt hat, will der mich eigentlich verarschen. Das war so damals die Diskrepanz. Und Microsoft dachte sich, wir müssen diesen ganzen Backend-Entwicklern, die besseres gewohnt sind, eine goldene Brücke bauen, und haben dann gesagt, wie wäre es, wenn wir JavaScript ergänzen, um so ein paar Sprachmittel, die der gemeine Backendler gewohnt ist. Typen. Interfaces, Klassen, die es damals in JavaScript noch nicht gab und damit den Leuten eine goldene Brücke bauen. Das war so die Idee. Das war früher mal ein im Prinzip Metadon für Backend-Entwickler, damit die sich im Frontend zurecht finden und das wurde dann irgendwann im Laufe der Zeit umgebaut zu im Prinzip einem Typsystem für JavaScript, das in der Lage ist, sämtliches seltsame Verhalten von JavaScript und daran ist die Sprache ja nicht arm, aber mithilfe eines Typsystems statisch zu beschreiben. Das ist halt eben immer noch seltsam, aber erlaubt es einem halt eben in der JavaScript-Entwicklung, dem ganzen seltsamen Zeug, das man so macht, Leitplanken zu geben. Ich würde so sagen, 90 Prozent des Sprachumfangs und 99 Prozent von dem, was normale Menschen in diesem langen Tag machen mit JavaScript, kann man damit statisch beschreiben und kriegt dann Compiler Error, Refactoring Tools, im Prinzip eine moderne IDE Developer Experience, wie man es eigentlich gerne habe.

Andy Grunwald (00:26:42 - 00:26:47)

Und unten drunter muss dann dieser ganze Code dann zu JavaScript transpiliert werden? Oder wie funktioniert das?

Peter Kröner (00:26:47 - 00:27:17)

So sieht es aus. In den einfachsten Fällen musst du ja bloß die Typ-Annotationen rausstreichen. Also der TypeScript-Compiler versteht sich wirklich nur als ein Type-Checker. Du sagst, ich habe hier eine Zahl, ich habe hier ein Array, ich mache Zahl geteilt durch ein Array, was in JavaScript geht. und eine seltsame Antwort produziert, ist in TypeScript nicht erlaubt, also muss der TypeScript-Compiler halt eben schauen, mache ich irgendwo Zahl geteilt durch ein Array, wenn ja, Fehler, wenn nein, ist ja alles okay mit dem Programm, dann lösche ich einfach diese Typ-Annotationen, die sagen, das ist eine Zahl, das ist ein Array, aus dem Programm raus, übrig bleibt JavaScript und das kann ich dann so laufen lassen.

Andy Grunwald (00:27:17 - 00:27:23)

Okay, das bedeutet, die in der Browser von heutzutage können TypeScript noch nicht nativ interpretieren?

Peter Kröner (00:27:23 - 00:28:04)

Nee, das werden sie wahrscheinlich auch nicht können, weil da gibt's ja auch nix zu interpretieren. Also TypeScript versteht sich wirklich explizit als ein reiner Typechecker, etwas, das ausschließlich zur Developmentzeit existiert. Sobald du das in einen Browser überführen möchtest, ist, Stand jetzt ist so, dass Einfach nur die Syntax erweitert wurde, um Zeug, das die Browser nicht verstehen. Entfernen wir diese Erweiterung, verstehen die Browser die Syntax als normales JavaScript. Und weil ja diesen Schritt des Syntax-Entfernens nur dann gegangen wird, wenn der TypeScript-Compiler gesagt hat, die Typen passen alle, ist es dann automatisch auch ein vernünftig laufendes JavaScript-Programm, das macht, was du erwartest. Im Rahmen dessen, was ein statisches Typ-System in einer Mainstream-Programmiersprache im Jahre des CERN 2023 zu leisten imstande ist.

Andy Grunwald (00:28:06 - 00:28:18)

Immer wenn ich mich zu dem Thema JavaScript, TypeScript und so weiter informiere, befindet sich der Begriff ECMAScript in dem ganzen Dunstkreis. Wie ist dieser denn jetzt zwischen JavaScript und TypeScript einzuholen?

Peter Kröner (00:28:19 - 00:29:01)

Also hat mit TypeScript erst mal nichts zu tun, Stand jetzt. European Computer Manufacturers Association ist halt einfach so ein Laden, der macht halt Industriestandards. Und da hat sich halt eben dann die Arbeitsgruppe, die JavaScript erweitert, drin eingefunden. Die haben da ihre Arbeitsgruppe, TC, Technical Committee 39. Und die machen da halt ihr Zeug. Und die entwickeln da sozusagen im standardisierten Entwicklungsprozess einfach so JavaScript weiter. Die bringen jährlich eine neue Edition vom Sprachstandard raus, wo drin steht, so und so läuft das jetzt. Und das ist sozusagen einfach nur die Dachorganisation dazu. Und ECMAScript ist halt nur so, also meiner Meinung nach, wenn du jetzt wirklich so dem Internet beweisen willst, dass du der besonders durchblickende Influencer bist, dann sagst du nicht JavaScript, weil das ist technisch gesehen ein Trademark von irgendwem?

Andy Grunwald (00:29:01 - 00:29:24)

Von Oracle. Ich hab nachgeguckt und ich war erschrocken, denn es geht ja immer der Running Gag Java, JavaScript ist so das Gleiche. Und jeder denkt so, Java kommt von Oracle. Und dann hab ich auf der ECMA-Skript-Seite in der Vorbereitung gesehen, dass Oracle das Trademark-Java-Skript besitzt. Und ich hab gedacht, what the fuck, das ist doch jetzt nicht euer Ernst. Dieser Running Gag hat wirklich einen Hintergrund?

Peter Kröner (00:29:24 - 00:32:00)

Naja, die Idee ist die folgende, pass auf. Beame dich zurück in die 90er. Du arbeitest bei Netscape, dem heißesten Start-up des Planeten. Du räumst gerade so richtig auf, weil du das Internet quasi beherrschst. So, und um halt wirklich das Internet komplett zu beherrschen, brauchst du nicht nur einen Browser, sondern du musst halt eben auch Server irgendwie haben. Was ist die beste Programmiersprache der Welt? Natürlich Java. Also tweetest du einen Deal mit den Java-Leuten ein, der so aussieht, dass einerseits auf den Server, die du von Netscape aus vermarktest, in Zukunft Java läuft, und im Browser, da läuft der neueste heiße Scheiß. Java-Applets. Ja, die Älteren erinnern sich, das sind so diese grauen Boxen, die nicht funktionieren und wenn sie funktionieren, naja, konnte man halt einfach nur froh sein, dass damals mit Cryptomining und irgendwelchen Erpressungssoftware Trojanern es noch nicht so weit war. Sicherheitslücke, langsam, schlecht, schlimm, alles und so weiter. Aber das war so die Idee. Java Applets machen das Frontend fit. Und Java Server machen halt den ganzen Serverkrempel. Problem ist halt, für Java, da muss halt ein richtiger Programmierer sein. Da muss ein richtiger Graubart im karierten Hemd sein, der im Keller sitzt und irgendwie so unverständliches Zeug fabriziert. Aber wäre es nicht für den Webbrowser, wo die Idee damals noch war, dass es wirklich Dokumente sind, die von normalen Menschen geschrieben werden. Es gab ja kein Social Media. Wenn du irgendwen davon überzeugen wolltest, dass es mit den Chemtrails doch ernst zu nehmen ist, dann musstest du eine eigene Webseite bauen. Das konntest du nicht einfach bei Facebook schreiben. Gab's ja alles nicht. Es musste also etwas geben, was nutzerfreundlich ist, womit normale Menschen eine Webseite schreiben können. War jedenfalls so die Idee. Also brauchen wir eine Ergänzung zu Java, die im Prinzip eine Programmiersprache ist. So Java nur halt eben vereinfacht. Java für Babys. Eine Skriptsprache vielleicht, die so ist wie Java, aber nicht so ganz. Und das hat man bei Netscape halt wirklich so gemacht, die haben halt so plötzlich 10 Tage vor dem Release ihrer neuen Version festgestellt, hey, lass mal ne Ergänzung zu Java einbauen in unseren Browser. Die haben sich im Büro umgeschaut, ein Typ hat sich nicht schnell genug unter seinem Schreibtisch versteckt und dann haben sie dem gesagt, hey du da, du hast ja 10 Tage Zeit, bau mal ne Programmiersprache in den Browser ein, die aussieht als wäre sie Java, dass die also so Sachen hat wie ein New Operator, dass die so ein bisschen nach OOP aussieht oder so. Und wie gesagt, hast 10 Tage Zeit, go. Und dieser Mensch hat dann mit sehr wenig Hilfe von ein paar anderen Leuten was hingebaut, was dann Livescript hieß und dann die erste Version von JavaScript am Ende wurde. In zehn Tagen hat er natürlich so manchen Bock geschossen, der auch heutzutage noch in der Sprache zu finden ist, weil ich meine in zehn Tagen Ich krieg's ja kaum in mein Büro aufzuräumen, geschweige denn eine Programmiersprache zu implementieren. Er hat's geschafft, wunderbar, und seitdem haben wir das so wie es ist. Und daher kommt halt eben auch der Name und diese Namensverwirrung. Also die haben technisch nicht was gemeinsam in irgendeiner Form, aber irgendwelche Business-Fritzen haben mal gedacht, dass das doch eine wunderbare Kombination und ein sehr guter Marketing-Gag wäre.

Wolfi Gassler (00:32:00 - 00:32:09)

Das nenne ich mal MVP. Innerhalb zehn Tagen eine Sprache auf die Füße zu stellen, die dann irgendwie Jahrzehnte überlebt und eine der wichtigsten Sprachen wird.

Andy Grunwald (00:32:09 - 00:32:16)

Aber das ist ja, das ist ja jetzt interessant. Okay, die ganze Sprache wurde in zehn Jahren mal schön dahin geklöppelt.

Wolfi Gassler (00:32:16 - 00:32:17)

Zehn Tage meinst du?

Andy Grunwald (00:32:17 - 00:32:54)

Oh, Entschuldigung. Die ganze Sprache wurde in zehn Tagen dahin geklöppelt und natürlich kommen da Flaws. Die Herausforderung ist natürlich jetzt, jetzt leben wir mit diesen Flaws ja immer noch. Und in serverbasierten Sprachen, also im Backend, sagen wir mal PHP und Go oder wie sie alle heißen, da kann man ja Features deprecaten und irgendwann nach PHP Version 8 oder 9 oder 10 oder was auch immer, fliegen diese Features raus. Ist ja bei Java ebenfalls so. Ich habe bei JavaScript aber noch nie ein Feature verschwinden sehen. Gibt es die Möglichkeit überhaupt in JavaScript Features wirklich zu deprecaten und dann essentiell zu entfernen oder wird das Internet dann einfach kaputt gehen?

Peter Kröner (00:32:54 - 00:32:54)

Let's do this.

Wolfi Gassler (00:32:54 - 00:32:55)

Es würde kaputt gehen.

Peter Kröner (00:32:55 - 00:33:02)

Ja, sagen wir so, das ist eine extrem theoretische Sache. Wir haben ja vorhin mal kurz über das ECMAScript-Komitee gesprochen, die, die das halt eben bauen.

Wolfi Gassler (00:33:02 - 00:33:24)

Vielleicht noch als kurzer Einwurf bzw. eine Frage dazwischen. Dieser ECMAScript-Standard, das ist wirklich, an den sich dann alle halten? Oder kommt da dann Chrome und Google um die Ecke und sagt, bei unserer V8-Engine oder keine Ahnung, was die aktuelle Engine ist, da halten wir uns aber schon an unseren eigenen Standard? Feind damit noch dazu, wenn da ein E für Europa dabei steht, sich daran zu halten.

Peter Kröner (00:33:24 - 00:34:57)

Also, dass da jetzt ein E dran ist, das ist jetzt wirklich nur ein reines... Man hat sich halt entschieden, sich unter den Schirm dieser Organisation zu stellen. Aber man hätte auch zu jeder anderen gehen können. Das macht halt am Ende keinen Unterschied so wirklich. Jetzt hast du gerade gesagt, halten sich an den Standard. Was heißt an den Standard halten? Also das Problem ist jetzt das folgende. Wenn ich jetzt sage, das ist ein Industriestandard und da sitzen halt so Firmen drin wie irgendwie Google und Microsoft und IBM und hast du nicht gesehen und die knuppern halt eben aus, wie das mit JavaScript so läuft, klingt das so ähnlich wie, weiß ich nicht, irgendwie 5G oder Bluetooth. Also man beschließt und dann folgt die Implementierung. Das ist in JavaScript teilweise so ein bisschen anders, weil das Problem tatsächlich ist, was der Andi gerade sagte, Features deprecaten geht halt nicht. Und das geht nicht, weil dann das Internet kaputt gehen würde, sondern die Sache ist die, der Standard muss umgesetzt werden, wenn er nur in einem PDF existiert, interessiert er niemanden. Also müsste ein Browser hingehen und müsste etwas implementieren, damit es wirklich eine reale Auswirkung auf die Welt hat. Wenn es jetzt den Beschluss gäbe, ein Feature zu deprecaten, würde der erste Browser, der das umsetzt, weniger Webseiten darstellen können als die Konkurrenz und damit in kürzester Zeit aufhören zu existieren. Und die anderen Browser würden sagen, oha, das implementieren wir mal lieber nicht, weil sonst hören wir auch auf zu existieren. Es wäre also eher so, dass nicht das Internet aufhören würde zu funktionieren, sondern es würde aufhören zu funktionieren, der Browser, der als erster probiert, etwas zu deprecaten. Also Internet funktioniert nicht mehr, wäre ein Effekt zweiter Ordnung, der nicht eintritt, weil es an der ersten Hürde schon scheitert, weil der erste Browser, der sagt so, wir schalten jetzt mal ein Feature ab, der hört halt eben auf zu existieren. Das ist halt so das Ding.

Wolfi Gassler (00:34:57 - 00:35:11)

Und im ECMAScript-Konsortium sitzen aber die Großen natürlich auch drinnen vermutlich, oder? Google und Co. Genau. Das heißt, die können da natürlich dann auch dementsprechenden Einfluss haben und dementsprechend sich das zurechtrichten im Idealfall.

Peter Kröner (00:35:11 - 00:35:21)

Es ist halt eine völlig theoretische, also dass irgendwas abgeschaltet wird und dass dann es Breaking Changes gibt, ist einfach so dermaßen hypothetisch, dass es im Prinzip keine Rolle spielt, so wie du das jetzt gerade beschrieben hast.

Wolfi Gassler (00:35:21 - 00:35:26)

Aber auch jetzt bei neueren Features zum Beispiel, da nehmen Google dann schon Einfluss, Google-Leute.

Peter Kröner (00:35:26 - 00:35:56)

Ja, klar, sicherlich. Es gibt also wirklich so ein Verfahren, wie das alles so gemacht wird. Also das können wir natürlich auch hier nachher in den Shownotes verlinken. Das ist alles öffentlich. Das ist nicht irgendwie, dass da irgendwelche geheimen Prozesse am Werk sind. Das ist alles öffentlich. Man kann da die Protokolle lesen von den Sitzungen, von den Meetings, die die machen. Es gibt Mailinglisten, wo man da seine eigenen Vorschläge einbringen darf und sich dann erklären lassen kann, warum das so auf keinen Fall funktioniert. Am Ende entscheidet natürlich immer die Implementierung. Also Features, die am Ende nicht wirklich im Browser landen, existieren halt nicht und deswegen ist das dann egal.

Wolfi Gassler (00:35:56 - 00:36:20)

Also das ist so ähnlich, wie man früher immer gesagt hat oder wie es früher auch immer war, dass Cisco zum Beispiel entscheidet, was für Netzwerkprotokolle verwendet werden und das, was Cisco implementiert, gilt. Und irgendwann später kommt dann die IEEE und sagt, ja, da machen wir einen Netzwerkstandard daraus. Aber ohne Cisco passiert ja nichts. Und so ähnlich ist es dann mit den Browsern auch, solange kein Browser mitzieht. Existiert der Standard nicht so in der Richtung?

Peter Kröner (00:36:20 - 00:36:28)

Ja, wenn kein Browser mitziehen würde, würde es nicht mal zu einem Proposal kommen, das besonders weit kommt. Also es ist alles extrem theoretisch, was wir hier gerade so ... Also die.

Wolfi Gassler (00:36:28 - 00:36:34)

Implementierung findet üblicherweise dann statt, bevor eigentlich der Standard definiert wird.

Peter Kröner (00:36:34 - 00:37:18)

Genau. Sobald du ein neues Feature einführst, wie wir ja gesagt haben, es kann nie wieder was entfernt werden, ist es natürlich ein extremes Commitment, wenn du jetzt sagst, so machen wir das in Zukunft. Und da willst du natürlich vorher tatsächlich Versuche starten und auch die Community befragen. Also das muss halt tatsächlich so sein. Implementierung heißt ja nicht notwendigerweise auch, dass es im Browser landet. Es gibt ja auch zum Beispiel so Tools wie Babel. Das ist ein JavaScript-zu-JavaScript-Compiler, der in der Lage ist, zukünftige Features zu transpilieren. Also etwas, was man normalerweise in 500 Zeilen JavaScript schreiben kann, in einer gegebenen Version, könnte ja eine Version später durch neue Syntax zum Beispiel viel kürzer sein, in zwei Zeilen, und das können die implementieren. Weil das ein Compiler ist, in das sich modernes JavaScript reinschmeißen kann, und der kann was ausspucken, was in heutigen Browsern oder alten Browsern noch funktioniert.

Wolfi Gassler (00:37:18 - 00:37:21)

Das heißt, der garantiert mir dann die Abwärtskompatibilität?

Peter Kröner (00:37:21 - 00:38:21)

Der garantiert dir jetzt in dem Schritt des Prozesses erst mal, dass du Feedback einsammeln kannst. Also du kannst ja erstmal spezifizieren, ich hab hier ein Proposal für diese und jene Syntax und du kannst das erstmal in einem allerersten Schritt als so ein Bargain-Plugin ausprogrammieren, damit du wirklich gucken kannst, wie funktioniert das denn wirklich? Hinter welchen Use Cases ist das sinnvoll? Wie interagiert das mit anderen Features? Findet die Entwickler-Community das gut oder poppen dann irgendwelche Leute auch auf, die sagen, Gute Idee, aber so wäre doch viel schöner. Oder das funktioniert hiermit nicht. Also damit kannst du es halt eben sozusagen einen Testlauf machen. Und dann muss es halt auch noch in die Browser kommen und dann eskaliert das so langsam raus und irgendwann, wenn es dann wirklich so das Siegel bekommt, von wegen das ist jetzt im neuen ECMAScript-Standard drin, hat es sich zu einem großen Teil bereits in der Realität festgesetzt über den Weg von Implementierungen in Browsern oder in anderer Software, wie zum Beispiel diesem Babel oder zum Beispiel auch in TypeScript. Und das ist mehr so ein fließender Prozess und das abschließende Standardisieren ist mehr so ein verabschieden und an sich darüber einig sein, dass wir jetzt wirklich so in die Zukunft gehen, aber es materialisiert sich vorher schon zu einem guten Stück.

Andy Grunwald (00:38:22 - 00:38:41)

Also der Prozess, die ganze Sache erstmal als Babel-Plugin zu bauen und dann mal ein bisschen rumzuspielen, wie fühlt sich das an und so weiter, der klingt ja wirklich genial. Was ich mich gerade nur frage, baut man da jetzt speziell bei Babel zum Beispiel nicht super viel Technical Depth auf, weil dieses Tryout-experimentelle Plugin kannst du ja nie wieder löschen.

Peter Kröner (00:38:41 - 00:38:46)

Nö, aber das liegt ja auf NPM rum und wird bis in alle Ewigkeit installierbar sein. Und die, die das nicht glauben, können das ja in den Vendor-Folder stecken.

Andy Grunwald (00:38:47 - 00:38:51)

Ich weiß nicht, ob ich Babel-Maintainer werden möchte. Das klingt echt dreckig.

Peter Kröner (00:38:52 - 00:40:06)

Das ist ein Plug-in-System. Babel ist nur so ein Ding, das hat so eine Parser-API und schluckt JavaScript-Code. Du kannst Transformatoren und Plug-ins dran knuppern, die sagen, ich verschlucke die Syntax-Extension, die vorher nicht verstanden wurde, und generiere daraus jenen Output. Das ist ein Plug-in-System und deswegen so anstrengend zu konfigurieren. Das ist ein Aspekt von JavaScript. Es gibt tausend Tools. Und man braucht irgendwie einen eigenen Doktor, um überhaupt die alle zu konfigurieren. Und das ist halt eben auch diesem sehr modularen Ding geschuldet. Es gibt halt zum Beispiel wirklich so JavaScript-Features, die sind im Ofen seit mittlerweile, ich glaube, zehn Jahren. Es ist jetzt verabschiedet worden, wie es zum Beispiel mit Decorators aus weitergehen soll. Das sind so Klassenannotationen mit einem Ad davor, die gibt's ja auch in Java und C-Sharp und anderen Programmiersprachen. Und da ist jetzt wirklich so im Ofen, wie es aussehen soll. Aber es gab vorher schon Implementierungen. Wir machen es jetzt so. Oh nee, funktioniert doch nicht. Wir machen es jetzt so. Ach nee, geht auch nicht. Und das ist weiterhin maintain. Also das Decorators-Plugin in Babel, das hat so einen Fleck, wo man sagen kann, welche Version hätte ich denn gerne? Die von damals, aus dem Jahr, aus dem Jahr oder aus dem Jahr. Und TypeScript hat zwei Implementierungen von Decorators, eine alte und eine neue. Und das müssen die halt so lange maintainen, bis die das abschalten. Aber weil die halt nur irgendwelche Software sind, können die das ja machen. Das können nur Browser nicht, weil die die Plattformen sind, aber irgendwelche Software. auf Basis der Plattform, die kann machen, was sie will.

Andy Grunwald (00:40:06 - 00:40:33)

Aber jetzt mal die Devil's Advocate-Question. Ja. Wenn die Standardisierung eigentlich nur noch ein formaler Prozess dann hinten dran ist, warum macht man den ganzen Aufwand denn da noch? Also ich mein, weil die ganze Sache wird ja dann schon in der Community genutzt via Babel-Plugin. Gegebenenfalls hat irgendein Browser vielleicht schon hinter einem Feature-Flag die ganze Sache implementiert. Also im Chrome kann ich ja etliche experimentelle Features sogar anschalten. Warum wird der Longtail da noch gegangen und wirklich alles standardisiert, auch wenn's, wie du schon sagtest, teilweise zehn Jahre dauert?

Peter Kröner (00:40:33 - 00:40:35)

Das wird deshalb gemacht, weil.

Andy Grunwald (00:40:37 - 00:40:37)

In dieser.

Peter Kröner (00:40:37 - 00:43:23)

Feature-Entstehung ist es so, dass du folgendes Problem hast. Du hast die vielen unterschiedlichen Aspekte von JavaScript. Zum Beispiel den Server und den Browser. Und was halt eben passiert, wenn einfach die Community ihre eigenen Wege geht, ist, dass sie mehrere Wege gehen und dass wir dann so divergierende Pfade bekommen. Das war zum Beispiel ein Problem mit JavaScript-Modulen. Es war so, JavaScript so nach 10 Tagen entwickelt, kein Modulsystem, weil natürlich nicht 10 Tage, was schmeiße ich als erstes raus aus der Feature-Liste. Modulsystem ist klar, weil kompliziert. Aber nur weil es kein Modulsystem von offizieller Seite gibt, wie wir aus Jurassic Park wissen, das Leben findet einen Weg. Und das Leben hat in dem Fall sogar zwei Wege gefunden, nämlich einen kleinseitigen Weg, wie Module funktionieren, nämlich mit irgendwie so Sachen wie Require.js, Die Älteren erinnern sich vielleicht noch. Und in Node.js gab es das Common-JS-Modul-System mit Exports und Require. Und die haben ja beide auf einer super High-Level-Ebene das Gleiche gemacht. Die haben nämlich gesagt, hier, wir implementieren mithilfe von Software ein Modul-System. Aber da haben wir wirklich genau eine Diskrepanz, die sich halt eben in der jeweiligen Realität der Subcommunities widerspiegelt. Auf dem Server kannst du einfach ein Modul von einer Festplatte laden und sagen, jawoll, beim ersten Start des Programms, wenn der ganze Modultree geladen wird, mei, dann hänge ich halt eben einfach so lange fest, bis halt irgendwie meine rotierende Rostfestplatte irgendwie die JavaScript-Datei da rausgekramt hat und wenn mein Programm fünf Sekunden zum Starten braucht, wen kümmert's? Fünf Sekunden zum Laden einer Webseite. In einer Zeit, wo wirklich der komplette Browser festhängt und eingefroren ist und blockiert und nix geht, ist komplett inakzeptabel. Und deswegen haben sie für das Browser-Modul-System einen asynchronen Lademechanismus gebaut, der für Browser essentiell ist, aber für die Serverseite komplett überflüssig ist, weil das ein Problem löst, das die gar nicht haben. Und dann kommst du in eine Welt, wo du zwei Modulsysteme hast, die das Gleiche wollen, auf einem hohen Level, aber die komplett massiv und fundamental inkompatibel zueinander sind. Und dann ist es schon sehr viel wert, wenn man sagen kann, Jungs, ihr wollt das Gleiche. Wollen wir nicht eine Lösung bauen, sie alle zu knechten? Und so sind halt eben dann die ECMAScript-Module zustande gekommen, die halt eben auch genau deshalb so kompliziert sind und deren Einführung so unglaublich schmerzhaft ist, weil die halt hier die Synthese aus zwei unterschiedlichen Sets von Anforderungen bringen, mit aber dem Ziel, dass du hinterher hingehen kannst zu NPM und sagen kannst, ich will eine Lösung für X haben. Du installierst sie und egal, ob du einen Server, einen Shell Script oder eine Webseite bauen willst, das funktioniert einfach. Da sind wir noch längst nicht, aber da werden wir sein, sobald das in ein paar Jahren endlich durchgekaut ist. Und das ist halt eben dann der Mehrwert, dass man halt eben nicht diese Parallelwelten hat. Davon haben wir mehr als genug in Form von Framework hier, Framework da, Webstandard da drüben, alter Browser hier. Das muss man nicht auch noch auf der Sprachebene noch weiterdrehen. Und Module sind halt ein gutes Beispiel dafür, wie unglaublich schmerzhaft und unglaublich aufwendig das ist, aber welchen Benefit das eben auch bringen kann, wenn wir es denn schaffen, das durchzuziehen.

Wolfi Gassler (00:43:23 - 00:43:49)

Siehst du den allgemeinen Problem mit Client und Server? Früher hat man auch immer gesagt, JavaScript zu Beginnzeiten, JavaScript ist die Lösung, weil da können wir jetzt endlich Code wiederverwenden. Code, den wir auf der Serverseite haben und Code, den wir auf der Clientseite haben. Ihr habt wenig Implementierungen gesehen, wo das wirklich funktioniert hat. Siehst du auch auf der Standardisierungsseite irgendwie Probleme, die daraus entstehen, dass man eben Client und Serverseite abdecken muss? Außer dass es vielleicht auch zwei Communities sind.

Peter Kröner (00:43:49 - 00:45:59)

Also in der Implementierung auf der Seite der Sprache selber, wenn wir jetzt wirklich auf dem ECMAScript-Standard unterwegs sind, gibt es das Problem eher nicht. Es ist zum Beispiel bei den Modulen auf die Weise gelöst, dass dort beschrieben ist, die Modulsyntax und ein gewisses High-Level-Verhalten beschrieben ist, aber zum Beispiel die Frage, Wie kommt ein Modulkode jetzt in die Ausführung rein? Das ist gar nicht beschrieben, sondern das ist zum Beispiel dann implementierungsabhängig. Das heißt, das Laden von Modulen ist dann zum Beispiel etwas, was so andere Standards wie zum Beispiel der, weiß ich nicht, DOM-Standard für Webbrowser beschreiben. Oder was halt so Implementierungen wie Node.js einfach frei entscheiden können. Wichtig ist halt nur, dass das makroskopische beobachtbare Verhalten halt eben gleich bleibt. Aber das ist halt nicht so das Problem, weil man immer noch sagen kann, es gibt hier diese relevanten Gemeinsamkeiten für die Entwicklerschaft, nämlich so schreibe ich es, um diesen Effekt zu erzielen und den Rest kann man dann halt eben durchaus sich aufgliedern lassen, aber es ist halt nur wichtig, diesen großen Fork zu vermeiden. Also da besteht halt mehr so das Problem und das wird dadurch in den Griff bekommen. Und wenn's jetzt darum geht, so Code-Reuse-Server-Site-Client-Seite, das gibt's heutzutage durchaus. Es gibt so diese sogenannten Full-Stack-Frameworks, so Next.js und Consorten, die so die Idee haben, man beschreibt abstrakt eine Web-Applikation, so und so soll sie aussehen, und das Ding ist im Prinzip ein ultraschlauer Compiler, der in der Lage ist, den geschriebenen Code, den du gebastelt hast, so zu portionieren, dass ein Teil davon auf dem Server läuft, ein Teil davon auf dem Client läuft, im Idealfall musst du dir darum keine Gedanken machen. Also das gibt es halt in der Form schon. Ich glaube, davon hat man sich anfangs sehr viel mehr versprochen, als man jetzt im Moment erntet. Aber das ist halt im Moment, wie es ist. Es ist jetzt nicht so, dass diese Vorteile nicht existent wären, aber es ist halt immer einfach immer so diese unglaublichen, schwierigen, unterschiedlichen Trade-Offs. Auf dem Server, wenn dir wirklich egal ist, wie lange dein Programm braucht zum Starten, kannst du halt alle möglichen Dependencies mit allen möglichen Subdependencies reinladen, das ist alles total kein Problem. Aber auf dem Client musst du halt dich darum kümmern, dass alles blitze-schnell lädt, weil du sonst halt irgendwie SEO-Probleme kriegst und irgendwelche Maschinenbauer aus dem Süden toppen dich in den Suchmaschinen-Ergebnissen. Also Performance ist da super wichtig. Und das ist halt wirklich schwierig, da so eine One-Size-Fits-All-Lösung zu finden, wenn nicht gar vielleicht ein Ziel, das man möglicherweise gar nicht verfolgen möchte, aber das muss man halt eben dann so für sich entscheiden. Was ist so das Ding, woraufhin man optimieren möchte?

Wolfi Gassler (00:45:59 - 00:46:02)

Jetzt hast du schon Nuxt.js erwähnt als Framework.

Peter Kröner (00:46:02 - 00:46:09)

Ich hatte Nuxt erwähnt, aber Nuxt ist die Variante von dem Ganzen auf Vue. Wir müssen sie ja alle namedroppen, sonst fühlt sich nachher jemand benachteiligt.

Wolfi Gassler (00:46:09 - 00:46:56)

Ist ja richtig. Da wären wir heute nicht mehr fertig in einer Episode, wenn wir alle Frameworks droppen müssen von JavaScript. Das wäre genau meine Frage gewesen. Es gibt ja massig an Frameworks. Hast du irgendwie eine Erklärung dafür, warum es eigentlich so viel gibt? Ist es, weil die Sprache eben so modular aufgebaut ist? Das ist ja nicht nur bei den Frameworks, sondern auch in der ganzen Build-Pipeline. Du hast überall kleine Tools, musst die zusammenstückeln und am Ende hast du wirklich hunderte Libraries, die du in irgendeiner Form verwendest. Ist es die Modularität von JavaScript? Ist es, weil es einfach die meistverwendete Sprache ist und dementsprechend einfach viele Köche daran kochen in dem ganzen Ecosystem oder hast du da irgendwie eine Erklärung dafür oder ist es einfach nur schlechtes Marketing, dass jeder schimpft? JavaScript hat so viele Frameworks und das, was ich heute verwende, ist morgen tot.

Peter Kröner (00:46:56 - 00:48:45)

Also erstmal das Geschimpfe finde ich besonders lustig. Also meine Internet-Experience besteht ja darin, dass ich 99,9% von allem, was an mir vorbei scrollt, ignoriere. Und das machen die meisten so und die kommen damit super klar, warum das gerade im Fall von JavaScript-Frameworks unmöglich sein soll, dass man dann irgendwie zu all diesen Dingern eine Meinung haben muss und von wegen, das ist jetzt aber eins zu viel, das verstehe ich nicht so ganz. Nee, aber zur Ursachenforschung jetzt mehr so, würde ich sagen, es ist halt so, dass so JavaScript-Framework eine Kategorie ist, die ist so breit, dass sie, glaube ich, anfängt, an Nützlichkeit zu verlieren. Du findest ja in Use Cases für JavaScript-Framework alles von WordPress-Webseite, die ein bisschen aufgehübscht werden muss, bis hin zu ich-bin-das-Frontend-von-facebook.com und alles dazwischen. Natürlich gibt es da nicht für alles irgendwie, weiß ich nicht, eine Lösung, sie alle zu knechten. Wäre doch Schwachsinn, wenn es das gäbe. Es ist ja auch so, die Leute kommen aus den unterschiedlichsten Richtungen. Ich will funktional arbeiten. Ich will objektorientiert arbeiten. Keines von diesen Paradigmen ist jetzt dem anderen irgendwie per se vorzuziehen, sondern das ist eine multiparadigmische Programmiersprache. Mach halt, wie du möchtest. Willst du mit TypeScript arbeiten oder willst du ohne TypeScript arbeiten? Naja, wenn du mit TypeScript arbeiten willst, dann ist es sinnvoll, das Framework auf eine Art und Weise zu gestalten, dass sämtliche Teile von der Konstruktion eines Moduls von TypeScript nachvollzogen werden. Sprich, wenn du irgendwie beschreiben willst, das ist der Aufbau der Webseite. Hier ist der Body, da ist das Ausklappwidget und da ist der Button. Das muss halt irgendwie in JavaScript passieren, damit TypeScript das checken kann. Wenn du sagst, TypeScript ist mir nicht so wichtig, dann ist es ja vielleicht eine gute Idee, so Sachen wie ein Template in so was wie HTML zu beschreiben. Ist ja egal, dass TypeScript das nicht versteht, weil TypeScript halt eben nicht deine Priorität ist. Und das ist alles so eine Vielfältigkeit an Use Cases, an Dingen, die abgedeckt werden müssen und an verschiedenen Varianten, wie man Dinge machen kann, dass es halt notwendigerweise so ist, dass es viele verschiedene Wege gibt, die nach oben führen. Und das finde ich auch vollkommen okay.

Andy Grunwald (00:48:45 - 00:49:18)

Das ist auch komplett nachvollziehbar, was du jetzt gerade erzählst. Doch wenn man das gleiche Ökosystem aber mal von einer anderen Perspektive betrachtet, nämlich von Leuten, die mit JavaScript anfangen zu arbeiten, hattest du mal vor knapp drei Jahren gesagt, und die Analogie fand ich sehr sehr schön, muss ich zugeben, an der Sprache ändert sich nicht mehr so richtig viel, Also das ist nicht die Komplexität für den Einstieg, also die Einstiegshürde, sondern es ist einfach nur die schiere Masse. Und du hattest die ganze Thematik als sehr verstreutes Ökosystem bezeichnet und mit einem Tümpel verglichen.

Peter Kröner (00:49:18 - 00:49:42)

Mit einem Ökosystem. Das ist einfach so ein Ding und da wohnen viele verschiedene Organismen und die vertragen sich teilweise und die vertragen sich teilweise nicht, die fressen sich teilweise, die parasitieren einander. Das ist wirklich ein Ökosystem. So krampfs wie irgendwie das C-Sharp-Ökosystem ist kein Ökosystem, sondern da hat sich halt irgendwer Gedanken gemacht und das designt. Will nicht sagen eins ist besser oder schlechter als das andere sind nur fundamentale unterschiedliche Organisationsstrukturen.

Andy Grunwald (00:49:43 - 00:50:18)

Und da frage ich mich klar C-Sharp primär von Microsoft getrieben mit hoher Wahrscheinlichkeit stark biased aber alles ich sag mal in line wohingegen natürlich jetzt bei diesem verstreuten Ecosystem bei einem Tümpel du weißt ja auch nicht auf welche Libellenart du erstmal gucken musst. wenn du jetzt neuer libellen forscher bist ist das nicht vielleicht sogar der riesen nachteil und dass da vielleicht auch wirklich ich sag mal die meisten fehler gemacht werden oder irgendwie immer nur mit kanonen auf spatzen geschossen wird also ich meine react wird glaube ich für das facebook front erfunden und irgendwie nutzt halt jeder react habe ich so das gefühl und ich frage mich machen die alle in.

Peter Kröner (00:50:18 - 00:52:00)

Facebook frontend Sehr extrem gute Frage. Das ist nämlich das Erste, was ich auch immer sage, wenn ich so beim durchschnittlichen Mittelständler einreite, und die sagen, wir machen jetzt hier React mit TypeScript, und ich so, okay, warum? Ihr baut irgendwie eine Webseite für die Abfallwirtschaft, und da braucht ihr jetzt React und TypeScript für? Ist das wirklich notwendig? Ja, nein, vielleicht? Ist der eine Punkt, ne? Der andere Punkt ist halt eben aber auch, wichtig ist doch am Ende, was hinten rauskommt. Und wenn du halt irgendwie zufälligerweise irgendwie einen Deal dafür bekommen hast für, keine Ahnung, das React mit TypeScript Bootcamp, und da kannst du irgendwie deine komplette Entwicklertruppe hinschicken, Und die kommen dann am Ende da raus und sind in der Lage, mit React und TypeScript was hinzuzaubern, was wunderbar funktioniert. Und du scheffelst damit Kohle ohne Ende und kaufst die Konkurrenz auf. Habe ich jetzt irgendwie nicht so sehr die Berechtigung, denen zu sagen, dass das irgendwie falsch gemacht ist. Also, ich will halt nur sagen, viele Wege führen nach rum und man muss halt eben individuell einschätzen, wenn man hinterher bewertet, wie ist es geworden. Die wichtige Frage ist ja nicht, ist das jetzt irgendwie optimal gelaufen oder nicht, sondern hätte man es besser wissen können. Am Ende musst du die ganze Software, die du fabriziert hast, früher oder später eh neu schreiben. Klar, das JavaScript ändert sich nicht mehr, das wird bis in alle Ewigkeit funktionieren. Und solange du dein Framework niemals updatest, wird alles immer so funktionieren wie bisher. Aber trotzdem, dann kommt Steve Jobs um die Ecke und er findet das iPhone. Dann kannst du dein Webdesign in die Tonne treten, ohne dass irgendwie an der technischen Grundlage irgendwas kaputt gegangen ist. Es verändert sich halt eben die Welt auch außenrum und die wirkt halt eben auf den Standard und das, was du geschrieben hast, mit rein. Also, ne? Und deswegen denke ich halt immer so, okay, wir haben was gebaut und das ist halt irgendwie jetzt hinten nicht so gut rausgekommen. Ist sowieso die wichtigste Frage. Erstens, wie kommen wir denn trotzdem dazu, dass wir am Ende wieder produktiv werden? Und in zweiter Ordnung, maximal ist relevant, hätte man es irgendwie besser wissen können. Also hätte man wissen können, dass irgendwie wir jetzt nicht Facebook werden. Und selbst das finde ich irgendwie uninteressant, weil es ist halt, wie es ist. Und jetzt ist halt die wichtige Frage, wie kriegen wir den Laden jetzt wieder ans Laufen? Und nicht so sehr, wer ist schuld?

Andy Grunwald (00:52:01 - 00:53:06)

Ich schreib zwar jetzt nicht jeden Tag JavaScript, aber hier und da mach ich schon mal ein npm install oder erstellen ein Package, lesen und hol mir ne Dependency rein etc. Doch ich komm auch aus ner Zeit früher Agenturzeit, jQuery per Script Tag eingeklinkt und weiter geht's. Und ich hab so das Gefühl, ein bisschen von außen beobachtet geb ich zu, dass wir früher sehr simplistisch waren und auf der einen seite des extremen pendels und dass wir in der zeit in den letzten paar jahren klar die welt hat sich gedreht die ganze sache ist komplexer geworden mehr mehr webtechnologien und so weiter und vielleicht auch sogar mehr polyfilz und was heißt der geil nicht alles Aber dass wir das mit dem Extrempendel genau in die andere Richtung gependelt sind. Weil wenn ich heute mal ein JavaScript-Projekt starte, ich bin mir nicht sicher, ob ich grad ordentlich ein Webpack-Config konfiguriert krieg, weil das ist halt schon echt kompliziert. Und ich frag mich, pendeln wir von den sehr simplistischen Methoden zu dem sehr extremen und finden wir uns bald irgendwie wieder in der Mitte ein, weil wir alle gelernt haben, wie's richtig funktioniert? Oder übertreib ich grad und ich seh das alles nur ein bisschen schlecht, Ich.

Peter Kröner (00:53:06 - 00:56:15)

Würde nicht sagen, dass du das schlecht siehst oder so ähnlich. Ich finde, du siehst es korrekt, im Sinne von das Frontend-Engineering ist sehr viel komplizierter geworden. Ich würde nur der Charakterisierung als Pendel ein bisschen widersprechen, weil das jetzt so in meinen Augen dann dazu führt, dass es am Ende auch wieder zurückgeht. Und da bin ich noch ganz klar bei, dass wir nicht in den gleichen Fluss zweimal reinspringen können. Also es ist komplizierter geworden, im Frontend sicherlich, aber das kommt ja nicht von ungefähr. Es ist sicherlich so, dass es viele Web-Projekte gibt, die wären mit sowas wie jQuery oder einem Mutools-Äquivalent oder weiß ich nicht, so einer super, super simplen Templating-Library wie Knockout.js, die Älteren erinnern sich vielleicht auch daran, immer noch ganz gut beraten. Und die sind sicherlich außer Mode gekommen, für die gibt es keine, in Anführungszeichen, modernen Äquivalente und da wäre sicherlich etwas zu machen für viele Projekte. Viele overengineeren sicherlich. Aber ich würde sagen, im Großen und Ganzen kommen wir nicht dazu, das Rad der Zeit wieder zurückzudehnen, weil das, was du jetzt gerade so geschrieben hast, also, ja, die Welt hat sich so ein bisschen gedreht. Ich würde sagen, das ist extrem relevant. Also die Ansprüche an das, was so eine Webseite macht, haben sich halt dann doch verändert. Wie schnell muss es halt eben laden? Was muss es alles so an Interaktionen unterstützen? Es soll bitteschön auf meinem Telefon, das ich in Dark Mode gestellt habe, halt eben auch entsprechend aussehen. Es soll auf meinem Telefon überhaupt funktionieren, so vom Layouting her. Ich möchte halt eben, dass so Dinge wie Sicherheit mit irgendwie Content Security Policy und was nicht allem, halt eben mich auch davor bewahren, dass ich von irgendwelchen finsteren Mächten gehackt werde. Das sind alles so Dinge, Da sagst du jetzt halt eben, boah, ja, Webpack-Config ist viel komplizierter als früher jQuery in die Webseite reinschmeißen. Aber ich wette, dass, erstens, wenn du nochmal sowas bauen willst, was mit dem jQuery früher gemacht werden konnte, das würdest du heutzutage genauso machen, das würde genauso funktionieren, das wäre auch sicherlich nicht verkehrt, das so zu machen. Nur die meisten Projekte wollen dann doch heutzutage ein bisschen mehr. Und sei es halt nur die Developer Experience, wo es halt eben darum geht, ich speichere, der Webserver, der Development Server baut alles neu, drückt automatisch auf F5 und ich sehe das Ganze live geupdatet, wie es jetzt ist. So Produktivitätssteigerungen sind halt eben auch was wert. Und dieser ganze Webcam-Pack-Config und so, das kommt halt nicht von ungefähr. Viele sehen das so als, ich muss jetzt viel Zeug machen, das ist alles so Boilerplate und das bringt mir alles nichts, aber ich glaube, da wird ein bisschen die Vergangenheit etwas überschätzt bezüglich, was wir früher alles hatten und was wir nicht hatten. Also, das Rad der Zeit lässt sich sicherlich nicht zurückgehen. Es ist nur so, viele Projekte, viele WordPress-Seiten, viele Webseiten, die könnten tatsächlich ohne React auskommen. Aber viele Projekte sind halt eben heutzutage auch nicht einfach nur die nächste WordPress-Seite, sondern die sind halt eben mehr. Und für die ist ein großes, oder sagen wir mal, ein signifikantes Maß an all dem ganzen Krempel, den man sich so reinlädt, sicherlich sinnvoll. Nur, das Einzige, worauf ich halt eben zurückkommen würde, wäre das, was ich zu Beginn gesagt habe, über die Bewertung des Risikofaktors. Also will ich mir wirklich alles mögliche reinziehen und einfach so reinladen oder will ich vielleicht gerade so als größere Firma nicht auch irgendwie so Teile meines Produkts auch besitzen und unter Kontrolle haben und so? Das sind so Fragen, die man stellen kann. Nur fundamental an der zunehmenden Komplexität ändert sich da eigentlich nicht viel. Das ist halt eben kompliziert. Die Welt dreht sich weiter, die Produkte werden immer fähiger und das muss halt irgendwie von irgendwen bezahlt werden und das sind dann halt eben wir, die wir da mit der Machete durch den Code-Dschungel uns durchhacken müssen.

Wolfi Gassler (00:56:16 - 00:57:14)

Mich persönlich wundert es ja immer, wie komplex es eigentlich ist, ein neues JavaScript-Projekt aufzusetzen. Einfach mit den ganzen Einstellungen, was für ein Target ich bei TypeScript verwende, was für ein Modulsystem ich verwende. Du hast Babel, du hast Webpack, keine Ahnung, was es noch alles für Libraries gibt und es gibt ja auch Wizards, aber dann machst du vielleicht irgendeine Änderung nach dem Wizard-Setup und Also ich rechne mir mittlerweile schon eigentlich bei einem neuen JavaScript-Projekt einige Stunden, teilweise sogar einen Tag schlussendlich, wenn ich dann irgendwie alten Code noch reinkopiere oder so, weil ich mir denke, ich will irgendwas machen, was ich früher verwendet habe. Das kopiere ich noch schnell rein und dann bricht wieder alles. Also dieser Ramp-Up-Time für mich persönlich ist zumindest extrem hoch, wenn ich das vergleiche jetzt mit irgendeinem PHP-System oder so, gefühlt. Also ich würde mir wünschen, dass es da vielleicht einfach bessere Wizards gibt oder Library-übergreifende Ich habe auch keine Lösung dafür, aber persönlicher Pain ist es immer wieder, kommt mir vor.

Peter Kröner (00:57:14 - 00:57:23)

Weißt du, was ich vorschlagen würde, was du machst? HTML-Webseite, kein Style-Sheet reinwerfen, Script-Tag auf, JavaScript-Code reintippen, Script-Tag zu. So lange, bis... Mach ich auch oft.

Wolfi Gassler (00:57:23 - 00:57:23)

Kann man gut starten.

Peter Kröner (00:57:23 - 00:58:59)

Genau. Und so fängst du halt eben an. Und so lange, bis es nicht mehr funktioniert. Und sobald das anfängt, nicht mehr zu funktionieren, eskalierst du es ein Stück weit. Da könntest du zum Beispiel hingehen und könntest sagen, statt Webpack, was ja wirklich so die große Kanone ist, nimmst du ein Tool wie Parcel. Parcel ist wie Webpack, aber mit so sinnvollen Defaults. Dem musst du nicht sagen, dass er Typescript verwenden soll, sondern in dem Moment, wo du halt eben in dein Script-Tag eine .ts-Datei einbindest, geht er halt eben hin und sagt sich, hm, da will wohl jemand Typescript verwenden, also sollte ich wahrscheinlich diese foo.ts in foo.js übersetzen mit den Typescript-Defaults. Und dann machst du damit so lange weiter, es hat nicht mehr funktioniert, und dann eskalierst du weiter. Weil, ich weiß jetzt ja nicht, was du unter Projekt verstehst, aber bei mir ist Projekt meistens, hm, mal gucken, ob das überhaupt irgendwo hinführt. Wahrscheinlich mache ich in drei Stunden was komplett anderes, aber ich gucke erst mal. Ne? Und für solche Sachen ist es halt wirklich wichtig, erst mal anzufangen mit wirklich den basalsten Basics. Und das ist halt eben dann der Punkt, wo so Sachen wie Grundkenntnisse in so HTML und CSS einen auch schon sehr weit tragen. Weil wenn du zum Beispiel irgendwie so ein Auf-Club-Zu-Club-Widget haben willst, Da musst du nicht React für haben. Es gibt das Details Element in HTML, was das einfach so nativ mitbringt und damit kommst du halt eben extrem weit. Es ist halt nicht fancy animiert, es ist ein bisschen schwierig zu stylen, aber vielleicht willst du es ja gar nicht haben für die ersten paar Tage, wo du an dem Ding rumschraubst. Also man muss halt ja nicht immer sofort all-in gehen. Man braucht nicht die ganze Toolchain ganz zu Beginn. Man kann mit seinen Aufgaben durchaus auch wachsen. Es ist halt so, dass diese ganzen Tools, diese ganzen Wizards wie Create, React App und Consorten halt eben immer hingehen und die einem die komplette Kathedrale hinstellen. Aber wenn man von den Basics ein bisschen Kenntnis hat und mit Basics meine ich halt so Sachen wie HTML, CSS und die Kenntnis davon, dass es neben Webpack auch Alternativen gibt, dann kann man halt eben auch klein anfangen und mit den Aufgaben wachsen.

Andy Grunwald (00:59:00 - 00:59:33)

Aber ich mein, sieht so der Alltag in Firmen aus, denn oft ist es ja natürlich so, dass innerhalb von einer Firma hast du mehrere Teams. Da wird vielleicht gesagt, okay, die Firma spezialisiert sich jetzt auf Vue.js oder auf React, ist ja völlig egal. Du baust ja auch In-House-Knowledge auf. Das geht ja viel weiter als ich wachse mit meinen Aufgaben und nehme die einzelnen Libraries, sondern es geht ja wirklich um effektiv Codesharen, ich sag jetzt mal, in den Entwicklerteams von 30, 40, 50 Leuten, die jetzt primär Frontend-Applikationen bauen und so weiter. Also das geht ja viel weiter und gegebenenfalls ist es dann auch einfacher, ein neues Projekt einfach mit React zu starten.

Peter Kröner (00:59:33 - 01:00:04)

Ja klar, aber für den Fall hast du dann tatsächlich ja auch ein Standardvorgehen für die Firma. Also was jetzt der Wolfgang beschrieben hat, habe ich jetzt mehr so verstanden als alle paar Mal, wenn ich das mal mache, so, hin und wieder mal, dann ist es mir halt immer relativ schwierig, das neu aufzugleisen. Aber wenn du jetzt wirklich eine Firma hast und du sagst, unser Business besteht darin, alle drei Tage ein neues Angular-Projekt anzustoßen, dann würde ich halt eben schon erwarten, dass es da irgendwie im internen Wiki vielleicht sogar ein Buildscript gibt, wo ich halt hingehen kann, kann das anstoßen und der installiert mir diese 30 Sachen und dann ist es halt eben so der Standardprozess, den ich hier habe.

Andy Grunwald (01:00:05 - 01:00:15)

Ich meine, vielleicht ist Wolfgang jetzt nicht die 50-Mann-Firma, das stimmt schon. Der ist vielleicht so produktiv wie 50 Mann, aber eigene Standard hat er sich bis heute, glaube ich, nicht gesetzt.

Wolfi Gassler (01:00:15 - 01:00:37)

Naja, ich verwende dann schon wirklich teilweise alte Projekte und kopiere mir das einfach, um das gleiche Setup wieder zu haben. Aber man will ja auch irgendwie mit der Zeit gehen, wieder was Neues machen und dann probiert mal irgendeinen neuen Standard aus, ändert es und dann fliegt einem wieder alles um die Ohren. Es ist halt so immer diese schlechte Experience. Aber wenn man mal einen sinnvollen Stack hat und Setup, kann man den ja gerne wiederverwenden. Das funktioniert normalerweise ganz gut.

Peter Kröner (01:00:37 - 01:03:00)

Also ich kopiere auch irgendwie so die wichtigsten fünf Config-Dateien immer vom letzten Projekt ins nächste und fange dann damit an. Aber das ist halt eben auch immer so, also das sind halt so Sachen wie der Linter und irgendwie so die TypeScript-Config und so. Es ist halt aber nicht die Projektstruktur, weil das halt wirklich so ein ich wachse mit meinen Aufgaben ist. Und das kann man halt eben schon so machen. Ich glaube, das wichtige Problem ist halt tatsächlich, in diesem ganzen Frontend-Krempel ist nicht so sehr der Umgang mit irgendwie JavaScript speziell, sondern es ist wirklich genau, was Andi gerade gesagt hat, so diese High-Level-Dinger. Wie mache ich Codesharing? Wie organisiere ich die Dinge, die halt auch über das individuelle Projekt hinausgehen? Und das sind wirklich so die wichtigeren Fragen und das interagiert irgendwo mit so dem JavaScript-Standard. So zum Beispiel irgendwie, okay, Modulsystem, wie mache ich das jetzt, dass ich irgendwie mein Modul so habe, dass es auf Node und auf dem Browser gleichermaßen läuft und wenn ich irgendwie npm install mache, dass das für die jeweilige Umgebung dann korrekt ist und so. Das sind sicherlich Herausforderungen, die da so in dem Tooling drin stecken. Aber das sind halt eben dann auch einfach Herausforderungen, die man irgendwie so dann mal auch angehen sollte. Also wenn ihr mich jetzt fragt, was sehe ich in den Firmen oft? Da sehe ich halt oft dieses Phänomen, dass alle machen es, aber niemand hat den Hut auf. Es gibt halt niemanden, der irgendwie so diese internen Prozesse mal irgendwie so vereinnahmt und sagt, so und so läuft das jetzt. Das sind halt so Sachen wie Projektstrukturen für halt eben solche, wir machen immer mal wieder so eine App, dass es da einfach keinen Standardweg gibt, sondern dass es halt eben im besten Fall so ein Copy-Paste-Geschichte ist, aber nicht irgendwie so ein Dokument, so und so macht das, macht man das. Codesharing passiert entweder gar nicht oder informell, statt dass man mal irgendwie NPM ein paar Dollar rüberschiebt und einfach so ein eigenes privates NPM-Package haben kann, weil das kann man wirklich für sehr kleines Geld haben und das würde sehr viel helfen, weil dann gibt es einen Weg für Codesharing, der heißt nämlich NPM-Install. Und dann war es das. Das kann man alles haben. Also das sind einfach so die makroskopischen Fragen, die halt so diese Firmen betreffen. Und viel größer halt eben noch, dass so Sachen wie, dass man so Projekte hat, die wirklich irgendwie so fundamental für den Betrieb von einem Unternehmen sind und die sind nicht irgendwie drei Jahre nicht gewartet worden und NPM-Install funktioniert nicht, sondern die sind so lange gewartet worden, bis man die Dokumentation für die Software gar nicht mehr aufrufen kann, wegen irgendwelcher HTTPS-Fehler im Browser. Das ist eigentlich mehr so das Ding, wo ich so viele rein rutschend sehe, dass sie halt den ganzen Webcramper überhaupt nicht ernst nehmen und so lange ignoriert haben, bis sie ein riesiges, vitales Produkt irgendwo in ihrem Backend laufen haben und sie irgendwie so das Fernziel haben, wir hätten jetzt gerne React, aber es fehlt halt irgendwie so der Weg, wie kann man überhaupt aus diesem Zombie wo gibt's überhaupt die Möglichkeit, so was wie ein Webpack oder auch nur die Idee eines Bildprozesses irgendwo reinzubasteln?

Andy Grunwald (01:03:00 - 01:03:51)

Du hast schon was Gutes angesprochen, aus dem Zombie was Modernes zu machen. Und wenn ich jetzt wieder an die Weiterentwicklung der Sprache denke, dann hab ich eigentlich so drei Player im Game. Das TC39, die Standardisierungsmenschen, dann die Frameworkentwickler, die Menschen, die das dann alles irgendwo einbauen in das Tooling, sei es React, sei es Webpack, sei es ... Auch mein kleines Polyfill ist ja charge, es ist ja völlig egal. Und dann auf der anderen Seite die Softwareentwickler in den Firmen, mit denen du tagtäglich arbeitest. Siehst du eine positive Entwicklung der Sprache dahingehend, dass reale Probleme in der Praxis gelöst werden? Oder würdest du sagen, da sitzen irgendwelche Leute in irgendwelchen Eiffeltürmen, machen sich die schöne neue Sprache, aber lösen gar nicht so wirklich die relevanten Probleme, womit die Softwareprogrammierer an der Basis wirklich strugglen.

Peter Kröner (01:03:51 - 01:06:55)

Nee, nee, nee, die lösen die Probleme. Also, das ist, das merkt man ganz deutlich an so einigen Sachen. Mein Lieblingsbeispiel dafür ist so die async-await-Syntax, die man im modernen JavaScript hat. Also, im einfachsten Fall kann man da wirklich den Leuten sagen, Vor die Dinger, die irgendwie was lange brauchen, machst du ein Await vor, machst die Funktion Async, Ende aus Mickey Maus und musst die Details gar nicht erklären. Wenn ich das so mit früher vergleiche, wo man irgendwie so sagen musste, ja, Promises, da musst du dann mit Then diese Ketten machen und den letzten Catch-Callback nicht vergessen, oder wenn man ganz früh zurückgehen muss, dann muss man irgendwie mit Callback-Funktionen arbeiten und sowas. Und diese ganzen Dinge sind halt eben einfach so ersetzt worden durch die neuen Features. Im Sinne von, die alten sind noch da, und wenn man will, kann man immer noch programmieren, als hätten wir die wilden 90er. Aber es gibt halt eben diese moderne Alternative, die einfach den Code viel, viel besser lesbar macht. Also zum Beispiel ist es so, haben wir ja gesagt ganz zu Beginn, das ist eine multiparadigmische Programmiersprache. Ich kann irgendwie funktional arbeiten, ich kann imperativ programmieren, OOP machen, was auch immer. Aber mit zum Beispiel sowas wie AsyncAwait kann man den Leuten einfach sagen, wenn ihr nicht wollt, dass ihr mit Funktionsverschachtelung und Piping und Callbacks und Funktionen höherer Ordnung arbeiten könnt, bietet euch AsyncAwait die Möglichkeit, in eine Welt zu treten, in der es ausschließlich imperative Programmierung gibt. for und while und else und if. Das ist alles einfach nur das eine Paradigma, das ihr wissen müsst und ihr müsst nicht Context Switching betreiben, wenn ihr das nicht unbedingt wollt. Und das ist zum Beispiel wirklich irre viel wert. Ich muss den Leuten nicht erklären, was Funktionen höherer Ordnung sind, wenn ich einfach sagen kann, async, await, ender, aus, mickey, mouse. Das ist zum Beispiel extrem viel wert. Und noch ein anderes Beispiel ist, wir haben ja gesagt, dass man keine Features abschalten kann. Das geht nicht. Alle Böcke aus der Vergangenheit sind weiterhin in der Sprache drin, aber die sind ja nicht alle noch weiter relevant. Zum Beispiel gibt die Möglichkeit, JavaScript in den Strict-Mode zu versetzen. Da kann man an den Anfang seines Programms ranschreiben, use strict, und dann sind bestimmte Böcke von früher deaktiviert. Ist aber so ein Opt-in-Verfahren. Muss ein Opt-in-Verfahren sein, weil man will ja bestehenden Code nicht kaputt machen. Jetzt ist es aber so, dass man, wenn man in TC39 ein neues Feature definiert, man ja sagt, okay, dieses Feature ist neu, diese Form von Sonntags gab es vorher nicht. Also gibt es auch keinen Bestandscode, der kaputt gehen kann. Also kann man sagen, wir definieren zum Beispiel ein neues Feature, wie zum Beispiel Klassen so, dass die per Default im Strict Mode sind, ohne Opt-Out. Das heißt, der JavaScript-Code, der heute geschrieben wird, ist, weil er so Sachen wie Module und Klassen verwendet, per Default im Strict Mode und damit sind de facto viele von den Böcken, die damals in den 10 Tagen geschossen wurden, nicht mehr relevant, ohne dass man was kaputt machen musste, weil man sozusagen den Entwicklern so eine Möhre vor die Nase hält. Guck mal hier, Möhre, Klassen und Module willst du haben, kriegst du aber nur, wenn du diese ganzen alten Böcke nicht mehr schießen kannst. Und was haben da die Entwicklerschaft gemacht? Die hat natürlich gesagt, Klassen und Module, gib! Und seitdem gibt es halt eine ganze Menge von Problemen nicht mehr. Und das ist so ein Fall, wo die Leute gar nicht wissen, dass es ihnen besser geht. Aber es gibt halt so viele, viele Fehler, die sie gar nicht mehr machen können. Und das ist auch was wert. Das sind so diese zwei Faktoren. Async-Await ist nur der offensichtlichste Fall von der Vereinfachung. Und der Default-Strict-Mode von neuen Features ist was, wo die meisten Leute gar nicht mitbekommen, dass sie jetzt in einer besseren Welt leben. Aber trotzdem, weniger Böcke, die man schießen kann.

Andy Grunwald (01:06:56 - 01:07:57)

Ich hab mal von einer Konferenz gehört, und zwar hat darüber, ich glaub, Rob Pike, einer der Köpfe hinter der Go-Programmiersprache gesprochen. Und zwar heißt die Konferenz, ich glaub, Language Conference oder Ähnliches. Ich glaub, die wurde von Microsoft organisiert. Da werden primär die Köpfe hinter den Programmiersprachen eingeladen. Um ein bisschen über die Features und Weiterentwicklung der Sprachen. Und Rob Pike hat darüber gesprochen, dass dort sichtbar war, dass ziemlich viele Programmiersprachen sich Features aus anderen Programmiersprachen nehmen und diese zu implementieren für ihre eigene. Das führt natürlich dann über Zeit dazu, dass sich alle Programmiersprachen, die bisher alle ihre Stärken und Schwächen gehabt haben für bestimmte Use Cases, natürlich über Zeit angleichen. Und wenn ich mir so ein bisschen durch die Proposals auf TC39 mal ein bisschen durchschaue, dann hab ich da teilweise so ein Gefühl dafür, dass das hier auch so der Fall ist, weil JavaScript sich natürlich auch ziemlich viel Features bedient, die in anderen Sprachen natürlich auch da sind.

Wolfi Gassler (01:07:57 - 01:08:00)

Hast du jetzt grad durch die Blume gesagt, die haben alle von Go abgeschrieben?

Andy Grunwald (01:08:00 - 01:08:45)

Wolltest du das jetzt wieder sagen als Go-Fan? Ganz und gar nicht, weil ... Ab und zu, ich mein, Go und Generics, ja? Ich glaub, die Diskussion hat jeder auch nicht Go-Fanboy mitbekommen. Oder dass Go einfach ewig kein Package-Manager hatte. Und dann, genauso wie der Peter dieses Modul-Chaos genannt hatte, hatten wir das in der Go-World auch mit Package-Manager, dass wir 30 Package-Manager hatten. Auf jeden fall habe ich so das gefühl okay die bedienen sich sehr vielen anderen sprachfeatures keine ahnung ein for instatement big int ich gucke jetzt mal named catch groups in regular expressions und so weiter und so fort. Hast du das gefühl dass die sprache sich viel näher an andere sprachen annähert oder sagst du hey das ist einfach eine stärke weil da muss man nicht immer das rad neue finde ich.

Peter Kröner (01:08:45 - 01:10:32)

Ich würde sagen, der Trend ist mehr so ein globaler Trend, dass die Programmiersprachen einander ähnlicher werden, weil... Also ich meine, was war eine Programmiersprache früher? Da saßen so ein paar Typen im Keller und die haben sich so Gedanken gemacht und haben mal eben aufgeschrieben, wie sowas aussieht. Das ist ja heutzutage nicht zu vergleichen mit so diesem gewaltigen Aufwand, der zum Beispiel betrieben wird, um sowas wie ein Rust in die Welt zu setzen. Der gewaltige Aufwand, der betrieben wird, um irgendwie PHP in die neueste Version zu bringen oder so. Das sind ja alles riesige, riesige, riesige Operationen. Das ist einfach... von der Quantität her eine ganz andere Menge von Arbeit, die dahinter steckt. Und dann kann man sich es halt eben auch erlauben, einfach mehr Features zu haben und für gewisse syntaktische Vereinfachungen, wo irgendwer mal eine gute Idee hatte, das halt eben auch auf andere Sprachen zu übertragen. Ich glaube, das ist halt so allgemein so ein Trend. Finde ich jetzt auch nicht irgendwie schlecht oder so. Ich glaube, dass es trotzdem so ist, dass diese Programmiersprachen immer noch in ihrem Kern, auch wenn sie sich syntaktisch ähnlich sehen, sehr unterschiedliche Qualitäten, glaube ich, haben. Und auch unterschiedliche Zielsetzungen und ich sag mal so, Werte haben, die sie vertreten wollen. Also wenn man jetzt zum Beispiel irgendwie sowas wie TypeScript, Go und Rust, um einfach so drei populäre Sprachen irgendwie mal zu nennen, nebeneinander hält. Dann, klar, kannst du eine lesen, kannst du auch die andere lesen, weil ja die Sprachkonstrukte ungefähr alle sich schon ziemlich ähnlich sind und man bekommt eine relativ gute Idee davon, was so auf einem Makro-Level da vor sich geht. Aber wenn es am Ende darum geht, das zu schreiben oder damit bestimmte Ziele zu verfolgen, könnte es doch unterschiedlicher am Ende nicht sein. Und ich glaube, da werden wir auch nicht von wegkommen, auch wenn sie sich oberflächlich einfach, weil sie bessere Informationen haben und mehr Ressourcen haben, sich voneinander zu bedienen. Klar, wird einander ähnlicher und das ist auch gut zum Lernen und zum Weiterverstehen und so weiter. Aber ich glaube, es ist immer noch so, dass das Konzept Programmiersprache in sich wieder so eine breite Kategorie ist und dass es da so viele unterschiedliche Ziele gibt, die es zu verfolgen sich lohnt, dass da aus einer oberflächlichen Ähnlichkeit nicht viel bei rumkommt, würde ich behaupten.

Andy Grunwald (01:10:33 - 01:10:35)

Jetzt hat ja JavaScript ein Monopol im Browser.

Peter Kröner (01:10:35 - 01:10:43)

Ja, wenn du jetzt JavaScript als Monolith da stehen lassen willst und nicht irgendwie JavaScript und TypeScript als zwei dann doch relativ getrennte Entitäten sehen willst.

Andy Grunwald (01:10:43 - 01:11:04)

Ich betrachte das als Monolith, weil im Endeffekt putzelt aus TypeScript ja auch JavaScript. Und deswegen sage ich, okay, JavaScript ist die Programmiersprache, die ein Monopol im Browser hat. Und meine Frage wäre jetzt eigentlich, denkst du, es wäre ein Vorteil, wenn JavaScript mal reale Konkurrenz im Browser bekommen würde? Browserskript jetzt schreiben kann oder ähnliches?

Wolfi Gassler (01:11:04 - 01:11:07)

Andi-Skript, du kannst ja mit einer neuen Skript-Sprache um die Ecke kommen, Andi.

Andy Grunwald (01:11:07 - 01:11:19)

Dass wir auf jeden Fall eine zweite Programmiersprache haben, die man genauso wie JavaScript auch im Browser laufen lassen kann. Und ich meine jetzt nicht was Transpiliertes oder Ähnliches, sondern wirklich so wie Python und Java oder so.

Peter Kröner (01:11:19 - 01:11:49)

Genau. Aber was wäre sozusagen der andere Wert, den du verkörpern würdest? Also, weil es reicht ja nicht, eine Programmiersprache zu haben und irgendwie zu sagen, ich bin irgendwie schneller zu tippen, ich kompiliere ein bisschen schneller, ich bin ein bisschen, keine Ahnung, moderner, sondern du musst ja irgendwie sagen, so, ich verfolge jetzt hier wirklich ein grundsätzlich anderes Set an Features. Ich bin Rust, ich komme jetzt hierhin, um mal irgendwie so C und C++ zu sagen, dass das so mit diesem ganzen Memory-Gebimsel so auch anders laufen könnte. Ich habe halt wirklich eine andere Idee davon, wie die Welt sein müsste.

Wolfi Gassler (01:11:50 - 01:11:57)

WebAssembly war ja so ein bisschen in die Richtung, oder? Die neuen Features, oder mit einem anderen Ansatz eigentlich so gekommen sind.

Peter Kröner (01:11:58 - 01:12:50)

Ja, mit so anderen Fähigkeiten, ne? Dass du halt irgendwie sagen kannst, ich nehm jetzt irgendwie so eine Library, die ich schon habe, wie zum Beispiel SQLite, irgendwie vollnützliche Datenbank, etabliert, alles super. Und ich nehm da jetzt dieses C-Programm, stopf das in irgendeinen Mechanismus rein, der das im Browser lauffähig macht, badabing, badabung, funktioniert, ne? Das wäre ja zum Beispiel etwas, was einen, sagen wir mal, weiterbringen könnte. Aber das ist immer mit Reibungsverlusten verbunden, weil du halt immer diese Brücke halt eben hast zwischen dann der WebAssembly-Welt und der JavaScript-Welt. Und die JavaScript-Welt ist halt immer noch eine, die halt davon viel profitiert, dass, wenn du die Aktion bei Button klickst, soll was passieren. Die ist halt erstmal inhärent JavaScript im Moment. Und ich wüsste auch nicht, was sozusagen auf dieser fundamentalen Ebene JavaScript jetzt ersetzen sollte oder warum man es ersetzen sollte. So, Button und Klick, mach was und dann mach vielleicht noch ein bisschen mehr und noch ein bisschen mehr und noch ein bisschen mehr. Das kannst du ja wirklich extrem weit drehen, bis es dir wirklich anfängt weh zu tun.

Andy Grunwald (01:12:51 - 01:13:20)

Ob wir jetzt für den Event-Händler, für Button-Klick eine neue Sprache bräuchten, weiß ich jetzt auch nicht. Aber JavaScript ist ja, wie du es auch schon beschreibst, weit, weit mehr als ein Event-Händler auf einem Button oder ähnliches. Und wenn ich mir jetzt die erweiterten Use Cases wirklich mit vermehrtem Zugriff auf native APIs, wenn ich da so ein bisschen drüber nachdenke, dann kann ich mir schon vorstellen, dass ein neues Paradigma gar nicht so schlecht wäre, was dann eine neue Programmiersprache reinbringen würde.

Peter Kröner (01:13:20 - 01:13:24)

Hm, was heißt das mit nativen APIs?

Andy Grunwald (01:13:24 - 01:13:55)

Na ja, also, wenn man jetzt sagt, dass über den Browser vermehrt wirkliche APIs von dem Rechner angesprochen werden. Ja. Dass man aus der Browser-Sandbox langsam rausgeht. Natürlich, mehr und mehr APIs kommen ja immer wieder. Doch irgendwann wird's ja ... Also, der Browser ist ja jetzt schon die Applikationsgrundlage mit Electron und V8 und alles, was da hinten dran ist. Das bedeutet, wer heutzutage eine Applikation baut, die auf dem Desktop läuft, und im Web, das ist ja mit hoher Wahrscheinlichkeit oft eine Webapplikation, Discord und Slack und.

Peter Kröner (01:13:55 - 01:13:56)

Wie sie alle heißen.

Andy Grunwald (01:13:57 - 01:14:12)

Da kann ich mir schon vorstellen, wenn das jetzt so weitergeht, bin ich mir gar nicht sicher, wie lange wir dann, populäre Aussage jetzt, wie lange wir dann wirklich noch native Objective-C-Applikationen haben auf einem Mac. Oder ob das dann nicht einfach Elektron einfach so gut wird, dass man da kaum noch einen Unterschied merkt.

Peter Kröner (01:14:13 - 01:16:13)

Aber die Frage ist ja trotzdem, wenn ich jetzt so eine Analogie mal aufmachen darf zwischen der Perspektive einer Webapplikation auf native APIs und einer anderen populären Applikationsplattform auf native APIs. Wenn ich zum Beispiel mein Telefon jetzt hernehme und ich habe da jetzt irgendwie so ein Android-Telefon und ich will jetzt damit irgendwie auf eine native API zugreifen. Sagen wir mal ein ganz simples Beispiel, ich will eine Kamera machen. Dann ist es ja so, okay, da ist eine Kamera drin mit irgendwie einem Sensor und einer Linse und was nicht allem. Aber einfach so nur aus schieren Gründen der Sicherheit und des Containments und des Sandboxings muss es ja trotzdem so sein, dass meine in zum Beispiel Java geschriebene Android-App zu einer High-Level-Plattform-API hingeht und sagt, gib mal Kamera mit diesen paar Konfigurationsoptionen. Genauso läuft es auch im Browser. Also da sehe ich auch nicht die Notwendigkeit. Ich sehe es eher so, dass es ganz praktisch ist, wenn das alles durch diese High-Level-APIs getunnelt wird. Einfach so im Sinne von der Verwaltung von Privacy und der Sicherheit und des Sandboxings oder so, wo du gerade gesagt hast, aus der Sandbox rauskommen, dachte ich schon so, bäh, nein, bloß nicht, ich will doch nicht, dass irgendwie eine dahergelaufene Webseite, auf die ich versehentlich draufklicke, dann plötzlich hingeht und weiß Gott was macht. Nein, da soll alles schön gesandboxert sein, die sollen irgendwelche High-Level APIs bekommen, wo auch ein Vollhuhn wie ich in der Lage ist, die Spezifikationen zu lesen und so feststellen kann, aha, okay, der kann zwar meine Kamera anmachen, aber nur, wenn dies, dies und dies passiert ist. Das ist eigentlich eine gute Welt, in der ich eigentlich sein möchte. Deswegen, wir haben jetzt gerade gesagt, den Button- und Click-Händler müssen wir nicht notwendigerweise ersetzen, aber vielleicht wollen wir SQLite nicht re-implementieren, sondern wir wollen diese C-Library verwenden. Das ist so das andere Ende, wo wir dann mit WebAssembly wären. Und ich glaube, auf dem Weg von Button-Click-Händler zu WebAssembly ist ein sehr, sehr großer Bereich, der mit JavaScript unter vertretbaren Schmerzen noch zu bespielen ist. sodass ich da jetzt die Notwendigkeit eines Ersetzens oder Ergänzens nicht wirklich sehe und deswegen auch bei WebAssembly sage oder so, das ist ein voll nützliches Teil für einen sehr, sehr überschaubaren Kreis von Use Cases und das ist gut, dass wir das haben, aber das wird nichts ersetzen oder so, sondern das ist mehr so eine Ergänzung der Capabilities von der Plattform als ganzem und betrifft JavaScript selbst eigentlich nur am Rande.

Andy Grunwald (01:16:13 - 01:16:32)

Das ist ein sehr, sehr guter Punkt. Eine Frage hab ich aber dennoch, wenn wir wieder zurück auf das Monopol kommen. Und zwar ist es jetzt so, dass mehr und mehr und mehr Features reinkommen. Es werden kaum Features gelöscht. Und reale JavaScript-Runtimes gibt's jetzt auch keine 100.

Peter Kröner (01:16:32 - 01:16:32)

Ja.

Andy Grunwald (01:16:32 - 01:16:39)

Also, wovon reden wir hier? Wir reden hier von Firefox Servo mit hoher Wahrscheinlichkeit. Wir reden hier von der V8.

Peter Kröner (01:16:39 - 01:16:41)

Servo ist die CSS-Engine, du meinst SpiderMonkey.

Andy Grunwald (01:16:42 - 01:16:49)

Entschuldigung, Spider Monkey. Dann reden wir von der V8. Mhm. Hat der Edge-Browser schon eine eigene oder ist das noch ...

Peter Kröner (01:16:49 - 01:16:54)

Der ist V8. JavaScript Core gibt's noch, das Ding von WebKit beziehungsweise Safari.

Andy Grunwald (01:16:54 - 01:16:57)

Sind wir dann bei allen? Also, ist das so der Markt?

Peter Kröner (01:16:57 - 01:17:50)

Nee. Also ich meine, JavaScript ist ja bei allen oberflächlichen Features, die es so hat, trotzdem eine Programmiersprache mit endlich vielen Features, wenn du das jetzt irgendwie neben C++ setzt oder so. Also da gibt es durchaus Leute, die so eigene JavaScript-Engines haben, die unterschiedliche Qualitäten verkörpern, wie zum Beispiel ich bin super klein und bin embeddable. Aber da hat das Ding halt irgendwie, sagen wir mal, sehr eingeschränkte Fähigkeiten, was so Performance angeht, hat keinen Just-in-Time-Compiler und so weiter und so weiter. Weil was du jetzt gerade aufgelistet hast, diese drei Dinger, Das sind halt auch wirklich Lamborghini, Ferrari und Aston Martin. So. Das sind vielleicht die, die du haben willst, aber das heißt nicht, dass nicht irgendwo wer da trotzdem noch ist und, sagen wir mal, die Langsameren, die für gewisse Leute dann auch die alltagstauglichen JavaScript-Engines rausbaut. Also, klar, eine konkurrenzfähige, massenmarkttaugliche JavaScript-Engine zu entwickeln, ist, da sind wir wieder bei den, ich erfinde mal eben eine Programmiersprache, das gibt's halt heutzutage nicht mehr, das ist vorbei. Okay, klar, das kannst du noch machen, aber damit wirst du halt niemals mehr die Weltherrschaft erringen, wie das halt irgendwie mit C oder PHP oder so mal passiert ist. Das gibt's halt nicht mehr.

Andy Grunwald (01:17:50 - 01:18:23)

Meine Frage ist eigentlich, ob sich über Zeit die ganze Sache nicht weiter zusammenzieht. Weil ich kann mir nicht vorstellen, dass wir jetzt die drei teuren Autos hier haben, die drei teuren Engines. Aber meine Frage ist halt, ob Apple irgendwann nicht sagt, pass mal auf, warum schieße ich den CF-50-Entwickler auf die Webcube-Engine? Warum nehmen wir nicht einfach die von V8? Ja, und dass sich das dann weiter vereinheitlicht. Und dass wir dann später mit einer Engine dastehen, mit einer generellen engine die dann eigentlich sagt haben wir auf wir sind jetzt jahrelang links gegangen ja aber ich bin jetzt hier am zug und.

Peter Kröner (01:18:23 - 01:18:30)

Jetzt gehen wir mal rechts naja gab es ja schon mal es gab ja damals die zeit als wir nur einen einzigen browser hatten ihr sechs war sein name und wir haben ja auch gemacht.

Wolfi Gassler (01:18:30 - 01:18:32)

Was sie wollten wettbewerb ist vielleicht nicht das schlechteste.

Andy Grunwald (01:18:33 - 01:18:43)

Und deswegen sag ich das ja. Ich hab zu IE6-Zeiten ja was geprogrammiert. Und ich bin ganz ehrlich, ich wollte das nicht und ich will das nicht mehr. Weil das war schwierig, das war schlecht, das war frustrierend.

Peter Kröner (01:18:43 - 01:18:47)

Wieso? Es gab nur einen einzigen Browser, um den du dich kümmern musstest. Wenn du den verstanden hast, war alles easy.

Andy Grunwald (01:18:47 - 01:19:09)

Dann hab ich's nicht verstanden, bin ich auch ehrlich. Weil danach kam noch CSS und so weiter, aber ich war noch nie stark empfunden. Ich hab halt so ein bisschen, umso mehr spezialisiert diese Sprache wird, umso mehr stelle ich mir die Frage, okay, wann gibt einer der großen drei ihre Engine auf? Also ich möchte jetzt kein Datum von dir, sondern eigentlich siehst du da eine Gefahr oder sagst du, ach, weißt du was, da bin ich noch relativ ruhig in meiner Hängematte.

Peter Kröner (01:19:09 - 01:19:28)

Ja, was heißt ich bin ruhig? Also die Frage ist ja immer, was ist jetzt das konkrete Bedrohungsszenario? Weil wenn ich jetzt meine Trollmütze aufsetzen würde, würde ich ja sagen, Das Szenario, in dem es de facto einfach nur eine Runtime gibt und die sagt, wie es läuft, die würde sich an anderen Programmiersprachen, wie zum Beispiel einer, die mit G anfängt und mit O endet, ja so auch wiederfinden und das ist ja auch kein Problem, oder?

Andy Grunwald (01:19:29 - 01:19:56)

Das ist ein fairer Punkt, aber da wusste ich ja von vorne herein, wo ich mich drauf einlasse. Und wo man bei JavaScript natürlich dann ein verändertes Szenario hatte, obwohl ich dann meine Technologieentscheidung bereits darauf getroffen habe. Zum Beispiel, nehmen wir mal deine Textilmaschine vom Anfang. Und jetzt sind wir 20 Jahre weiter. Klar, das ist jetzt ein bisschen theoretisch, verstehe ich schon, aber vielleicht wäre es auch ganz gut, in 20 Jahren einen Rewrite von der Firmware dieser Textilmaschine zu machen.

Peter Kröner (01:19:56 - 01:19:57)

Möglicherweise, ja.

Wolfi Gassler (01:19:58 - 01:20:26)

Aber du musst es ja auch so sehen, dass, wenn wir vielleicht nicht den Kampf gehabt hätten zwischen Firefox und Chrome bezüglich Speed und wer hat die schnellste JavaScript-Engine und einmal ist der von einmal der, wären wir vielleicht jetzt gar nicht an diesem Punkt, dass wir sehr viele oder einige zumindest sehr schnelle Engines haben überhaupt. Weil wo ist der Sinn? Wenn du eine Monopolliste hast, dann brauchst du auch nichts mehr weiterentwickeln. Aber ich fang jetzt schon an, den Wettbewerb zu verteidigen. Das ist ja gar nicht normal meine Sache.

Andy Grunwald (01:20:27 - 01:20:35)

Ich advocate auch nicht für den Monopolismus hier. Ganz und gar nicht. Ich stell mir halt diese Frage. Aber ich glaub, wir werden hier in diesem Podcast auch nicht mehr zu einer Antwort kommen.

Peter Kröner (01:20:35 - 01:22:54)

Nee, aber ich find das gut und richtig, dass du dir diese Frage stellst. Weil es gibt ja tatsächlich so Dinge, die so passieren draußen in der Welt der Webbrowser, wo, wenn man dazu eine Haltung entwickeln möchte, man sich ja wirklich Gedanken darum machen muss, was bedeutet das jetzt wirklich für die große weite Welt? Also so zum Beispiel das Monopol von Apple. Dass die halt eben sagen, hier auf dem iPhone ist Safari und sonst nix. Das ist ja im Moment etwas, das im Fallen begriffen ist. Und die Frage ist, okay, wenn das jetzt wirklich passiert ist und da kommt jetzt Chrome und seine sämtlichen Derivate, kommen da jetzt an und machen sich halt auf der Plattform auch noch breit, was gibt's denn dann noch? weil ich meine unter den großen Browsern, die heute jetzt noch rum existieren, die man wirklich so als distinkte Entitäten ausmachen kann, hat man den Firefox, den keiner mehr benutzt, den Safari, der noch benutzt wird, weil es halt eben auf den Apple-Geräten keine Alternativen gibt, und alles, was irgendwie Chrome ist, also Chrome und Opera und Brave und Internet Explorer, ne, wie heißt das Ding, Edge, So, und das kann ja irgendwann tatsächlich irgendwie dazu führen, dass es dann de facto nur noch eine Engine ist. Aber das muss halt eben auch nicht notwendigerweise zu einer Art von Katastrophe führen. Weil auch da dann am Ende die Frage ist, wenn dieser Punkt erreicht ist, was passiert dann damit? Es muss ja nicht notwendigerweise sein, das kennt man ja jetzt ja aus dem Monopolrecht tatsächlich auch. Also viele Jurisdiktionen sagen ja, das Monopol an sich ist kein Problem. Das Problem ist dann, wenn das Monopol auf eine Art und Weise benutzt wird, dass es für den Verbraucher schädlich ist. Das ist ja zumindest bei vielen ist das ja so. Monopolist sein kannst du sein, aber du darfst es halt nicht irgendwie zum Nachteil der Gesamtbevölkerung auslegen. Und das wäre ja theoretisch möglich. Also, weil ich meine, im Moment ist es ja zumindest mal so, dass jetzt an dieser Entwicklung von zum Beispiel ECMAScript und von Webbrowsern und so mehrere Parteien beteiligt sind und die alle da irgendwie reinreden und die einen werden von Google direkt bezahlt und die anderen werden von Google indirekt bezahlt, weil sie für Mozilla arbeiten. Das ist ja am Ende wirklich was, das so irgendwie für den Prozess und für die Gestehung des Endergebnisses möglicherweise irgendwie relevant ist. Aber es ist ja auch nicht gesagt, dass notwendigerweise jetzt, wenn irgendwie Last Man Standing übrig bleibt, dass der sich dann halt eben zum fiesen Diktator à la IE6 aufspielt. Das ist ja nicht gesagt, das kann halt eben sein. Es kann ja auch ein Szenario geben, wie zum Beispiel als Netzklebepleite gegangen ist, da haben sie ja was gänzlich Unmögliches gemacht. Nämlich haben gesagt, so hier, Open Source macht, was ihr wollt. Und dann ist da der Firefox draus geworden. Ich will jetzt nicht sagen, man sollte sich nicht darum besorgt sein, dass jetzt alles zu Chrome wird, aber man muss dann eben auch nicht notwendigerweise direkt sagen, das war dann ein Griff ins Klo, dass ich eine Web-App gebaut habe.

Andy Grunwald (01:22:55 - 01:23:01)

Ich glaube, ich habe noch nie eine volkswirtschaftliche Diskussion über Programmiersprachen gehabt. Vielen lieben Dank.

Peter Kröner (01:23:01 - 01:23:53)

Das war... Naja, ich meine, es ist ja letztlich nur ein Mechanismus zum Beschreiben der Welt. Und so Sachen wie Incentives und Return on Investment und so Zeug und ja auch zum Beispiel, was ich ganz zu Beginn gesagt habe, Risiko ist ja tatsächlich auch was, was so der gemeine Mensch, wenn der irgendwie ein Investment tätigt, sei es in Bitcoin oder in ein Haus, das sind ja die Variablen mit denen, der auch jongliert. Und ich glaube, das ist so als Mechanismus zum Beschreiben der Welt nicht nutzlos. Nicht der einzige Mechanismus, aber es ist nicht nutzlos. Und deswegen, was wird aus JavaScript-Engines? Keine Ahnung, aber es lohnt sich auf jeden Fall drauf zu achten. Aber es ist jetzt nicht notwendigerweise so, dass wenn jetzt am Ende irgendwie Firefox davon geht und irgendwie Safari platt gemacht wird, dass jetzt die Apokalypse nahe ist und dass wir dann wieder zum IE6 kommen, weil auch das hatte ich ja schon mal gesagt, das wird nicht wieder genauso werden wie früher. Die Geschichte wiederholt sich nicht. Möglicherweise reimt es sich punktuell mal. Aber ich würde trotzdem eher optimistisch bleiben, dass wir da noch viele lustige Sachen werden bauen können mit vielen lustigen APIs, an die wir jetzt noch nicht mal denken können.

Wolfi Gassler (01:23:54 - 01:24:13)

Also es wird noch vieles auf uns zukommen. Schade, dass jetzt eine Glaskugel in der Wartung ist, sonst hätten wir da jetzt genauer reinschauen können. Ich bin übrigens noch voller Firefox-Verfechter und versuche den Firefox möglichst lang zu verwenden. Aktuell funktioniert er nur relativ gut, außer für unsere Aufnahmesoftware zum Beispiel. Da muss ich jetzt immer in Chrome wechseln, damit es sinnvoll läuft. Aber ich kann damit leben.

Peter Kröner (01:24:13 - 01:24:20)

Firefox auf Android ist super. Also Adblock und alles ist ganz, ganz großes Tennis. Alles rendert schön und ist schnell und nett und so. Da bin ich auch ein großer Verfechter von.

Andy Grunwald (01:24:21 - 01:25:04)

Wow, ich glaub, ich hab noch nie eine Podcast-Episode gemacht, ohne tief in React, Vue.js, Angular und Framework-Bashing reinzugehen, sondern primär auf Grundlagen und Foundations und Co. einzugehen. Peter, ich hatte sehr, sehr viel Spaß und auch als Nicht-JavaScript-Fan, ich schreibe es ab und zu, aber ich bin da bei weitem kein König drin, hat mir diese Episode sehr viel Spaß gemacht und ich habe auch das Gefühl, ich verstehe die Welt ein bisschen besser und besonders dein Punkt, dieses 90% meines Tages überscrolle ich Themen, außer bei JavaScript-Fanworks, da regen sich alle drüber auf, Du hast einen Punkt und ich glaube, du hast eine Persönlichkeitsänderung bei mir durchgeführt.

Peter Kröner (01:25:04 - 01:25:11)

Oha, ich wäre schon zufrieden, wenn ich einfach dein Scrollen etwas entspannter gestalten kann. Das wäre schon ausreichend, würde ich sagen.

Andy Grunwald (01:25:11 - 01:25:26)

Vielen lieben Dank für die Zeit, die du dir genommen hast, um hier im Engineering-Kiosk uns zu erleuchten. Für alle Leute, die ein bisschen mehr von Peter hören wollen, schalte doch mal beim Working Graph Podcast rein. Ich glaube, da bist du jede Woche, alle zwei Wochen?

Peter Kröner (01:25:26 - 01:25:42)

Ich arbeite daran, meine Beteiligung wieder hochzufahren. Während der Pestilenz haben wir uns eine Trümmertruppe aus Hauskatzen reingeholt. Die haben sehr viel von meiner Zeit und gerade auch von meiner mentalen Kapazität aufgefressen. Jetzt sind die aber alle gesund, einigermaßen. Und jetzt kann ich auch wieder podcasten. Das wird wieder.

Wolfi Gassler (01:25:43 - 01:25:57)

Okay, wir sind also gespannt, viel Content auch im Working Draft Podcast von dir zu hören, hoffentlich. Vielen Dank, auch von meiner Seite super viel gelernt und ich hoffe, dass jetzt Andi endlich von seinem Go-Trip mal runterkommt und zu uns in die JavaScript-Welt vorbeischaut.

Andy Grunwald (01:25:58 - 01:26:06)

Ich glaube, da muss ich noch ein paar Wochen drüber schlafen. Vielleicht höre ich mir noch ein paar mehr Working Draft Podcast-Folgen an oder ich glaube, die Programmierbare macht auch ziemlich viel im JavaScript-Bereich.

Peter Kröner (01:26:07 - 01:26:09)

Kauft ihr einen meiner Workshops ein, jetzt im Sonderangebot.

Andy Grunwald (01:26:11 - 01:26:14)

Ist das hier der Influencer-Rabatt? Hast du auch einen Instagram-Account, wo wir dir folgen können?

Peter Kröner (01:26:14 - 01:26:17)

Der Rabattcode und alles. Wahnsinn.

Andy Grunwald (01:26:17 - 01:26:40)

Packen wir natürlich alles in die Shownotes, auch wo ihr mehr Infos über PETA bekommt. Und PETA packt natürlich auch noch eine ganze Menge Links in die Shownotes, inklusive dieser JavaScript-Engine, die man auch embedden kann. Da hätte ich Bock drauf, weil ich hab nämlich gesehen, meine Waschmaschine hat einen Netzwerkeanschluss. Gegebenenfalls deployen wir da mal JavaScript drauf.

Wolfi Gassler (01:26:40 - 01:26:42)

Endlich mal eine sinnvolle Sprache auf deiner Waschmaschine.

Andy Grunwald (01:26:43 - 01:26:46)

Wir sagen vielen lieben Dank und bis zum nächsten Mal. Tschüss.

Peter Kröner (01:26:46 - 01:26:51)

Tschüss, Dankeschön.

Andy Grunwald (01:26:51 - 01:26:59)

Und nicht vergessen, falls ihr eine Förderung in Höhe von 50.000 Euro für euer Open Source Projekt haben wollt, bewerbt euch beim Media Tech Lab. Link in den Shownotes.