JavaScript Warum wird JS nicht weiterentwickelt?

[Zeboo]

Hallo Leute, in meine Frage geht es nicht wirklich ums Code sondern ich habe da mal etwas was ich nicht ganz verstehe:

Javascript ist ja die Skriptsprache die sogut wie überall läuft. Vorallem jetzt dank den Tablets und Smartphones boomt es ja (zumindest habe ich das so verstanden, weils eben überall läuft und kombiniert mit html5 + css3 kann man unglaublich gute Sachen entwickeln - was nochmal: überall läuft). Warum steht also (laut Wiki) die Sprache seit 2008 im Ruhestand? Warum wird da nicht ständig was neuentwickelt?

Lese das einige über einen Nachfolger arbeiten (wie Google) aber das ist irrelevant, denn die neue Skriptsprache (wenn sie mal irgendwann fertig ist) wird eh nur auf speziellen Browsern laufen und es wird eh sehr lange dauern bis alle Hersteller mal über die Funktionen einig werden. Damit will ich sagen: um JS kommt man nicht rum. Warum also die Sprache nicht weiterentwickeln? Es gibt sicherlich noch VIEL zu verbessern. Verstehe ich halt irgendwie alles nicht ganz.

Gruß

 

[Hancoque]

Du hast dir die Frage ja eigentlich selbst schon beantwortet:

Lese das einige über einen Nachfolger arbeiten (wie Google) aber das ist irrelevant, denn die neue Skriptsprache (wenn sie mal irgendwann fertig ist) wird eh nur auf speziellen Browsern laufen und es wird eh sehr lange dauern bis alle Hersteller mal über die Funktionen einig werden.

Es spielt keine Rolle, ob es sich um einen Nachfolger oder nur "Weiterentwicklungen" handelt. Das Resultat ist in beiden Fällen, dass ältere Browser damit dann nicht klar kämen und es dann eben auch nicht mehr "überall läuft".

 

[IceMatrix]

Die wird nicht weiterentwickelt, weil sie inperformant und einfach grottig ist (in meinen Worten ausgedrückt).
Wenn man rich media applications entwickeln will (wie z.b. in flash), dann muss etwas effizienteres als javascript her. außerdem verleitet javascript durch seinen sehr freien programmierstil zu schlampigem programmierstil. viel verbessern kannst du an javascript leider auch nicht, weil es abwärtskompatibel sein müsste.

 

[harrysun]

Ein berechtigte Frage und die Antwort ist nicht-technischer Natur.

(Hardware-/Betriebssystem-)Hersteller haben kein Interesse an plattformunabhängiger Software-Entwicklung. Schließlich ist die Bindung/Abhängigkeit an deren Plattform ein erster Schritt für eine Kaufentscheidung und somit (Lizenz-)Gebühren.

Hersteller ohne Marktanteile versuchen über das Thema "Unabhängigkeit" d.h. Initialkosten bei der Entwicklung Anwendungsentwickler für "ihre" Plattform zu gewinnen, um anschließend proprietäre Funktionen anzubieten zu können.

Ohne Differenzierung, d.h. wenn alles gleich wäre, könnten die Hersteller sich nur über den Preis differenzieren. Das möchte jedoch niemand.

Wer nun Java (nicht JavaScript) als Beispiel aufführt, sollte nicht verschweigen, dass vormals Sun Microsystems, Inc. die Verbreitung seiner MIPS basierenden Rechensysteme auf diese Weise unterstützten wollte -- auch wenn oft vom Vorsatz einer Sprache für das Internet gesprochen wird.

Die Bedeutung des Browser als Terminal hätte sich vor ein paar Jahren keiner träumen lassen. Als Antreiber kann hier Google gesehen werden, der als Anbieter von Geschäftsanwendungen ala Office in der Cloud eine passable Lösung gebraucht hatte.

Mit dieser Strategie lassen sich Kunden dazu gewinnen oder die Abwanderung der Kunden verhindern (siehe Office 365 von Microsoft). Eine Bindung des Kunden an eine proprietäre Plattform wird jedoch aus unterschiedlichen Gründen der Hersteller jedoch langfristig ein Ziel bleiben.

 

[geisterfahrer]

Javascript wird weiterentwickelt! Nur sehr langsam. Hier ein kleiner Überblick, was bei der letzten Version so rumkam:
http://www.peterkroener.de/ecmascript5-die-nachste-version-von-javascript-teil-1-ein-uberblick/

 

[ice-breaker]

Ich habe keine Ahnung, wo du deine Informationen her beziehst, aber JavaScript wird weiterentwickelt. In EcmaScript5 gibt es einige Neuerungen.
Und selbst wenn es nicht weiterentwickelt werden würde, gibt es mittlerweile gute Sprachalternativen, die dann direkt nach JavaScript kompilieren: CoffeeScript

