Zurück zur Übersicht


Geschrieben am 21.6.2010 um 0:40 Uhr von Klopfer in der Kategorie Allgemeines

Javascript-Frameworks

Ich mag sie nicht.
Damit will ich nicht sagen, dass sie schlecht wären, aber sie verschleiern Wirkungsweisen, und das wirkt sich negativ auf die Qualität der Skripte aus.

Dafür muss man sich nur mal viele Javascript-Tutorials angucken. In einem Tutorial geht es um Ajax - mit JQuery. Okay, denkt der geneigte Programmierer, ich benutze dann eben JQuery. Dann liest man in einem nächsten Tutorial etwas von einer ganz tollen Animationstechnik per Javascript - mit der script.aculo.us-Bibliothek, welche wiederum auf dem Prototype-Framework basiert. Und schon steckt man in der Frameworkhölle, in der man versucht, mehrere Frameworks einzubinden, ohne dass sich alle im Weg stehen, obwohl man von jedem Framework gerade mal 1% der Funktionen für die Dinge benötigt, die man machen will.

Und das Schlimmste - man hat immer noch keine Ahnung, wie diese Effekte eigentlich realisiert werden, weil die Tutorials einem nur den Weg über vorgefertigte Funktionen der Frameworks erklären, aber nicht den Hintergrund. Das ist so, als würde man statt einem Pizzarezept die Nummer des Bringdienstes bekommen.

Seit einiger Zeit betreiben die Browserhersteller diesen unsäglichen Schwanzvergleich mit der Ausführungsgeschwindigkeit von Javascript - als wenn sie damit ein Problem lösen würden, was irgendjemand hätte. Im normalen Einsatzbereich von Javascript auf Websites ist die Ausführungsgeschwindigkeit der Skripte gar kein Flaschenhals, der die Funktionsfähigkeit merkbar beeinflussen würde. Bei Ajax ist es z.B. nicht die Geschwindigkeit des Javascripts, sondern die lange Antwortzeit des Servers, die oft eine schnelle Ausführung behindert. Ich nehme fast an, dass die Hersteller auf die Idee gekommen sind, weil so viele Leute einfach massenhaft Javascript-Frameworks auf ihre Seiten schmeißen, um irgendwelche Probleme zu lösen, die sie mit selbst geschriebenen Skripten viel schlanker meistern könnten.

Das Grundproblem liegt dabei natürlich nicht bei den Programmierern der Frameworks, sondern bei den Leuten, die mit Tutorials irgendwelche Tricks erklären wollen. Diese Tutorials sollten beschreiben, was das Framework eigentlich macht, um z.B. ein Element sanft einzublenden, anstatt einfach nur hinzuwerfen, mit welchen Befehlen man das Framework dazu bringt. So würde man eher dafür sorgen, dass man gewisse Effekte im Framework seiner Wahl nachbilden kann.

Allerdings wissen die Autoren der Tutorials ja oft selbst nicht Bescheid.
Kleiner Exkurs: Mittlerweile ist es ja modern, bei Ajax die Serverantworten nicht mehr als XML-Daten, sondern als JSON-String zu schicken. Ich mag JSON nicht, denn dieser String muss mit der Javascript-Funktion eval() interpretiert werden - und mir ist gar nicht wohl dabei, einen String, der womöglich nur untergeschoben wurde, einfach so als Javascript-Code ausführen zu lassen. In einem Tutorial las ich dann, man solle genau aus diesem Grund ein Framework benutzen, denn da müsse man eval() nicht verwenden. Allerdings benutzen die Frameworks selbst intern diese Funktion. Auch wenn sie vorher sicher versuchen, die Zeichenkette unschädlich zu machen - irgendwann muss darauf ein eval() angewendet werden. Selbst wenn man auf sein Framework vertraut, sollte man sich doch im Klaren sein, wo eventuelle Schwachpunkte liegen könnten. Wenn das nicht gegeben ist, so spielt man als Tutorial-Autor einen Kochlehrer, der selbst nur Fertignahrung aufwärmen kann.

