Stranger Than Usual

2021 habe ich einige Webcomics, die ich gerne lese vorgestellt. Das war schon eine ordentliche Liste, aber keine vollständige Liste. Das wäre auch zu viel gewesen. Aber in den Jahren danach habe ich nie nachgeholt, mal den einen oder anderen Webcomic vorzustellen. Also fange ich jetzt damit an. Und zwar mit dem Science-Fiction-Webcomic Drive.

Der Webcomic ist humorvoll geschrieben und behandelt ein ausgearbeitetes Setting. Es gibt viele interessante und skurrile Charaktere, es werden aber auch ernste Themen behandelt. Zwischendurch gibt es auch immer wieder kleine Informationsschnipsel, z.B. aus der Encyclopedia Xenobioógica. Hier eine kleine Einführung in die Story (SPOILER WARNUNG, aber nur für den Teil wirklich am Anfang).

Prolog

These are the eyes of a failed man. …and they will build an Empire

Spanien, 2258: Ein soeben arbeitslos gewordener Ingenieur aus Madrid beobachtet auf der Heimfahrt ein notlandendes außerirdisches Raumschiff, dessen einziger Passagier vor Jahrzehnten von einem Mikrometeoriten getötet wurde. Es wird angedeutet, dass dieser Ingenieur ein Imperium aufbauen wird. Danach ein Lexikoneintrag über die außerirdische Zivilisation „The Continuum of Makers“, die offenbar den Menschen feindlich gesinnt ist, darunter ein zensierter Abschnitt, der wohl darauf hindeuten könnte warum das so ist. Am Ende ein handschriftlicher Brief des ehemaligen Ingenieurs, jetzt Imperator, in dem er einem Enkel gesteht, dass er den Antrieb des Raumschiffes (den namensgebenden „Drive“) zwar duplizieren konnte, ihn aber nie verstanden hat.

Die Befreiung aus dem Gefängnis

Captain, no! You can not use the Pinch Drive that close to a planet! The Earthquakes would destroy everything.

– Nosh

143 Jahre später wacht auf einem Gefängnisplaneten eine kleine echsenartige Gestalt mit einem Kopfkamm auf und kann sich an nichts erinnern. Vor ihm steht ein Veetan namens Nosh, groß, gutmütig und die Gestalt hat ihn gerade vor der Waffe einer Wache gerettet. Nosh wird vorgeworfen, den Imperator getötet zu haben, der wohl aber in einer Intrige von einem seiner Neffen getötet wurde, um sich selber zum Imperator aufzuschwingen.

Nosh wird von seiner Kapitänin und ihrer Crew gerettet, die dafür ein kleines Schiff mit Drive gestohlen haben. Aus Dankbarkeit nimmt er die echsenartige Gestalt mit. Bei der Flucht zerstören sie die Gefängnisdatenbank, wodurch Noshs Spuren verwischt werden, aber auch jegliche Information verlorengeht, woher die echsenartige Gestalt herkommt.

Der Pilot

Wonderful. So they are bigger and faster… and I'm fllying THE DANG CAR I HAD IN HIGH SCHOOL!

– Kapitänin Taneel

An Bord der „Machito“, eine kleinen und alten Schiff, sind neben Kapitänin Taneel auch der 14-Jährige Fernando „Nando“ Cruz, Neffe des Imperators. Da die Macht des Imperiums auf der Kontrolle des Überlichtgeschwindigkeitsantriebs beruht, dürfen nur Mitglieder der Familie das Drive bedienen.

Auf der Flucht wird die Machito von zwei Schiffen des Continuum of Makers angegriffen. Das Schiff flüchtet sich in ein Asteroidenfeld, was bei Überlichtgeschwindigkeit extrem gefährlich ist. Es stellt sich heraus, das die echsenartige Gestalt (kurz darauf „Skitter“ getauft) mit dem Kopfkamm Gravitationswellen wahrnehmen kann und so das Schiff sicher durch die Asteroiden bringt, während die Continuum-Schiffe zerstört werden.

Die Suchmission

You and I have a shared opportunity, Captain

– Imperator Ramirez Cruz

Durch im Schiffscomputer verbaute Spionagetechnik spürt der Imperator die Machito auf und bietet der Crew einen Deal an: Sie werden rehabilitiert, dafür müssen sie herausfinden, wo Skitters Spezies herkommt und sie als Piloten für das Imperium anheuern, das gerade einen verzweifelten Kampf gegen das Continuum führt. Und somit beginnt eine lange Suche…

