ABAKUS

Hi,

also ich würde Dir zu Prototype raten.

- ist sehr sparsam aufgebaut.
- erfüllt soweit ich das überschaue alle Deine Anforderungen.
- wird gut gepflegt.
- gut dokumentiert.
- für mich persönlich ist prototype DER Standard.
- kann dennoch mit Frameworks, die drauf aufbauen erweitert werden. (script.aculo.us, Rico oder wenn Du es ganz dick brauchst auch ext)

JQuery dagegen, obwohl es offensichtlich eine grosse Community hat, wirkt wie eine ständige Baustelle. Mit JQuery lassen sich zwar jede Menge tolle Effekte herbeizaubern. Aber egal was man bauen möchte es gibt tausende von Abhängigkeiten und in der Doku findet man dann nur veraltete oder unvollständige Beschreibungen. JQuery ist meiner Meinung nach eher die zweite Wahl. Oder anderst. JQuery ist gut für den schnellen Effekt, aber nicht wirklich toll, wenn man damit arbeiten will.

Ausser Mojo, um das es etwas ruhig geworden ist, und was ich nicht unbedingt in der Gewichtsklasse von Prototype und JQuery sehe, fällt mir gerade kein anderes Framework ein.

Achso zu deiner Frage. Mir ist leider kein Vergleichschart bekannt

Sonnige Grüsse
HaPe

Danke fuer die Infos. xajax kennste nicht, oder? Ein bisschen Sorge machen mir die ganzen Bindings heutzutage.. denn der Browser muss sich das ja alles "irgendwie merken" und wird dadurch hoffentlich nicht erheblich langsamer.. bislang versuchte ich immer moeglichst "keep it simple" zu arbeiten, z.B. dass ein Object Array ueber int ids aufgebaut war etc. zu Gunsten hoeherer Performance..

> JQuery dagegen, obwohl es offensichtlich eine grosse Community hat, wirkt wie

Bei mir hinterliess JQuery sogar den Eindruck dass man durch JQuery noch mehr Code schreiben muss, als man es mit nacktem nativem Javascript schreiben muesste. Z.B. muss man functions oder ein simples onload nochmal irgendwie in JQuery kapseln und sich dabei schwer verkuensteln. Teilweise kann dann der "Code" wie "Latex" wirken: mehr Kunst im Schreiben als im Inhalt

> in der Doku findet man dann nur veraltete oder unvollständige Beschreibungen.

oder ca. 50 varianten, so ging es mir als ich nur wissen wollte wie man ein event an ein formular element binded.

Airport1 hat geschrieben:Gibt es sowas wie eine Vergleichsmatrix (wie fuer CMS) auch fuer derzeit verbreitete Ajax-Bibliotheken?

Mir fällt nur https://www.domassistant.com/slickspeed/ ein. Das ist allerdings keine Eigenschaftsübersicht, sondern ein Geschwindigkeitstest, der zudem nicht AJAX betrifft - da gibt es javascriptseitig nichts zu messen -, sondern den Zugriff via CSS-Selektoren.

JQuery … Z.B. muss man functions oder ein simples onload nochmal irgendwie in JQuery kapseln

Dass man Funktionen einkapseln müsse, ist so per se Unsinn, ich wüsste jetzt auch nicht, wie du überhaupt auf die Idee gekommen sein könntest. Ich habe mich aber zugegebenermaßen auch noch nicht sonderlich mit JQuery beschäftigt, nur ein wenig rumgespielt.

Die Sache mit onLoad betrifft alle, die Seiteninhalte mittels DOM manipulieren o.ä. wollen (also eigentlich so ziemlich jeden, der heute mit Javascript zu tun hat). Das Problem bei onLoad ist, dass das Ereignis bei den meisten Browsern erst dann eintritt, wenn die Seite komplett geladen ist, insbesondere mitsamt sämtlicher Bilder - und das kann naturgemäß dauern. Die Seitenstruktur selbst kann aber schon wesentlich früher stehen, dementsprechend kann auch die Abarbeitung gewisser Funktionalitäten früher beginnen.
Genau da greift die vermeintliche onLoad-Kapselung. $(document).ready() wird früher ausgeführt als window.onLoad. Das ist also eine durchaus sinnvolle Alternative, unnötige Wartezeiten bzw. Verwirrung beim Besucher zu vermeiden. Alternative, weil es dir frei steht, weiterhin onLoad zu nutzen. Und diesen Weg gibt es übrigens nicht nur bei JQuery.

Mehr zu onLoad findest du unter https://dean.edwards.name/weblog/2005/09/busted/ und https://dean.edwards.name/weblog/2006/06/again/

oder ca. 50 varianten, so ging es mir als ich nur wissen wollte wie man ein event an ein formular element binded.