7 Kommentar(e)


Geschrieben am 21.6.2010 um 2:07 Uhr
Lubin

JSON muss (und sollte) man nicht mehr mit eval() parsen. Alle gängigen Browser in ihrer aktuellen Version -- ja, selbst der Internet Explorer! -- bieten ein natives JSON-Objekt an, mit dem solche Daten sicher und dadurch, dass man eine sehr einfache Syntax hat und nicht auf JavaScript-Funktionen achten muss, sogar schneller geparst werden.

Frameworks wie jQuery und Prototype nutzen diese originalen Objekte auch, wenn der Browser es unterstützt. Die Daten durch eval() zu jagen ist höchstens noch eine Fallback-Methode; einige Frameworks haben hier sogar eigene Parser implementiert (so aufwändig ist es ja nicht), die dann nur etwas langsamer laufen.

Sicherlich wäre es wünschenswert, dass man zumindest im Groben nachvollziehen kann, wie solche Frameworks intern wohl arbeiten werden.

Doch seien wir mal ehrlich: Früher hatten wir HTML, das wir können mussten. Das mussten wir nicht einmal besonders gut können, weil die Browser eh jedes noch so dahin gerotzte Markup irgendwie interpretiert haben.

Dann kamen irgendwann CSS und JavaScript hinzu, mit denen man zunächst auch noch nicht allzu viel machen konnte. Nach und nach wurden diese Standards dann mehr und mehr umfangreich, es kamen mehr Browser hinzu, die auch wieder teilweise inkompatibel untereinander waren, man musste auf dies achten und auf jenes und serverseitig dann noch mal das Gleiche.

Mittlerweile ist das alles so viel geworden, dass es schon sehr schwierig ist, überall den Überblick zu behalten und alle Feinheiten zu kennen. Da überlasse ich das bei viel genutzten Funktionen doch lieber Leuten, die sich sehr intensiv mit bestimmten Details beschäftigen und vertraue darauf, dass sie mir da schon die beste Methode implementieren werden.

Natürlich gebe ich damit etwas Kontrolle aus der Hand, aber dafür gewinne ich auch an Zeit, weil vieles einfacher und schneller geht.

Es mag sein, dass man mit liebevoller Handarbeit noch etwas mehr Leistung herauskitzeln könnte, aber erstens werden Browser und Rechner doch auch immer leistungsfähiger und zweitens ist die Gefahr dann auch recht hoch, dass man irgendwo Fehler oder regelrechte Sicherheitslücken einbaut.

Oder programmierst Du in C auch immer ohne die Standard Library?

Geschrieben am 21.6.2010 um 3:50 Uhr
Klopfer (Website)

Die Standard Library ist etwas ganz anderes, die konkurriert ja nicht gleichberechtigt mit zig Frameworks.

Es geht mir gar nicht darum, dass man "mit Handarbeit mehr Leistung" herauskitzeln könnte, man killt Leistung dadurch, dass man dazu verführt wird, viel zu viele unnötige Frameworks einzubinden. Fehler und Sicherheitslücken sind doch eben ein Grund dafür, dass man möglichst wenig Code verwenden sollte, schließlich sind die Frameworks auch nicht fehlerfrei. Würde man wenigstens erklären, wie gewisse Dinge funktionieren, könnte man z.B. Tipps, die auf Prototype aufbauen, auch auf JQuery übertragen, und sich so auf ein Framework beschränken.

(Gewisse Dinge wie Ajax sollte man meiner Meinung nach übrigens auch mal per Hand gemacht oder zumindest gesehen haben. Das ist jetzt auch nicht sooo kompliziert, dass man da irgendwelche besonderen Feinheiten kennen müsste.)

Geschrieben am 22.6.2010 um 22:54 Uhr
Niemand

