Die Vorteile dürften die Nachteile aber bei weitem überwiegen: endlich andere Sprachen fürs Web. Klar kann man heute auch schon andere Sprachen nach Javascript kompilieren, aber das ist einfach grausam. Mir wäre Python als Skriptsprache tausendmal lieber als JavaScript. Und JavaScript kann man auch durch nen Obfuscator jagen, da kommt auch nix anderes raus als wenn man den ByteCode disassembliert.
"da kommt auch nix anderes raus als wenn man den ByteCode disassembliert"
Tatsächlich dürfte der Bytecode mehr lesbare Informationen als ein obfuscated JS Code enthalten, da es hier keinen Grund gibt, per se Namen von Variablen und Klassen zu ändern. Siehe das Beispiel .Net, wo deren Common Intermediate Language diese Informationen beibehält. Wenn der Sinn eines Bytecodes nicht die Verschleierung ist, ist er am Ende auch nur eine optimierte Version des Quellcodes, und dürfte "disassembliert" weiterhin gut lesbar sein.
Was hat Ausführung als Binary oder nicht mit Open Source oder Closed Source zu tun?
Beispielsweise werden alle in C oder C++ geschriebenen Open-Source-Programme als Binaries ausgeführt (LibreOffice, GIMP, Linux-Kernel, ...).
Und umgekehrt kann der auf einer Webseite ausgeführte JavaScript-Code Closed Source sein, obwohl ihn zwar jeder sehen kann, nämlich wenn er nicht vom Copyright-Inhaber unter eine Open-Source-Lizenz gestellt wurde.
Begrüßenswert ist für mich im Moment einzig und allein der Ansatz das Ganze in einer offenen Arbeitsgruppe beim W3C aufzuhängen. Das war es dann allerdings schon. Die restlichen Argumente für WebAssembly sind ohnedies praktisch wertlos, die Ideen alter Wein und der Hype drumherum (positiver wie negativer) grenzenlos und langweilig.
Das hört sich alles wie ein riesiger Haufen Bullshit an. Die Argumente sind an den Haaren herbeigezogen oder schlichweg falsch.
Zum Beispiel Security: Also aus der Jjavascript-Sandbox kann man "allzu einfach(..) Ausbrechen". Aha. Aber der Bytecode, "der in die JavaScript-Interpreter integriert wird" kann das natürlich nicht - also alles gut. Bullshit!
Im übrigen waren die Gründe, warum Java sich im Webbrowser nicht durchgesetzt hat, ganz andere als die genannten. Das weiß ja wohl ncoh jeder, der noch weiß was ein Applet ist... Stichwort Ladezeit, verschiedene und veraltete (danke Microsoft) JVMs, keine Verbindung zum DOM etc. ...
Stichwort Geschwindigkeit: In einem JIT ausgeführte Javascript-Programme kommen nahe an C++ ran (kann ja jeder selbst leicht testen) - das ist wieder so ein Kack, der drau fhindeutet, dass hier Letue am machen sind, die eine GANZ andere Agenda haben ... Werbeindustrie klingt plausibel (danke Firefox).
Bytecode würde vermutlich schneller zu laden sein - aber es gibt ja kaum Seiten (und das ist auch gut so!) die eine so irre (sic!) große Scripting-Sache benötigen. Und wenn doch, ist es eine Anwendung und auf den Start einer Anwendung kann man schon mal 2 Sekunden warten. Zum Vergleich: Für das Laden einer Seite mit 2 MB Javascript-Anweisungen benötigt mein Firefox auf dem Desktop 1 gute Sekunde. So what?? Mobiles sind langsamer? Naja, also gezippter Javascript-Code kommt mind. genauso schnell zum Browser wie Bytecode und wenn ich die neuen Handys angucke: Oktacores mit 2 Ghz ...
LLVM ist nicht plattformunabhängig? Aha. Aber zum Glück kann man ja nun endlich mit einer Systemsprache (!) (und noch dazu so einem alten Scheissdreck) wie C++ auf den Browser. Juhu! Endlich Buffer-Overflows, Dangling Pointers und was das Herz sonst noch begehrt - zumindest für den, der Viren schreibt.
Zum "Vorteil der geringen Download-Größe": Was zu beweisen wäre - insbesondere bei zip. Zu 99 % wird der Bytecode NICHT kleiner als gezipptes javascript. Und wenn erst mal die ganzen Narren nicht mehr auf die Größe achten müssen weil es ja sooo klein ist, dann kommen erst die richtigen Monster ... mit Abhängigkeiten zu anderen Monstern mit Abh ...
für mich klingt jgz oderjxz auch erstmal besser als blob. Und wenn schon wieder mit bytecode weshalb nicht was bestehendes wie java, dalvik/art oder die vm von python oder sogar mono?
Yeah, binary blobs im Browser. Genau das, was die Welt braucht! Mehr closed-source-Krams!
Die Vorteile dürften die Nachteile aber bei weitem überwiegen: endlich andere Sprachen fürs Web. Klar kann man heute auch schon andere Sprachen nach Javascript kompilieren, aber das ist einfach grausam. Mir wäre Python als Skriptsprache tausendmal lieber als JavaScript.
Und JavaScript kann man auch durch nen Obfuscator jagen, da kommt auch nix anderes raus als wenn man den ByteCode disassembliert.
"da kommt auch nix anderes raus als wenn man den ByteCode disassembliert"
Tatsächlich dürfte der Bytecode mehr lesbare Informationen als ein obfuscated JS Code enthalten, da es hier keinen Grund gibt, per se Namen von Variablen und Klassen zu ändern.
Siehe das Beispiel .Net, wo deren Common Intermediate Language diese Informationen beibehält.
Wenn der Sinn eines Bytecodes nicht die Verschleierung ist, ist er am Ende auch nur eine optimierte Version des Quellcodes, und dürfte "disassembliert" weiterhin gut lesbar sein.
Was hat Ausführung als Binary oder nicht mit Open Source oder Closed Source zu tun?
Beispielsweise werden alle in C oder C++ geschriebenen Open-Source-Programme als Binaries ausgeführt (LibreOffice, GIMP, Linux-Kernel, ...).
Und umgekehrt kann der auf einer Webseite ausgeführte JavaScript-Code Closed Source sein, obwohl ihn zwar jeder sehen kann, nämlich wenn er nicht vom Copyright-Inhaber unter eine Open-Source-Lizenz gestellt wurde.
Begrüßenswert ist für mich im Moment einzig und allein der Ansatz das Ganze in einer offenen Arbeitsgruppe beim W3C aufzuhängen. Das war es dann allerdings schon. Die restlichen Argumente für WebAssembly sind ohnedies praktisch wertlos, die Ideen alter Wein und der Hype drumherum (positiver wie negativer) grenzenlos und langweilig.
just my two cents
Volle Zustimmung
Das hört sich alles wie ein riesiger Haufen Bullshit an.
Die Argumente sind an den Haaren herbeigezogen oder schlichweg falsch.
Zum Beispiel Security: Also aus der Jjavascript-Sandbox kann man "allzu einfach(..) Ausbrechen". Aha.
Aber der Bytecode, "der in die JavaScript-Interpreter integriert wird" kann das natürlich nicht - also alles gut.
Bullshit!
Im übrigen waren die Gründe, warum Java sich im Webbrowser nicht durchgesetzt hat, ganz andere als die genannten. Das weiß ja wohl ncoh jeder, der noch weiß was ein Applet ist... Stichwort Ladezeit, verschiedene und veraltete (danke Microsoft) JVMs, keine Verbindung zum DOM etc. ...
Stichwort Geschwindigkeit: In einem JIT ausgeführte Javascript-Programme kommen nahe an C++ ran (kann ja jeder selbst leicht testen) - das ist wieder so ein Kack, der drau fhindeutet, dass hier Letue am machen sind, die eine GANZ andere Agenda haben ... Werbeindustrie klingt plausibel (danke Firefox).
Bytecode würde vermutlich schneller zu laden sein - aber es gibt ja kaum Seiten (und das ist auch gut so!) die eine so irre (sic!) große Scripting-Sache benötigen. Und wenn doch, ist es eine Anwendung und auf den Start einer Anwendung kann man schon mal 2 Sekunden warten. Zum Vergleich: Für das Laden einer Seite mit 2 MB Javascript-Anweisungen benötigt mein Firefox auf dem Desktop 1 gute Sekunde. So what??
Mobiles sind langsamer? Naja, also gezippter Javascript-Code kommt mind. genauso schnell zum Browser wie Bytecode und wenn ich die neuen Handys angucke: Oktacores mit 2 Ghz ...
LLVM ist nicht plattformunabhängig? Aha. Aber zum Glück kann man ja nun endlich mit einer Systemsprache (!) (und noch dazu so einem alten Scheissdreck) wie C++ auf den Browser. Juhu! Endlich Buffer-Overflows, Dangling Pointers und was das Herz sonst noch begehrt - zumindest für den, der Viren schreibt.
Zum "Vorteil der geringen Download-Größe": Was zu beweisen wäre - insbesondere bei zip. Zu 99 % wird der Bytecode NICHT kleiner als gezipptes javascript. Und wenn erst mal die ganzen Narren nicht mehr auf die Größe achten müssen weil es ja sooo klein ist, dann kommen erst die richtigen Monster ... mit Abhängigkeiten zu anderen Monstern mit Abh ...
Holy shit!
für mich klingt jgz oderjxz auch erstmal besser als blob. Und wenn schon wieder mit bytecode weshalb nicht was bestehendes wie java, dalvik/art oder die vm von python oder sogar mono?