Ich sehe im Kapitel Events unter Event Handling genau fünf Einträge, von denen nach kurzem Überfliegen der Beschreibungen nur zwei in Frage kommen, eine davon nennt sich, Überraschung, bind().
Für Tippfaule gibt es weiter unten auch noch Hilfsfunktionen zum Anbinden von Standardereignissen, die allesamt, wen wundert's, den Namen des jeweiligen Ereignisses tragen und somit leicht auszusortieren sein sollten.

Mich dünket, du hast eher keine Lust, mal einen vernünftigen Blick in die Anleitung zu werfen, als dass das alles so grausig unübersichtlich wäre :)

Eigentlich brauch ich nur den "Unterbau"
[…]
- grundlegender Ajax-Support
- Suggest, Pagination, Object+Form Edit/Load/Save/Cache..

„Eigentlich nur den Unterbau“ bzw. Ajax zu benötigen, aber die Sachen im zweiten Punkt nennen, scheint mir ein krasser Widerspruch zu sein. Solche fortgeschrittenen Anwendungen wie in Punkt 2 wirst du wohl in keiner reinen Javascript-Bibliothek finden, weil sie serverseitige Unterstützung benötigen.

Welcher Funktionsumfang nun für dich der richtige ist, kann ich wegen dieses Widerspruchs nicht sagen, ich vermute aber, du brauchst eher deutlichst mehr als du glaubst. Aber da dir an kleinem und leichtem Code gelegen ist, hilft dir vielleicht neben obigen Slickspeed-Test folgender Vergleich weiter:

Prototype: 25 KByte
JQuery: 19 KByte
DOMAssistant: 9 KByte

Alles jeweils eingedampft und gzip-komprimiert. Alle drei bieten vollständige Grundfunktionalität (Ajax, Zugriff über CSS-Selektoren, Elementmanipulation). DOMAssistant hat die wenigsten zusätzlichen Funktionen, ist dafür beim Zugriff auf Elemente am schnellsten. JQuery bietet dank der Abteilung Effects die meisten Zusatzfunktionen. Prototype liegt funktionsmäßig irgendwo dazwischen, ist aber langsam und der größte Byte-Klotz.

Schlingel, du hast ja auch im zweiten Punkt das "- ggf. auch sowas wie " entfernt Das ggf. sollte darauf hindeuten dass ich es nicht unbedingt benoetige, ggf. nur was Rudimentaeres vorhanden sien muesste auf dem man aufbauen koennte.

bzgl. der jquery anleitung : ich empfand sie an manchen stellen unvollstaendig (aehnlich selfhtml - ist zwar oft ausreichend, aber manchmal wegen des "stehengebliebenseins" dann halt doch nicht mehr).

> Dass man Funktionen einkapseln müsse, ist so per se Unsinn,

oft in (schlechten?) jquery beispielen so gesehen. gut wenn mans nicht muss, denn nur der "kunst" wegen schreibt man (ich) ungern noch mehr. ne lib soll ja eigentlich eine arbeitserleichterung sein..

dein slickspeed link und dein zusammenfassung mit vergleich der libs ist super, das hat gut weitergeholfen, danke!

ist prototype ggf. so langsam weil zuviel ueber die $()-funktion gemacht wird? nur ne vermutung ..

https://ajaxpatterns.org/Frameworks_Matrix

hatte auch mal eine gefunden, wo man features an und abwählen konnte und dann wurde die liste angepaßt.

ich würde mir ein paar frameworks anlernen und das passende verwenden. natürlich nicht 10 verschiedene. es kommt am ende ganz auf die anwendung an und was zählt. bei einer kleinen anwendung kann der code vielleicht etwas unübersichtlicher sein. bei einer sehr großen, ist das fatal. an anderer stelle kommt es auf jeden furz performance an, an anderer stelle nicht. habe auch schon öfters prototype und jquery kombiniert und natürlich hier und da auch mal was eigenes.

frameworks (genau wie CMS) brauchen immer eine ganze weile, bis sie reifen und so alt sind die ganzen libs ja noch nicht.

Airport1 hat geschrieben:Schlingel, du hast ja auch im zweiten Punkt das "- ggf. auch sowas wie " entfernt ;)

Hoppla, sorry. Das kommt davon, wenn man ein Zitat zusammenstückelt …

Dass man Funktionen einkapseln müsse, ist so per se Unsinn,

oft in (schlechten?) jquery beispielen so gesehen.

Oft? Meinst du eventuell sowas: Das ist eine Abkürzung. Du kannst genauso Folgendes schreiben: Für den einmaligen Einsatz von event() ist das, wie unschwer zu sehen, deutlich mehr Aufwand, aber wenn man event() bei mehreren Elementen anwenden möchte, kann das sinnvoller sein.
Wobei man natürlich andererseits auch mit $() gleich mehrere Elemente auswählen könnte (zB $("p,a,img") für sämtliche <p>, <a>, <img>, die ein HTML-Dokument zu bieten hat).

