Python bald im Browser...

[lunar]

@DasIch: In Safe Haskell lässt sich, wenn ich die Seite richtig verstehe, statisch die Sicherheit von Typen und Funktionen festlegen und mithin die Sicherheit darauf aufbauender Typen und Funktionen berechnen. Das ist nicht äquivalent zur Sicherheit von Code im Allgemeinen, denn diese bestimmt sich auch aus den verarbeiteten Daten, welche je nach Szenario als sicher oder unsicher gelten. Unter Berücksichtigung der verarbeiteten Daten ist die Sicherheit von Code allerdings per se nicht berechenbar, und mithin nur sehr schwierig zu beweisen. Für einen Browser ist Safe Haskell mithin nicht genug, es braucht trotzdem eine Sandbox, denn die meisten Sicherheitsrichtlinien wie die Same Origin Policy betreffen nicht Funktionen oder Typen generell, sondern die von Funktionen verarbeiteten Daten.

[0x1cedd1ce]

Python in Browsern finde ich eine schlechte idee. Da der Pythonsyntax Whitespaces zwingend benötigt kann man ein Python-Skript nicht so einfach komprimieren wie ein js-Skript. Das führt zu größeren Datenaufkommen und daher auch zu längeren Ladezeiten und größeren Serverkosten.

[Leonidas]

Python in Browsern finde ich eine schlechte idee. Da der Pythonsyntax Whitespaces zwingend benötigt kann man ein Python-Skript nicht so einfach komprimieren wie ein js-Skript. Das führt zu größeren Datenaufkommen und daher auch zu längeren Ladezeiten und größeren Serverkosten.

Öhm, du kennst aber schon gzip?

[BlackJack]

@webskipper: Noch mal zu den Apps: Bei HTML5 kann man zu einer Webseite ein „Manifest“ angeben wo drin steht welche Dateien dauerhaft lokal gecachet werden müssen, damit die Seite auch offline funktioniert. Siehe http://diveintohtml5.info/offline.html

Mit `window.localStorage()` und in Chrome „Web SQL Storage“ kann eine App auch lokal persistente Daten speichern.

[sma]

Leonidas, eine neue Technologie parallel zu anderen anzubieten - zudem wenn noch geschützt durch "vendor prefixes" - ist unkritisch und etwas anderes, als nach dem "embrace, extend, extinguish"-Prinzip eine vorhandene Standard-Technologie (ECMAScript) zu erweitern, um die Kontrolle darüber zu bekommen und die anderen auszubooten. Das würde man ihnen garantiert vorwerfen, und sei es nur deswegen, damit der eigene Browser (z.B. im Fall von Microsoft) nicht relativ gesehen schlechter wird.

ECMA-Bytecode hätte IMHO eine höhere Chance gehabt, als Dart, welches wohl eine Chrome-spezifische Sache bleiben wird. Bei SPDY ist es offenbar so, dass die Vorteile zu überzeugend sind - das Mozilla in den mehr oder weniger sauren Apfel beißt. Gegen Dart sind sie jetzt jedenfalls erst mal alle.

Gegen NaCl übrigens auch. Hier ist aber der Vorteil, dass dies eine von vielen Spieleherstellern sehnsüchtig erwartete Technologie ist und aus dem Wissen, das auf mobilen Geräten das meiste Geld mit Spielen gemacht wird, hoffen sie (zu recht) auf einen neuen Markt, wo es relativ egal ist, dass sie "nur" 200 Mio Chrome-User als potentielle neue Kunden gewinnen. Wenn das Spiel nur überzeugend genug ist, werden die Nutzer schon Chrome installieren und dann hat auch Google gewonnen und Mozilla verloren. So kann es durchaus sein, dass auch Mozilla irgendwann gezwungen ist, NaCl zu unterstützen - oder unter zu gehen. Ich denke nicht, dass Microsoft reagieren wird, sondern hier muss Google mit ChromeFrame versuchen eine Lösung zu bieten.

Und ja, man kann mit NaCl + Pepper theoretisch andere Scriptsprachen in den Browser ziehen, doch das fühlt sich nach wie vor wie ein Plugin an - was es ja auch ist. AFAIK kann man so eine Sprache nicht als "web facing"-Language realisieren, die auf ein <script>-Element im HTML anspricht.

Webskipper, Safari nennt es Erweiterungen. Chrome übrigens auch. Apps nennt es eigentlich nur Apple und liebend gerne hätten die sich den Begriff bestimmt geschützt Jetzt wird er für alles, was man (lokal) installieren und ausführen kann benutzt und zusammen mit Web sogar für die Art von Anwendungen, die etwas bessere Webseiten sind.

Du sagt etwas von Hosted Apps, aber sind die das nicht alle? Ob das Betriebssystem nun Chrome oder Windows oder OS/X heißt, dieses System hostet die App. Und ob nun ein Betriebssystem (wie Chrome) als App in einem anderen Betriebssystem gehostet wird, ist doch egal. So könnte man sagen, dass OS/X noch mal unter Mach läuft. Oder was ist mit Java- und .NET-Apps, die eine VM mit Laufzeitumgebung als "Betriebsystem haben"?

