Javascript als Bytecode laden

[Thorsten]

Hallo Forumsgemeinde,
gibt es eine Möglichkeit eine JavaScript-Datei in Bytecode zu kompilieren und diese dann anstelle der KlarText-Datei entsprechend zu laden? Habe gegoogelt aber wenig brauchbares gefunden....

viele Grüße

Thorstem

[Andreas]

Hi,

keine Chance. Script bleibt Script. Es gibt Software, mit der man JS "unlesbar" machen kann. Aber ist das wirklich sinnvoll? Dann lieber gleich serverseitige Scripts (CGI).

Ciao
Andreas

[Thorsten]

Es gibt Software, mit der man JS "unlesbar" machen kann.

*g* Es ging mir wirklich nur um die kompilierung, um evtl. Geschwindigkeitsvorteile nutzen zu können.... ;)

Schade, daß das nicht möglich ist...

AFAIK gibt es von MS ein Tool das JS decoden kann (nennt sich JSDecoder o.ä.), das encoden funktioniert dann aber auch nur unter MS IE...

[Andreas]

Hi,

das wusste ich auch noch nicht - ist ja interessant! Was es nicht alles gibt... Solange nicht wie bei Perl2Exe der ganze Perl-Interpreter (bzw. JS-Interpreter) gemerged wird könnte sowas durchaus Sinn machen.

Aber für Dich währe Clientseitig wohl eher Java interessant. Da dauert es nur ein wenig bis die Java VM geladen ist - aber bei komplexen Routinen kann man darüber schonmal hinweg sehen. Ich habe mit JavaScript mal eine 80x40 Pixel-Grafik auf eine HTML-Seite geplottet - das dauert ja Ewigkeiten... Für solche Zwecke ist Java halt ideal.

Ciao
Andreas

[Thorsten]

[...]

Dads mit dem Plotten würde mich interessieren... Beispiel?

Ich werde mir später heute mal ein wenig die Mozilla-Tools anschauen, irgendwo habe ich von einer offenen Implementierung des JavaScript-Compilers gelesen.

Vielleicht ließe sich ja mit einem klitzekleinen Applet ein entsprechender Interpreter basteln...

[Andreas]

Hi,

es ging bei dem Projekt um einen Handylogo-Editor. Das Ganze hat dann so ausgesehen, dass ich um Traffic zu sparen das Editor-Raster nicht komplett in HTML geschrieben, sondern durch JS-Schleifen erzeugt habe:

<CUT>

var pixel=new Array(39);
for(i=0;i<=39;i++){
  var pixel[i]=new Array(79);
  for(j=0;j<=79;j++){
    pixel[i][j]=false;
    document.writeln('<img src="off.gif" onclick="click('+j+','+i+');" id="'+j+'/'+i+'" style="cursor:crosshair">');
    document.writeln('<input type="hidden" name="'+j+'_'+i+'" value="false">');
  }
  document.writeln('<br>');
}
function click(x,y){
  if(pixel[y][x]){
    pixel[y][x]=false;
    document.images[x+'/'+y].src="off.gif";
    document.logoedit[x+'_'+y].value=false;
  }else{
    pixel[y][x]=true;
    document.images[x+'/'+y].src="on.gif";
    document.logoedit[x+'_'+y].value=true;
  }
}

<CUT>

Das ist nicht das Original, aber so ungefähr hat es ausgesehen. Das Ganze natürlich zwei mal, weil der Editor als grobes Raster dargestellt wurde und unten drunter nochmal eine Vorschau, wie es dann im Handydisplay aussieht. Auf einem schnellen Rechner dauerte der Rasteraufbau so ca. 30 Sekunden. Und dann kommt noch das Malen der vorgefertigten Bilder, die der User zur Auswahl hat - aber das ist eine ganz andere Geschichte... Das willst Du nicht wissen... Wirklich nicht... Lerne lieber Java... Oder VB... Oder C++... Aber JS ist definitiv nicht für sowas geeignet. Das Projekt ist auch mittlerweile (Gott sei Dank!) gestorben, nachdem auch der letzte JS-Fetischist von der schwachen Leistung des JS-Interpreters überzeugt war.