Ich bin selbst kein Webentwickler, aber die Doku von z.B. Prototype sieht mir doch schon recht gut und umfangreich aus.
http://api.prototypejs.org/
Nach Tutorials zu lernen halte ich generell für recht bedenklich, ein gutes Buch und die Doku sollten reichen und Tutorials dann als Ergänzung.
Denn, wie du öfter sagst, sind Tutorials oft unkomplett und beschreiben nicht immer den besten Weg etwas zu tun. Schreibst du denn alle browserspezifischen Anpassungen und Fallbacks selbst? Wenn ja, dann wirst du das ja auch nicht extra für jedes Projekt neu tun, sondern bestehendes verwenden, was ja dann auch im Prinzip (dein eigenes) Framework ist.

Geschrieben am 23.6.2010 um 15:18 Uhr
Cohlendioxyd

Also ich find JQuery praktisch und die core datei ist glaub ich nur 27kb gross und wenn du ein blick hinter die kullissen werfen willst gibts ne developer version mit klartext...

ausserdem kannste dir von JQuery ui auch dateien zusammen bauen lassen die nur die effekte enthalten die du auch nutzt

Geschrieben am 25.6.2010 um 0:22 Uhr
Klopfer (Website)

@Niemand: Viele benutzen aber nur Tutorials, denn API-Dokumentationen lesen sich die meisten ja nur durch, wenn irgendwas nicht geht oder etwas gemacht werden soll, wofür es kein spezielles Tutorial gibt. Dokumentationen nehmen die Leute eben nicht bei der Hand, um ihnen einen Faden und eine Lernkurve vorzugeben.

Ich schreib sicher nicht alles neu, aber ich weiß immerhin genau, was ich mache. Und ich binde nur das ein, was ich wirklich brauche.

@CO2: 27 KByte sind zwar nicht gerade klein, aber allein geht das tatsächlich. Ich bezweifle nur, dass sich so viele Leute die Mühe machen, einen script.aculo.us-Effekt in jQuery nachzubauen, statt stupide zu versuchen, zwei Frameworks gleichzeitig zu benutzen.

Geschrieben am 25.6.2010 um 14:15 Uhr
Lubin

Also ich habe in einem Test gerade mal jQuery und scriptaculous gemeinsam eingebunden und bin mit ein paar Optimierungen (minify, gzip) auf etwa 70 kB gekommen.

Wenn man das dann, wie das selbstverständlich sein sollte, noch mit ewig langer Cachegültigkeit (10 Jahre oder so) ausliefert, ist das meiner Meinung nach auch nicht mehr so das Problem.

Klar, wenn es sich vermeiden lässt, sollte man auch bemüht sein, es zu vermeiden. In diesem Fall aber würde die Datei (wie z. B. auch Bilder -- das Logo hier bei Dir ist auch schon 42 kB groß) einmal runtergeladen und dann mindestens während des Besuchs, optimalerweise noch für viele weitere Besuche im Cache vorgehalten werden.

Und bei den heute üblichen Geschwindigkeiten machen mal eben 70 kB auch nicht so den Braten fett, selbst über UMTS mit den gängigen Abzocker-Datentarifen.

Wer mit einer Verbindung unterwegs ist, bei der 70 kB zu ernsthaften Problemen führen, der wird vermutlich auch allgemein wenig Spaß mit einer aufwändigeren Webanwendung mit AJAX und pipapo haben.

Geschrieben am 25.6.2010 um 14:20 Uhr
Lubin

Nachtrag: Ich habe da ein bisschen geschludert. Weil's schnell gehen sollte, habe ich nicht beachtet, dass scriptaculous modular aufgebaut ist und habe einfach mal alle Dateien mitgenommen.

In der Minimalfassung komme ich auf 49 kB. Der Rest waren dann schon Effektplugins.


Eigenen Kommentar schreiben

Kommentar:
Smilies und Codes
Name: (darf nicht leer sein)
E-Mail: (nicht öffentlich sichtbar)
Website:
Spamschutzfrage: Wie heißt die Hauptstadt Frankreichs?
Username: Passwort: