Draconis Pro - JavaScript auf dem Atari
Dort wo CAB aus dem Hause ASH aufhört, fängt Draconis erst richtig an: Java-Script-Fähigkeiten im HTML-Browser eines Atari-Programmes sind ab sofort kein Ding der Unmöglichkeit mehr. Wie im ersten Teil versprochen, mußte sich Adamas nun dem Online-Test stellen.
Dank der JavaScript 1.1 Anbindung ist Adamas wohl der erste Atari-Browser, der vollständig Netscape-3.0-kompatibel ist. Von daher diente dieser Browser als Referenz, auch wenn viele kommerzielle Seiten die 4er Browser empfehlen bzw. voraussetzen. Diese Seiten bleiben also weiterhin für Atari-Besitzer nur eingeschränkt nutzbar, ebenso Seiten, die Java oder Plugins als Hauptelement der Seite verwenden.
Geschwindigkeit
Auf vielen Internet-Seiten wird der beliebte Rollover-Effekt benutzt: Fährt der Mauszeiger über einen Verweis, wird eines der Bilder ausgetauscht. Das sieht nicht nur gut aus, sondern hat manchmal auch einen nützlichen Aspekt: In diesem Fall werden die einzelnen Links erklärt. Damit diese zusätzlichen Bilder angezeigt werden können, müssen sie natürlich vorher geladen werden, was wiederum die Ladezeiten erhöht. Ist JavaScript allerdings ausgeschaltet, werden die zusätzlichen Bilder gar nicht erst geladen. Da für Adamas eine Geschwindigkeitsoptimierung bislang nur angekündigt ist, sollten die Atari-Besitzer, die keinen TT oder schnellen Atari-Clone auf ihrem Schreibtisch stehen haben, JavaScript nur bei Bedarf einschalten. In diesem Zusammenhang wäre es natürlich schön, wenn alle möglichen Wege ausgeschöpft würden, um die Bilder möglichst schnell auf den Bildschirm zu befördern, z.B. die Nutzung des DSP auf dem Fal-con.
Beim Rollover-Effekt fiel auf, daß Adamas zur Zeit noch einen Redraw des gesamten Fensters durchführt, anstatt dies auf das Bild zu beschränken.
Ansonsten ist aber kaum ein Unterschied zwischen JavaScript unter Netscape und Adamas zu bemerken. Scipts sind selten auf einen schnellen Computer angewiesen, und bei den typischen JavaScript-Aufgaben - wie z.B. zwei Frames gleichzeitig ändern oder Berechnungen - gab es keinen subjektiven Geschwindigkeitsunterschied. Typische Benchmarks, wie sie unter anderen Programmiersprachen üblich sind, haben in JavaScript nur eine geringe Aussagekraft, da wohl kaum jemand auf einer Website eine Schleife von 1 bis 10000 durchlaufen läßt.
Online-Umfragen und Gewinnspiele
Daß im Web die Kontaktaufnahme häufig über sogenannte Formulare läuft, dürfte bekannt sein. Bisher war es jedoch so, daß manchmal beim Absenden nichts passierte. Oft liegt das daran, daß die Formulareingaben vor dem Abschicken überprüft werden und im Fehlerfall eine kleine Warnmeldung ausgeben wird. Da das Abschicken auch vom Script übernommen wird laufen Browser ohne JavaScript ins Leere. Nun könnte man zwar einwenden, daß dies doch auch mit Server-basierten Script-Sprachen wie Perl und PHP erledigt werden könnte. Stimmt zwar, jedoch die Web-Realität sieht anders aus, und viele Web-Master schielen eher auf die Netscape/MSIE-Benutzer - zwangsläufig müssen sich andere Browser danach richten.
Die Formularüberprüfung lief mit JavaScript ohne Probleme. Damit sollte man nun wirklich auf alle Gewinnspiele, Online-Umfragen, Suchmaschinen etc. Zugriff haben. Einige Webseiten kommen zwar auf die geniale Idee, für ein simples Formular gleich Java oder DHTML zu verwenden, aber diese sind wirklich in der Minderheit. Mit 95% aller Formulare sollte es keine Probleme geben.
Fehlerangaben
Tritt ein Fehler im JavaScript auf, reagiert Adamas ähnlich wie Netscape: eine Alert-Box klappt auf. Außer, daß diese ziemlich altmodisch ist und das Multitasking blockiert, ist zu sagen, daß die Fehlermeldungen ziemlich ungenau sind, denn es fehlen die Angabe einer Zeilennummer und der ungefähren Position des Fehlers innerhalb der Zeile. Da können manche Websites ganz schön frustrieren, wenn erst eine Alertt-Box nach der anderen weggeklickt werden muß. Eine bessere Lösung wäre in diesem Zusammenhang die Lösung des Internet Explorers, der es erlaubt, die Script-Ausführung für die Seite auszusetzen, oder die des Netscape 4.6/IE5, die Fehlermeldungen nur noch auf Wunsch anzuzeigen. Oft sind die Seiten nämlich trotz Script-Fehlern funktionsfähig.
Stabilität
Während des Tests traten vereinzelt Abstürze auf, wobei kaum festzustellen war, ob dies nun an der noch recht neuen Java-Script-Anbindung lag. Ein Script selbst kann kaum einen Browser zum Absturz bringen, es sei denn, es existiert eine Sicherheitslücke im Browser - ein Grund dafür, warum es fast jeden Monat kleine Updates zu Netscape- und Microsoft-Browsern gibt.
Das Script-Overlay wurde während des Tests noch laufend verbessert. Bei problematischen Seiten hilft es dem Adamas-Programmierer sicherlich weiter, einen entsprechenden Hinweis, sprich URL und Situationsbeschreibung, zu bekommen.
Semikolon
Mit dem Semikolon werden in vielen Programmiersprachen die Programmzeilen abgeschlossen. Während Perl extrem allergisch auf ein fehlendes Semikolon reagiert und damit auch erfahrene Programmierer zum Verzweifeln bringt, sind diese in JavaScript optional. C/Perl-Programmierer setzen diese schon fast aus Gewohnheit, und da JavaScript sich in einigen Bereichen an diese Sprachen anlehnt, wird das auch toleriert. Werden jedoch die Zeilen nicht mit einem Semikolon abgeschlossen, reagiert Adamas allergisch und meldet einen "Missing Semicolon" Fehler. Hier zeigte sich der Unterschied zwischen der Theorie auf der Basis der HTML-Dokumentation SelfHTML und dem praktischen Web-Test. Auf der Slayerette-Seite wurden bspw. die Semikolon-Zeichen bei der Rollover-Funktion weggelassen. Das Resultat machte die Seite mit eingeschaltetem JavaScript unbenutzbar. Jedesmal, wenn sich der Mauszeiger über einem Link befand, wurde die Rollover-Funktion aufgerufen, und da dort die Programmzeilen nicht per Semikolon abgeschlossen wurden, erschien eine Alert-Box mit besagter Fehlermeldung. Da bleiben nur zwei Möglichkeiten: entweder JavaScript ausschalten oder schneller als der Browser sein.
Beides ist jedoch nicht akzeptabel, und so sollte dieser Bug möglichst schnell beseitigt werden, da er nicht gerade bei wenigen Web-Sites auftrat.
Sonstiges
Außerhalb von JavaScript hat sich nichts Auffälliges am Browser getan. So bleiben also die Kritikpunkte an der vl.6 auch für die Pro-Version weitgehend bestehen. Technisch läßt sich kaum noch etwas verbessern, wenn man von Wünschen wie Java, DHTML und PNG absieht, so daß hauptsächlich Verbesserungen an der Geschwindigkeit und der Präsentation auf der Wunschliste stehen. Zu letzteren zählen auch Standards wie BubbleGEM und OLGA. Auch die nicht mehr zeitgemäßen Alert-Boxen sollten in Fenster befördert werden. Zwar ist dies mit externen Erweiterungen wie z.B. Multi-Dialog möglich, aber die Auto-Ordner der meisten Ataris sind ohnehin schon voll genug mit irgendwelchen Systemerweiterungen und Patches.
Fazit
Wäre der Semikolon-Bug und die wirklich störende Anzeige der Fehlermeldungen nicht, würde das Urteil über die JavaScript-Anbindung sehr gut lauten, denn in so kurzer Zeit ein funktionierendes und konkurrenzfähiges Script-Overlay zu erstellen, verdient Respekt. Besonders, da Jens Heitmann, wie viele andere Atari-Programmierer auch, nicht hauptberuflich den Atari programmiert.
Mit der JavaScript-Anbindung stößt der Atari jedenfalls in den betuchten Kreis der JS-fähigen-Browser.
In der nächsten Ausgabe werden die restlichen Bestandteile des Pro-Pakets untersucht, u.a. eine neue Marathon-Version sowie Draconis-FTP und -Telnet.
Preis: 99,- DM
Bezugsquelle:
M.u.C.S. Gustav-Adolf-Str. 11 30167 Hannover www.atari-soft.de
Tip
Lesen Sie zum Thema Java und Java-Script auch den Artikel "JAVA und Atari" auf Seite 22 dieser Ausgabe.
Mia Jaap