WebAssembly vs Javascript: Binärcode wird das Web schneller machen

Mit WebAssembly haben die Entwickler der bekannten und meistgenutzen Webbrowser Firefox, Internet Explorer und Chrome gemeinsam ein Alternative zu JavaScript vorgestellt. Der neue Standard soll vor allem durch Schnelligkeit punkten. mehr... JavaScript, WebAssembly, Bytecode Bildquelle: Mozilla JavaScript, WebAssembly, Bytecode JavaScript, WebAssembly, Bytecode Mozilla

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
Die Idee finde ich gut. Bin mal gespannt was da kommt.
 
Was mich dazu mal interessieren würde, kann man aus WebAssembly auf den DOM zugreifen und kann ich aus JavaScript WebAssembly aufrufen? Wenn beides ein ja bekommt wäre das grandios für Bibliotheken wie jQuery und co. :)
 
@Knerd: wasm klingt für mich wie ein kompiliertes JavaScript. Letztlich wird für den Entwickler nix anders, sondern lediglich die Kompilierung passiert nicht mehr auf dem Client, sondern schon auf dem Server bzw. wahrscheinlich beim publishen der Webseite.
 
@larsh: Was aber - konsequent zu Ende Gedacht - Sinn ergibt. Wieviele menschliche Aufrufer lesen schon dein Javascript?

Die einzige Gefahr, die ich in ein paar Jahren sehe ist dass selbst ernannte Programmierer sensible Informationen dort einbetten, weil Sie nicht wissen, dass das lesbar gemacht werden kann.
 
@dognose: Da ist was dran. Wo ich mir WebAssembly gut für vorstellen kann, im Bereich node.js :)
 
Also wenn man sich die Use Cases durchliest, muss man sich schon auf den Kopf greifen: https://github.com/WebAssembly/design/blob/master/UseCases.md ... was haben AAA Games im Browser verloren? Genauso Bilderkennung, DOSBox, CAD, etc? Für browser-basierte Web-Anwendung gibt's schon seit 20 Jahren etwas: Java. Und das läuft nicht nur im Browser, sondern auch am Desktop. Und nicht nur unter Windows, sondern auch unter Linux, Mac, Solaris. Und am Mobiltelefon wird's mit Android ebenso verwendet. Wenn sie das Web unbedingt schneller machen wollen, dann sollen sie mal schauen wie gross der Anteil zwischen tatsächlichem Content und Werbe-Content ist.
 
@Lofi007: Irgendwie scheinst du die letzten Jahrzehnte etwas verschlafen zu haben, oder? Also mir ist seit Jahren nirgendwo mehr Java untergekommen, ich vermute wirklich wird das nur noch in Unternehmen genutzt. Selbst Flash ist glücklicherweise langsam am Aussterben. Javascript ist dagegen die letzten Jahre der Quasistandard für alle anderen Dinge geworden. Und wieso sollte ein Spiel nicht im Browser laufen? Hat doch nur Vorteile: für den Entwickler, er muss nur einmal programmieren und für den Käufer: Es läuft im besten Fall auf allen möglichen Plattformen.
 
@dodnet: Schon mal was von Minecraft gehört? Rat mal womit das entwickelt wurde ...
 
@Lofi007: Und? Minecraft ist das einzige Spiel das ich kenne, dass mit Java läuft ;)
 
@Lofi007: WOW... eine Referenz. Es gibt auch noch den jDownloader... also eine Wahnsinnsbandbreite an Javaprogrammen gibt es ;)
 
@dodnet: Ähm... Nur weil man java nicht "sieht", heißt das nicht, dass es nicht da ist.

Schonmal was von Glassfish, WebSphere, Jboss oder Wildfly gehört? Das sind Java-Application Server und kommen sehr häufig zum Einsatz. Der Nutzer bekommt davon nichts mit, da "normales" (x)html generiert wird.