Kann "Safe Haskell" das Halteproblem lösen? Kann es sicherstellen, dass nicht unbegrenzt Ressourcen verbraucht werden? Als muss man auch hier ein Sandbox haben, die sicherstellt, dass amoklaufende Programme nicht den Rest mitreissen.

Stefan

[webskipper]

Du sagt etwas von Hosted Apps, aber sind die das nicht alle? Ob das Betriebssystem nun Chrome oder Windows oder OS/X heißt, dieses System hostet die App. Und ob nun ein Betriebssystem (wie Chrome) als App in einem anderen Betriebssystem gehostet wird, ist doch egal.

Ich sehe da schon einen Unterschied, ob ich eine App rein lokal, mixed oder rein remote betreibe. Man kann den Begriff "App" als Obermenge nehmen, nur darf man nicht vergessen, dass der Begriff aus der Offline-Welt stammt. Und meinem Vater, geschweige denn Großvater brauche ich das gar nicht mehr erklären, die kommen da nicht mehr mit, wenn Sie in Chrome eine "App" aufrufen und das ist nichts weiter als ein Link.

Im Übrigen sehe ich im Sandboxing für Python kein Problem. Ich erwarte nicht, dass der volle Funktionsumfang verfügbar ist, aber Sockets und Sandboxes sind nicht unbedingt ein Widerspruch. Es kommt darauf an, was man machen will.

[Leonidas]

Ich erwarte nicht, dass der volle Funktionsumfang verfügbar ist, aber Sockets und Sandboxes sind nicht unbedingt ein Widerspruch. Es kommt darauf an, was man machen will.

Das habe ich auch nicht gemeint. Aber wenn ECMAScript keine Sockets aufmachen kann (also aus Webseiten raus, aus Erweiterungen geht das natürlich schon), dann wird Python dies auch nicht von den Browser-Herstellern erlaubt bekommen.

[sma]

nur darf man nicht vergessen, dass der Begriff aus der Offline-Welt stammt. Und meinem Vater, geschweige denn Großvater brauche ich das gar nicht mehr erklären, die kommen da nicht mehr mit, wenn Sie in Chrome eine "App" aufrufen und das ist nichts weiter als ein Link.

Ah, da kommt das Missverständnis. Erweiterungen für Chrome sind Apps in deinem Sinne, denn sie laufen lokal im Browser und können auch offline funktionieren, wenn das der Autor so will.

Du findest Erweiterungen für Chrome in dessen App Store, aber nicht alle Apps dort sind Erweiterungen. Und nicht alles, was dort als App bezeichnet wird, ist ein Link. Angry Birds z.B. läuft bei mir lokal. Der App Store von Chrome ist ein Sammelsurium von Links auf klassische Webapps, auf Flash-Apps, auf Chrome-Extensions und auf NaCl-Apps, die wiederum für Chrome wie Extensions aussehen. Außerdem hat der Webstore auch noch Themes für Chrome oder könnte auf Java-Applets oder Silverlight-Apps verweisen, wenn denn diese noch beliebt wären.

Im Übrigen sehe ich im Sandboxing für Python kein Problem. Ich erwarte nicht, dass der volle Funktionsumfang verfügbar ist, aber Sockets und Sandboxes sind nicht unbedingt ein Widerspruch. Es kommt darauf an, was man machen will.

