Kaum Sinn, aber ein Zeichen

[twothe]

Auch wenn einige ... spezielle Hacker jetzt vielleicht aufspringen und sich freuen das sie jetzt Python im Browser laufen lassen können, die Geschwindigkeit des Endprodukts dürfte sich im überschaubaren Rahmen halten. Dennoch zeigt das Experiment (und einige andere ebenso) deutlich: Coder wollen mehr Möglichkeiten im Browser, also nur das olle JavaScript.

Gründe dafür gibt es ja genügend, beispielsweise simple Performance, oder die Wartbarkeit von größeren Projekten. Google strickt hier sein eigenes Süppchen, dass zwar sicher nicht schlecht ist, aber dann zu sehr an ein Monopol gebunden. Andere brauchen entweder ein Plugin das keiner installieren will, oder sie schaffen es nicht gegen die Heerscharen an Nein-Sagern, die eigentlich gegen so ziemlich alles sind was sich ändern könnte.

Ich glaube man sollte sich an LLVM ein Beispiels nehmen und eine einheitliche Schnittstelle im Browser anbieten, durch die dann jegliche, kompatible Form von Code ausgeführt werden kann.



1 mal bearbeitet, zuletzt am 06.05.15 16:38 durch twothe.

[droptable]

Diese Schnittstelle gab's schon mal, nannte sich ActiveX... Genug gesagt.

[LH]

twothe schrieb:
--------------------------------------------------------------------------------
> Ich glaube man sollte sich an LLVM ein Beispiels nehmen und eine
> einheitliche Schnittstelle im Browser anbieten, durch die dann jegliche,
> kompatible Form von Code ausgeführt werden kann.

Dies ist heute bereits der Fall, nur das eben Javascript asm.js als diese Zwischensprache dient. Es ist im Grunde völlig gleich, ob du nun zu einem Bytecode oder zu asm.js kompilierst, wichtig ist, dass ein Browser es fix ausführen kann.

[leipsfur]

CoffeScript, TypeScript, Dart...

es gibt bereits andere Sprachen, nur werden diese alle zu JS kompiliert.

Wie Scott Hanselman so schön sagte: "Javascript is the assembly language of the web"

[twothe]

ams.js gibt es, aber es ist immer noch JavaScript und mit "echten" Sprachen nicht zu vergleichen. Ein LLVM Zwischencode wäre z.Z. aus nahezu jeder Sprache erzeugbar, würde aber mit erheblich höherer Geschwindigkeit ablaufen.

[LH]

twothe schrieb:
--------------------------------------------------------------------------------
> ams.js gibt es, aber es ist immer noch JavaScript und mit "echten" Sprachen
> nicht zu vergleichen. Ein LLVM Zwischencode wäre z.Z. aus nahezu jeder
> Sprache erzeugbar, würde aber mit erheblich höherer Geschwindigkeit
> ablaufen.

Nein, hier irrst du. Du betrachtest JS hier zu sehr als vollwertige Sprache, aber in diesem Nutzungsfall ist es - in form von asm.js - nicht mehr als ein Bytecode, der nur eben von jedem Browser verstanden wird. Versteht der Browser asm.js, ist JS sehr effizient, da es dann mit einem JIT direkt in sehr effizienten nativen Code umgewandelt werden kann, ohne jedes interpretieren.
LLVM würde hier keinen Vorteil mehr bringen.

Zudem ist "aus nahezu jeder Sprache erzeugbar" bereits heute mit JS als Zwischensprache der Fall. Dies ist ja auch nicht die erste Python-Variante für JS.

Es gibt ganze Unreal-portierungen auf asm.js, auch Engines wie Unity setzen in Zukunft darauf.
Alles, was diese Lösungen von der nativen Ausführungsgeschwindigkeit unterscheidet, ist der Overhead des Browsers selbst. Daran würden aber auch LLVM und co. nicht ändern.

[freebyte]

twothe schrieb:
--------------------------------------------------------------------------------
> Gründe dafür gibt es ja genügend, beispielsweise simple Performance, oder
> die Wartbarkeit von größeren Projekten.

Du müsstest mal auf die asmjs.org Seite gehen, da ist das Konzept in einer Präsentation von asm.js recht gut beschrieben und Du wirst schnell herausfinden, warum Du etwas daneben liegst.

Sehr kurzgefasst: asm.js ist sozusagen ein auf den Funktionsumfang von C abgestripptes Javascript. Du hast also deine normalen Integervariablen etc, der Rest wird (wie zb. in C und ASM) auf einem Memory-Heap abgebildet der bei asm.js als ein typed Array vorliegt. Dh. all der Kram wie Garbage Collection etc. fällt weg.

Der Trick ist jetzt: man nimmt zb. ein C Programm und lässt es durch einen guten C-Compiler laufen der alle Optimierungen und Prüfungen vornimmt die er so kann - den Output übergibt man einem Zwischencompiler der das nach asm.js übersetzt.

Oder eine andere Sprache die einen assemblernahen Zwischencode ausspucken kann welcher dann nach asm.js übersetzt wird (ich würde mir zutrauen meinen alten BASIC-Compiler von 1990 so umzubauen dass er asm.js kompatiblen Code ausspuckt - vielleicht 4 Tage Aufwand incl. Einarbeitung).

Und da asm.js halt nicht viel kann, ist es möglich das Wenige in der Javascript-Engine zu optimieren.

fb

[twothe]

Entgegen der Kommentare kenne ich mich mit asm.js durchaus aus. Bezüglich dem Kommentar "Wartbarkeit" zitiere ich hier auch gerne einen der Pioniere, die sinngemäß sagten: "Es ist schon gut, aber wir mussten viel debuggen, und da fängt der Alptraum an."

Viele Werkzeuge sind für asm.js schlicht nicht vorhanden, ich kann z.B. in meiner IDE nicht per F5 durch-steppen und nachschauen was passiert, und der Code ist sogar noch schwerer lesbar als Assembler. Auch ist nicht garantiert, dass minimale Änderungen am eigentlich Code auch nur minimale Änderungen am JS Ergebnis verursachen, so dass post-compile Patches - die leider im aktuellen Entwicklungszustand nötig sind - ebenso zum Alptraum werden. Und dazu bekommt man zwar eine höhere Performance als bei normalem JavaScript, aber definitiv keine die nativ entspricht oder wenigstens dran liegt (außer bei ausgewählten Beispielen, die dann gerne aus dem Zusammenhang zitiert werden).

Aber allein schon die Existenz von asm.js sagt ja, dass JavaScript für viele Anwendungsgebiete nicht ausreicht und ersetzt werden muss. Und wenn man sich die Entwicklungsgeschichte und das geplante Einsatzgebiet anguckt, dann ist das ja auch nicht weiter verwunderlich. Mich wundert nur wie viele Leute immer noch glücklich lächelnd versuchen dem toten Pferd die Sporen zu geben statt mal übers Umsatteln nachzudenken.

[FreiGeistler]

> Wie Scott Hanselman so schön sagte: "Javascript is the assembly language of the web"
Einspruch. Ich blocke js standardmässig und muss nur selten Ausnahmen zulassen.