Auf meinem PC lief das Webspiel – auf Smartphones nicht: die Falle beim Deployment

Ich hatte ein Webspiel veröffentlicht.

Auf meinem Rechner lief es. Der korrigierte Code lag auf GitHub. Das Deployment war erfolgreich durchgelaufen.

Trotzdem funktionierte das Spiel auf einigen Smartphones nicht.

In Analytics fand ich diesen Fehler:

SyntaxError: Unexpected token '<'

Ich arbeitete mit JavaScript. Warum sollte plötzlich ein „<“ das Problem sein?

Das passierte während der Entwicklung meines Webspiels ORA Quest. Die wertvollste Erkenntnis war keine magische Codezeile, sondern zu verstehen, worauf dieser Fehler oft tatsächlich hinweist.

Das „<“ ist vielleicht gar nicht der Täter

Mein erster Verdacht war ein Syntaxfehler. Ein falsches Zeichen? Kaputtes JSON? Ein fehlendes Komma?

Bei Unexpected token '<' lohnt sich aber zuerst eine andere Prüfung: Hat der Browser JavaScript oder JSON angefordert, aber HTML vom Server bekommen?

Angenommen, der Browser lädt game.js. Erwartet wird JavaScript. Tatsächlich liefert der Server aber eine Fehlerseite, die mit <!DOCTYPE html> beginnt.

Der Browser versucht diese Antwort als JavaScript zu lesen und scheitert beim ersten <.

Das Zeichen selbst ist also nicht unbedingt das Problem. Der Browser hat möglicherweise schlicht die falsche Art von Inhalt erhalten.

Die schlimmsten Bugs treffen nicht alle Nutzer

Genau das machte den Fehler so tückisch.

Am Desktop lief das Spiel. Auf manchen Smartphones ebenfalls. Auf anderen Geräten oder in einem In-App-Browser einer Social-App scheiterte es.

Dann ist dieser Ablauf verführerisch:

Code ändern → deployen → am eigenen PC öffnen → funktioniert → erledigt.

So habe ich früher ebenfalls getestet.

Hängt der Fehler aber mit Cache, Browser, einer alten Ressource oder einem bestimmten Request-Pfad zusammen, kann der eigene Rechner ein falsches Gefühl von Sicherheit geben.

Diese fünf Dinge würde ich heute zuerst prüfen

1. Die URL der fehlerhaften JS- oder JSON-Datei direkt öffnen.
2. Prüfen, ob tatsächlich JavaScript oder JSON zurückkommt.
3. Nachsehen, ob stattdessen eine 404-Seite, Login-Seite, WordPress-Seite oder anderes HTML geliefert wird.
4. Prüfen, ob der Produktivserver wirklich die erwartete Datei aus GitHub ausliefert.
5. Auf einem anderen Gerät oder Browser testen und denselben Cache möglichst vermeiden.

Vor allem Punkt 1 spart Zeit.

Statt Code umzuschreiben, weil der Fehler „nach JavaScript aussieht“, sollte man zuerst fragen:

Was liefert diese URL tatsächlich zurück?

Diese Frage kann viele nutzlose Änderungen verhindern.

Richtiger Code auf GitHub bedeutet noch keine richtige Produktion

Auch das musste ich lernen.

GitHub kann korrekt sein, während beim Nutzer trotzdem etwas anderes ankommt.

Dazwischen liegen eventuell Deployment-Automatisierung, Hosting, WordPress, Server- oder CDN-Cache, Browser-Cache und In-App-Browser.

Wenn nur eine dieser Schichten eine alte oder unerwartete Antwort liefert, entsteht das frustrierende „Aber ich habe das doch längst behoben“.

Deshalb hat sich meine Definition von „behoben“ geändert.

Ein Fix ist nicht fertig, wenn der Commit stimmt. Er ist fertig, wenn die Produktions-URL unter Bedingungen funktioniert, die dem echten Nutzer nahekommen.

Nicht nur den Fehler beseitigen – den nächsten verständlicher machen

Früher wollte ich Fehler vor allem schnell verschwinden lassen.

Heute versuche ich zusätzlich Informationen zu hinterlassen, die beim nächsten Auftreten helfen.

Welche Datei ist fehlgeschlagen? Welche URL wurde angefordert? In welcher Umgebung? Welcher Build lief?

Dann lautet die Frage beim nächsten Mal nicht mehr nur „Schon wieder derselbe seltsame Fehler“, sondern „Ist es dieselbe Ursache wie letztes Mal?“

Das ist nicht spektakulär. Für einen Solo-Entwickler kann es aber wertvoller sein als die nächste neue Funktion.

Solo-Entwicklung heißt oft: weniger Code schreiben, mehr Realität verstehen

Bevor ich Webspiele entwickelte, dachte ich vor allem an Figuren, Geschichten und Programmierung.

In der Praxis verbringe ich viel Zeit mit Fragen wie: Warum scheitert nur dieses Gerät? Warum erscheint noch das JavaScript von gestern? Warum liefert eine JSON-URL HTML?

Jedes verstandene Problem erweitert ein Stück weit das, was ich als Nächstes bauen kann.

Die wichtigste Lektion aus Unexpected token '<' war für mich:

Der Code, den man geschrieben hat, und die Datei, die der Nutzer tatsächlich erhält, sind nicht immer dasselbe.

Wenn du gerade an diesem Fehler hängst, öffne zuerst die betroffene JS- oder JSON-URL direkt. Wenn dort HTML erscheint, hast du bereits einen sehr wichtigen Hinweis.

Ich lerne all das während der Entwicklung von ORA Quest. Wenn du sehen möchtest, wofür dieses Debugging am Ende gut ist, kannst du die kostenlose ORA-Quest-Demo ausprobieren.