Ich glaube, der Golem-Artikel basiert auf einem Link aus HackerNews (dort habe ich ihn jedenfalls gesehen) auf eine Diskussion auf der Webkit-Mailing-Liste und dort war das Ergebnis das genaue Gegenteil der Meldung. Google hat angefragt, ob man doch nicht einen offiziellen Webkit-Branch machen könnte, in dem sie ausprobieren können, was man ändern müsste, damit WebKit nicht nur verschiedene JavaScript-Engines unterstützt, sondern mehrere parallele Engines, also z.B. JavaScript und Dart. Natürlich könnte man dann auch auf ähnliche Weise Engines für weitere Sprachen integrieren. Die Stimmung auf der Liste war aber eisig und der Vorschlag wurde vehement abgelehnt, sodas Google jetzt einen Fork von Webkit macht und dort die Integration von Dart vorantreibt.
Somit wäre Python wenn überhaupt nur in Chrome bzw. Chromium als "web facing language" denkbar, nicht aber in Safari und andere Webkit-basierten Browsern - und sowieso nicht in Gecko-basierten Browsern, dem IE oder Opera.
Wäre es überhaupt wünschenswert? Die Webkit-Entwickler sagten ganz klar nein. VBScript hat gezeigt, dass die Idee scheiße war und immer noch ist und es darf keine Sprache neben ECMAScript (nicht JavaScript, das ist ja nur ein Trademark von Oracle) geben.
Alle Hersteller von Browsern zu zwingen, diverse Programmiersprachen zu unterstützen, wäre IMHO wirklich nicht erstrebenswert. Dann bitte lieber ein so gutes ECMAScript wie irgend möglich.
Doch wenn man Webkit als Rendering Engine und GUI betrachtet, wäre es schon nett, wenn man andere Sprachen als JavaScript effizient zur Verfügung hätte und nicht auf solch komische Workarounds wie Titanium Desktop (was glaube ich tot ist) zurückgreifen müsste und immer noch JavaScript als Glue-Code irgendwo hat.
Den Vorschlag, man könnte ja entweder den Quelltext in JavaScript kompilieren oder LLVM-Maschinencode mittels EmScripten kompilieren, finde ich auch nicht wirklich erstrebenswert, weil man dadurch a) immer nur Sprachen haben kann, die semantisch sehr ähnlich zu JavaScript sind oder b) extrem langsam ausgeführt werden. Das ist Stillstand, kein Fortschritt.
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.
Interessant zu wissen wäre, wie die Python "sandboxen" wollen? Schmeißt man alle IO-Mechanismen raus? Geht das so einfach? Kann man 3rd Party Module einbinden?
Das ist noch einmal eine ganz andere - interessante - Fragestellung und ein Punkt, warum JavaScript (ähnlich wie Lua es wäre) so eine tolle Sprache für den Browser ist - ECMAScript beschreibt wirklich nur die Sprache und ein minimales Laufzeitsystem, keine umfangreichen Bibliotheken.
Bei Python würde ich sagen, ja, man lässt alle Bibliotheken weg und nur wenige ausgewählte zu. Die App Engine hat ja schon gezeigt, wie man Python-Sandboxen kann, aber bei einem Browser würde ich noch viel radikaler vorgehen. Insbesondere wäre es wohl ausgeschlossen, C-Erweiterungen einzubinden. Doch auch threading muss man weglassen und wohl (aus Effizienz und Sicherheitsgründen) viel der reflektiven Möglichkeiten von Python.
Im Prinzip landet man dann glaube ich bei etwas wie CoffeeScript, aber mit einfacherer Syntax und ohne anonyme Funktionen. Könnte eine nette Sprache sein. Oder auch nicht, weil ohne leichtgewichtige Funktionen wäre es Hölle, den im Browser notwendigen asynchronen Programmierstil für Events durchzuhalten.
Ich wär ja schon mal froh, wenn Google endlich mal aktuelles JavaScript implementieren würde in ihrem Browser
Falls du aktuelles ECMAScript meinst, und das wäre Version 5, dann wüsste ich nicht, was in V8 da fehlt. Zugegeben haben sie noch nicht alle Features von Version 5.1 (oder 6, mal sehen, wie das heißen wird) umgesetzt, aber der Standard wird ja wohl auch erst in einem Jahr verabschiedet. Falls du die propritären Erweiterungen von Mozilla in IrgendwasMonkey meinst, das ist nicht, was man unter Standard-JavaScript aka -ECMAScript versteht, sondern ein Experiment von Mr. Eich und Co, wo sie schon mal ausprobieren, was der zukünftige Standard können sollte und das lässt man ihm und keinem anderen nur deswegen durchgehen, weil er die Sprache mal erfunden hat. Würde Microsoft, Google oder Apple einfach mal ihre JavaScript-Engine erweitern, garantiere ich, wäre der Aufschrei groß.
Und diese Apps sind auch nur Webseiten. In meinen Augen eine sehr unglückliche Wortwahl seitens Google.
Aus irgendeinem Grund, der sich mir nicht erschließt, wird hier der größte Vorteil als Nachteil hingestellt. Es ist unglaublich einfach, Chrome in Grenzen (wie übrigens auch Safari und Firefox und vielleicht auch Opera und IE, doch da kenne ich mich mal wieder nicht aus) um mehr oder weniger sinnvolle Funktionen zu erweitern. Firefox und Safari gehen hier noch deutlich weiter und Chrome ist sehr konservativ in dem was möglich ist, damit man sich als Nutzer nicht leichtfertig Schadsoftware einfängt.
Stefan
Aber wie soll genau die Schnittstelle zwischem dem DOM und Python dann aussehen?