CPython ist ein ziemlich großes Projekt mit einem nicht trivialen Build-Process. Wenn man da eingreifen will und wirklich verstehen will, was da passiert und den ganzen low-level-Kram auf Peper portieren will, ist das nichts, was in ein paar Stunden geschafft ist (möglicherweise hat's aber schon jemand mal als Beispiel für NaCl gemacht). Was Sockets angeht: NaCl kann AFAIK nur durch das Peper-API mit der Außenwelt kommunizieren. Dort kann man glaube ich HTTP-Requests abschicken, aber reine Socket-Verbindungen sind nicht möglich. Bei HTTP gilt dann bei nicht-lokalen Apps garantiert auch noch die Same-Origin-Policy.

Stefan

[Dav1d]

Python im Browser … als JavaScript!

https://github.com/kripken/emscripten/wiki

[Leonidas]

https://github.com/kripken/emscripten/wiki

Das hat doch sma längst erwähnt...

Aber was anderes, weil das an mir vorbeigescrollt ist:

Ich fände ja, es wäre nett gewesen, JavaScript, ähm, ECMAScript zu einem Bytecode weiter zu entwickeln, der diese aber auch andere interessante Sprachen effizient repräsentieren kann und dann eine effiziente virtuelle Maschine dafür zu entwickelt. Das hätte zwar Aufregung aus einer andere Ecke gegeben - von Leuten, die es als den größten Wert sehen, dass JavaScript immer lesbar ist - aber IMHO ist das kein wichtiges Argument und mir die Möglichkeit zu nehmen, meinen Quelltext ggf. zu verstecken, ist keine Freiheit, sondern eine Einschränkung.

Why Not a Bytecode VM? (Google+ Link um dem ganzen etwas mehr Kontext zu geben, Direktlink). Aber ich muss sagen, sonderlich überzeugend finde ich den Artikel ja nicht.

[sma]

Die Argumente überzeugen mich nicht. Ich kann verstehen, dass Dart keinen Bytecode will, weil ein erklärtes Ziel von Dart ist nicht nur eine bessere Sprache als JavaScript, sondern auch bessere Werkzeug-Unterstützung und diese ist natürlich sprachabhängig. Aber genau das schreiben sie nicht.

Stattdessen kommt das Argument, dass die JVM Java-spezifischen Bytecode hat und das doof ist. Wen interessiert hier Java? Es geht um JavaScript. Ich denke, man kann einen Bytecode finden, der effizient JavaScript, Smalltalk und damit auch Ruby oder Python oder auch Scheme, Lisp oder Erlang abbilden kann. Gerade wenn der Bytecode keine Klassen annimmt, sondern Klassen mittels prototypischer Vererbung simulieren kann, ist man schon mal freier, als was die JVM so bietet (JSR 292 mit invokedynamic relativiert diese Aussage glücklicherweise). Da JavaScript keine primitiven Typen und nur einen numerischen Typ kennt, finde ich auch OK, wenn das im Bytecode so abgebildet wird und eben andere Sprachen hier von der Semantik wie JavaScript sein müssen. Ich würde aber einen effizienten BigInteger-Datentyp vorsehen, mit dessen Hilfe man ggf. Brüche oder auch Dezimalzahlen repräsentieren kann - und natürlich unbeschränkt große Ganzzahlen. Eine Optimierung der Endrekursions-Optimierung wäre nett, die CLR von .NET kann das ja auch. Ausnahmen (Conditions), die man erneut aufrufen kann, wären statt der "üblichen" Exceptions zwar Klasse, denn Smalltalk oder auch Dylan oder CommonLisp wollen so etwas haben, aber das ist zur Not auch etwas, auf das man verzichten kann, weil es leider nicht so effizient umsetzbar ist.

Eine Self-VM (und Self war ein Vorbild für JavaScript und deren VM war Vorbild für alle modernen VMs wie die Hotspot-JVM oder V8) kommt mit etwa einen halben Dutzend Befehlen plus vielleicht zwei Dutzend primitiven Operationen aus - eine Smalltalk-VM liegt bei etwa 20 Befehlen, wenn ich's richtig erinnere. Bei Lisp könnte man mit 7 oder so Befehlen auskommen, hat dann aber nix, was praktikabel ist und nur sich selbst ausführen kann - auch dort bräuchte man noch primitive Operationen.

Was das Argument angeht, man braucht nicht nur Bytecode, sondern auch ein Serialisierungsformat: Ja, richtig, aber genau das wollen sie für Dart ja auch definieren, wenn sie von Images (a la Smalltalk) sprechen, also Speicherabzügen mit vorkompilierten Objekten, die man einfach in den Speicher mappen und relokalisieren kann.

Was dem vorgeschlagenen Native-Client-Ansatz fehlt ist IMHO die Einfachheit, mit dem Browser zu interagieren, ohne das man komplizierte Datenstrukturen in C++ verwalten muss.

Auch V8 (oder Dart) werden nicht Quelltext Zeichen für Zeichen in Maschinencode verwandeln, sondern vorher einen AST generieren. Das ist eine andere Art von Bytecode, aber die selbe Idee. Der Bytecode muss (ja sollte nicht) für die Interpretation optimiert sein (wie es beispielweise bei der Variante aus dem legendären Bluebook für Smalltalk-80 oder aber auch bei der JVM gedacht war), sondern für eine effiziente Kompilation und da bietet sich ein serialisierter AST als "Bytecode" an. Der ist nicht schwerer zu verifizieren als der Quelltext, im Gegenteil.

Die Idee, in Quelltext zu kompilieren, hat IMHO einen großen Nachteil, der sich insbesondere bei CoffeeScript zeigt: Die Abstraktion "leckt" und ist durchlässig. Für CoffeeScript muss man nicht nur eine Sprache, sondern zwei kennen, denn ohne JavaScript-Kenntnisse UND das wissen, wie CoffeeScript in JavaScript abgebildet wird, kann man den Kram nicht debuggen und auch nicht mit anderen Bibliotheken interagieren. Zudem ist es komplizierter neue Quelltext-Debugger zu bauen. Hat man Bytecode und eine Abbildung von Bytecode auf Zeilennummern in der Quellsprache, braucht man nur einen universellen Debugger. Zudem gibt es dann keine Zwischenebene, die man kennen müsste, d.h. der Sprachentwickler muss sich hier mehr anstrengen, schafft aber auch keine "leaky abstractions".

Stefan

[burli]

Ich arbeite mich gerade in JavaScript ein... und hoffe jetzt inständig, dass Python bald in allen Browsern verfügbar ist. Allerdings hoffe ich dann auch, dass zumindest die wichtigsten Klassenbibliotheken wie re mitgeliefert werden. Also alles, was im Browser halt Sinn ergibt.