jquery vs. prototype

[heinetz]

Hallo Forum,

ich mutmasse mal, dass sich der direkte Vergleich nicht
wirklich anstellen lässt zumal es ja noch andere
JS-Frameworks gibt. Ich mache nun seit mehr als 10 Jahren
mit JS rum, hab Spass daran und bisher immer mehr oder
weniger das hinbekommen, was ich brauchte. Ich habe mich
nie mit einem dieser Frameworks anvertraut, weil ich die
Notwednigkeit nicht gesehen habe, sehe allerdings, wie
sie zunhemend verwendet werden und denke, dass ich mich
doch mal damit auseinander setzen sollte.

Da sich hier nun eher die Leute rumtreiben, die wissen,
was dahinter steckt, die in der Lage wären sollche
Frameworks selbst zu entwickeln, würden mich eure Meinungen
dazu interressieren. Was ist besser? Gibt es noch bessere?
Braucht man sowas überhaupt? ist das eine als Arbeits-
erleichterung zu werten? Soll man von einem ganz die Finger
lassen? Welches setzt sich durch?

danke für eure Meinungen und

beste gruesse,
heinetz

[suit]

Da sich hier nun eher die Leute rumtreiben, die wissen,
was dahinter steckt, die in der Lage wären sollche
Frameworks selbst zu entwickeln, würden mich eure Meinungen
dazu interressieren. Was ist besser? Gibt es noch bessere?
Braucht man sowas überhaupt? ist das eine als Arbeits-
erleichterung zu werten? Soll man von einem ganz die Finger
lassen? Welches setzt sich durch?

Es ist eine (imho) enorme Arbeitserleichterung wenns um DOM-Manipulation, Animationen oder Ajax geht - der Nachteil: es geht auf die Bandbreite, da die Frameworks auch übertragen werden müssen.

Prototype ist imho nur mit script.aculo.us brauchbar (hängt natürlich vom Anwendungszweck), jQuery hingegen ist out-of-the-box ordentlich benutzbar.

jQuery (~23 kb) ist weitaus schlanker als Prototype (je nach Ausstattung weit über 200 kb). jQuery ist schneller, usw.

Im direkten Vergleich schneidet jQuery wesentlich besser ab als Prototype - aber das muss jeder für sich entscheiden.

Allerdings gibts noch andere Frameworks - MooTools und Dojo sind ebenfalls recht schlank und sollen gut funktionieren, ich hab' damit allerdings noch nicht praktisch gearbeitet, ich bin mit jQuery sehr zufrieden und war zuvor sehr unzufrieden mit Prototype :)

[telofon]

Hallo

Prototype ist imho nur mit script.aculo.us brauchbar (hängt natürlich vom Anwendungszweck), jQuery hingegen ist out-of-the-box ordentlich benutzbar.

Prototype kann man auch out-of-the-box benutzen. Einfach die JS-Datei einbinden und fertig. Schon stehen all die schönen Funktionen zur Verfügung, die Prototype bietet.
Das Prototype ziemlich aufgebläht ist, kann ich bestätigen. Aber ob es dadurch auch langsam ist, kann ich nicht sagen, denn ich habe mit bisher keinem anderen Framework gearbeitet.

Prototype ist, was Ajax angeht, ziemlich genial, und dabei einfach. IMHO. Wie geht JQuery an Ajax heran?

Was mich an Prototype begeistert, ist die Sache mit dem $(''), was gleichbedeutend ist mit document.getElementById(''). Wie macht das JQuery?

Gruß
telofon

[EKKi]

Mahlzeit telofon,

Prototype ist imho nur mit script.aculo.us brauchbar (hängt natürlich vom Anwendungszweck), jQuery hingegen ist out-of-the-box ordentlich benutzbar.

Prototype kann man auch out-of-the-box benutzen. Einfach die JS-Datei einbinden und fertig. Schon stehen all die schönen Funktionen zur Verfügung, die Prototype bietet.

Das ist zwar richtig - was suit aber vermutlich meinte, ist dass jQuery von Haus aus mehr und mächtigere Funktionen mitbringt ... die man bei der Benutzung von Prototype eben z.B. durch script.aculo.us "ergänzen" muss.

Was mich an Prototype begeistert, ist die Sache mit dem $(''), was gleichbedeutend ist mit document.getElementById(''). Wie macht das JQuery?

IMHO besser: Du kannst der globalen Funktion $() als Parameter nicht nur die ID, sondern komplett CSS-kompatible Selektoren übergeben, z.B.

$('#foobar')  
  
$('.bla')  
  
$('tbody th .blubb input.dideldum')

usw. ...

MfG,
EKKi

[suit]

Das ist zwar richtig - was suit aber vermutlich meinte, ist dass jQuery von Haus aus mehr und mächtigere Funktionen mitbringt ... die man bei der Benutzung von Prototype eben z.B. durch script.aculo.us "ergänzen" muss.

Richtig, das meinte ich. Ein Framework ist für meine zwecke nur sinnvoll, wenn es DOM-Manipulation/Traversing, Animationen und Ajax (oder vergleichbares) beherrscht.

Die Animations-/Effekt-Geschichte ist bei Prototype ziemlich kümmerlich.

IMHO besser: Du kannst der globalen Funktion $() als Parameter nicht nur die ID, sondern komplett CSS-kompatible Selektoren übergeben, z.B.

$('tbody th .blubb input.dideldum')[/code]

Das kann Prototype auch - allerdings heisst die Funktion dann $$() - diese kennen aber die wenigesten, drum neigt der Prototype-Benutzer dazu, alles mit IDs zuzupflastern.

[Gunnar Bittersmann]

@@EKKi:

nuqneH

Du kannst der globalen Funktion $() als Parameter nicht nur die ID, sondern komplett CSS-kompatible Selektoren übergeben, z.B. […]
$('tbody th .blubb input.dideldum')

Und hier kommt ins Spiel, dass man wissen sollte, was man tut. Nicht meckern, das Framework wäre langsam, wenn man den Mist selbst verbockt.

Such man bspw. von Elementen der Klasse "foo" alle Kinder der Klasse "bar", dann sollte man $('.foo>.bar') notieren, nicht $('.foo .bar').

