Aus mir nicht genau bekannten Gründen (ich tippe auf IE9-Releasestress) stockt die Publikation meiner HTML5-Artikel im Microsoft-Blog und Working Draft fällt für diese Woche auch aus. Damit ihr euch nicht zu sehr langweilt, empfehle ich dieser Stelle einen einstündigen Talk von David Herman (Mozilla) über die fernere Zukunft von JavaScript, also, das was nach ECMAScript 5 kommt:
Von dem was da erzählt wird funktioniert Stand heute noch kaum etwas in irgendwelchen Browsern, aber die Chancen für eine Standardisierung der Features stehen gut. Falls ihr mehr an funktionierenden Dingen interessiert seid: Ich habe eine Artikelserie zu ES5 in Mache, die schätzungsweise übernächste Woche starten wird. Da gibt dann weniger bahnberechendes, aber dafür schon heute benutzbares.
Kommentare (12)
molily ¶
16. März 2011, 14:59 Uhr
Warum wird dort eigentlich nicht von Harmony geredet? Brendan Eich spricht ja ständig von Harmony, wenn er seine Ideen und Wünsche vorstellt. Ist damit mehr so die Zukunftsrichtung gemeint (so wie HTML5 auch keine feste Version meint)? Also auch das, was erst nach .next kommen könnte? Für .next werden die Features anscheinend schon festgezurrt werden, während andere wohl auf .next.next verschoben werden...?
Peter ¶
16. März 2011, 15:12 Uhr
Gute Frage. Ich habe das bisher so verstanden, dass sowohl mit „Next“ als auch mit „Harmony“ einfach das gemeint ist, was nach ES5 kommt. Denn was immer das sein wird, einen endgültigen Namen und einen fertigen Funktionsumfang hat es ja noch nicht. Die Features aus dem Video decken sich so sehr mit Eichs Harmony-Träumen.
Sven Drieling ¶
18. März 2011, 13:23 Uhr
Warum eigentlich nur JavaScript? Wieso keine Unterstützung für weitere Sprachen, die besser als JavaScript sind? Warum keine VM, kein AST im Webbrowser auf dem sich beliebige Sprachen abbilden lassen?
Es gibt zwar zahlreiche x nach JavaScript-Compiler aber richtig gut geeignet ist JavaScript dazu nicht.
Peter ¶
18. März 2011, 13:41 Uhr
Meinst du nicht dass JS reicht? Und es sowohl Browser- als auch Webentwicklung schon kompliziert genug sind? Mal ganz abgesehen davon, dass sich die Browserhersteller auf eine neue gemeinsame Technologie einigen müssen, was ja auch schon mal schief gehen kann (siehe HTML5 Video/Audio).
Sven Drieling ¶
18. März 2011, 15:35 Uhr
Zitat Peter:
Nein, weil z.B. CoffeeScript im Gegensatz zu JavaScript Spaß macht.
Weil die JavaScript-Compiler in den Webbrowsern zwar technisch interessant sind, deren Entwicklung aber viel Arbeitszeit verschlingt, was bei einer klaren VM nicht der Fall wäre. Diese gewonnene Zeit könnte dann in die Entwicklung guter Programmiersprachen gesteckt werden.
Weil die Entwicklung von JavaScripts und das Erlernen von JavaScript durch die Schwächen der Sprache mehr Arbeitszeit verschlingt als nötig und man diese Zeit innovativer verwenden könnte, wenn man bessere Sprachen zur Auswahl hätte.
Sprich JavaScript verschlingt sowohl bei der Webbrowserentwicklung als auch bei der Clientseitigen-Scriptentwicklung Zeit, die man besser einsetzen könnte.
Zitat Peter:
Sich aber mehr als lohnen würde, wenn es klappt.
Peter ¶
18. März 2011, 15:50 Uhr
Zitat Sven Drieling:
Meinst du nicht, dass das Ansichtssache ist? Gerade in jüngster Zeit boomt doch das JS-Fantum wie bekloppt. Und JS leidet eigentlich nur darunter, dass es für Zweck A erfunden wurde (kleine Scripts) und heute für Zweck B verwendet wird (monströse Webapps). Mit ES5 und Harmony wird das glaube ich viel besser.
Und du bist ganz sicher dass das am Ende Zeitersparnis gibt? Ich (der ich keine Ahnung von sowas habe – ich kenne ja nicht mal den Unterschied zwischen einer „klaren“ und einer „unklaren“ VM) stelle mir die Entwicklung einer neuen Umgebung recht arbeitsintensiv vor, selbst wenn man sich auf gemeinsame Eckdaten einigen würde. Und vor allen Dingen müsste dieses neue Werk dann auch immer weiter optimiert und gefixt werden – so wie jetzt gerade JavaScript. Klingt für mich nach einem Schritt zurück.
Mit ES5 und Harmony wird das doch schon gleich viel besser. Und die meisten Probleme kann man sich doch mit einem schönen kleinen Framework vom Hals schaffen.
Und wenn nicht? Das letzte große Webbrowser-Rewrite-Projekt war Netscape. Und wie das ausgegangen ist, ist bekannt.
Florian ¶
18. März 2011, 16:34 Uhr
Ich verstehe beides sehr gut.
Einmal, dass Javacript da ist und wir uns alle dran gewöhnt haben, aber auch, wie sehr ich - sogar heute noch, mit guten 10 Jahren Erfahrung in JS - manchmal drauf einschlagen könnte, weil etwas "uninstinktives" passiert.
Gemildert wird dieses Problem um ein gutes Stück durch die allseits beliebten Frameworks, bspw. jQuery, Mootools, Dojo, ....
Wobei genau diese "Allround-Konstruktionen" die Sache aufblähen und unübersichtlich machen ... Seien es komplexe Dateisystemstrukturen, Ajax, Cross-Brower-Fähigkeiten oder ganz banal der Traffic.
Ob und inwieweit JS "unsauber" ist, kann ich nicht beurteilen: bin auch nur ein praktischer Informatiker. Was aber auffällt: JS ist anders aufgebaut als andere OO-Sprachen. Auch wenn das alle paar Jahre als Vorteil - weil streng genommen viel näher an dem theoretischen Ideal [whatsoever] als andere OO-Sprachen - geprisen wird, ist JS ein Ausreißer.
Die Lösung des Problems liegt auf der Hand: die Schnittmenge der guten Frameworks in den ECMA-Standard und damit in die Browser integrieren.
Das passiert ein Stück weit durch ES5 und Harmony, wenn ich das richtig überblicke.
Aber nichts ist umsonst: ECMA-Script ist ein Standard, der zwischen mehreren großen Playern verhandelt wird. Und das dauert dementsprechend lange.
Ich glaube nicht, dass sich die Situation bessert, wenn 8 Scripte auf dem Markt sind, die von 6 Browser-Herstellern stammen.
Das dürfte mitunter auch gar nicht so einfach sein: schau dir an, wie es Google WebM geht -- eins der größten Technologieunternehmen der Erde hat eine neue Lösung für ein bereits gelöstes Problem entwickelt; ob WebM performanter, schöner, billiger oder Sonstwas als JPEG ist, interessiert (noch?) niemanden.
Diese Entwicklung hatten wir nämlich schonmal: Flash ist eine coole Sache. Oder vielmehr: war es, als es neu war.
Beinahe alle coolen Sachen, die in Flash damals neu waren - Text-, Farb-, Grafikfilter, Einbindung von "Webfonts", Audio, Video, ... - kommen gerade nativ in die Browser, das ist schneller, semantischer, kompakter, besser.
Mein Fazit: Abwarten. Und wenns dich in den Fingern juckt: am Standard mitarbeiten, experimentelle Techniken dokumentieren oder deinen eigenen kleinen Beitrag leisten (äquivalent zu Peters Turbine ;))
PS
Hast du mal einen anschaulichen Vergleich des gleichen Skripts zwischen JS und einer theoretischen sauberen Sprache? (Es geht mir nicht ums "Zerdiskutieren", ich weiß, fürchte ich, schlicht noch nicht genau, was eine saubere Sprache ist.)
Peter ¶
18. März 2011, 16:45 Uhr
Zitat Florian:
Wen das ernsthaft stört, der kann problemlos kleinere Frameworks wie zum Beispiel Underscore JS oder einen angepassten Mootools-Build nehmen.
Florian ¶
18. März 2011, 20:51 Uhr
Zitat Peter:
Recht hast du, und das ist reine Sache der Gewöhnung.
Ich persönlich habe wenig Probleme mit umfangreichen Programmierungen.
Wo du aber darauf eingehst: auch das ist ein Argument dafür, die Schnittmenge guter Frameworks mit in ECMA-Script aufzunehmen: Leute, die schon im Thema neu sind, sollten sich nicht noch auch in die Frage, ob und welches Framework sie für ihr Vorhaben benutzen, einarbeiten müssen.
Sven Drieling ¶
19. März 2011, 18:22 Uhr
Zitat Peter:
Weil es bei Programmiersprachen unterschiedliche Vorlieben gibt macht es ja Sinn mehr als eine zur Auswahl zu haben.
Ja, das macht einen guten Eindruck.
Das beginnt ja nicht von null. Die jetzigen JavaScript-Engines könnten sich vielleicht als Grundlage eignen, sie enthalten ja Parser, Syntaxbaum, Codegenerierung eventuell auch einen Zwischencode in der einen oder anderen Form.
Das aufwendiger an den JavaScript-Engines ist ja, dass JavaScript eine sehr dynamische Programmiersprache ist, das macht es schwer sie auf Geschwindigkeit zu trimmen. Wäre interessant mal auszuprobieren, ob eine VM, die zusätzlich auch auf statische Datentypen ausgelegt, innerhalb eines Webbrowsers eine deutlich höhere Geschwindigkeit erzielen kann, so dass sich sowas dann auch wirklich lohnt.
Sven Drieling ¶
19. März 2011, 18:38 Uhr
Zitat Florian:
Bei den Tools die JavaScript generieren kann man sich die Ausgangssprache und den dann generierten JavaScript anschauen. CoffeeScript macht das gleich auf der eigenen Website.
Im Mozilla-Wiki werden zur Erklärung von OOP JavaScript und Java gegenübergestellt.
Bertram Simon ¶
19. März 2011, 18:53 Uhr
Womit wir wieder bei VBScript wären:-D