Auch "Android" kennst du bestimmt? Aber nein, Java kommt einem nirgends unter :-)

Und Java mit JavaScript vergleichen ist "Äpfel und Birnen" vergleichen. Das ist ja wie zu sagen: "Ich schreibe meine App nicht mit C#, sondern XAML..."

Du beziehst dich sicher (hoffentlich) auf das "klassische Java-Plugin", das java code direkt auf dem Client ausführt? Ja, das ist so gut wie tot.
 
@dognose: Wo habe ich Java mit Javascript verglichen? Ich habe nur gesagt, dass Java (außer für einige Server- und Unternehmensanwendungen) kaum vorkommt. Dagegen sind Anwendungen auf HTML5- und in dem Zusammenhang Javascript-Basis im Vormarsch. Dass Java und Javascript außer die Namensähnlichkeit nix miteinander zu tun haben, ist mir schon klar ;)
 
@dodnet:

"Also mir ist seit Jahren nirgendwo mehr Java untergekommen [...] Javascript ist dagegen die letzten Jahre der Quasistandard für alle anderen Dinge geworden."

ließt sich im Kontext irgendwie so als würde JavaScript langsam Java ablösen.
 
@Lofi007: Tjo, und gerade weil es (nur) Java gibt, wollen diese Firmen was anderes. Weil dafür benötigst du noch immer die VM auf dem Client.
 
@Fallen][Angel: so ist's eben eine andere VM, die den Bytecode interpretieren wird. Und wenn's so ist wie in der Vergangenheit, dann wird MS wieder mal ein eigenes Süppchen kochen anstatt sich an einen Standard zu halten.
 
@Lofi007: Momentan ist eher Webkit und Blink die Liste der nicht Standards ;)
 
@Lofi007: Java? Willkommen in den 90ern ;)
 
@Knerd: Schau mal was auf Platz 1 der populärsten Programmiersprachen ist: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html ;-)
 
@Lofi007: Java wird aber nicht mehr fürs Frontendweb genutzt ;) Backend ja, Android man wird gezwungen, SIM Karten ja, Blu Ray Player ja, Smartcards ja, etc. Kurz, Java wird für vieles benutzt, aber nicht mehr fürs Frontend im Web.
 
@Knerd: Man wird bei Android nicht wirklich zu Java gezwungen. C++ geht auch.
 
@TiKu: Ist aber nicht empfohlen. Zumindest war es der Stand 2013.
 
Logo das das schneller ist. Weniger zu übertragen. Weniger zu analysieren (Stringparsing und Analyse braucht eben seine Zeit)
 
Prof. Eich beschäftigt sich also mit Webstandards, wenn er nicht gerade einen Pokedex entwickelt. Soso...
 
Hmm, ich verstehe den Speed-Vorteil, allerdings sehe ich nicht wie das ganze Menschenlesbar gemacht werden soll. Das geht bei einem via gcc compiliertem Programm ja auch nicht. Für mich klingt das irgend wie nach dem Ende eines wirklich freien Webs. Ich meine, Silverlight war ja genau das hier. Ein Binärformat für das Web und besser wurde dadurch auch nicht wirklich viel.
 
@Sam Fisher: Weil Silverlight clientseitig noch ein Plugin benötigte, genauso wie Java und Flash. WebAssembly soll aber direkt im Browser integriert sein.
 
@TiKu: Silverlight brauchte nur ein Plugin, da es niemand nativ im Browser nachbaute. Das hier ist wie Silverlight, nur das alle Browser-Hersteller es eigenständig integrieren.
 
@Sam Fisher: Der Sourcecode ist ja jetzt bereits oftmals nicht mehr lesbar, durch die ganzen Compiler, die Bezeichnungen verkürzen, Kommentare entfernen u.s.w, um die Dateigrösse zu verringern. Bevor alle ihren Code dadurch unleserlich machen, um etwas Bandbreite zu sparen, ist mir wasm wesentlich lieber, wodurch ich auch in der Verarbeitung eine bessere Performance habe.
 