Fazit

Das ist der Einstieg in die Geschichte. Es kommen nach und nach ein paar weitere Crewmitglieder hinzu, andere Alienspezies und manchmal auch deren Reiche werden vorgestellt, die Motivation des Continuum of Makers wird aufgedeckt und weitere Spieler treten auf, die eine viel größere Gefahr für die Menschheit aber auch für andere Reiche (inklusive der Maker) darstellen. Der immer wiederkehrende Humor dieses Comics gemischt mit fantastischen Worldbuilding und schrulligen Charakteren ist, was für mich diesen Comic wirklich empfehlenswert macht.

Es gibt ja diese Wegwerf-elektrischen Zigaretten (Vapes). Das ist eine Menge Müll für etwas, dass einen Lithium-Ionen-Akku enthält und eigentlich problemlos wieder aufgefüllt werden könnte. Es gibt dazu schon viel im Netz zu finden, oft nehmen Bastler die Dinger auseinander um die Akkus für Bastelprojekte zu verwenden.

In einem speziellen Fall war da aber nicht nur ein Akku, sondern ein Mikrokontroller mit drin. 24 MHz Prozessor, 3 kiB RAM, 24 kiB Flashshpeicher. Den hat jemand genutzt, um darauf einen Webserver zu hosten. Der Blogpost beschreibt den Werdegang des Projekts (z.B. wie der Autor die Ping-Responsezeit von 1,5 Sekunden auf 10 ms zu reduzieren und eine einfache Website innerhalb von 160 ms auszuliefern. Der Autor nennt das „blazingly fast“. Das ist es natürlich nicht, und ich vermute, dass er auch nur selbst einmal die mittlerweile memetischen Worte „blazingly fast“ verwenden wollte. Trotzdem eine ordentliche Leistung für einen selbstgebastelten Netzwerkstack auf einem Chip mit einer Rechenleistung, die Ende der 80er verbreitet war und weniger Flashspeicher, als nötig wäre, um allein das HTML der Homepage meines Blogs zu fassen.

Der Server auf dem Vape-Akku ist im oben verlinkten Blogpost auch verlinkt, ich kann ihn aber nicht erreichen. Vermutlich ist das Projekt so bekannt geworden, dass das arme Ding einfach überlastet ist.

Freunde von mir (insbesondere ein Spielleiter einer meiner Rollenspielrunden) arbeiten gerade an einem Rollenspielsystem namens „Trainpunks“. Ich habe auch schon einmal einen Oneshot davon probegespielt.

Das Setting ist ein gewaltiges U-Bahn-Netz mit U-Bahnen unergründlicher Herkunft und übernatürlicher Schaffner. Die Spielercharaktere sind Menschen (dem Titel nach zufolge Punks), die dort unten irgendwie überleben müssen. Denn es gibt nicht nur Menschen, sondern auch verstörende cthulhueske Wesen, die äußerst gefährlich sind.

Die Spielercharaktere können hier verschiedene Rollen einnehmen, wie zum Beispiel „Graffiti Artists“ (die ihre Schöpfungen zum Leben erwecken können, Bilder über längere Distanzen auf andere Wänder übertragen und ähnliches), „Guerilla Gardeners“ (die Pflanzen wachsen lassen und kontrollieren können), „fare dodger“ (hat kein Ticket für die U-Bahn und wird dafür von den Schaffnern gejagt, hat dafür aber andere Vorteile), „busker“, „squatter“, „bootlegger“ und „traceur“.

Mir hat der Oneshot damals gut gefallen, und ich werde demnächst das System playtesten. Für alle, die dieses Setting anspricht: Im Februar 2027 wird eine Kickstarterkampagne, der man aber jetzt schon folgen kann, um das Projekt zu unterstützen. Mein Spielleiter und der Entwickler des Spiels hat unter dem Namen „Foxes in Boxes“ auch schon andere kleinere Rollenspielsysteme veröffentlicht.

Das Artwork oben stammt von der anderen Person in dem Bunde und ist Teil eines Flyers, den die beiden für die NordCon 2026 entworfen haben. Eine volle Version des Flyers ist auf tumblr zu finden.

Also: verfolgt das Kickstarter-Projekt, je mehr Leute, desto besser. Ich hatte viel Spaß mit dem Trainpunks-Oneshot und möchte, dass dieses Projekt erfolgreich wird.

PS: Dieser Blogpost ist keine bezahlte Werbung. Ich unterstütze das Projekt weil

• mir das Konzept gefällt
• es von Freunden von mir gemacht wurde
• es ein Indie-Projekt ist.

Im Mai habe ich zum Digital Independence Day nichts gemacht. Dafür konnte ich dass dann nachholen, als ich am Towel Day zusammen mit einigen Freunden ein paar Sachen gemacht habe. Auf meiner Seite hat das auch gut funktioniert, ich kann jetzt auch aufwändigere Windows-Spiele unter Linux spielen und bin damit von Windows weg. Und ich habe mich von der Google Search Console verabschiedet.

Heute hatten wir uns wieder verabredet, aber alle haben kurzfristig aus Erschöpfungsgründen abgesagt. Also wird es heute zum DID wieder nichts, aber zumindest in einem Fall gibt es schon einen Plan, bei dem ich helfen kann, vielleicht diesen Monat. Und darum geht es ja auch. Nicht zwanghaft irgendwas machen, sondern Schritt für Schritt, in einer nachhaltigen Geschwindigkeit Dinge umstellen.

Wenn es dann soweit ist, schreibe ich noch einmal dazu.

Die meisten Blogposts hier plane ich nicht gründlich, und mache auch kein gründliches Korrekturlesen. Wenn ich aber Tippfehler bemerke, korrigiere ich sie. Wenn ich unter meinen git-commits für dieses Blog nach „typo“ suche, finde ich schon gut 100 commits.

Nun weiß ich aber, dass mir selbst Rechtschreibfehler, Satzbaufehler, Typographiefehler oder allgemein Tippfehler in fremden Texten schneller auffallen als in Texten, die ich selber geschrieben habe. Ich glaube, das geht anderen auch so. Nun sind viele Leute zu höflich, um Tippfehler zu melden. Ich persönlich werde aber gerne darauf hingewiesen, weil ich die Fehler dann korrigieren kann. Hier also für alle: Ihr könnt mir solche Fehler gerne melden, ich korrigiere die dann (wenn ich auch der Meinung bin, dass es Fehler sind).

Wenn ihr einfach zu faul seid, für einen Fremden den Korrekturleser zu machen, dann ist das vollkommen in Ordnung. Wenn euch der Fehler aber nervt und ihr unsicher seid, ob ihr ihn melden sollt: Meldet ihn, ich weiß das zu schätzen.

PS: das gilt auch für andere Fehler, zum Beispiel ungültiges HTML oder so.

PPS: Diese Aufforderung gilt speziell für mich. Andere Leute mögen ihre Blogs anders behandeln und Tippfehler aus welchen Gründen auch immer nicht korrigieren. Das ist auch in Ordnung.

Es ist jetzt etwas über ein Jahr her, seit ich eine Zusammenstellung meiner Gedanken über LLM und Bildgeneratoren gepostet habe. Seitdem hat sich viel getan. Modelle haben sich verbessert, RAM-Preise wurden in die Höhe getrieben weil OpenAI angekündigt hat, alles aufzukaufen, nur um es dann doch nicht zu run. Redner, die bei Absolventen über „AI“ predigen werden ausgebuht. Die Preise für Modell-Abos steigen. Firmen verpulvern ihr ganzes LLM-Budget in den ersten paar Monaten des Jahres. Wieder einmal wurde bewiesen, dass trotz des Hypes „AI“-Agenten eine schlechte Idee sind. In den letzten Wochen insbesondere sind mir wieder einige spezielle interessante Dinge untergekommen:

• „Big Tech erklärt das Problem zur Lösung“ auf netzpolitik.org. „AI“ verbraucht Unmengen an Energie. Ist das ein Problem für die Energiewende? Ja. Was macht man mit dem Problem? Naja, die „AI“ wird es schon richten.
• Instagram-Accounts wurden von Angreifern übernommen, weil Meta einen „AI“-Agenten als Support eingesetzt hat, der dann mit ein bisschen Betteln eine Passwort-Reset-Email an die falsche Adresse geschickt hat
• es gab einen Post über Timnit Gebru, die 2020 von Google entlassen wurde, weil sie Probleme mit LLMs prognistiziert hat, in ihrem Paper „On the Dangers of Stochastic Parrots: Can Language Models Be Too Big? 🦜“. Viel davon, was sie damals vorhergesagt hat, ist eingetroffen.
• „No, Artificial Intelligence Is Not Conscious“ ein Artikel der sehr anschaulich darstellt, warum LLMs kein Bewusstsein haben (unabhängig davon, ob sie jetzt nützlich sind oder nicht).

LLM-Einsatz bei mir auf der Arbeit

Aber warum dränge ich jetzt darauf, dass die AI-Blase jetzt bald mal platzen sollte? Nun, das hat persönliche Gründe. Mein Arbeitgeber hat sich bisher zurückgehalten, was LLMs zum Programmieren angeht. Insbesondere auch, weil der Code von Kunden nur bei Systemen landen sollte, auf denen der Kunde ihn erlaubt. Und weil Agenten, denen man Zugriff auf sein System gibt, auch geheime Daten _wie zum Beispiel kryptographische Schlüssel auslesen können.

Heute jedoch gab es eine große Ankündigung: Wir sollen jetzt groß Experimente mit LLM-Codegenerierung machen (eine „AI code factory“ oder so ähnlich aufbauen). Hier ging es nur um die Codeerzeugung, Planung, Konzeption, Gespräche mit dem Kunden soll immer noch von Menschen gemacht werden. Mein Chef hat u.a. die Sorge, dass wenn wir nichts mit „AI“ machen, es die Konkurrenz macht, und wir dann mit kaputten „AI“-Prozessen beim Kunden arbeiten müssen. Teilweise seihen sogar schon McKenzie-Consultants gesichtet worden. Bevor die beim Kunden Unheil anrichten, sollen wir es lieber selber tun.

Insbesondere hat er uns dazu aufgefordert, Experimente zu machen. Natürlich nicht mit Kundencode. Sind ja Experimente. Sondern mit unseren Privatprojekten. Die Firma wird uns aber nicht die Kosten für den LLM-Codeassistenten erstatten. Sind ja unsere Privatprojekte. Natürlich müssen wir das nicht machen. Aber wir hätten es schon längst machen sollen. Oder so.

Noch einmal kurz als Stichpunkte:

• wir sollen Experimente mit LLM-Codegeneratoren an unseren Privatprojekten machen
• wir müssen es natürlich nicht machen, aber wenn wir es nicht machen, dann enttäuschen wir die Firma
• wir kriegen nicht einmal die Kosten dafür ersetzt

Ich werde kein LLM in die Nähe meiner Privatprojekte lassen. Ich entwickle die zur Erholung. Da kommt keine umweltzerstörende Technologie dran, die mir auch noch den Teil davon wegnimmt, den ich am liebsten habe. Und das mit dem „das musst du nicht machen, aber eigentlich doch“ habe ich schon einmal gehabt. Bei meiner Einstellung wurde extra betont, dass ich zwar auf meinem Handy Software für die Arbeit installieren darf (dann muss ich da aber auch Spyware installieren), aber nicht muss. Zwei Monate später stellt unser Kunde die 2-Faktor-Authentifizierung so um, dass ich eine Android-App brauche, die ich mir auf meinem Phone aber mangels PlayStore nicht installieren konnte. Ich muss diese App aber installieren, sonst kann ich mich beim Kunden nicht mehr einloggen. Die Firma will mir kein Phone dafür bereitstellen. Das war während meiner Probezeit, also habe ich am Ende in den sauren Apfel gebissen und mir ein gebrauchtes Phone gekauft. Obwohl es mein Recht gewesen wäre, dass die Firma mir es stellt.

Nein, ich werde keinem weltzerstörenden „AI“-Unternehmen Geld in den Rachen werfen. Ich werde mich nicht von dieser Technologie abhängig machen. Ich mache mir aber Sorgen über meine Zukunft in der Firma, wenn ich diese Ansicht zu offen vertrete. Deswegen brauche ich den Kollaps der AI-Blase jetzt bitte schnell, am Besten bis zum Ende des Monats.

Rollenspielszene. Wir sind eine Gruppe von Freigeistern die im Wald leben. Jüngstes Mitglied ist Siobhan, Nichte von Niamh, der schon länger bei uns lebt. Siobhan hat sich vorrübergehend aus ihrer politischen Arbeit zurückgezogen, weil es in der nächsten Stadt Leute gibt, die sie besser nicht sehen sollten.

Es ist später Vormittag. Siobhan wacht auf und bevor sie Niamhs Behausung verlässt, schreibt sie in ihr Journal:

Heute werde ich nicht das System stürzen, und das ist ok.

Ich bin kein großer Barrierefreiheitexperte, auch nicht, wenn es um Websites geht. Eines weiß ich aber: Einfach irgendwelche Elemente mit Javascript anklickbar zu machen, die üblicherweise nicht anklickbar sind, ist nicht barrierefrei, weil Screenreader oder andere Hilfstechnologie sie nicht als anklickbar erkennt. Das ist eine Barriere für z.B. sehbehinderte Personen, für die die Klickbarkeit einfach unsichtbar ist.

Vor diesem Problem stand ich gestern, als ich ein paar Tabellenzeilen (<tr>, „table row“ in HTML) nicht nur anklickbar, sondern auch mit der Tastatur auswählbar machen musste. Die Idee war: User sucht etwas, User kriegt eine Tabelle mit Ergebnissen, User klickt auf eine Zeile, irgendetwas passiert. In meinem Fall war es ein Button, der eine Änderung auslöste, es könnte aber auch genausogut ein Link sein, der irgendwohin führt.

Was tun? Man kann den <button> oder das <a> nicht um das <tr> wrappen, weil das in HTML nicht erlaubt ist. Man kann in jede einzelne Zelle einen Link oder Button stecken, aber das ist unschön und die Tabellenzellenpaddings sind dann auch nicht klickbar. Man könnte in eine Zelle einen Link stecken und dann zusätzlich mit Javascript die Zeile anklickbar machen. Das ist aber unschön und funktioniert nicht ohne Javascript (letzteres wäre in meinem Fall kein größeres Problem gewesen.

Ich habe ein bisschen recherchiert und einen Blogpost mit einer Lösung gefunden. Ich gehe hier nicht in die Details, lest euch dazu den Post durch, aber die Idee ist: Man packt nur in eine Zelle den Link und sorgt dann mit geschicktem CSS dazu, dass für typische Browsernutzer der Link auf die ganze Zeile ausgedehnt wird. Für Hilfstechnologie ist aber der ursprügliche Button oder der Link immer noch da (sollte aber einen passenden Text haben). Ich weiß nicht, ob das komplett barrierefrei ist, ist aber auf jeden Fall deutlich besser als die Variante, in der man die Zeile nur klickbar macht. Bonus: Man kann auch mit Tab durch die Zeilen wechseln und dann mit Enter eine auswählen (die Anleitung ist für einen <button>, mit leichten Änderungen funktioniert es aber auch für ein <a>).

Ich war also ganz zufrieden mit dem Ergebnis, bis mir ein Kollege sagte: Hey, das funktioniert bei mir überhaupt nicht und macht die ganze Seite unbrauchbar. Was ist passiert?

Wir sind kurz zusammen durchgegangen: In Firefox funktioniert es. In Chrome auch. In Safari nicht. Woran lag das? Nun, um den Klickbereich auf die ganze Zeile auszuweiten, habe ich einen Trick verwendet: Ich habe dem Button in CSS mit einem ::after selector ein Dummy-Kindelement hinzugefügt. Dieses habe ich dann mit position: absolute und inset: 0 positioniert und skaliert. Und zwar genau über das nächste Vorfahrelement, das ebenfalls explizit positioniert war (position: relative. In diesem Fall war es die Tabellenzeile <tr>.

Safari hat aber einen Bug, durch den ein position: relative an einer Tabellenzeile ignoriert wird. Dabei wollte ich die Tabellenzeile ja nicht einmal bewegen, ich brauchte sie nur als Referenzpunkt. Mangels weiterer positionierter Elemente hat sich dann das button::after auf die gesamte Seitengröße ausgedehnt. Man konnte also nichts mehr klicken. Egal, wo man klickte, es wurde immer derselbe Button gedrückt.

Glücklicherweise habe ich einen anderen Blogpost mit einem Workaround gefunden. Das ist ein bisschen hacky, funktioniert aber auf allen drei getesteten Browsern.

Rollenspielszene. Nini, Sprinkle und Cory sind vor der Scawnbande geflohen und zwar direkt in das Höhlensystem in der Rinde des Weltbaums, in der sie den gesuchten Schatz vermuten. Das Höhlensystem ist ein Irrgarten, durchsetzt von magischen Fallen, und Gedächtniszaubern, die das Verirren sehr leicht machen.

An einer Stelle tut sich ein Abgrund auf. Als Zi Ri kann Nini fliegen und erkundet deshalb den Boden des Abgrunds sowie den Gang, der gegenüber weiter geht. Im Gang gegenüber findet zie etwas Glitzerndes das in der Wand aus Borke eingelassen ist. Es glitzert! Nini ist klar, dass das der Weg ist, den die Gruppe nehmen muss.

Die anderen schaffen es mit einem heraufbeschworenen Seil, die andere Seite zu erreichen. Sie schauen sich das aus ihrer Sicht recht unbemerkenswerte Glitzerding an und wollen da weiter. Nini will aber das Glitzerding haben! Zie krallt sich an dem Glitzerding fest, während Sprinkle sie wortwörtlich von ihm wegzerren muss.

Neeeein! Mein Glitzerding!

In meinem vorherigen Projekt auf der Arbeit war das Frontend eine Flutter-Web-App. Der Grund dafür war, dass der Kunde für alle Frontends Flutter verwendet, also auch für unsere App. Das war übrigens derselbe Kunde, der überall C# verwendet (ugh).

Flutter fing an als ein Framework für Mobile-Apps. Und zwar eins, in dem man Apps nur ein Mal schreiben musste, um sie dann sowohl fürAndroid als auch für iOS verwenden zu können. Den Wunsch danach kann ich verstehen. Um das zu erreichen, verwendet Flutter auch nicht die nativen Bibliotheken der beiden Betriebssysteme, sondern re-implementiert die komplette UI-Bibliothek (passt sich aber vom Aussehen her an das jeweilige System an). Man kann hier geteilter Meinung zu Flutter sein (ich finde es grundsätzlich nicht so schlimm, aber vermutlich hätte man denselben Effekt auch mit einer PWA haben können), aber immerhin erfüllt es seine Aufgabe recht brauchbar.

Aber dann ist jemand auf die Idee gekommen, Flutter auch zur Entwicklung von Web-Anwendungen einzusetzen. Und hier beginnen für mich die Schmerzen. Flutter Web verfolgt nämlich denselben Ansatz wie auf Android und iOS: Alles wird neu gemacht, es werden keine nativen Elemente verwendet. Und im Web bedeutet das: Kein HTML (bzw. das HTML nur als Rahmen), alle UI-Inhalte werden in ein <canvas>-Element gezeichnet.

Mit anderen Worten: Man wirft alle native Browser-Funktionalität weg (mehr noch als bei anderen One-Page-Apps) und muss jede Kleinigkeit mit in den ausgelieferten Code packen. Und das ist nicht wenig. Eine einfache „Hello World“-App ist schon gut 9 MiB groß, wenn sie optimiert wurde. Im Developer-Modus sind es eher 100 MiB. Und damit sind einige Sachen noch nicht enthalten. Zum Beispiel:

• SVG-Rendering: Dafür muss man eine gesonderte Abhängigkeit einziehen
• relative Stylegrößen wie em in CSS
• Hyperlinks. Ja, Hyperlinks. Das Rückrat des Webs. Geht nicht ohne halbwegs komplizierten Code.

Andere Funktionen, die sonst nativ mit dem Browser kommen, wurden auch re-implementiert (irgendwie muss man ja auf die neun Megabyte kommen):

• Navigation
• UI-Rendering (wie schon erwähnt im Canvas)
• responsiveness
• Layout
• Barrierefreiheit (auf dem Canvas ein großes Problem, man muss eine Menge manuellen Aufwand betreiben, um nur grundlegende Barrierefreiheitsfunktionen zu bekommen)
• Form handling
• Textauswahl (zum Kopieren)
• Scrolling (!)
• je nach Betriebssystemeinstellungen ist sogar das Rendern von Schriftarten ein Problem

Alles in Allem erinnert das an die Flash-Apps der späten 2000er. Wo Leute aus irgendeinem Grund die ganze Website in Flash geschrieben haben, anstatt in HTML. Groß, langsam, Kernfunktionen des Browser werden ignoriert. Und alles, damit man eine App nur ein Mal schreiben muss. Wisst ihr was? Genau dafür gibt es Progressive Web Apps (PWAs). Aber nein, hier muss das Rad unbedingt neu erfunden werden, es erzeugt gewaltige Mengen an JS-Code um ein schlechteres Ergebnis zu bekommn.

Ich bin froh, dass ich damit nicht mehr arbeiten muss (das Projekt selber war allerdings ganz interessant, da wäre ich auch geblieben). Ich kann nur empfehlen: Nutzt Flutter nicht für Web-Apps. Und grundsätzlich: Wenn ihr eine App wollte, die auf verschiedensten (insbesondere Android und iOS) Systemen läuft, überlegt euch, ob eine PWA vielleicht eine Option wäre.