ist prototype ggf. so langsam weil zuviel ueber die $()-funktion gemacht wird?

Nein, das ist bei allen so und der Slickspeed-Vergleich bezieht sich auch nur auf diese Möglichkeit, HTML-Elemente mittels CSS-Selektoren anzusprechen. Diese Methode ist Dreh- und Angelpunkt aller Bibliotheken.

Warum Prototype nun für $$("#bla") dreimal so lange braucht wie die gleiche Funktion $("#bla") bei DOMAssistant, kann ich dir nicht sagen. Man könnte auch durchaus mit Recht argumentieren, dass es bei Prototype für den Zugriff per ID die spezielle Funktion $("bla") gibt, welche möglicherweise fixer ist. Aber andererseits: Warum zwei Funktionen, wenn's auch mit einer geht.

Die Ergebnisse sollten aber auch nicht überbewertet werden. Ob ein Element nun in 1 oder 10 Millisekunden angesprochen wird, macht sich erst bei umfangreichen Zugriffen bemerkbar.
Dieser Aspekt kann also immer nur einer von mehreren sein. Mir ist zum Beispiel neben dem passenden Funktionsumfang auch die Dateigröße wichtig.

dank dir hab ich jquery nochmal ne chance gegeben. mit der doku bin ich zwar weiterhin nicht ganz so gluecklich, aber mit etwas googlen (die suchfunktion in der doku half mir da vergleichsweise selten) gehts.

interessant sind vor allem so sachen wie $('#mydivid').load('myurl'); oder dass man json sich von ner url direkt mal gschwind "reinziehen" kann.

was ist eigentlich vom prototyping ("aufblaehen") von javascript objekten zu halten, z.b. wenn man (immerhin alle!) arrays um ne funktion contains(needle) erweitert? bzgl. der "browserbelastung"? derzeit ziehe ich lieber ne separate "abgekoppelte" funktion vor, der man sozusagen auch den haystack uebergibt..

Bei allen Überlegungen zur Performance sollte man eines nicht vergessen: "premature optimization is the root of all evil" und das stimmt.
Zuerst mal sauber das Problem lösen. Mit gut lesbarem und wartbarem Code. Wenn dann wirklich Performanceprobleme auftauchen, kann man immer noch optimieren.

Wie viele wirre Scripte habe ich schon gesehen, die super unverständlich aber hochgradig optimiert waren und dann wegen Header Einstellungen nicht gecached wurden

Airport1 hat geschrieben:was ist eigentlich vom prototyping ("aufblaehen") von javascript-objekten zu halten, z.b. wenn man (immerhin alle!) arrays um ne funktion contains(needle) erweitert?

Ich kann's nur vermuten, aber:

Der ganze Sinn der Eigenschaft prototype ist, dass sie nicht nur für die jeweilige Variable gilt, sondern für den Typ dieser Variablen. In der Theorie findet die Erweiterung also nur einmal statt, es wird nicht jede Variable einzeln erweitert, sondern nur einmalig der Typ.
Da das ganze Javascript-Konzept in Sachen Variablenelemente sehr flexibel ist und sich jedes Element überschreiben lässt, auch „ab Werk“ vorhandene, würde ich es zudem sinnvoll finden, wenn in der Praxis der Zugriff auf per prototype hinzugefügte Elemente genauso vonstatten geht wie auf die im Browser vorhandenen, sprich: interne als auch hinzugefügte Methoden und Eigenschaften werden in derselben Liste geführt.

Entsprechend dürfte es egal sein, ob eine oder hundert Variablen betroffen sind, es dürfte sogar egal sein, ob es sich bei Element X überhaupt um ein hinzugefügtes oder vom Browser bereitgestelltes handelt.

Nun ist es bei Eigenschaften natürlich so, dass die für jede Variable separat geführt werden müssen, aber was die von dir angesprochenen Methoden angeht, sollten diese nur einmalig im (Typ-) Speicher stehen, nicht bei jeder Variablen einzeln.

Prototype zu benutzen hat sogar den Vorteil, dass du die Elemente bzw. ihre Namen da einsortierst, wo sie benötigt werden, und nicht den allgemeinen Namensbereich zumüllst. 20 zusätzliche Funktionen im allgemeinen Namensbereich kosten bei nahezu jeder Operation Zeit zum Auffinden des Namens bzw. dazugehörigen Elements, 20 zusätzliche Funktionen unter Array.prototype kosten nur bei Zugriffen auf Variablen vom Typ Array Zeit.

Aber wie eingangs gesagt: Das habe ich mir jetzt alles selbst ausgedacht ;)