@glurak15: Naja, dafür gibt es, wie von z.B. jQuery eine development und eine deployment Version. Im Browser habe ich eh nicht vor den JS Code zu lesen.
 
@Knerd: Aber dann hat die neue Technologie erst Recht keinen Nachteil in dieser Hinsicht. Ob ich nun eine minified und plain Version oder die Kompilierte und den Quelltext veröffentliche, macht auch keinen Unterschied.
Und wie du bereits sagst, ich bezweifle, dass sehr viele Entwickler Source Codes von Webseiten anschauen und wenn, dann ist ein gewisses Know How nötig, wodurch man sich auch gleich nach Tutorials umschauen kann.
 
@glurak15: Aktuell kann man den code zwar verkürzen und schwer lesbar machen, aber es ist immer noch 100% lesbar. Bei einem binärformat so wie hier ist das nicht mehr der Fall da man es erst komplet reverse engeneern muss.
 
@Sam Fisher: Lesbar finde ich relativ. Ob ich aus dem Kontext herausfinde, was Funktion a() macht, welche b() und c() aufruft, ist bei einem etwas komplexeren Code fast unmöglich.
Zumal wasm wohl assembler oder ähnliches sein wird, was man, sofern man es beherscht, auch lesen könnte.
 
@Sam Fisher: Java.classes kann man auch wieder in Quellcode zurückumwandeln und in die Bytecode Richtung dürfte es ja gehen.
 
Weil Java und Flash so sichere bewährte JS-Alternativen sind, muss diese Idee aufgegriffen werden.
Fremde Binaries automatisch ausführen? Yuhu.
Die Übertragungsgeschwindigkeit kann man durch Kompression mindestens genauso erreichen.
 
Schon vergessen, WARUM man "Quellcode" - also Text -- fürs Web verwendet? Tz.

Gottseidank gibt es ja nur PCs und PC-Kompatible im Internet. Big Endian? Was das? MIPS? SPARC? ARM? Was das? Braucht kein Mensch. Und ans Internet müssen die auch nicht.

Schon mal gefragt, warum TCP/IP insbesondere *Plaintext* überträgt? Auch schon zu Zeiten, wo Bandbreite ein sehr(!) kostbares Gut war.

Hier beißt sich die Katze in den Schwanz. Die Webanwendungen heutzutage sind doch nur *deswegen* so furchtbar groß, weil sich kein Schwein mehr um Optimierungen und *kleinen* Fußabdruck kümmert - einfach deswegen, weil genug Bandbreite angenommen werden kann (und auch *wird*).

Fangt an, sauber zu programmieren.
 
@RalphS: sauber programmieren heißt bei dir wenig Code zu schreiben?

Üblicherweise ist sauberer Code eher deutlich länger als unsauberer Code, da der Fokus auf der Lesbarkeit liegt...
MVC ist zum Beispiel ein Konzept um die Wartbarkeit von Oberflächen (Websites) zu verbessern. Dabei erzeugt MVC aber deutlich mehr (besser strukturierten) Code.

Die Codemenge zu reduzieren ist im Prinzip eine reine Web-Krankheit, eben weil der ganze Code erst über die Leitung muss. Bei installierten Anwendungen fällt der Anteil des reinen Codes kaum ins Gewicht. Da sind die restlichen Assets üblicherweise deutlich größer...
Und da versucht auch niemand den Code zu verkleinern...wozu auch, ob der Installer 50 oder 55 MB hat ist wurscht...
 
@Draco2007: Eh? Wer hat denn das Gerücht in die Welt gesetzt, "sauber" hätte was mit "lesbar" zu tun? *kopfkratz*

Sauberer Code ist effizient, kurz und schmerzlos. Da den kein Mensch lesen *soll*, muß er auch nicht von Menschen lesbar *sein*.

