1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Javascript-Bibliothek…

jQuery vs. Ext JS vs. …

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. jQuery vs. Ext JS vs. …

    Autor: Ferrum 01.02.11 - 09:33

    Wie sind eigentlich eure Erfahrungsberichte im Vergleich zu anderen Frameworks wie Protype, MooTools und Ext JS? Wo liegen die Stärken? Wo die Schwächen?

  2. Re: jQuery vs. Ext JS vs. …

    Autor: cmi 01.02.11 - 09:43

    Ferrum schrieb:
    --------------------------------------------------------------------------------
    > Wie sind eigentlich eure Erfahrungsberichte im Vergleich zu anderen
    > Frameworks wie Protype, MooTools und Ext JS? Wo liegen die Stärken? Wo die
    > Schwächen?

    vorab: ich nutze jquery. aus gewohnheit und auch etwas mangels zeit mich in andere libraries einzuarbeiten. aber: früher schwankte ich zwischen prototype/scriptaculous und jquery - habe mich dann aber für jquery entschieden, schon allein weil die suche danach viel einfacher ist. bei prototype hat mich einfach massiv gestört, dass es es nach einem sprachkonstrukt benannt ist, was bei der googlesuche sehr störend ist/war. dazu kam, dass jquery eine plugin-bibliothek auf der webseite direkt anbot, im gegensatz zu prototype wo man sich den kram mehr oder weniger zusammensuchen musste.

  3. Re: jQuery vs. Ext JS vs. …

    Autor: tux-zuechter 01.02.11 - 09:43

    jQuery ist halt einfach der standard... du bekommst dafür einfach die beste unterstützung es gibt sogar mitlerweile zig bücher über jQuery.. so was wirst du für die anderen frameworks nicht bekommen... ich kann mir sogar vorstellen das jQuery irgendwann nativ unterstützt werden könnte...

  4. Re: jQuery vs. Ext JS vs. …

    Autor: Cassiel 01.02.11 - 09:45

    Pro jQuery:
    1. Besser les- und schreibbare Syntax
    2. Sehr gute Plugin-Architektur
    3. Deutlich performanter
    4. Größere Community

    Contra überlasse ich gerne den Kritikern ;-)

  5. Re: jQuery vs. Ext JS vs. …

    Autor: deefens 01.02.11 - 09:46

    Protoype sollte man nicht mehr verwenden, es wird nur selten aktualisiert und enthält eigentlich nur rudimentäre Funktionen verglichen mit jQuery. Ext JS hat ein gänzlich anderes Einsatzgebiet, es geht dort mehr um die mitgelieferten Widgets und um Web-Anwendungen möglichst nah an das Look&Feel normaler Clients zu bringen. MooTools kenn ich nur vom Namen, da enthalte ich mich einer Bewertung.

  6. Re: jQuery vs. Ext JS vs. …

    Autor: Sneaky Pie 01.02.11 - 09:47

    jQuery ist für mich immer noch die am besten dokumentierte JavaScript Bibliothek, Prototype und MooTools sind dagegen einfach armselig. Mir macht es einfach keinen Spaß, die Methoden anhand des Quellcodes herauszufinden.

    Bei Ext JS stört die Lizenz, denn es ist nur für Open Source Projekte frei verfügbar, bei allen anderen werden Lizenzgebühren fällig. Freiheit ist für mich anders.

  7. Re: jQuery vs. Ext JS vs. …

    Autor: Schnarchnase 01.02.11 - 10:39

    Ok, ich versuche mich mal an einem Vergleich mit Mootools (wobei ich jQuery nicht so gut kenne).

    An Mootools gefallen mir die Klassen, dadurch hat man eine einheitliche Syntax und kann den Code gut strukturieren (Prototype bietet das auch).

    Bei jQuery missfällt mir, dass Funktionen teilweise als Setter und Getter fungieren, das ist fehleranfällig und nicht logisch. ".attr('title')" holt den Wert des title-Attributs, ".attr('title', 'Foobar')" setzt ihn.

    Die Benennung finde ich bei Mootools auch besser "getParent" statt "parent", wobei "attr" wohl das Paradebeispiel der verkrüppelten Namensgebung ist. Zudem entspricht die Rückgabe der Funktionen in jQuery nicht immer dem erwarteten Wert, ein kleines Beispiel:
    <ul><li><p id="foo">bar</p></li></ul>

    jQuery:
    $('foo').parent('ul'); // liefert ein leeres Array

    Mootools
    $('foo').getParent('ul'); // liefert ul

    Laut jQuery-Doku nimmt parent einen Selektor entgegen, aber wozu wenn ich nicht das entsprechende Elternelement bekomme?

    Nächster Punkt Event-Delegation. jQuerys live-Funktion registriert den Listener immer auf dem gesamten Dokument, bei Mootools kann ich ihn auf irgendein beliebiges Element registrieren.

    Ich denke jQuery ist schon ein gutes Toolkit, aber den Hype kann ich nicht verstehen, Mootools macht meiner Meinung nach eigentlich alles besser. Der große Pluspunkt für jQuery ist die Masse der verfügbaren Plugins/Erweiterungen.

  8. Re: jQuery vs. Ext JS vs. …

    Autor: Schnarchnase 01.02.11 - 10:46

    Cassiel schrieb:
    --------------------------------------------------------------------------------
    > Pro jQuery:
    > 1. Besser les- und schreibbare Syntax

    Meiner Meinung nach hat jQuery zumindest im Vergleich zu Mootools und PrototypeJS die schlechter lesbare Syntax. Die Syntax der beiden genannten ist sprechender.

  9. Re: jQuery vs. Ext JS vs. …

    Autor: deos 01.02.11 - 10:47

    Sneaky Pie schrieb:
    --------------------------------------------------------------------------------
    > jQuery ist für mich immer noch die am besten dokumentierte JavaScript
    > Bibliothek, Prototype und MooTools sind dagegen einfach armselig. Mir macht
    > es einfach keinen Spaß, die Methoden anhand des Quellcodes herauszufinden.

    guter witz
    ich bin absolut pro MooTools und contra jQuery!
    jQuery ist in meinen augen absolut erbärmlich was viele sachen angeht. es ist ein kasten der viel bietet und noch viel mehr falsch macht (vor allem in sachen API)
    (beispiel: ich will keine eigene funktion für jeden event, ein addEvent('click', ...) ist die logische vorgehensweise, nahe am nativen addEventListener und passt halt einfach perfekt)

    übrigens, wer mal in die MooTools doku geschaut hat findet sich sofort zurecht, ist alles übersichtlich und schnell zu verstehen. wer was anderes sagt ist offenbar ein js-noob, sorry

    wohlgemerkt: MooTools ist das komplexeste der frameworks, einfach weil es keine blackbox ist der man sein zeug hinschmeißt sondern weil man javascript als solches halbwegs beherschen muss um es nutzen und verstehen zu können
    aber wenn man mal drin ist gibts nichts größeres

  10. Re: jQuery vs. Ext JS vs. …

    Autor: Schnarchnase 01.02.11 - 10:48

    Sneaky Pie schrieb:
    --------------------------------------------------------------------------------
    > jQuery ist für mich immer noch die am besten dokumentierte JavaScript
    > Bibliothek, Prototype und MooTools sind dagegen einfach armselig. Mir macht
    > es einfach keinen Spaß, die Methoden anhand des Quellcodes herauszufinden.

    Vielleicht solltest du mal wieder einen Blick über den Tellerrand riskieren. Die aktuelle Doku von Mootools ist meiner Meinung nach besser als die von jQuery. Bei letzterem muss ich deutlich öfter die Suche bemühen und die hilft auch nur wenn man weiß wie die Funktion heißt.

  11. Re: jQuery vs. Ext JS vs. …

    Autor: Kein Kostverächter 01.02.11 - 10:50

    Du verwechselst Freiheit mit Kostenfreiheit. Es ist die Freiheit der Entwickler von Ext JS, von Leuten, die mit Hilfe des Frameworks Geld verdienen, einen Anteil zu verlangen. Deine Freiheit ist es, ein anderes Framework zu verwenden, wenn Dir das nicht passt (Was Du ja auch tust, ich übrigens auch).
    Alles andere ist die altbekannte "Ich will alles für umme"-Mentalität.

    Bis die Tage,

    KK

    ----------------------------------------------------------
    Mach dir deine eigenen Götter, und unterlasse es, dich mit einer schnöden Religion zu beflecken.
    (Epikur, griech. Phil., 341-270 v.Chr.)
    ----------------------------------------------------------
    We provide AI Blockchain Cloud (ABC) enabled applications bringing Enterprise level synergies to vertically integrated business processes.

  12. Re: jQuery vs. Ext JS vs. …

    Autor: OLee 01.02.11 - 10:54

    @Schnarchnase
    $('foo').parent('ul'); // liefert ein leeres Array
    das ist kein jQuery Selector!
    $('#foo').parent('ul'); //so ists richtig

    jQuerys Selektoren entsprechen CSS Selektoren nur mit vielen zusätzlichen Pseudoklassen
    $('#ul > li a:not(.inactive)').show();

  13. Re: jQuery vs. Ext JS vs. …

    Autor: deos 01.02.11 - 11:01

    OLee schrieb:
    --------------------------------------------------------------------------------
    > @Schnarchnase
    > $('foo').parent('ul'); // liefert ein leeres Array
    > das ist kein jQuery Selector!
    > $('#foo').parent('ul'); //so ists richtig
    >
    > jQuerys Selektoren entsprechen CSS Selektoren nur mit vielen zusätzlichen
    > Pseudoklassen
    > $('#ul > li a:not(.inactive)').show();

    Mootools:
    $$('#ul > li a:not(.inactive)')
    bzw. getElement/s statt $$, das ist nur ein shortcut

    das CSS3 selectoren, keine jQuery eigenen, lol, daher können es auch andere frameworks problemlos

    @Schnarchnase
    fullack!



    1 mal bearbeitet, zuletzt am 01.02.11 11:02 durch deos.

  14. Re: jQuery vs. Ext JS vs. …

    Autor: OLee 01.02.11 - 11:02

    deos schrieb:
    --------------------------------------------------------------------------------
    > (beispiel: ich will keine eigene funktion für jeden event, ein
    > addEvent('click', ...) ist die logische vorgehensweise, nahe am nativen
    > addEventListener und passt halt einfach perfekt)

    was ist an einer Funktion für eine Event so verkehrt? Außerdem steht es dir frei eine Funktion für Events verschiedener Objekte zu verwenden.
    was hälst du denn von:
    .bind('click',...);
    oder
    .click(...);

    jQuery legt einfach auch viel wert auf wenig Code (write less, do more), deshalb muss man sich einige Funktionsnamen ersteinmal verinnerlichen. Allerdings fällt das wohl keinem sonderlich schwer.

  15. Re: jQuery vs. Ext JS vs. …

    Autor: OLee 01.02.11 - 11:07

    deos schrieb:
    --------------------------------------------------------------------------------
    > > jQuerys Selektoren entsprechen CSS Selektoren nur mit vielen
    > zusätzlichen
    > > Pseudoklassen
    > > $('#ul > li a:not(.inactive)').show();
    >
    > Mootools:
    > $$('#ul > li a:not(.inactive)')
    > bzw. getElement/s statt $$, das ist nur ein shortcut
    >
    > das CSS3 selectoren, keine jQuery eigenen, lol, daher können es auch andere
    > frameworks problemlos

    und was sagt dir z.B. der :animated selektor? Steht der auch in der CSS3 Spezifikation. Informier dich bitte etwas besser, bevor du hier rumlolst.

  16. Re: jQuery vs. Ext JS vs. …

    Autor: deos 01.02.11 - 11:08

    OLee schrieb:
    --------------------------------------------------------------------------------
    > deos schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > (beispiel: ich will keine eigene funktion für jeden event, ein
    > > addEvent('click', ...) ist die logische vorgehensweise, nahe am nativen
    > > addEventListener und passt halt einfach perfekt)
    >
    > was ist an einer Funktion für eine Event so verkehrt? Außerdem steht es dir
    > frei eine Funktion für Events verschiedener Objekte zu verwenden.
    > was hälst du denn von:
    > .bind('click',...);
    > oder
    > .click(...);
    >
    > jQuery legt einfach auch viel wert auf wenig Code (write less, do more),
    > deshalb muss man sich einige Funktionsnamen ersteinmal verinnerlichen.
    > Allerdings fällt das wohl keinem sonderlich schwer.

    .bind gibt es in mootools auch, allerdings ist es hier die funktion mit der man this in funktionen festlegt
    bsp: function(){ console.log(this); }.bind(document.id('myElement'))

    aber im grunde hast du recht, solange so etwas vorhanden ist würde ich aber niemals die anderen funktionen nutzen. über hoover red ich lieber nicht btw, das ist totales chaos

    jaja, jQuery gibt kurzen code und ist einfach zu lernen
    aber es ist nicht sehr mächtig weil wenn man nicht weiß wie man größere plugins selber schreibt

    naja, das ganze ist ein glaubenskrieg... ich bin absolut gegen jQuery und hab mich schon lang in mootools verliebt, daher seh ich die dinge ein wenig anders als die ganzen jQuery-fanboyz ;)

  17. Re: jQuery vs. Ext JS vs. …

    Autor: deos 01.02.11 - 11:11

    OLee schrieb:
    --------------------------------------------------------------------------------
    > deos schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > > jQuerys Selektoren entsprechen CSS Selektoren nur mit vielen
    > > zusätzlichen
    > > > Pseudoklassen
    > > > $('#ul > li a:not(.inactive)').show();
    > >
    > > Mootools:
    > > $$('#ul > li a:not(.inactive)')
    > > bzw. getElement/s statt $$, das ist nur ein shortcut
    > >
    > > das CSS3 selectoren, keine jQuery eigenen, lol, daher können es auch
    > andere
    > > frameworks problemlos
    >
    > und was sagt dir z.B. der :animated selektor? Steht der auch in der CSS3
    > Spezifikation. Informier dich bitte etwas besser, bevor du hier rumlolst.

    wer hat einen derartigen selektor angesprochen hier? wo?
    und man kann ihn auch problemlos in slick (der neue moootools selector kern) integrieren, das erlaubt das hinzufügen beliebiger subselektoren wenn man weiß was man tut
    siehe hierzu auch http://davidwalsh.name/slick-pseudo

    edit: ja etwas wie :animated bietet mootools nicht standardmäßig (zumindest nicht dass ich wüsste) und der selektor wird auch nicht ganz so leicht anzlegen sein denke ich. aber ganz ehrlich: wer braucht bitte sowas??



    1 mal bearbeitet, zuletzt am 01.02.11 11:14 durch deos.

  18. Re: jQuery vs. Ext JS vs. …

    Autor: buster hymen 01.02.11 - 11:18

    Schnarchnase schrieb:
    --------------------------------------------------------------------------------
    > jQuery:
    > $('foo').parent('ul'); // liefert ein leeres Array
    >

    Der Aufruf bei jQuery erfolgt in diesem Fall mit:
    $("#foo").closest("ul");

    >
    > Mootools
    > $('foo').getParent('ul'); // liefert ul
    >
    > Laut jQuery-Doku nimmt parent einen Selektor entgegen, aber wozu wenn ich
    > nicht das entsprechende Elternelement bekomme?
    >

    Die Methode parent() gibt wie sie auch (streng gesehen) vermuten lässt das (direkte) Elternelement zurück und nicht die "Großeltern", was hier aber gewünscht ist.
    Der Selektor dient als Filter für das Elternelement.

  19. Re: jQuery vs. Ext JS vs. …

    Autor: deos 01.02.11 - 11:25

    buster hymen schrieb:
    --------------------------------------------------------------------------------
    > Schnarchnase schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > jQuery:
    > > $('foo').parent('ul'); // liefert ein leeres Array
    > >
    >
    > Der Aufruf bei jQuery erfolgt in diesem Fall mit:
    > $("#foo").closest("ul");
    >
    > >
    > > Mootools
    > > $('foo').getParent('ul'); // liefert ul
    > >
    > > Laut jQuery-Doku nimmt parent einen Selektor entgegen, aber wozu wenn
    > ich
    > > nicht das entsprechende Elternelement bekomme?
    > >
    >
    > Die Methode parent() gibt wie sie auch (streng gesehen) vermuten lässt das
    > (direkte) Elternelement zurück und nicht die "Großeltern", was hier aber
    > gewünscht ist.
    > Der Selektor dient als Filter für das Elternelement.

    ein interessanter unterschied genaugenommen
    mootools gibt bei getParent() das direkte elternelement aus, gibt man der funktion aber einen selektor gibt er das höherliegende element aus das dem selektor entspricht, egal ob direktes elternelement oder nicht
    jQuery hingegen gibt hier immer nur das direkte elternelement aus, ob selektor oder nicht
    gut zu wissen, ich bevorzuge aber die mootools methode da ich, wenn ich einen selektor eingib, eh nicht (zwingend) das direkte eltern-element will sondern den baum evtl nicht genau kenne

  20. Re: jQuery vs. Ext JS vs. …

    Autor: Ferrum 01.02.11 - 11:35

    deos schrieb:
    --------------------------------------------------------------------------------
    > daher seh ich die dinge ein wenig
    > anders als die ganzen jQuery-fanboyz ;)

    Sehr interessant die Informationen auch einmal aus einem anderen Blickwinkel zu erfahren. Genau so etwas wollte ich eingangs wissen. Danke dir!

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. operational services GmbH & Co. KG, Frankfurt am Main, Berlin, Dresden, München
  2. ESWE Versorgungs AG, Wiesbaden
  3. VIVAVIS AG, Koblenz
  4. operational services GmbH & Co. KG, verschiedene Standorte

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 31€
  2. 16,99€
  3. 59,99€
  4. 17,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de