Wäre eine statisch typisierte Alternative zu JavaScript auf Webseiten praktisch?

9

Die Präferenz für dynamisches und statisches Tippen ist weitgehend Geschmackssache, und verschiedene Menschen finden sie in verschiedenen Situationen mehr oder weniger geeignet.

Meine Frage ist, wäre es technisch möglich, eine statisch typisierte Alternative zu JavaScript für die clientseitige Webseitenerweiterung usw. zu haben?

Armand
quelle
3
Warum nicht? `` ``
Josh K
2
Sprechen Sie über eine hypothetische statisch typisierte Sprache, die jeder Browser implementieren müsste, oder über bereits vorhandene Möglichkeiten?
user281377
2
Sie könnten Java-Applets verwenden, nehme ich an.
David Thornley
@ammoQ das, das Sie erwähnen, hypothetisch
Armand
@ Josh, ich weiß es nicht. @ David LOL, danke dafür!
Armand

Antworten:

22

Es gibt sicherlich keinen technischen Grund, warum so etwas nicht existieren könnte. Es gibt nichts besonders über clientseitigen Code , dass Mandate die Verwendung von dynamisch typisierten Sprachen.

GroßmeisterB
quelle
1
Dart verfügt über eine optionale statische Typisierung, wird jedoch mit normalem Javascript kompiliert. www.dartlang.com
Nishant George Agrwal
16

Da es sehr unwahrscheinlich ist, dass eine andere Sprache breite Akzeptanz findet, ist es am besten, eine statisch typisierte Version von JavaScript (dh eine Sprache in der Nähe von Java) und einen Präprozessor zu erstellen, der diese in normales JavaScript konvertiert.

Zum Beispiel sieht Ihr Skript so aus:

<script type="text/staticjavascript">
   String foobar(int foo, String bar) {
      String result="";
      for (int i=0; i<foo; i++) {
         result += bar;
      }
      return result;
   }
</script>

und der Präprozessor überprüft, ob jede Variable, Funktion, jedes Objekt usw. entsprechend ihrem Typ korrekt verwendet wird, und ändert das Skript in

<script type="text/javascript">
   function foobar(foo, bar) {
      var result="";
      for (var i=0; i<foo; i++) {
         result += bar;
      }
      return result;
   }
</script>

was jeder Browser handhaben kann.

user281377
quelle
5
+1 für einen pragmatischen Ansatz
Gary Rowe
In dieser Frage geht es wirklich nicht um Pragmatismus, sondern um Theorie. Werde Dich auf dem Laufenden halten.
Armand
2
Ich würde auch vorschlagen, Typinferenz zu verwenden.
Oliver Weiler
Hilfsmethode: Sehr guter Vorschlag, aber ich ändere mein Beispiel jetzt nicht, da durch Typinferenz die statische Version der dynamischen Version sehr ähnlich wäre, da das Beispiel so einfach ist.
user281377
4
Ich denke nicht, dass ein statisch typisiertes Javascript Java sehr nahe kommt, außer syntaktisch. Javascript und Java weisen viele Unterschiede auf, die über die statische und dynamische Typisierung hinausgehen - zum einen klassenbasierte oder prototypbasierte OO. Da Ihr Beispielcode klassenbasiert zu sein scheint, würde ich argumentieren, dass "staticjavascript" eine falsche Bezeichnung für diese Sprache ist und eher als "clientseitiges Java" bezeichnet werden sollte. +1 für das Kompilieren in Javascript (übrigens kompiliert das Google Web Toolkit Java in Javascript).
sepp2k
8

Meine Frage ist, wäre es technisch möglich, eine statisch typisierte Alternative zu JavaScript für die clientseitige Webseitenerweiterung usw. zu haben?

Sicher. Das Google Web Toolkit kompiliert statisch typisiertes Java in JavaScript ... Denken Sie nur daran: die ganze Schönheit und Flexibilität von Java mit der ganzen Leistung von maschinengeneriertem JavaScript!