Aber das Wichtigste ist, daß er möglichst *nichts* mit "binär" oder "Hardware" zu tun hat, sonst können wir Netzneutralität gleich vergessen, auch ohne das wir das Kind beim Namen nennen.

Und, ja. Davon wird das länger. Klar.

Nur, vielleicht hast Du das übersehen... es ging ja gar nicht darum, "weniger" Code zu haben. Es ging darum, das schneller ausführen zu können und *hier* kommt der saubere, lies: effiziente Code ins Spiel.
 
@RalphS: Ok, wir haben einfach eine unterschiedliche Definition von sauberem Code. Da werden wir uns wohl auch nicht einig.

Was du mit effizient meinst, also Laufzeitoptimiert geht üblicherweise mit absolut schlechter Lesbarkeit einher und damit mit sehr schlechter Erweiterbarkeit und Wartbarkeit. Das läuft für mich eher unter dem Begriff "dreckige Optimierung", zum Beipiel Bitshift Operationen statt temporäre Variablen. Garantiert schneller, garantiert nicht nachvollziehbar nachdem man den Code ein paar Monate nicht mehr gesehen hat.

Zumindest in meinem Kopf schwebt immer ein Kredo herum "Do not optimize", heißt ich überlasse das optimieren dem Compiler, mit einer Ausnahme... ich kann eine bestimmte Codestelle als kritisches Bottleneck identifizieren und MUSS selbst optimieren. Dann sollten wir aber von mind. Faktor 10 eher Faktor 100 reden, was die Laufzeit angeht, damit es die Zeit, die für die Optimierung gebraucht wird, auch wert ist. Und mit der Zeit meine ich nicht nur die Zeit, die das Entwickeln braucht, sondern auch die langfristige Zeit, wenn man später wieder auf den Code stößt.

Moderne Softwareprojekte sind einfach viel zu komplex um JEDE Codestelle immer von Hand zu optimieren und oft ist es auch einfach nur verschwendete Zeit, weil der betreffende Code nur einen minimalen Bruchteil der Laufzeit ausmacht.
Und deshalb überträgt man häufig dem Compiler die Optimierungsaufgaben. Zum Beispiel im .Net mit C# läuft ein verdammt guter Optimierer, der auf Optimierungen kommt auf die ich als Entwickler teilweise überhaupt nicht gekommen wäre. Also kann ich mich doch auf die eigentlichen Aufgaben konzentrieren, nämlich das hochkomplexe Projekt.

Und auch bei diesem Thema sorgt beispielsweise MVC NICHT dafür, dass der Code schneller oder effizienter wird, sondern nur dafür, dass er auch nach Monaten noch nachvollziehbar bleibt und während der Entwicklung gut "verteilbar" ist. Und das ist ab einer gewissen Größenordnung der Projekte auch bitter nötig.

Was jetzt die Netzneutralität mit Binary-Code zu tun hat ist mir auch fraglich. Selbst wenn wir hier von hardwareoptimiertem Code reden, hat das nichts mit Netzneutralität zu tun, denn das NETZ wird diesen Code genauso behandeln, wie nicht binären. Es ist nur der Webserver, der unterschiedlich ausliefert. Und auch das wird heute schon gemacht, wenn du mit einem Smartphone oder einem Desktop-Browser eine Webseite besuchst. Auch da hast du schon unterschiedlich optimierten Code.

Vor 20 Jahren hätte ich dir noch in allen Punkten Recht gegeben, aber heutige Softwareprojekte sehen einfach anders aus....
 
Erinnert mich etwas an Java. Browser wird dann zur VM.
Kommentar abgeben Netiquette beachten!

WinFuture Mobil

WinFuture.mbo QR-Code Auch Unterwegs bestens informiert!
Nachrichten und Kommentare auf
dem Smartphone lesen.

Folgt uns auf Twitter

WinFuture bei Twitter