Auch wenn das für den Ablauf des Scripts keinen Unterschied macht, für die Performanz tut es das. Es ist ein Unterschied, ob von einem Knoten nur deren Kindknoten bearbeitet werden müssen oder ob der gesamte Teilbaum unter dem Knoten traversiert werden muss.

Qapla'

[EKKi]

Mahlzeit Gunnar Bittersmann,

Und hier kommt ins Spiel, dass man wissen sollte, was man tut.

... und wissen sollte, ob man sich darauf verlassen kann, dass man für standardkonforme Software oder für vorsintflutliche Dinosaurier entwickeln "darf".

Nicht meckern, das Framework wäre langsam, wenn man den Mist selbst verbockt.

... oder wenn in Redmond ansässige Entwickler und in der heimischen Chefetage ansässige Entscheider den Mist verbocken.

Such man bspw. von Elementen der Klasse "foo" alle Kinder der Klasse "bar", dann sollte man $('.foo>.bar') notieren, nicht $('.foo .bar').

... außer natürlich für IrgendEinen Browser in gewissen Versionen (siehe "<http://de.selfhtml.org/css/formate/zentrale.htm#verschachtelte_elemente@title=Beachten Sie:>").

Oder sind die JS-Bibliotheken so schlau, korrekte CSS 2.0-Syntax so umzusetzen, dass auch der IE < 7 alle Elemente wie gewünscht findet?

MfG,
EKKi

[suit]

Oder sind die JS-Bibliotheken so schlau, korrekte CSS 2.0-Syntax so umzusetzen, dass auch der IE < 7 alle Elemente wie gewünscht findet?

Ja. Damit lassen sich sobar CSS3-Selektoren nutzen, auch wenn der Browser von CSS3 keine Ahnung hat :)

Darum ist für mich das wichtigste Argument für Frameworks eben die Selektor-Engine. Man hat dieselben Selektoren wie im CSS-File und muss nicht mit irgendwelchen teilweise sehr verkorksten DOM-Methoden herumhangeln bis man die nötigen Elemente findet wenn man im CSS ohnehin bereits die richtigen Selektoren hat, die man nur 1:1 kopieren muss.

[Gunnar Bittersmann]

@@EKKi:

nuqneH

Oder sind die JS-Bibliotheken so schlau, korrekte CSS 2.0-Syntax so umzusetzen, dass auch der IE < 7 alle Elemente wie gewünscht findet?

Ja, natürlich.

Das hat aber weniger mit Schlauheit zu tun denn damit, dass CSS und JavaScript völlig unterschiedliche Dinge sind. Die Script-Engine wird zur Selektion wohl kaum den CSS-Parser bemühen, sondern DOM-Funktionen.

jQuery benutzt (u.a.) eine an CSS angelehnte Syntax, um es dem Programmierer einfacher zu machen. Das bedeutet aber nicht, dass, wenn ein CSS-Parser eines Browsers mit CSS(!)-Kindselektoren nicht umgehen kann, jQuery $('.foo>.bar') diesem Browser nicht verständlich machen könnte.

Qapla'

[suit]

jQuery benutzt (u.a.) eine an CSS angelehnte Syntax, um es dem Programmierer einfacher zu machen.

Angelehnt ist nicht ganz richtig CSS3-Selektoren werden vollständig abgebildet - Sizzle fügt lediglich einige Ergänzungen hinzu - somit sind einige zusätzliche Dinge mit Sizzle möglich, die in CSS3 nicht möglich sind.

Das ist allerdings nicht immer ein Vorteil :)

[suit]

Such man bspw. von Elementen der Klasse "foo" alle Kinder der Klasse "bar", dann sollte man $('.foo>.bar') notieren, nicht $('.foo .bar').

Das kommt aber auf auf das Framework und die verwendete Selektor-Engine an. Es muss nicht zwangsläufig so sein - es gibt Frameworks bei denen div.foo schneller ist als .foo, es kann aber auch umgekehrt sein. Ebenso hängt es vom Browser ab.

In jQuery 1.4.1 ist z.B. div div unwesentlich langsamer als div>div, YUI 2.8 hingegen zeigt hier bereits deutliche Unterschiede (im Millisekundenbereich) - jeweils unter Opera 10.10.

Wieder jQuery und YUI unter Opera: jQuery ist es einerlei ob man div.foo, div[class=foo], .foo oder *[class=.foo]. YUI hingegen reisst bei .foo aus und wird extrem langsam.

[suit]

Prototype kann man auch out-of-the-box benutzen.

Das meinte ich nicht.

Das Prototype ziemlich aufgebläht ist, kann ich bestätigen. Aber ob es dadurch auch langsam ist, kann ich nicht sagen, denn ich habe mit bisher keinem anderen Framework gearbeitet.

Ich sagte nicht, dass es "dadurch" langsam ist, ich sagte dass es langsam ist - und nicht nur messbar sondern auch praktisch.

Prototype vereint also zwei entscheidende Nachteile: es ist riesig (und erhöht somit die Ladezeiten nicht unwesentlich) und ist nochdazu langsam.

[telofon]

Hi

Ich sagte nicht, dass es "dadurch" langsam ist, ich sagte dass es langsam ist - und nicht nur messbar sondern auch praktisch.

Danke für den tollen Link! Was haltet ihr von DOMAssistant? Scheint in meinem Test der schnellste zu sein.

Gruß
telofon

[suit]

Danke für den tollen Link! Was haltet ihr von DOMAssistant? Scheint in meinem Test der schnellste zu sein.

Das hängt stark vom Browser und dem verwendeten Rechner ab - du solltest dich auf keinen Fall davon blenden lassen, dass in einem Benchmark genau in einem Browser auf deinem Rechner irgendwas vorne liegt. Slickspeed ist nur eines der bekannteren Bechmarks auf diesem Bereich, darum wurde es von mir gewählt - es testet aber ansich nur die Selektor-Engine, nicht aber den Rest.

MooTools ist z.B. unter Opera 10.10 auf diesem Rechner (Q9400) lt. Slickspeed wesentlich langsamer als jQuery - in der Praxis ist da aber nicht so viel Unterschied. Ebenso ist Prototype auf diesem Rechner schneller als MooTools und YUI ist "irgendwo".

