nicht angemeldet
Hallo,
nachdem hier die meisten meiner Argumente entkräftet wurden und ich HTML bereits bei meiner Antwort an Daniel.S abgegolten habe, werde ich mich mal mehr JavaScript widmen.
JavaScript ist keine Lernsprache wie Java, dafür ist sie zu mächtig, zu dynamisch und zu funktional. Sie gibt einem keine einfache, vorgefertigte Struktur, keine rigorosen Konventionen, die man nur befolgen braucht - das ist bekannt.
Macht es Sinn, in diesem Falle C++ (gefällt mir persönlich sehr) mit JavaScript zu vergleichen? Denn in C++ hat man auch die Wahl zwischen vielen Programmierparadigmen und nur wenige Beschränkungen, ist aber natürlich im Gegensatz zu JavaScript streng typisiert. Allerdings fällt es mir in JavaScript sehr viel schwerer ein Paradigma anzunehmen, da es nicht richtig funktional ist, aber auch nicht unmittelbar objektorientiert. Wobei man das evtl. auch "zu viel objektorientiert" nennen könnte, nachdem dort prinzipiell auch Klassen und Methoden Objekte zu sein scheinen (oder doch wieder Funktionen?).
Das heißt nicht, dass man nicht mit JavaScript Programmieren lernen kann, aber brauchbares clientseitiges JavaScript zu schreiben bedarf eines Haufens an Wissens.
Also kann JavaScript ohne Probleme mit Java in Konkurrenz treten (z.B. auf Smartphones, nachdem Java aus Webseiten fast komplett verdrängt wurde)?
Das ist Quatsch. JavaScript-Engines können es locker mit anderen üblichen Websprachen aufnehmen. Sicher, die JVM ist in vielerlei Hinsicht ausgereifter und überlegen, aber das liegt einfach am Konzept. Diese Vorteile erkauft man sich mit Nachteilen, die man bei dynamischen, interpretierten Sprache nicht hat. Doch die Programmiersprache selbst ist bei Webprogrammierung selten das Bottleneck, sondern Datenbankzugriff und Datenverarbeitung, Parallelisierung, Skalierung.
Okay, das ist implizit eine Antwort auf meine oben gestellte Frage. Allerdings sehe ich bei strikter Typisierung und Vorkompilierung keine Nachteile gegenüber dynamischer Typisierung und Interpretation. In meinen Augen ist es gar umgekehrt, da Fehler schneller auffallen, wenn nicht implizit eine Variable theoretisch von jedem Typ sein kann.
Besonders in der heutigen Zeit ist es zudem so, dass zunehmend ressourcenaufwändige Webanwendungen auf dem Desktop/Notebook daheim laufen. Für grafische Spielchen und dergleichen benötigt man aber in meinen Augen eben auch eine schnelle Sprache. Ist dem denn JavaScript gewachsen? Auf jeden Fall wird versucht, es darauf vorzubereiten. WebGL ist da das beste Beispiel.
Vielleicht hast du es nicht mitbekommen, aber selbst Adobe hat Flash für Mobilgeräte aufgegeben.
Das ist tatsächlich an mir vorübergegangen. Was machen nun die ganzen Seiten, die komplett auf Flash aufbauen (meistens sind diese ja zu Filmen, oder auch mein Zahnarzt nutzt so eine)? Die lassen Smartphones außen vor?
JavaScript ist *die* ubiquitäre Sprache [...]
Wenn das so ist, muss ich sie jetzt nur noch meistern.
JavaScript als Sprache ist wie gesagt nicht das Bottleneck, wenn es um Anwendungsentwicklung geht. Entscheidend sind hier z.B. Grafikperformance, also hardwarebeschleunigtes CSS, sowie die Performance der verschiedenen HTML5-APIs. Hier ist tatsächlich noch viel zu tun, aber der Fortschritt ist enorm.
Dennoch möchte ich noch die Frage stellen, ob den die Schnittstellen, von der Geschwindigkeit abgesehen, die allerdings ja auch sehr wichtig ist, den Zwecken gerecht werden. Ist die DOM-API geeignet für Anwendungen, wie ich sie oben beschrieben habe? Wenn man native GUIs schreibt, ist das Vorgehen doch vermutlich nicht so, dass man bei Manipulationen durch einen DOM-Baum laufen muss, oder? Ich habe bisher immer nur manuell welche geschrieben, könnte mir aber vorstellen, dass man mit Glade oder dergleichen auch einen Baum erhält. Damit wäre mein Einwand hier wieder entkräftet.
Das DOM ist keine reine Datenstruktur, sondern eine Darstellungsweise, eine Repräsentation von Daten. Das DOM sollte daher keine komplexen Informationen enthalten. Das ist ein Architekturproblem, welches man mit gängigen Pattern wie MVC lösen sollte, welche die Darstellung und die Rohdaten und der Anwendungslogik trennen.
Ich dachte immer, Markup soll den Inhalt beschreiben und nicht die Darstellungsweise. Zumindest wird es einem von SELFHTML ja so beigebracht. Wenn man jetzt den Inhalt selbst im Hintergrund verwaltet und den DOM-Baum nur noch zur Ausgabe "missbraucht", ist das doch beinahe so ähnlich wie eine Flash-Seite. Je nach Umsetzung könnte so eine bestimmt das Modell auch sehr gut umsetzen.
Jede gute JavaScript-Anwendungsbibliothek setzt ein MVC-, MVP- oder MVVM-artiges Pattern um (siehe Backbone, Ember, YUI, Dojo, ExtJS usw.). Das ist keine besondere Stärke oder Schwäche von JS/HTML5, das Problem hat man z.B. auch bei Flash (siehe Flex, PureMVC usw.)
Hm, ich muss zugeben, dass ich mich nie mit einer JavaScript-Anwendungsbibliothek beschäftigt habe. Mir ging es immer darum, erst einmal selbst zu verstehen, was im Hintergrund passiert. Daher kam ich nie mit einer in Kontakt. Vielleicht sollte ich mich mal mit der ein oder anderen außeinandersetzen.
Jedenfalls danke für deine Antwort!
Schöne Grüße