Im Ernst, Sie könnten dies für alle Arten von Sprachen tun, und viele haben es versucht (es gibt oder gab auch Compiler für C und C #). Ob das Endergebnis praktisch ist oder nicht, hängt davon ab, was Sie erreichen möchten: Google sucht nach einer konsistenten Plattform für die Entwicklung sehr großer clientseitiger Apps und verfügt über eine eigene JavaScript-Engine zum Booten. Sie werden vielleicht feststellen, dass die Übernahme eines solchen Tieres für Hover-Effekte und den seltsamen AJAX-Aufruf weitaus mehr Schmerzen verursacht, als nur zu lernen, mit ein bisschen untypisiertem Code zu leben ...

Shog9
quelle
3
Ich kann nicht genau sagen, ob Sie über die "Vorteile" von GWT scherzen. Wenn Sie sind, Bravo. Die Arbeit mit GWT war eine der verrücktesten Erfahrungen meines Lebens.
Nicole
@Renesis: Als ob die Arbeit mit Javascript und Browserkompatibilitäten nicht schon verrückt wäre? Aber es hat raffinierte Funktionen, wie das Herunterladen mehrerer Bilder in einem einzigen Bild und das anschließende Ausschneiden auf dem Client.
Macneil
1
@Macneil Möglicherweise haben sie dies inzwischen behoben, aber als ich mit Sprites arbeitete, wurden fast alle Vorteile zunichte gemacht, da automatisch andere CSS-Hintergrundeigenschaften geschrieben wurden, die Sie möglicherweise nicht wollten, sodass Sie Ihr CSS jedes Mal überladen mussten, um es zu überschreiben .
Nicole
6

Die meisten Vorteile statisch typisierter Sprachen werden beim Kompilieren realisiert. Wenn die Sprache auf dem Client interpretiert werden soll, gehen viele dieser Vorteile verloren. Wenn Sie sie auf dem Server kompilieren, müssen Sie herausfinden, wie Sie sie laden und auf dem Client ausführen können (denken Sie an ActiveX-Steuerelemente). Sie könnten einen hybriden Ansatz wählen (zu einer Zwischenform mit Token kompilieren), aber dann kehren Sie im Grunde zu Java-Applets zurück.

TMN
quelle
2
+1 für die Erklärung eines möglichen Grundes, warum nicht , nicht nur zu antworten, wenn es möglich ist.
4

Es existiert bereits.

ActionScript 3 (die Skriptsprache hinter Flash und Flex) ist ein Dialekt von ECMAScript, der starke Typen implementiert, und Sie können ihn mehr oder weniger clientseitig wie JavaScript verwenden (der Unterschied besteht darin, dass AS3 ein Flash-Plugin benötigt, und wird zusammengestellt). Ich persönlich versuche heutzutage, mich davon fernzuhalten, aber wenn Sie im "statischen" Lager sind, versuchen Sie es.

Damit ist die Hauptfrage beantwortet, und jetzt, da wir diese haben, lautet Ihre sekundäre Frage "Ist Flash praktisch?". Die Antwort lautet "Ja", mit ein paar "Wenn" und "Aber"

  • ... wenn Sie Ihren Code aus irgendeinem Grund verstecken müssen.
  • ... wenn Sie ein sehr, sehr hohes Interaktivitätsniveau (nach jQuery) wünschen
  • ... aber auch ohne HTML5 werden die browserübergreifenden Kompatibilitäten in letzter Zeit viel besser.
  • ... aber HTML5 kommt bald.
  • ... aber einer der großen Vorteile der statischen Eingabe / Kompilierung (im Gegensatz zur Interpretation) ist die zusätzliche Geschwindigkeit, die durch Optimierungen ermöglicht wird (und Flash hat trotz des Typsystems keine wirklich gute Geschwindigkeit).
Inaimathi
quelle
AS3 basiert auf dem aufgegebenen ES4.
Gsnedders
3

Theoretisch können Sie beliebige Skripte auf eine gewünschte Seite kleben. Das <script>Tag hat schließlich ein typeAttribut.

Das einzige Hindernis besteht darin, genügend Marktanteile in Bezug auf die Implementierung in verschiedenen Browsern zu gewinnen, damit sich die Verwendung lohnt.


Also ja, es ist zu diesem Zeitpunkt eher unwahrscheinlich.

Anon.
quelle
Also kein Problem mit der statischen Eingabe? Ich bin nicht allzu besorgt über die praktischen Aspekte dieses Auffangens.
Armand
1
@Alison: Sie können jeden gewünschten Textinhalt in ein Skript-Tag einfügen (mit einer Ausnahme - es kann die Zeichenfolge nicht enthalten </script>). Sie könnten dort Brainf * ck-Code einfügen, wenn Sie es wirklich wollten. Anschließend müssen Sie in dem Browser, den Sie verwenden möchten, lediglich einen Interpreter für die von Ihnen gewählte Sprache implementieren.
Anon.
@ Anon. danke sehr interessant. Wenn es so einfach ist, wurde es wahrscheinlich irgendwo gemacht. Ich erinnere mich <script type="vbscript">einmal ...
Armand
Alison: vbscript war nur für den Internet Explorer verfügbar, und einige Leute verwendeten es, wenn der Marktanteil des Internet Explorer> 90% betrug. Mit einem Marktanteil von etwa 50% bei IE, wahrscheinlich weniger in einigen Teilen der Welt, ist dies heute ein großes No-Go. Und solange kein Browser wieder so viel Marktanteil erhält, sollten Sie nicht damit rechnen, dass eine neue clientseitige Skriptsprache verwendet wird.
user281377
@Alison: Internet Explorer unterstützt weiterhin VBScript als Skriptsprache ... Ich sollte wissen, dass wir hier Intranetseiten haben, die es verwenden (und daher Internet Explorer benötigen - urgh!)
Dean Harding
2

Wäre es praktisch? Nein.

Ist es möglich? Ja!

Die Entwicklung einer eigenen statisch typisierten Alternative zu JavaScript wäre bestenfalls zeitaufwändig. Im schlimmsten Fall könnten Sie keine vorhandenen Browser davon überzeugen, Ihre Client-Skriptsprache zu implementieren, und müssten Ihre eigene schreiben.

Marcie
quelle
Möchtest du das erklären?
back2dos
Ein Folgeabsatz wurde hinzugefügt.
Marcie
Ich möchte nur hinzufügen, dass der einzige Grund, warum es möglicherweise nicht praktikabel ist, die aktuelle Situation ist. Wenn wir kurz vor der Veröffentlichung von Javascript wieder an dem Punkt wären, wären die Dinge anders.
Yakiv
1

Sie können Sprachen wie haXe verwenden, um Ihren Code statisch zu schreiben und in Javascript zu exportieren. JavaScript wird sehr schnell und ist daher als Ausgabesprache ausreichend. Der Versuch, eine statisch typisierte Sprache als Webstandard durchzusetzen, ist nahezu unmöglich. Versuche, statische Typisierung in JavaScript einzuführen, sind aus zu weitreichenden Gründen gescheitert.

back2dos
quelle
1

Wäre es technisch möglich? Wenn es in Java implementiert werden soll, würde ich "sehr, sehr schwer, aber möglich" ohne signifikanten Leistungsverlust sagen.

Ich schreibe gerade ein statisch typisiertes DSL in Java von Hand. Die einzige Möglichkeit, die Überprüfung des Laufzeit-Typs zu vermeiden, besteht darin, Generika zu verwenden und "ungeprüfte" Warnungen zu unterdrücken ... das heißt, bis die Zeit für die Implementierung gekommen ist mehrdimensionale Arrays (Klassenparameter müssen zur Kompilierungszeit bekannt sein und sind daher von Natur aus endlich, während mehrdimensionale Arrays eine unendliche Anzahl von Typen darstellen ...) Ich versuche leider immer noch, dies herauszufinden - ich bin mir sicher, dass ich Bei benutzerdefinierten Klassen treten ähnliche Probleme auf.

Ich stolpere immer wieder über diese Art von Problemen, aber nachdem ich eine Weile darauf gesessen habe, finde ich eine gute Lösung. Also, es zu tun , und die haben Leistung Vorteile der statischen Typisierung (keine Laufzeittypprüfung), würde ich sagen , es ist extrem schwierig, aber nicht unmöglich. Abzüglich der Leistung würde ich hart sagen, aber sehr gut möglich.

Ich weiß, dass es eine alte Frage ist, dachte nur, dass meine Erfahrung für jemanden wertvoll sein könnte.

Philip
quelle
0

Es ist technisch möglich, clientseitige Skripte in jeder vom Benutzeragenten (Browser) unterstützten Skriptsprache zu schreiben. In der Praxis ist JavaScript / ECMAScript die einzige weit verbreitete Sprache. Es ist unwahrscheinlich, dass es erfolgreich ist, Browserhersteller davon zu überzeugen, eine neue Sprache zu implementieren und zu unterstützen. Wenn Sie also eine neue statisch typisierte clientseitige Sprache verwenden möchten, müssen Sie entweder die neue Sprache in JavaScript übersetzen oder einen Interpreter dafür in JavaScript implementieren.

Es gibt mehrere Projekte, die bereits so etwas tun. Zum Beispiel Google Web Toolkit , wie in einer der anderen Antworten erwähnt.

Mithrandi
quelle
0

Vorausgesetzt, Sie haben keine Hoffnung darauf, dass alle Browser, die in der realen Welt verwendet werden, eine neue Sprache unterstützen. Die Sprache muss bis zu jscript kompiliert werden.

Da alle Beispiele des Webs in jscript vorliegen, sollte die Sprache meistens wie jscript aussehen.

Ich denke, es gibt einen Bereich mit einer "Teilmenge" von jscript, die von einem statischen Prüfer überprüft wird, aber auch gültiges jscript ist. Z.B:

  • Alle Variablen müssen einen Kommentar haben, der besagt, dass es vor der ersten Verwendung Typen gibt.
  • Alle Verwendungen von Variablen müssen mit den oben genannten gültig sein.
  • Funktionen / Klassen dürfen nicht verwendet werden, wenn sie nicht in einem Kommentar # deklariert wurden
  • Ein Kommentar oben in der js-Datei muss alle anderen js-Dateien auflisten, von denen er abhängt.
Ian
quelle