Letztlich musst du entscheiden, was für dich taugt und was nicht - meine aussage "jQuery is best" bezieht sich auf meinen Anwendungszweck, meine Anforderung und mein Zielgruppe - das ist sicher nicht 1:1 auf andere übertragbar.

Wenn man z.B. nur Selektoren benötigt und hart bestimmte Seitenteile ein&ausblendet, tuts eine reine Selektorengine wie z.B. Sizzle auch.

Notiere also zuerst deine Anforderungen und stelle dann konkrete Fragen - fragen wie "Was haltet ihr von DOMAssistant" sind eher weniger zielführend, da dir niemand eine wirklich qualifizierte Antwort geben kann.

[heinetz]

Hallo Forum,

danke schonmal für die Diskussion!

nach dem was ich bisher zu dem Theme gefunden und gelesen habe,
soll jquery schneller sein, es sollen mehr 3rdparty-Plugins
zu kriegen sein, aber soll auch insgesammt unsauberer gecoded
sein. Jquery scheint eher etwas für jeman zu sein, der sich
JS vom Hals halten will und ohne grosse Kenntnisse Effekte
zaubern will. Prototype soll dafür schwerer zu erlernen sein,
dafür aber sauberer gecodet sein.

Interessant dazu fand ich:

http://blog.thinkrelevance.com/2009/1/12/why-i-still-prefer-prototype-to-jquery

beste gruesse,
heinetz

[suit]

http://blog.thinkrelevance.com/2009/1/12/why-i-still-prefer-prototype-to-jquery

Seit diesem Artikel gabs große Minor-Releases - der erstere hat den kompletten Selektor-Core gegen Sizzle ersetzt. Trotzdem wird er immer wieder zitiert obwohl 2 Tage nach erscheinen dieses Artikels die neue jQuery-Version etwa 50% des Artikels obsolet gemacht bzw, entkräftet hat.

Der Abschnitt "Where Prototype Wins" ist unter dem Gesichtspunkt neuer Funtkionen/Methoden sowie dem übergeben von Kontexten direkt in den $-Funktion hinfällig.

Wenn man diesen Artikel also als Basis nimmt, "gewinnt" jQuery auf ganzer Linie.

[heinetz]

... für mich persönlich soll und kann dieser Artikel nicht
die Basis darstellen. Dazu hätte ich zu wenig Ahnung, wovon
ich rede. Ich hatte vielmehr den Eindruck, dass der Artikel
das beschreibt, was nach meiner kurzen Rechersche bei mir
persönlich hängen geblieben ist. Wohlgemerkt ohne den Anspruch
auf Richtigkeit.

Ich tendiere nach dieser Rechersche zu JQuery, weil es wohl
das meist genutze Framework ist, daher die sicher grösste
Community hat und sich viellleicht am Besten weiterentwickeln
wird. Aber in meinem Beitrag will und kann ich überhaupt
keine Postition übernehmen, sondern die Einschätzung derer
hören, von denen ich denke, dass Sie es beurteilen können.

beste guresse,
heinetz

[suit]

Community hat und sich viellleicht am Besten weiterentwickeln
wird. Aber in meinem Beitrag will [...] ich [...] die Einschätzung derer hören, von denen ich denke, dass Sie es beurteilen können.

Wie bei meiner Antwort auf telofon ist es dafür aber notwendig, deine Anforderungen zu kennnen.

Mit jQuery selbst machst du aber vermutlich wenig falsch - sowohl für den Einstieg alsauch für den Umstieg ist jQuery gut geeignet.

[heinetz]

wird. Aber in meinem Beitrag will [...] ich [...] die Einschätzung derer hören, von denen ich denke, dass Sie es beurteilen können.

Wie bei meiner Antwort auf telofon ist es dafür aber notwendig, deine Anforderungen zu kennnen.

logisch. Wenn ich konkrete Anforderungen hätte, wäre die
Antwort auf die Frage 'Welches Framework soll ich benutzen,
um diese Anforderungen sicher leicher beantwortet?' Ich habe
die Frage allerdings auch schon so unkonkret gestellt, weil
ich gerade keine konkreten Anforderungen habe, sondern einfach
gerade Zeit und Musse, mich gezielt weiterzubilden.

Mit jQuery selbst machst du aber vermutlich wenig falsch - sowohl für den Einstieg alsauch für den Umstieg ist jQuery gut geeignet.

... und genau das ist die Qualität einer Antwort, die mich in
meinem Situation weiterbringt: Auch ohne konkrete Anforderung
möchte ich gezielt lernen.

danke für den Rat!

heinetz

[molily]

Hallo,

einen weiteren guten Artikel zum Vergleich zweiter Frameworkansätze findest du hier:
http://jqueryvsmootools.com/
Wie gesagt, vieles davon trifft auch auf Prototype zu.

Mootools-Tutorial:
http://www.peterkroener.de/neue-artikelserie-mootools-fuer-die-massen-teil-1-mootools-im-ueberblick/

Mathias

[molily]

nach dem was ich bisher zu dem Theme gefunden und gelesen habe,
soll jquery schneller sein, es sollen mehr 3rdparty-Plugins
zu kriegen sein, aber soll auch insgesammt unsauberer gecoded
sein. Jquery scheint eher etwas für jeman zu sein, der sich
JS vom Hals halten will und ohne grosse Kenntnisse Effekte
zaubern will. Prototype soll dafür schwerer zu erlernen sein,
dafür aber sauberer gecodet sein.

Jein. Beide APIs haben ihre Stärken und Schwächen. Manches ist intutiv und konventionell umgesetzt, anderes weicht von etablierten Mustern ab oder ist unnötig kompliziert. Nicht alles, was die einem vorsetzen, erspart einem Arbeit oder lässt bessere Schreibweisen zu.

Prototype ist schwerer, weil es einen umfassenderen Anspruch hat, der von der Übertragung von OOP aus Ruby nach JavaScript herrührt. jQuery ist gekapselt und lässt die Native Objects (Kernobjekte wie Array, String, Date usw.) unangetastet, während Prototype diese und die Elementobjekte direkt erweitert. Das gibt dem Programmierer mehr Möglichkeiten, aber erfordert auch ein Verständnis dieser Paradigmen. (Das genannte underscore.js versteht sch als jQuery-Zusatz, weil jQuery im Gegensatz zu Prototype eben nicht diese Möglichkeiten in gleicher Ausdrucksstärke bietet.)