Die wird nicht weiterentwickelt, weil sie inperformant und einfach grottig ist (in meinen Worten ausgedrückt).

interessanterweise ist JavaScript mit der V8 die schnellste Scriptsprache, falls ich keine andere übersehen habe.
Und sogar im Serverumfeld, wildert V8, denn mit node.js lassen sich so hochperfomante Server-Anwendungen leicht bauen, da kann PHP und dergleichen nur von träumen.
Natürlich wird Js nie eine Alternative zu typisierten Sprachen sein, aber als Scriptsprache ist sie mit der V8-Implementierung von Google höllisch schnell.

 

[IceMatrix]

Javascript mit V8 ist deshalb die schnellste Scriptsprache, weil da viel Entwicklungsarbeit reingesteckt wurde um an jeder nur möglichen Schraube zu drehen. Gibt aber noch immer diverse Probleme, die sich negativ auf die Performance auswirken und sich so einfach auch nicht lösen lassen. Native Sprachen sind deshalb noch immer ein Vielfaches schneller. Es würde schon viel bringen eine Variante von Javascript mit starker Typisierung zu erstellen.

 

[ice-breaker]

dann kann man auch gleich Java nutzen...

 

[sourcefreak]

Wsa hat den jetzt JAVA mit JavaScript zu tun?

 

[IceMatrix]

@ice-breaker: Java ist aber heavyweight. Und dann kommt Oracle gleich mit der juristischen Keule. Für meine Begriffe ist Java als offener Standard seit der Übernahme von Sun tot.
Ich finds recht interessant wie Google jetzt versucht einen neuen offenen Standard zu etablieren, der diverse Probleme von Javascript beseitigt. Wird zwar trotzdem nicht an native Sprachen rankommen, aber geht in die richtige Richtung.

@sourcefreak: substr("JavaScript", 0, 4) == "Java"

 

[Yuuri]

Wsa hat den jetzt JAVA mit JavaScript zu tun?

Nur den Hype.

Der Name Javascript sei etwas irreführend, aber damit müssten wir leben, sagt Brendan Eich Golem.de. Netscape, bei dem Eich die erste Version von Javascript entwickelte, habe den Hype um Java damals nutzen wollen und sich darum für den Namen Javascript entschieden. Mit Java habe die Skriptsprache aber bekanntlich nie etwas zu tun gehabt. Heute scheine es so, als würde Javascript Java den Rang ablaufen.

@ IceMatrix: Aber sonst nichts.

 

[IceMatrix]

@ IceMatrix: Aber sonst nichts.

Jup. So wars gemeint

 

[carom]

Wird zwar trotzdem nicht an native Sprachen rankommen, aber geht in die richtige Richtung.

Verstehe nicht ganz, was der Vergleich zu nativen Sprachen an dieser Stelle soll. Für dieses Einsatzgebiet kommen eigentlich nur interpretierte Sprachen in Frage, die mit nativen Sprachen niemals mithalten werden können.

 

[ice-breaker]

meine Aussage war einfach, dass wenn man statische Typisierung in JS einbauen würe, man gleich Java/C# verwenden könnte, dabeide Sprachen sich dann kaum noch unterscheiden würden.

 

[IceMatrix]

@carom: Der Vergleich zu nativen Sprachen ist deshalb wichtig, weil der Trend dazu geht Anwendungen nicht mehr nativ zu entwickeln, sondern als Rich Media Applikation im Browser. Ein Beispiel dafür ist Google Mail.

Je nachdem was für eine Applikation das ist wird mehr oder wenige Leistung vom Client benötigt. Und wenn man jetzt auf stark multimedialastige Anwendungen gehen möchte (z.B. 3D-Spiele im Browser) wird eine entsprechend leistungsfähige Programmiersprache benötigt. Eine besondere Rolle spielt das übrigens bei embedded devices (z.b. smartphones), weil die eben deutlich weniger Rechenleistung haben als normale PCs. Wenn du da jetzt z.B. ne native iPhone-App mit einer gleichwertigen Web Application vergleichst merkst du schnell einen enormen Unterschied in der Ausführungsgeschwindigkeit. Darum sollte das Ziel sein eine Programmiersprache fürs Web zu entwickeln, die möglichst nah an die Performance von nativen Applikationen heran kommt. Das tut Javascript aber leider nicht.

 

[ice-breaker]

Wenn du da jetzt z.B. ne native iPhone-App mit einer gleichwertigen Web Application vergleichst merkst du schnell einen enormen Unterschied in der Ausführungsgeschwindigkeit. Darum sollte das Ziel sein eine Programmiersprache fürs Web zu entwickeln, die möglichst nah an die Performance von nativen Applikationen heran kommt. Das tut Javascript aber leider nicht.

