nicht angemeldet
Hallo,
endlich wieder Internet, nachdem mein Provider 5 Tage lang nicht geschafft hat, den Port zu resetten. Naja, zurueck zum Thema.
Eine Übersicht habe ich mal hier zusammengestellt:
http://molily.de/js/organisation-ueberblick.htmlJavaScript ist unmittelbar objektorientiert, allerdings nicht klassenbasiert. Alles ist entweder ein Objekt oder verhält sich wie eins, es gibt Funktionen/Konstruktoren und Prototypen.
Vermutlich ist es das beste, wenn ich mal mehr mit JavaScript arbeite. Dann sollte ich die Moeglichkeit haben, auszuprobieren, wie man es gut umsetzt. Danke uebrigens fuer die Uebersicht.
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.
Dass Java wirklich aus dem Web verschwunden ist, kann ich leider nicht bestaetigen. Ich wuerde eher behaupten, dass es ein Nischendasein fristet. Richtige Webanwendungen findet man zwar nicht, aber dafuer noch Veranschaulichungen (meist von Universitaetsseiten) oder auch Spiele.
Und bezueglich der nativen (Java-) Apps stelle ich mir immer noch die Frage, ob eine Ersetzung mit HTML5/JavaScript nicht zu erhoehten Hardwareanforderungen und Mehrbedarf an Energie fuehren koennte, nachdem es eben nicht nativ laeuft, sondern noch einmal abstrahiert wurde. Auch wenn JavaScript "nur zehnmal mal langsamer" ist als C (und noch weniger langsamer bei Java), kann ich mir nicht vorstellen, warum leistungsschwache (bzw. energiesparsame) Systeme darauf umgestellt werden sollen (ich denke wieder an Firefox OS, das angeblich auch auf billigen Smartphones hervorragend laufen soll)
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.
Somit kann man die HTML5 zugeordneten Technologien wohl als eine Art "Rolling Release" ansehen, an dem (zumindest in naechster Zeit) immer weiter gearbeitet wird, um den Anforderungen von Webanwendungen gerecht zu werden?
An sich ist ja schon eine ganze Menge vollbracht. Vermutlich hast du mich ueberzeugt, dass JavaScript eine akzeptable Sprache ist und HTML5 gar nicht so viel "schlechter", sondern eventuell sogar besser ist als ein auf XML basierendes Konstrukt.
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.
Was darf ich unter "nativen Controls" verstehen? Damit ist bestimmt nicht Canvas gemeint, oder? HTML5 will ja immer noch einer Auszeichnungssprache gerecht werden.
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.
Das DOM ist aber doch eher der Syntaxbaum eines semantischen Inhaltsmodells als ein Objektbaum der grafischen Ausgabe. Da es allerdings zur Ausgabe verwendet wird, fehlt doch irgendwie die Trennung von Layout und Inhalt. Mir wird noch nicht ganz klar, ob du das DOM nun fuer die Ausgabe nutzen wuerdest (bzw. ob die von dir genannten Toolkits das so umsetzen) und die eigentlichen Daten intern in einer Datenstruktur verwalten wuerdest, oder ob das DOM gleichzeitig als Datenstruktur dient. Es wirkt wie ein Zwischenschritt, den ich nicht so ganz einordnen kann.
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.
Das muss ich mir mal anschauen, vielleicht kann das meine Frage von oben klaeren. Ohne einfacheres Tutorial empfinde ich es allerdings als schwierig, mir in kurzer Zeit einen Ueberblick zu verschaffen. Sieht aber sehr schoen aus, muss ich zugeben!
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.
Ist das jetzt die Antwort auf meine andere obige Frage? Einfach ausgedrueckt, kann man jetzt wohl sagen, dass HTML5 keine semantische Sprache, sondern eine graphische Sprache sein soll? Wenn ich das jetzt richtig verstanden habe, werfe bitte alle meine obigen Fragen ueber Bord, wenn HTML5 aber immer noch Semantik in das Web bringen soll, bleiben sie stehen ;)
Noch schoene Gruesse,
Rachus