»Sauber gecodet« sind mittlerweile beide, meinem Eindruck nach wird in jQuery mehr Arbeit in Unit Testing und Qualitätssicherung gesteckt. Trotzdem finden sich in neuen Versionen fiese Bugs, Undurchdachtes und wenig Robustes. Letztlich schleppt jQuery architektonische Fehlentscheidung mit sich herum (die aus Gründen der Abwärtskompatibilität nicht so einfach geändert werden können) und macht zum Teil auch neue. Das nervt natürlich auf Dauer.

Auch wenn sich das jQuery-Team sehr bemüht, das Verhältnis von offenen Bugs und Schwachstellen ist meinem Empfinden in letzter Zeit nach wieder zum Negativen ausgeschlagen. Es ist einfach ein riesiges Softwareprojekt mit entsprechendem Pflegebedarf geworden. Dafür ist die Community und die Nutzerschar sehr groß und aktiv. Der allgemeine Trend geht, wie die Vorredner sagten, tatsächlich zu jQuery, während Prototype vergleichsweise eingeschlafen wirkt. Diese Verengung auf jQuery ist bedauerlich, weil andere, weniger etablierte Frameworks zum Teil viel clevere Ideen haben.

Anfänger und Leute, die JavaScript eigentlich hassen, greifen oft direkt zu jQuery. jQuery hat sicher diesen zweischneidigen Ruf, JavaScript für Nicht-JavaScripter zugänglich zu machen. Ich denke, jQuery legt einen, weil es so gekapselt und begrenzt ist, weder auf einen gänzlich schlechten noch auf einen wirklich guten Programmierstil fest. Den muss der Programmierer mitbringen, und wenn er das tut, dann lassen sich auch mit jQuery vernünftig geordnete Programme schreiben. Wer schon Erfahrung in JavaScript hat, der wird das schnell merken, die Möglichkeiten der Biliothek mit Gewinn nutzen und mit eigenen Best Practises deren Schwächen nivellieren.

jQuery kann wirklich auf ein großes Plugin-Arsenal zurückgreifen, allerdings sind viele davon höchstens als Grundlage und Ideengeber brauchbar. Aber erfahrenen JavaScript-Programmierern ist das vermutlich vertraut.

Mathias

[Kai345]

[latex]Mae  govannen![/latex]

Ich mache nun seit mehr als 10 Jahren
mit JS rum, hab Spass daran und bisher immer mehr oder
weniger das hinbekommen, was ich brauchte.

Dann bleib einfach dabei.

Ich habe mich
nie mit einem dieser Frameworks anvertraut, weil ich die
Notwednigkeit nicht gesehen habe, sehe allerdings, wie
sie zunhemend verwendet werden und denke, dass ich mich
doch mal damit auseinander setzen sollte.

Nö - nur weil Millionen Lemminge in den Tod gehen (ja, ich weiß, Legende) muß man nicht selber ein Lemming werden.
Gilt auch und vor allem für JS-Framewürgs. Wenn du bisher ohne zurechtgekommen bist, gibt es eigentlich keinen Grund, jetzt damit anzufangen. Außerdem macht man sich abhängig von einer bestimmten, JS-fernen Syntax und ist bei Framework-internen Problemen (und die kommen sicher, wenn man den Werdegang von z.B. jquery bisher betrachtet) aufgeschmissen und muß auf einen Fix warten.
Das Forum hier benutzt z.B. immer noch eine uralte Version, weil der Code mit Folge-Versionen nicht richtig lief. Ob es mit noch neueren Verionen laufen würde oder immer noch nicht?  Keine Ahnung.

Jedenfalls; daß ein bisher funktionsfähiger Code mit einer neuen Version nicht mehr läuft ist schon KO-Kriterium. Bei selbstgeschriebenem Code hat kann den Bug beheben, bei Frameworks muß man auf einen Fix warten oder auf Updates verzichten.

Braucht man sowas überhaupt?

Nein.

ist das eine als Arbeits-
erleichterung zu werten?

Nicht wirklich. Es erscheint auf den ersten Blick vielleicht so, aber im Endeffekt ist man bei eigenen Sachen besser dran. Man weiß, was man gemacht hat, wo man im Fehlerfall ansetzen muß, was genau passiert usw.

Und es geht durch Funktionen, die Funktionen aufrufen, die Funktionen aufrufen die Funktionen aufrufen .... auf die Performance. Ich habe gerade mal mit jQuery 1.3.2 (hatte ich gerade irgendwoher im Cache) einen Test gemacht:

Etwas einfaches wie $('#foo) zeigt beim Erst-Aufruf im Firebug 172 Funktions-Aufrufe, davon allein 16 Mal each() und 11 Mal extend().

Soll man von einem ganz die Finger lassen?

Ja. Wenn man schon ein paar Jahre mit JS arbeitet, dürfte man ohnehin viele Funktionen bereits geschrieben haben.

Welches setzt sich durch?

Leider jQuery

Cü,

Kai

[molily]

Das Forum hier benutzt z.B. immer noch eine uralte Version, weil der Code mit Folge-Versionen nicht richtig lief.

Das ist Quatsch. Wie kommst du darauf?
Der Code, der hier jQuery verwendet, ist vielleicht 20 Zeilen lang.
Dass hier eine uralte Version verwendet wird, liegt daran, dass sie noch niemand aktualisiert hat.

Ob es mit noch neueren Verionen laufen würde oder immer noch nicht? Keine Ahnung.

Der Grund, warum jQuery hier nicht aktualisiert wurde, ist ein jQuery-Bug gewesen. </archiv/2009/6/t187879/#m1249697>

Jedenfalls; daß ein bisher funktionsfähiger Code mit einer neuen Version nicht mehr läuft ist schon KO-Kriterium.

Keine Ahnung, aber FUD verbreiten. Das passt zu deiner Haltung, die du hier propagierst: Was der Bauer nicht kennt, das schaut er sich erst gar nicht an, denn er weiß bereits alles und alles besser als andere.

M.

[Kai345]

[latex]Mae  govannen![/latex]

Das Forum hier benutzt z.B. immer noch eine uralte Version, weil der Code mit Folge-Versionen nicht richtig lief.

Das ist Quatsch. Wie kommst du darauf?

Ich hab es mir wohl nicht richtig gemerkt bzw. ais der Erinnerung in einen falschen Zusammenhang gebracht. So what, lag ich _damit_ halt falsch. Daß jQuery und die anderen Frameworks meist überflüssig und teilweise problematisch sind [z.B. jQuerys attr() trotz jehrelanger Hinweise], ändert daran aber nichts.

Keine Ahnung, aber FUD verbreiten. Das passt zu deiner Haltung, die du hier propagierst: Was der Bauer nicht kennt, das schaut er sich erst gar nicht an, denn er weiß bereits alles und alles besser als andere.

Gähn. Wie gut, daß _du_ genau weißt, was _ich_ früher mit jQuery gemacht habe. Weißt du nicht? Na dann kannst du es mir ja trotzdem unterstellen, paßt ja so schön, gelle?

Cü,

Kai

[molily]

Wie gut, daß _du_ genau weißt, was _ich_ früher mit jQuery gemacht habe. Weißt du nicht?

Es ist doch völlig egal, was du mit jQuery gemacht hast oder nicht. Da fragt jemand bei »SELFHTML« und die Antwort ist:

1. Bleib bei dem, was du kennst
2. Setze dich gar nicht erst mit Frameworks auseinander
3. Es lohnt sich nicht, dir selbst eine Meinung zu bilden
4. Man braucht Frameworks nicht und niemals
5. Frameworks sind scheiße programmiert, fehlerhaft und nicht abwärtskompatibel
6. Alles selbst schreiben ist das Beste

Ja, dein Posting war so pauschal und einseitig.

Mathias

[Kai345]

[latex]Mae  govannen![/latex]

Wie gut, daß _du_ genau weißt, was _ich_ früher mit jQuery gemacht habe. Weißt du nicht?

Es ist doch völlig egal, was du mit jQuery gemacht hast oder nicht. Da fragt jemand bei »SELFHTML« und die Antwort ist:

Schön, wie du immer wieder den Kontext wechselst. Der obige Satz bezog sich ausschließlich auf dein:

Keine Ahnung, aber FUD verbreiten. Das passt zu deiner Haltung, die du hier propagierst: Was der Bauer nicht kennt, das schaut er sich erst gar nicht an, denn er weiß bereits alles und alles besser als andere

in dem du mir vorwirfst, keine Ahnung zu haben und jquery nicht einmal angeschaut zu haben etc. und hat mit der ursprünglichen Frage genau _nichts_ mehr zu tun. Versuch also bitte nicht, hier wieder einen Zusammenhang zum Rest der Diskussion herzustellen, um davon abzulenken.

Ja, dein Posting war so pauschal und einseitig.

Na wie gut, daß die Postings der "Framework-Befürworter" alle nicht-pauschal und völlig ausgewogen sind und sämtliche Vor- und Nachteile gleichbedeutend beleuchtet haben. Bei Zustimmung ist es demzufolge ok, einseitig zu sein, bei Kritik aber nicht? Kannst du es nicht ertragen, daß es andere Meinungen gibt?

Aufgrund des persönlich beleidigenden Tonfalls, den Du direkt bei deiner ersten Antwort an mich angeschlagen hast sowie zum Nutzen des Forums, das auf solche "Gespräche" gut verzichten kann, habe ich ehrlich gesagt keine Lust auf eine weitere Diskussion mit dir, insbesondere, da ich diesen Stil schon von früher her kenne (bei weitem nicht nur mir gegenüber btw.)

Cü,

Kai

[molily]

Schön, wie du immer wieder den Kontext wechselst. Der obige Satz bezog sich ausschließlich auf dein (...) in dem du mir vorwirfst, keine Ahnung zu haben

»Keine Ahnung!« war dein eigener Ausspruch, den ich wiederaufgenommen habe. Die dahinterliegende Haltung, dass du es nicht für nötig hältst, Aussagen zu überprüfen (»Keine Ahnung, mir egal, ich plappere es trotzdem mal weiter, denn es passt mir gerade so schön in mein Framework-Bashing hinein«), habe ich damit kritisiert.

und jquery nicht einmal angeschaut zu haben etc.

Das habe ich nirgendwo geschrieben.

Na wie gut, daß die Postings der "Framework-Befürworter" alle nicht-pauschal und völlig ausgewogen sind und sämtliche Vor- und Nachteile gleichbedeutend beleuchtet haben.

Behaupte ich gar nicht. Deren Äußerungen in diesem Thread klangen allerdings weitaus differenzierter und erlaubten zumindest ein »Mach dir selbst ein Bild«.

Bei Zustimmung ist es demzufolge ok, einseitig zu sein, bei Kritik aber nicht?

Die Kritik in deinem Rundumschlag-Posting muss man leider mit der Lupe suchen und erst einmal verorten.

Aufgrund des persönlich beleidigenden Tonfalls ...

Nichts davon entspricht den Tatsachen.
Du hast gewisse Fakten verdreht und dies zu Argumenten gemacht; das habe ich richtiggestellt. Ferner hast du ein inhaltlich fragwürdiges, weil undifferenziertes Posting geschrieben; das habe ich als solches bezeichnet: pauschal und einseitig.

Mathias

[suit]

Na wie gut, daß die Postings der "Framework-Befürworter" alle nicht-pauschal und völlig ausgewogen sind und sämtliche Vor- und Nachteile gleichbedeutend beleuchtet haben.

Nachdem ich mich in diesem Thread als "Framework-Befürworter" sehe, kannst du mir bitte erläutern, was an der knackigen Zusammenfassung

Es ist eine (imho) enorme Arbeitserleichterung wenns um DOM-Manipulation, Animationen oder Ajax geht - der Nachteil: es geht auf die Bandbreite, da die Frameworks auch übertragen werden müssen."

einseitig ist? Ich würde mich diesbezüglich gerne verbessern um in zukunft mehr Seiten und vor allem gleichberechtigter zu beleuchten.

Die Bugs, konzeptionelle Fehler der Frameworks oder vergleichbares sind für mich übrigens kein Argument - die gibts bei selbst geschriebenen Code bzw. Codeschnipseln aus "dem Internet" ebenfalls.

[Kai345]

[latex]Mae  govannen![/latex]

Na wie gut, daß die Postings der "Framework-Befürworter" alle nicht-pauschal und völlig ausgewogen sind und sämtliche Vor- und Nachteile gleichbedeutend beleuchtet haben.

Nachdem ich mich in diesem Thread als "Framework-Befürworter" sehe, kannst du mir bitte erläutern, was an der knackigen Zusammenfassung

[...]

einseitig ist? Ich würde mich diesbezüglich gerne verbessern um in zukunft mehr Seiten und vor allem gleichberechtigter zu beleuchten.

Dein Posting ist völlig in Ordnung. Du mißverstehst, was ich sagen will:

Molily hat meinem Posting Einseitigkeit vorgeworfen. Wie überraschend, wenn man gegen etwas argumentieren will.

Nur: Dann muß man diesen Maßstab bitte auch auf _jedes_ andere Posting anwenden, und _jedes_ andere Posting _muß_ dem standhalten, und zwar unabhängig davon, welche Richtung es vertritt, und nicht nur bei Postings, die sich *gegen* die eigene Meinung aussprechen, ansonsten wirkt dieser spezielle Vorwurf leicht unglaubwürdig, weil man Kriterien nicht nach Gutdünken nur für einen Teil der Postings anwenden darf, der einem gerade (nicht) in den Kram passt.

Cü,

Kai

[Kai345]

[latex]Mae  govannen![/latex]

[latex]Mae  govannen![/latex]

Na wie gut, daß die Postings der "Framework-Befürworter" alle nicht-pauschal und völlig ausgewogen sind und sämtliche Vor- und Nachteile gleichbedeutend beleuchtet haben.

Nachdem ich mich in diesem Thread als "Framework-Befürworter" sehe, kannst du mir bitte erläutern, was an der knackigen Zusammenfassung

[...]

einseitig ist? Ich würde mich diesbezüglich gerne verbessern um in zukunft mehr Seiten und vor allem gleichberechtigter zu beleuchten.

Dein Posting ist völlig in Ordnung. Du mißverstehst, was ich sagen will:

Molily hat meinem Posting Einseitigkeit vorgeworfen. Wie überraschend, wenn man gegen etwas argumentieren will.

Nur: Dann muß man diesen Maßstab bitte auch auf _jedes_ andere Posting anwenden, und _jedes_ andere Posting _muß_ dem standhalten, und zwar unabhängig davon, welche Richtung es vertritt, und nicht nur bei Postings, die sich *gegen* die eigene Meinung aussprechen, ansonsten wirkt dieser spezielle Vorwurf leicht unglaubwürdig, weil man Kriterien nicht nach Gutdünken nur für einen Teil der Postings anwenden darf, der einem gerade (nicht) in den Kram passt.

Cü,

Kai

.

Cü,

Kai

[molily]

Und es geht durch Funktionen, die Funktionen aufrufen, die Funktionen aufrufen die Funktionen aufrufen .... auf die Performance.

Als wäre das so weit hergeholt. Erstmal wäre festzuhalten: Diese Arbeitsweise liegt in der Natur der Sprache. In einer funktionalen Programmiersprache operiert man üblicherweise mit Lambdas über Listen. Zumindest wenn man die Operationen wiederverwendbar halten will. Und das tut eine Bibliothek sinnigerweise.

Natürlich kann man in JavaScript auch imperativ wie BASIC, C oder PHP schreiben. Sämtliche Listen mit konventionellen for-Schleifen durchlaufen und den Code immer wieder im Schleifenkörper wiederholen. Ja, das muss man tun, wenn es Performance das wichtigste, alles andere überragende Ziel ist. Weil Funktionsaufrufe immer noch ziemlich viel kosten. Aber eine solche Art zu Programmieren erzeugt grässlichen Code.

jQuery ist für den Umgang mit Knotenlisten gedacht. Der jQuery-Konstruktor erzeugt eine Liste. jQuery.prototype enthält allesamt map-, filter-, each-, reduce- usw. Funktionen. Prototype ist da aufgrund seiner Ruby-Abstammung noch konsequenter, weil es erst einmal unter JS die funktionale Programmierung möglich macht, die Ruby auszeichnet. Wie man es auch dreht und wendet: Die meisten gut strukturierten Bibliotheken enden bei einem »Funktionen rufen Funktionen auf, die Funktionen aufrufen ...«.

Die Performance-Optimierung drehte sich daher in letzter Zeit darum, immer nur soviele Funktionen aufzurufen, wie gerade nötig. Dem sind naturgemäß Grenzen gesetzt bei einer API, die völlig flexibel in seiner Anwendung sein soll. Dieses Thema ist zweischneidig und ebenso differenziert müsste man es diskutieren.

Man kann sich nun quer stellen und JavaScript wie PHP schreiben. Das muss man leider tun, wenn es auf jede Millisekunde ankommt. Das ist aber nur äußerst selten der Fall. Wir schreiben aus ganz bestimmten Gründen nicht mehr ständig Assembler oder C, sondern nutzen vielseitige Sprachen wie JavaScript, mit der sich Probleme sehr konzis und aussagekräftig in Code ausdrücken lassen. Auch mit funktionalem JavaScript lässt sich performanter Code schreiben. Performance ist hier natürlich relativ zu sehen: Relativ dazu, dass man Probleme in gut lesbarem Code sehr schnell und sauber lösen kann.

Man kann aber auch versuchen, die Programmierparadigmen, die Javascript ermöglicht, auszunutzen. Nichts anderes machen die auf dem Markt verfügbaren JavaScript-Bibliotheken mit unterschiedlichen Ansätzen, in unterschiedlicher Codequalität und in unterschiedlicher Produktionsreife. Es lohnt sich auf jeden Fall, sich diese verschiedenen Arten der Programmierung anzuschauen. Und unter der Haube der Abstraktion zu schauen, wie häufige Aufgaben tatsächlich gelöst werden. Das muss nicht unbedingt uneingeschränkt besser sein als das, was man bereits kennt, aber da steckt zum Teil jahrelang gewonnenes Know-How und Optimierung drin.

Ich habe gerade mal mit jQuery 1.3.2 (hatte ich gerade irgendwoher im Cache) einen Test gemacht:

Etwas einfaches wie $('#foo) zeigt beim Erst-Aufruf im Firebug 172 Funktions-Aufrufe, davon allein 16 Mal each() und 11 Mal extend().

Bei jQuery 1.4.1 sind es nur noch zwei Aufrufe. Und was sagt uns das? Ziemlich wenig, denn mit was soll man diesen Wert vergleichen. Eine Selektor-Engine und ein Wrapper für Knoten bzw. Knotenlisten ist eben nicht mit getElementById() und der nackten DOM-API vergleichbar.

Mathias

[suit]

Man kann sich nun quer stellen und JavaScript wie PHP schreiben. Das muss man leider tun, wenn es auf jede Millisekunde ankommt. Das ist aber nur äußerst selten der Fall. Wir schreiben aus ganz bestimmten Gründen nicht mehr ständig Assembler oder C, sondern nutzen vielseitige Sprachen wie JavaScript, mit der sich Probleme sehr konzis und aussagekräftig in Code ausdrücken lassen. Auch mit funktionalem JavaScript lässt sich performanter Code schreiben. Performance ist hier natürlich relativ zu sehen: Relativ dazu, dass man Probleme in gut lesbarem Code sehr schnell und sauber lösen kann.

Du hast einen entscheidenden Punkt vergessen: die "Performance" ist heute praktisch nicht mehr relevant da ein Gros der Geräte bei weitem schnell genug ist um auch schlechten, langsamen JavaScript-Code schnell und sauber auszuführen (da muss man schon arge Schnitzer einbauen).

Imho ist ein wirkliches Argument (für meinen Zweck) lediglich die verbrauchte Bandbreite - eine durchschnittliche Inhaltsseite bei der Webseite an der ich grade Arbeite hat etwa 11 KiB HTML-Quelltext und 7 KiB CSS.

Wenn ich hier nun jQuery verwende, habe ich 23 KiB extra nur durch das JavaScript-Framework - allerdings habe ich alles dabei was ich üblicherweise brauche und kann mit wenigen weiteren Zeilen alle mögliche realisieren.

Prototype mit script.aculo.us hingegen hat in Minimalkonfiguration bereits 33 KiB (self hosted) - wenn ich die Sache hingegen über ein CDN einbinde - z.B. die Google AJAX Libraries API - mute ich dem Kunden schon 139 + 2 KiB extra zu. Das ist eine Sache die in diesem Kontext für mich nichtmal mehr ansatzweise vertretbar ist.

[EKKi]

Mahlzeit suit,

Imho ist ein wirkliches Argument (für meinen Zweck) lediglich die verbrauchte Bandbreite - eine durchschnittliche Inhaltsseite bei der Webseite an der ich grade Arbeite hat etwa 11 KiB HTML-Quelltext und 7 KiB CSS.

Wenn ich hier nun jQuery verwende, habe ich 23 KiB extra nur durch das JavaScript-Framework - allerdings habe ich alles dabei was ich üblicherweise brauche und kann mit wenigen weiteren Zeilen alle mögliche realisieren.

In meinen Augen wird bei derartigen Überlegungen und Totschlagargumentationen wie "Das verschwendet aber zu viel Bandbreite!" sehr oft übersehen, dass es ohne Weiteres möglich sein sollte, *DIE* zentral verwendete JS-Bibliothek (welche es auch immer sein sollte) vom Browser cachen zu lassen ... das Ganze kann man sogar ansatzweise steuern, wenn man anstatt auf die Bibliothek direkt ersatzweise auf ein Server-seitiges Skript referenziert, welches Content-Type, Cache-Control und andere benötigte HTTP-Header auf die gewünschten Werte setzt (um z.B. nach einem Upgrade der Bibliothek das Neuladen zu erzwingen) und anschließend die aktuelle gewünschte JS-Bibliothek 1:1 durchreicht.

MfG,
EKKi

[suit]

In meinen Augen wird bei derartigen Überlegungen und Totschlagargumentationen wie "Das verschwendet aber zu viel Bandbreite!" sehr oft übersehen, dass es ohne Weiteres möglich sein sollte, *DIE* zentral verwendete JS-Bibliothek (welche es auch immer sein sollte) vom Browser cachen zu lassen ... das Ganze kann man sogar ansatzweise steuern, wenn man anstatt auf die Bibliothek direkt ersatzweise auf ein Server-seitiges Skript referenziert, welches Content-Type, Cache-Control und andere benötigte HTTP-Header auf die gewünschten Werte setzt (um z.B. nach einem Upgrade der Bibliothek das Neuladen zu erzwingen) und anschließend die aktuelle gewünschte JS-Bibliothek 1:1 durchreicht.

Darum binde ich derartige Frameworks idR. über die Google AJAX Libraries API ein - dort wird das schon für mich erledigt und die Wahrscheinlichkeit ist hoch, dass der Benutzer bereits auf einer Seite war, die ebenfalls dasselbe Framework einbindet.

Nur ist für mich der Faktor "erster Seitenbesuch muss einen guten Eindruck machen" äußerst wichtig - viele Besucher kommen über Suchmaschinen und sehen sich überhaupt nur eine Seite an, wenn diese dann lahmt und langsam läd, kann das schon ein Ausstiegskriterium sein bevor die Seite überhaupt fertig geladen ist.

[molily]

Hallo,

Du hast einen entscheidenden Punkt vergessen: die "Performance" ist heute praktisch nicht mehr relevant da ein Gros der Geräte bei weitem schnell genug ist um auch schlechten, langsamen JavaScript-Code schnell und sauber auszuführen (da muss man schon arge Schnitzer einbauen).

Natürlich spielt Runtime-Performance immer noch eine Rolle, weil die JavaScript-Anwendung im Web umfangreicher und komplexer wird. Frameworks wie jQuery werden zunehmend für große JavaScript-lastige Projekte verwendet (und damit meine ich nicht einmal RIAs). Tausende Leute sind tagtäglich damit beschäftigt, JavaScripte auf Basis von Frameworks zu optimieren.

Allerdings sind wahrscheinlich 90% der Framework-Anwendungen vergleichsweise trivial, sodass Komplexität in der Bibliothek die Runtime-Performance nicht nennenswert beeinflusst. Das stimmt sicher: Für ein bisschen DOM-Querying, DOM-Traversing und Event-Handling auf regulären Websites ist selbst das lahmste Framework kein Bottleneck, zumindest nicht mit aktuellen JS-Engines. Die übliche Website verwendet jQuery für Aufklapp- und Einblendeffekte, für Menüs, Formularvalidierung und Lightboxen. In diesem Kontext ist das größte Performanceproblem die Ladezeit der Bibliothek selbst und man muss wissen, wie man damit umzugehen hat (z.B. Scripte am Ende des Dokuments einbinden, CDNs nutzen usw., wie du sagst).

Sobald es aber etwas komplexer wird, dann muss man auch für jQuery & Co entsprechende Runtime-Optimierungstechniken kennen. Welche wieder JavaScript-Programmierfähigkeiten und tiefergehendes Verständnis erfordern. In dieser Größenordnung merkt man es tatsächlich, wenn jQuery bei $('#id') nicht mehr 176, sondern nur noch 2 Funktionsaufrufe tätigt.

Mathias

[Cheatah]

Hi,

ich stimme der Meinung zu, dass man ein Framework nur dann einsetzen sollte, wenn die Vor- die Nachteile überwiegen, unter Einbeziehung aller Faktoren wie Performance und Dateigewicht. Oft genug brauchst Du kein Framework, selbst wenn Dir eines helfen würde. Aus dieser Betrachtung kristallisiert sich u.U. auch tatsächlich ein bestimmtes Framework heraus.

Lautet das Ergebnis lediglich "pro Framework", und die Entscheidung prototype.js ./. jQuery bleibt offen, so habe ich eine glasklare Empfehlung: Früher habe ich mit prototype.js gearbeitet, was umständlich und zäh war. Die Objekte sind (in mehreren Bedeutungen des Wortes) überladen. jQuery hingegen schreibt und liest sich fließend, ist mächtig, im Vergleich äußerst performant, gut gepflegt und hat eine umfangreiche Community. Ich kann nicht sagen, dass bei prototype.js der Nutzen höher war als der Aufwand, während ich mich täglich an jQuery erfreue.

Aber wie gesagt: Ein Framework, egal welches, ist kein pauschales Allheilmittel. Es muss unbedingt im Einzelfall betrachtet werden, ob es sich wirklich lohnt.

Cheatah

[molily]

Hallo,

die heutigen JavaScript-Frameworks decken alle ein Grundset an typischen Aufgaben ab, die beim DOM-Scripting anfallen. Sie unterscheiden sich daher wenig unter der Haube, sondern gleichen sich diesbezüglich an. - Wenn du zehn Jahre JavaScript programmiert hast, dann wirst du vieles davon (wiederer)kennen.

Die Frameworks unterscheiden sich vielmehr in den Paradigmen und Entwurfsmustern, denen der Abstraktionlayer folgt. Diese entstammen zum Teil anderen Programmiersprachen und betonen unterschiedliche Aspekte von JavaScript. Alle haben ihre legitimen Anwendungsbereiche und ihre Vor- und Nachteile. Letztlich ist es auch Geschmackssache, mit welchen Konzepten der Einzelne besser zurechtkommt.

Z.B. jQuery und Prototype bieten einen vergleichbaren Funktionsumfang und eine allgemeine Ausrichtung, aber die Art und Weise, wie man ein Problem löst, kann sich stark unterscheiden. Bibliotheken wie Dojo/YUI 2, YUI 3 und fusejs bieten noch einmal ganz andere Ansätze. Mootools hingegen ähnelt konzeptionell stark Prototype. DOMAssistant und weitere kleinere greifen Ideen von jQuery auf.

Es sind einfach verschiedene Philosophien, Code zu strukturieren und Probleme in Algorithmen auszudrücken. Kein Framework beansprucht für sich, alle Probleme lösen zu wollen. Es gibt unzählige Bibliotheken mit besonderem Ensatzbereich (z.B. ExtJS und qooxdoo für Ajax-Anwendungen) sowie Zusätze zu größeren Bibliotheken (z.B. Scriptaculous/Scripty2 für Prototype, underscore.js für jQuery).

Pauschalaussagen wie »XY ist schneller« halten nicht mehr als ein paar Monate, bis eine andere Bibliothek den bisherigen Spitzenreiter in puncto Geschwindigkeit unterbietet. Aufgrund der besagten Unterschiede ist auch keine Bibliotheken »besser«, es kommt immer auf den Anwendungsfall und weitere Kriterien an, z.B. auf die Erfahrung und den Hintergrund des Programmierers.

Mit Prototype und jQuery für allgemeines DOM-Scripting solltest du dich auf jeden Fall auseinandersetzen. Am besten mit beiden dieselbe Aufgabe versuchen umzusetzen, damit du siehst, wie sich die unterschiedlichen Herangehensweisen in der Praxis anfühlen und wo sich Stärken und Schwächen abzeichnen. Daraus kannst du nur lernen und letztlich zwingt dich niemand, dann nur noch mit Frameworks zu programmieren. Es sind bloß Beispiele für mögliche Software-Architekturen, die du auf deine eigene Programmierung und deine eigenen Bibliotheken gewinnbringend anwenden kannst oder auch nicht.

Zuletzt noch ein paar Texte:
http://matthiasschuetz.com/javascript-framework-matrix/de/
http://www.b-list.org/weblog/2007/jan/22/choosing-javascript-library/
http://forum.de.selfhtml.org/archiv/2008/8/t176131/#m1158392
http://aktuell.de.selfhtml.org/weblog/javascript-bibliotheken
http://aktuell.de.selfhtml.org/artikel/javascript/organisation/#ausblick
http://molily.de/weblog/javascript-zukunft-2010#js-zukunft-5
http://molily.de/js/bibliotheken.html

Grüße,
Mathias

[jobo]

Hallo,

ein schöner Beitrag für der/die/das SELF-Wiki...

Gruß

jobo