Der Vergleich hinkt ja auch gewaltig, damit eine Web-Applikation wie eine echte Applikation aussieht, müssen zig Hacks implementiert werden und die ganze UI nachgebaut werden.
Nimmst du aber z.B. Titanium Mobile, bei dem die Applikationen in JavaScript gebaut werden, die Oberfläche aber durch die nativen Objective-C-Operationen behandelt wird (damit es der exakt gleiche Look&Feel ist), merkst du gar keinen Unterschied.
Auch mit PhoneGap lässt sich ähnliches erreichen, denn da lässt sich eine Webseite in ein echtes App einbinden.

Die Performance von JavaScript ist mehr als ausreichend, es ist nur i.R. nicht gut genug in das System eingebunden, um auch für das Auge gleichwertig schnell zu funktionieren. Ist dieser Schritt aber gemacht, siehst du gar keinen Unterschied mehr, so wie z.B. bei Adobe Air.


Wenn du aber mit Argumenten wie 3D-Spiele in JavaScript kommst, kann man dich wirklich nicht für voll nehmen, denn das ist eine der letzten Anwendungen, die man in JavaScript bauen würde, obwohl es mit WebGL nun natürlich möglich ist.

 

[IceMatrix]

Wenn du aber mit Argumenten wie 3D-Spiele in JavaScript kommst, kann man dich wirklich nicht für voll nehmen, denn das ist eine der letzten Anwendungen, die man in JavaScript bauen würde, obwohl es mit WebGL nun natürlich möglich ist.

Tatsächlich? Es gibt bereits Games dafür. WebGL wurde u.A. aus genau solchen Gründen erst geschaffen. Selbst wenn es "nur" einfache Visualisierungen im Browser sind wird dazu bereits reichlich Leistung benötigt. Google ist sich dem bewusst, und versucht auch genau deswegen jetz auf nativen Code zu setzen. Das ist fürs Web aber schlecht, weil es nicht mehr plattformunabhängig ist.

Adobe Air ist übrigens kein wirklich offener Standard, sondern wieder sehr proprietär angehaucht. Fürs Web eher ungeeignet.

 

[ice-breaker]

Adobe Air ist übrigens kein wirklich offener Standard, sondern wieder sehr proprietär angehaucht. Fürs Web eher ungeeignet.

Es geht hier doch nicht um offene Standards usw.
Ich habe lediglich anhand einiger Beispiele deine unbegründete Aussage, dass JavaScript grottenlangsam sei widerlegt. Und Adobe AIR ist da eben ein gutes Beispiel.
Und die V8-Engine zeigt ja, dass es noch eine ganze Ecke performanter geht, RIAs sind da absolut kein Problem, und irgendwann wird auch jemand so intelligent sein und V8 mit GUIs für Desktop-Programme koppeln.

 

[harrysun]

Die Entwicklung von Desktop-Anwendungen auf Basis der RIA Technologien wird sich für mein dafürhalten deshalb ergeben, weil der Markt für Arbeitskräfte günstigere (weil mehr) Web-Entwickler hervorbringt wie geschulte Windows Presentation Foundation oder Forms "künstler" in C#.
Der Trend mit Windows 8 Metro Richtung Web-Technologien und C/C++ (WinRT) zeigt für mich die Einsicht, dass Silverlight / Flash & Co. langfristig ein Nischendasein fristen werden.

 

[carom]

@carom: Der Vergleich zu nativen Sprachen ist deshalb wichtig, weil der Trend dazu geht Anwendungen nicht mehr nativ zu entwickeln, sondern als Rich Media Applikation im Browser. Ein Beispiel dafür ist Google Mail.

Genau. Die Zielvorgabe lautet aber dann eher, die schnellst mögliche interpretierte (oder aus anderen Gründen plattformunabhängige) Technologie zu finden, und nicht die, die nativen Sprachen möglichst in nichts nachsteht. Das sind 2 Paar Schuhe.
Mit anderen Worten: du kannst Javascript anlasten, dass es nicht für alle Webanwendungen schnell genug ist (was aber ein anderes Thema ist), du kannst aber nicht anlasten, dass es mit nativen Technologien nicht mithalten kann.
Sprachen, die für Webanwendungen in Frage kommen, werden sich immer den Limitationen eines Interpreters o.ä. beugen müssen. Ziel ist also, diese Sprachen/Interpreter so schnell wie nur möglich zu machen. Und wenn man diesem Ziel erfolgreich nachgeht, dann ist es egal, ob nativer Code immer noch zig mal schneller sein wird, es hilft doch nichts. Der Vergleich ist nutzlos.