nicht angemeldet
Hallo,
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.
In der Hinsicht ergibt der Vergleich vielleicht Sinn, ja.
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?).
Eine Übersicht habe ich mal hier zusammengestellt:
http://molily.de/js/organisation-ueberblick.html
JavaScript ist unmittelbar objektorientiert, allerdings nicht klassenbasiert. Alles ist entweder ein Objekt oder verhält sich wie eins, es gibt Funktionen/Konstruktoren und Prototypen.
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)?
JavaScript tritt nicht generell in Konkurrenz mit Java und hat es auch nicht vor. An ECMAScript werden verschiedene Änderungen vorgenommen, die »programming in the large« erlauben, aber das sind höchstens konzeptionelle Angleichungen.
Java spielte im öffentlichen Web nie eine große Rolle. Java-Applets sind seit Jahren verschwunden, von obskuren Intranets mal abgesehen. Wie gesagt gibt es mit Android eine Mobilplattform, für die man native Apps üblicherweise in Java entwickelt. Es ist tatsächlich so, dass es einen Widerstreit zwischen plattformübergreifenden Web-Apps for Mobilgeräte und nativen Apps gibt. Viele fragen sich, ob sie lieber mobiltaugliche Web-Apps oder verschiedene native Apps entwickeln. Für aufwändigere Dinge sind native oder hybride Apps immer noch die beste (und weitaus teurere) Wahl.
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.
Das sind die bekannten Kompromisse, die man bei kompilierten bzw. interpretierten Sprachen eingeht, ja.
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?
JavaScript-Engines sind in manchen Benchmarks nur zehnmal langsamer als C. Das reicht für das, was die üblichen Anwendungen tun, bei weitem aus. Das zeigen auch Projekte wie Emscripten. Für High-Performance-Spiele sind interpretierte Sprachen natürlich wenig attraktiv, für mittelgroße Spiele wird das Web als Plattform aber zunehmend attraktiver.
Anwendungen fressen üblicherweise nicht Ressourcen im Sinne von reiner CPU-Rechenpower. Sie brauchen Grafikressourcen (hardwarebeschleunigtes CSS, Canvas, WebGL), Asynchronität und Nebenläufigkeit (setImmediate, requestAnimationFrame, Web Workers), schnelle Netzwerkprotokolle (Websockets, Server-sent events, XHR2/CORS, SPDY), clientseitige Datenbanken (indexedDB, Offline-Storage) und so weiter. An diesen APIs wird im Zuge von HTML5 gearbeitet.
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?
Ja, schon immer. Es gab zwar einige Flash-Releases für Android, aber wirklich benutzen ließen sich große Flash-Sites damit nicht. HTML5 ist in aller Munde ist, weil wir im Post-PC-Zeitalter leben. Für Smartphones, Tablets und manche Netbooks gibt es kein nutzbares Flash.
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?
Das HTML-DOM für Anwendungen zu verwenden ist natürlich ursprünglich ein Hack, denn HTML beschreibt Hypertext-Dokumente, nicht GUIs. Erst mit HTML5 sind ein paar entsprechende native Controls hinzugekommen.
Bei nativen GUI-Toolkits operiert man nicht direkt auf einem DOM-Baum, aber intern haben die auch nur einen Objektbaum aus wiederverwendbaren Controls, die letztlich aus primitiven Zeichenobjekten bestehen. Im Vergleich zum DOM ist nur der Abstraktionsgrad höher. Ansonsten arbeitet z.B. Flex oder Qt durchaus mit einem DOM-ähnlichen Objektmodell.
Für HTML gibt es z.B. mit den Web Components und dem Shadow DOM Erweiterungen, die auf eine höhere Abstraktion abzielen. Außerdem gibt es wie gesagt GUI-Toolkits für JavaScript. ExtJS, YUI, Ember und Co. sorgen dafür, dass man auf Anwendungsebene nicht mehr direkt mit dem DOM zu tun hat, sondern nur mit Views bzw. UI-Komponenten und Widgets.
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.
Soweit ich weiß, erzeugen Qt Designer, Glade und Flex (MXML) XML-Dokumenten, aus denen dann ein Objektbaum erstellt wird.
Ich dachte immer, Markup soll den Inhalt beschreiben und nicht die Darstellungsweise.
Ja, siehe oben, das ist die ursprüngliche Aufgabe: Hypertexte zu strukturieren und auszuzeichnen. Webanwendungen gehen natürlich weit darüber hinaus. Wie gesagt gibt es verschiedene Bestrebungen, diesen Paradigmenwechsel auch technisch eine Form zu geben. HTML5 als Spezifikation von »web applications« ist ein Ansatz, zusätzlich gibt es etwa WAI-ARIA, wodurch HTML-Elemente zum Zweck der Zugänglichkeit GUI-Semantik bekommen.
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.
Flash hat im Grunde eine ähnliche Entwicklung durchgemacht, ja. Am Ende kamen wie AS3 und Flex heraus.
Mathias