Geschichten aus meinem Leben ;o)

Ciao
Andreas

[Thorsten]

[...]

Nun ja, ich denke man kann schon noch etwas an dem Code frickeln, damit es zumindest "etwas" performanter wird.

Für die Schleifen hätte ich bspws. Duffs Device genommen, und die Elemente statt mit document.write mit einem createElement() und späteren cloneNode() genutzt.

Das boostet das ganze schon um einiges...

Was meinst Du eigentlich mit Traffic sparen? Sollte der Logo-Editor auf "Leitungs-kritischen" endgeräten laufen (Handy?) oder sollte der Editor das Bearbeiten der Logos im Browser mit späterem Dload aufs Handy erlauben?

[Andreas]

Hi,

vielen Dank für die Tipps! Ich bin leider (noch :o) kein JS-Pro, weiss mir aber (meistens) zu helfen, wenn ich eine Lösung für ein Problem brauche. Wahrscheinlich kann ich diese Funktionen irgendwann einmal gebrauchen... Wir sind jedenfalls mit einem Java-Applett ganz glücklich geworden: Das hat nur 16K, eine super Optik und intuitive Funktionalität, für die eine Menge HTML, CSS, JS usw. notwendig gewesen wäre. Okay, der Benutzer braucht jetzt einen Java-Compiler (VM?), aber ich denke das ist immer noch ein guter Kompromiss gegenüber der JS-Version. Immerhin liefert M$ ja eine JavaVM mit dem M$IExplorer - also irgendwo ein Standard.

Gibt's eigentlich sowas wie ein JS-Tuning-Tutorial? Für C habe ich mal sowas gesehen (hab's aber leider nicht mehr - siehe astalavista.com). Da wurde erklärt wann welche Funktion oder Schleife mit welcher Syntax wie schnell ist. Somit kann man das C-Programm bis in den Nano-Sekunden-Bereich optimieren.

Mit Traffic sparen meine ich, dass eine 200KB-HTML-Seite, die über eine 56K-Modem-Leitung geschickt wird a) auf Dauer richtig Traffic verursacht ( / verursachen kann) und b) urlangsam übertragen wird. Da in diesem Beispiel das JS den Großteil an HTML-Code clientseitig generierte, muss nur das 1K JS übertragen werden. Mit dem Applett kommen wir jetzt auf eine insgesamte Seitengröße von nur 45K (inkl. Grafiken!), das ist sehr überzeugend, finde ich. Und (arme, bedauernswerte) Modem-Surfer bleiben auch nicht auf der Strecke. Naja, wie oft verschickt man schon Handylogos...? (Ich persönlich noch nie!)

Ciao
Andreas

[LanX]

Hi Torsten

Die Frage ist was du erreichen willst:

1. Kompression: Nun du könntest den Code natürlich mit
einem Wrapper JS entpacken und mit eval() ausführen.
ich bezweifle dass sich der aufwand auszahlt da die meisten webserver mittlerweile die Daten sowieso gezippt übertragen sollten (modgzip oder so ähnlich)

2. Leseschutz des Codes: sowas wiederspricht prinzipiell
dem prinzip von scripten. Wenn du dein geistiges eigentum schützen möchtest dann schreibe am besten schlechten unübersichtlichen und unkommentierten Code
den klaut keiner. Oder hat schon mal jemand MSWord durch den dissassambler gejagt und ausgewertet?

Was die erwähnte Codierung von MS fürs Scripting anbelangt glaube ich du sprichst von diesem WSH Mechanismus um encryptete VBScript oder JScript Dateien
executen zu können. Da kann ich dir nur abraten das Verschlüsselungsverfahren ist dermaßen Banane dass man
es mit einer simplen Häufigkeitsanalyse zoiemlich schnell knacken kann.

Cheers
  Rolf