HTML-DOM manipulieren?

[Alexander (HH)]

Moin Moin!

»» Ich würde Java-Applets außerhalb einer kontrollierbaren Umgebung nicht einsetzen. Insbesondere zum Basteln mit dem DOM ist JS wesentlich besser geeignet.

Es geht eher um eine kontrollierte Umgebung.

Nö, wohl nicht. Kontrollierte Umgebung in diesem Zusammenhang ist eine Monokultur aus Maschinen mit geringer Hardware-Auswahl, einheitlichem Betriebssystem, einheitlichem Browser, einheitlichen Einstellungen, Software-Verteilung, und vor allem unprivilegierten Benutzern, die nicht ständig an den Maschinen herumkonfigurieren können. Also das, was man typischerweise in einer Firma mit einer durchsetzungskräftigen IT-Abteilung findet.

Wer mein Programm nutzen möchte, muss dann halt einen kompatiblen Browser benutzen.

Oder aber er sch***t drauf und sucht sich einen anderen Anbieter, dessen Angebot mit dem Browser des Besuchers funktioniert.

Es ist ohnehin nur für eine überschaubere Zielgruppe interessant, für die das kein Problem sein sollte.

Hoffst Du.

Eigentlich geht es um folgendes:

Eine umfangreiche, rechen- und datenintensive Javascript-Anwendung, deren Sourcecode ich nicht unbedingt herausgeben möchte, soll aber dennoch im Browser laufen. Ein Server wäre schnell überlastet, wenn mehrere Benutzer damit arbeiten wollten, denn es müssen jeweils u.a. mehrere zig tausend Arrays angelegt und ständig Daten berechnet und umhergeschoben werden. Allein das macht einen IE z.B. völlig ungeeignet – Der packt es einfach nicht...

Wenn Du -- nach eigener Aussage -- eine kontrollierte Umgebung hast, warum mußt Du dann unbedingt im Browser Datenmengen verarbeiten, mit denen der Browser nicht klarkommt? 10.000 Arrays für einen User klingt für mich nach einem völlig aus dem Ruder gelaufenen Projekt.

Warum willst Du in einer kontrollierten Umgebung den Quelltext nicht ausliefern? Warum kannst Du nicht einfach mit Hilfe der kontrollierten Umgebung eine dedizierte Client-Software verteilen? Ist Deine Umgebung vielleicht doch nicht so kontrolliert?

Nun bin ich auf die Idee gekommen, zumindest einige Schlüsselobjekte und Methoden in ein Java-Applet zu kompilieren und von Javascript aus aufzurufen.

Was versprichst Du Dir davon? Hoffst Du, dass die Java-VM um Zehnerpotenzen schneller ist?

Ein besserer Algorithmus oder optimierte Datenstrukturen kann Dir Zehnerpotenzen bringen, für den Wechsel von JS auf Java glaube ich das nicht.

Ich habe gerade für einen guten Kunden ein kleines, eigentlich triviales Perl-Script um den Faktor 20 beschleunigt. Unter anderem dadurch, dass ich die internen Datenstrukturen umgebaut habe, unnnötige Sortierungen rausgeworfen habe, und möglichst viel von den optimierten, schnellen Core-Funktionen erledigen lasse statt das Rad neu zu erfinden. Angesichts des kruden Algorithmus im Script gehe ich eigentlich davon aus, dass da noch reichlich Luft für weitere Optimierungen drin wäre, so dass das Script am Ende vielleicht 25x oder 30x schneller als das Original wäre. Aber für Faktor 20 werden Sie mir schon die Füße küssen. ;-)

Um auch den Zugang zum restlichen JavaScript-Code möglichst zu erschweren, dachte ich mir, dass man den vielleicht sozusagen durch die Hintertür erst über das Applet nachladen könnte. Dazu müsste das Applet aber z.B. ein <script>-Tag im HTML-DOM einfügen können. Alle anderen DOM-Operationen können mit JavaScript erfolgen.

Security by Obscurity funktioniert nicht. Wenn Du Code nachlädst, sehe ich das z.B. am Log eines zwischengeschalteten Proxy-Servers oder ganz einfach im Firebug, mit vollständiger URL, und, wenn ich will, mit Session Keys und Passworten. Egal ob Du XMLHttpRequest benutzt oder ein Script-Tag einbaust, egal ob aus Javascript, Java-Applet oder Flash.

Davon abgesehen gibt es für Java-Applets durchaus brauchbare Decompiler. Ich habe einen externen Mitarbeiter mal über die Schulter geschaut, als er ein fremdes Applet "mal eben" decompiliert, an unsere Bedürfnisse angepaßt und wieder compiliert hat -- alles an einem ganz entspannten Nachmittag. Der decompilierte Quelltext sah durchaus brauchbar und nachvollziehbar aus.

Deine Software ist jetzt schon offensichtlich an der Leistungsgrenze, die Komplexität scheint recht hoch zu sein, und sie scheint einige Anforderungen zu stellen. Darauf noch mehr Komplexität zu werfen und noch mehr Anforderungen zu stellen klingt für mich nicht sonderlich sinnvoll.

Angenommen, das funktioniert – mit oder ohne Nachladen von JavaScript – würde durch die ständige Interaktion mit einem Applet die Perfomance des Programms leiden? JavaScript ist als Scriptsprache ohnehin nicht gerade pfeilschnell, daher wäre es nicht wünschenwert, wenn es durch Java noch weiter ausgebremst würde. Oder kann ich hoffen, dass die Anwendung dann sogar schneller läuft als in reinem JavaScript?

Fange an zu messen, ganz klassisch mit der Stoppuhr. Ich denke, die meiste Zeit wird der PC darauf warten, dass der Benutzer etwas tut, egal ob du JS oder Java einsetzt.

Wahrscheinlich wäre es wesentlich besser, Du würdest Deine Software mal gründlich überdenken. Du sagst, sie sei sehr rechenintensiv. Kannst Du Dinge vorberechnen und bei Bedarf statt einer aufwendigen Rechnung einfach einen vorberechneten Wert vom Server laden? Kannst Du mit schneller berechenbaren Näherungen arbeiten? Mußt Du jedes mal mit 10.000 Arrays herumjonglieren oder könntest Du den Großteil der Daten erst "on demand" laden? Kannst Du einen schnelleren Algorithmus benutzen? Für mich klingen 10.000 Arrays irgendwie nach einer auf alle Clients ausgekippten Datenbank, in der die Clients von sich aus herumwühlen müssen. Das geht definitiv schneller auf einem optimierten RDBMS-Server.

Oder anders ausgedrückt: Erkläre uns Dein wahres Problem, statt an Symptomen herum zu quacksalbern.

Alexander