Ist JavaScript eurer Meinung nach die ideale Scriptsprache für Clientseitigen Programmcode für den Browser?



  • Meine Meinung schrieb:

    Mr Meinung schrieb:

    Was wäre wenn Frage schrieb:

    Bei der Frage geht es um eine "Was wäre Wenn Frage".
    Denn natürlich ist Javascript faktisch heute ideal, weil es eben jeder Browser versteht, aber das meine ich nicht.

    Sondern ich meine, als man sich überlegt hat, Scriptfähigen für Webseiten auf Browsern einzuführen, ob nicht eine andere Sprache dafür besser geeignet gewesen wäre.

    Javascript ist so gut wie jede andere Sprache auch,

    Das glaubst du doch selber nicht.

    JavaScript ist verglichen mit anderen Sprachen wenig durchdacht bzw. schlecht designed.
    Und aufgrund eines Fehlens eines Klassenbasierten Programmierparadigmas, wie man es von C++, Java, C# usw. kennt, ist die Sprache selbst auch ein ziemlicher Fremdköper für die breite Masse der Progammierer, denn die programmieren in der Regel in C++, Java, C# usw. und nutzen Klassen.

    JavaScript ist gewöhnungsbedürftig, aber wenn man sich erstmal dran gewöhnt hat, finde ich sie durchaus mächtig und elegant. Ich vermisse sowas wie C++ im Browser sicher nicht, und vom Konzept her ist JavaScript völlig in Ordnung, man kann damit sehr sauber und elegant programmieren. Wenn du sagst, die Sprache ist wenig durchdacht, würde ich behaupten, du hast sie nicht richtig verstanden.



  • Mechanics schrieb:

    Meine Meinung schrieb:

    Mr Meinung schrieb:

    Was wäre wenn Frage schrieb:

    Bei der Frage geht es um eine "Was wäre Wenn Frage".
    Denn natürlich ist Javascript faktisch heute ideal, weil es eben jeder Browser versteht, aber das meine ich nicht.

    Sondern ich meine, als man sich überlegt hat, Scriptfähigen für Webseiten auf Browsern einzuführen, ob nicht eine andere Sprache dafür besser geeignet gewesen wäre.

    Javascript ist so gut wie jede andere Sprache auch,

    Das glaubst du doch selber nicht.

    JavaScript ist verglichen mit anderen Sprachen wenig durchdacht bzw. schlecht designed.
    Und aufgrund eines Fehlens eines Klassenbasierten Programmierparadigmas, wie man es von C++, Java, C# usw. kennt, ist die Sprache selbst auch ein ziemlicher Fremdköper für die breite Masse der Progammierer, denn die programmieren in der Regel in C++, Java, C# usw. und nutzen Klassen.

    JavaScript ist gewöhnungsbedürftig, aber wenn man sich erstmal dran gewöhnt hat, finde ich sie durchaus mächtig und elegant. Ich vermisse sowas wie C++ im Browser sicher nicht, und vom Konzept her ist JavaScript völlig in Ordnung, man kann damit sehr sauber und elegant programmieren. Wenn du sagst, die Sprache ist wenig durchdacht, würde ich behaupten, du hast sie nicht richtig verstanden.

    http://www.heise.de/developer/meldung/Google-tueftelt-an-Sprache-fuer-Webprogrammierung-1341328.html

    http://www.tamagothi.de/2011/09/13/warum-javascript-unbrauchbar-ist/

    http://blog.jodies.de/2005/03/javascript-mist/



  • Mechanics schrieb:

    JavaScript ist gewöhnungsbedürftig, aber wenn man sich erstmal dran gewöhnt hat, finde ich sie durchaus mächtig und elegant. Ich vermisse sowas wie C++ im Browser sicher nicht, und vom Konzept her ist JavaScript völlig in Ordnung, man kann damit sehr sauber und elegant programmieren. Wenn du sagst, die Sprache ist wenig durchdacht, würde ich behaupten, du hast sie nicht richtig verstanden.

    Vom Konzept her... vermutlich.
    Was mir abgeht sind Funktionen in der Standard-Library (bzw. den vordefinierten Prototypen).

    Mir letztens aufgefallen: es gibt nichtmal ne Funktion mit der man einen Datetime Wert vernünftig formatieren kann (vernünftig = Format selbst definierbar).
    Vermutlich fehlen noch 1000 andere Sachen die jede andere noch-so-schmalspurige Standard-Library mitbringt.

    Das führt zu unnötig viel Fehlern (weil's jeder Code-Monkey selber programmiert, oder den schlechtesten verfügbaren Code von jmd. anderem kopiert), und zu unnötig viel Traffic, weil die ganzen Implementierungen immer übertragen werden müssen.



  • Helium schrieb:

    Meiner Meinung nach wäre es sinnvoll, wenn es eine Bytecoe VM wie die Java VM oder die CLR im Browser gäbe (natürlich nicht so groß). Man könnte beliebige Sprachen verwenden, die vorher in diesen Bytecode compiliert werden.

    👍



  • Ich finde JavaScript nicht so schlecht. Klar gibt es schlechte Seiten und man würde heutzutage vermutlich einiges anders machen. Aber gerade die Art der OOP passt viel besser zu einer kleinen Skriptsprache. Komplexe Klassenhierachien wären da einfach viel zu kompliziert und bist vor kurzem wurde JavaScript noch komplett interpretiert, damit wären also größere Dinge eh ausgeschlossen worden. Wer auf Java-like Klassenhierachien steht, kann ja Dart verwenden. Und schwer zu lernen ist JavaScript wirklich nicht.

    Ganz interessant zu dem Thema: https://www.youtube.com/watch?v=hQVTIJBZook



  • Helium schrieb:

    Meiner Meinung nach wäre es sinnvoll, wenn es eine Bytecoe VM wie die Java VM oder die CLR im Browser gäbe (natürlich nicht so groß). Man könnte beliebige Sprachen verwenden, die vorher in diesen Bytecode compiliert werden.

    Aktuelle Browser compilieren javascript in Bytecode um die Ausfuehrung zu beschleunigen. Leider ist diese VM nicht standardisiert. Aber Javascript ist standardisiert, so dass einige Sprachen fuer Web/Browser nach javascript compilieren.



  • knivil schrieb:

    Helium schrieb:

    Meiner Meinung nach wäre es sinnvoll, wenn es eine Bytecoe VM wie die Java VM oder die CLR im Browser gäbe (natürlich nicht so groß). Man könnte beliebige Sprachen verwenden, die vorher in diesen Bytecode compiliert werden.

    Aktuelle Browser compilieren javascript in Bytecode um die Ausfuehrung zu beschleunigen. Leider ist diese VM nicht standardisiert. Aber Javascript ist standardisiert, so dass einige Sprachen fuer Web/Browser nach javascript compilieren.

    JavaScript wird doch mittlerweile JIT kompiliert. Machen die da wirklich vorher noch Bytecode raus? Klingt ineffizient.



  • rüdiger schrieb:

    knivil schrieb:

    Helium schrieb:

    Meiner Meinung nach wäre es sinnvoll, wenn es eine Bytecoe VM wie die Java VM oder die CLR im Browser gäbe (natürlich nicht so groß). Man könnte beliebige Sprachen verwenden, die vorher in diesen Bytecode compiliert werden.

    Aktuelle Browser compilieren javascript in Bytecode um die Ausfuehrung zu beschleunigen. Leider ist diese VM nicht standardisiert. Aber Javascript ist standardisiert, so dass einige Sprachen fuer Web/Browser nach javascript compilieren.

    JavaScript wird doch mittlerweile JIT kompiliert. Machen die da wirklich vorher noch Bytecode raus? Klingt ineffizient.

    Was willst du denn sonst JIT kompilieren wenn nicht den Bytecode? einen AST? 😕 🙄



  • gastantwort schrieb:

    rüdiger schrieb:

    knivil schrieb:

    Helium schrieb:

    Meiner Meinung nach wäre es sinnvoll, wenn es eine Bytecoe VM wie die Java VM oder die CLR im Browser gäbe (natürlich nicht so groß). Man könnte beliebige Sprachen verwenden, die vorher in diesen Bytecode compiliert werden.

    Aktuelle Browser compilieren javascript in Bytecode um die Ausfuehrung zu beschleunigen. Leider ist diese VM nicht standardisiert. Aber Javascript ist standardisiert, so dass einige Sprachen fuer Web/Browser nach javascript compilieren.

    JavaScript wird doch mittlerweile JIT kompiliert. Machen die da wirklich vorher noch Bytecode raus? Klingt ineffizient.

    Was willst du denn sonst JIT kompilieren wenn nicht den Bytecode? einen AST? 😕 🙄

    Warum nicht???



  • Ob man irgendeinen Zwischencode verwendet oder nicht ist mMn. ziemlich egal. So lange man sich nicht an eine Spezifikation für einen ganz bestimmten Bytecode halten muss würde ich das als Implementierungsdetail ansehen.



  • Mechanics schrieb:

    gastantwort schrieb:

    rüdiger schrieb:

    knivil schrieb:

    Helium schrieb:

    Meiner Meinung nach wäre es sinnvoll, wenn es eine Bytecoe VM wie die Java VM oder die CLR im Browser gäbe (natürlich nicht so groß). Man könnte beliebige Sprachen verwenden, die vorher in diesen Bytecode compiliert werden.

    Aktuelle Browser compilieren javascript in Bytecode um die Ausfuehrung zu beschleunigen. Leider ist diese VM nicht standardisiert. Aber Javascript ist standardisiert, so dass einige Sprachen fuer Web/Browser nach javascript compilieren.

    JavaScript wird doch mittlerweile JIT kompiliert. Machen die da wirklich vorher noch Bytecode raus? Klingt ineffizient.

    Was willst du denn sonst JIT kompilieren wenn nicht den Bytecode? einen AST? 😕 🙄

    Warum nicht???

    Langsam, keine vernünftigen Optimierungsmöglichkeiten, keine sinnvolle Abstraktion verschiedener Architekturen, etc. pp. Hat schon einen Grund warum alle Compiler eine Zwischensprache verwenden, egal ob statisch oder JIT. Und die die es nicht tun gammeln in der Performanz von Javascript anno 1999 rum (die wohl wahrscheinlich tatsächlich reine Text -> Befehl interpreter waren).



  • Helium schrieb:

    Meiner Meinung nach wäre es sinnvoll, wenn es eine Bytecoe VM wie die Java VM oder die CLR im Browser gäbe (natürlich nicht so groß). Man könnte beliebige Sprachen verwenden, die vorher in diesen Bytecode compiliert werden.

    +1



  • Wie wäre es sich zurückzubesinnen und ungescriptete WEbseiten zu erstellen?
    Ohne NoScript trau ich mich garnichtmehr ins Internet, traurig.



  • Vermutlich recht langweilig und rückschrittlich.



  • gastantwort schrieb:

    rüdiger schrieb:

    knivil schrieb:

    Helium schrieb:

    Meiner Meinung nach wäre es sinnvoll, wenn es eine Bytecoe VM wie die Java VM oder die CLR im Browser gäbe (natürlich nicht so groß). Man könnte beliebige Sprachen verwenden, die vorher in diesen Bytecode compiliert werden.

    Aktuelle Browser compilieren javascript in Bytecode um die Ausfuehrung zu beschleunigen. Leider ist diese VM nicht standardisiert. Aber Javascript ist standardisiert, so dass einige Sprachen fuer Web/Browser nach javascript compilieren.

    JavaScript wird doch mittlerweile JIT kompiliert. Machen die da wirklich vorher noch Bytecode raus? Klingt ineffizient.

    Was willst du denn sonst JIT kompilieren wenn nicht den Bytecode? einen AST? 😕 🙄

    Jop. Und so scheint V8 auch implementiert zu sein https://code.google.com/p/v8/issues/detail?id=301

    SpiderMonkey nutzt wohl Bytecode. https://developer.mozilla.org/En/SpiderMonkey/Internals/Bytecode



  • Da steht nur dass V8 native Code erzeugt. Ob dazu aus dem AST erstmal irgendwelche Zwischenformen gebaut werden, die man als Bytecode bezeichnen könnte wenn man unbedingt wollte, lässt sich da für mich nicht rauslesen.



  • hustbaer schrieb:

    die man als Bytecode bezeichnen könnte wenn man unbedingt wollte

    🙄 ...



  • http://techon.nikkeibp.co.jp/article/HONSHI/20090106/163617/ schrieb:

    V8 does not convert the source into this intermediate language, instead generating machine language directly from the abstract syntax generated by the JavaScript server, and executing it.



  • rüdiger schrieb:

    hustbaer schrieb:

    die man als Bytecode bezeichnen könnte wenn man unbedingt wollte

    🙄 ...

    Ja Freund rüdiger das 🙄 geb ich dir zurück.

    "gastantwort" hat die Sache aufgebracht, und nach meiner Interpretation seines letzten Beitrags meint er genau das, also einfach eine Darstellung in etwas "praktischerem" als einem AST, die im Compiler/Optimizer/Code-Generator verwendet wird weil man damit einfach besser arbeiten kann.

    Lies seine Beiträge nochmal, geht denke ich ziemlich klar daraus hervor.

    gastantwort schrieb:

    Hat schon einen Grund warum alle Compiler eine Zwischensprache verwenden, egal ob statisch oder JIT.

    Und wie gesagt: ich kann nirgends herauslesen dass V8 sowas nicht verwenden würde.

    Dass es fraglich ist das dann als Bytecode zu bezeichnen ist ne andere Sache, deswegen schreib ich ja auch "könnte wenn man unbedingt wollte".

    Mir einen 🙄 hinzuknallen weil ich versuche ein (von mir vermutetes) Missverständnis aufzuklären ist aber auch 🙄.

    Und natürlich auch ganz grosses Kino: 🙄 ohne Erklärung was denn nun daran so 🙄 ist.

    Bis 🙄 dann



  • Was regst Du Dich so auf? Das steht ziemlich klar, dass da kein Bytecode generiert wird und das Zitat im Beitrag von Zeus macht es auch nochmal ziemlich klar. Nicht jede Zwischenrepräsentation ist ein Bytecode und es ist eigentlich ziemlich klar, was ein Bytecode ist. Also warum sollte man nun irgend etwas als Bytecode interpretieren wollen, wenn es nicht einmal die Entwickler machen? Gastantwort hat in dem von mir zitierten Beitrag auch nur von Bytecode gesprochen. Typisch sinnloses Foren "ich ändere Definitionen, bis ich recht hab"-Gehampel können wir uns sparen. Daher das 🙄


Anmelden zum Antworten