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

Und wieder jQuery als Abhängigkeit

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


  1. Re: Und wieder jQuery als Abhängigkeit

    Autor: raw 02.09.13 - 14:42

    Tapsi schrieb:
    --------------------------------------------------------------------------------
    > * Pro JavaScript Design Patterns
    > ...

    danke für schnelle Antwort! Wie gesagt, wir hatten kein JavaScript, Patterns sind mir auch noch nicht wirklich ein Begriff :P. Wird Zeit mich einzulesen ;)

  2. Re: Und wieder jQuery als Abhängigkeit

    Autor: Moe479 02.09.13 - 14:52

    was? buttons farbig machen? machen wir ganz easy über style attribute:
    [code]
    var myButton = document.getElementById("myButton");
    myButton.style.backgroundColor = "yellow";
    [/code]

  3. Re: Und wieder jQuery als Abhängigkeit

    Autor: Tapsi 02.09.13 - 14:54

    Kein Problem. =D

    Ich habe noch mal schnell nachgeschaut. Am Anfang sind Bücher vom O'Reilly Verlag ganz gut. ^^

    while not sleep
    sheep++

  4. Re: Und wieder jQuery als Abhängigkeit

    Autor: Moridin 02.09.13 - 14:55

    Die jQuery-API ist ja nun wirklich nicht toll.
    Fängt damit an, dass Getter und Setter die gleiche Funktion nutzen und über die Anzahl der Parameter entschieden wird, was passiert. Außerdem gibt es Abkürzungen wie attr als Funktionsnamen, gefühlte tausend verschiedene Möglichkeiten, die selbe Sache zu erreichen etc.
    Aber das schlimmste: Chaining - wer sich das ausgedacht hat, gehört erschossen.

    Das ganz hat zu Konsequenz, dass man recht viele eigene Regeln definieren muss, wenn man mit jQuery im Team effektiv lesbaren Code schreiben will.

  5. Re: Und wieder jQuery als Abhängigkeit

    Autor: raw 02.09.13 - 15:04

    Moe479 schrieb:
    --------------------------------------------------------------------------------
    > was? buttons farbig machen? machen wir ganz easy über style attribute:
    >
    > var myButton = document.getElementById("myButton");
    > myButton.style.backgroundColor = "yellow";
    >

    $('#mybutton').css('background-color','yellow');

    fast noch einfacher =P

  6. Re: Und wieder jQuery als Abhängigkeit

    Autor: raw 02.09.13 - 15:06

    Moridin schrieb:
    --------------------------------------------------------------------------------
    > Die jQuery-API ist ja nun wirklich nicht toll.
    > Fängt damit an, dass Getter und Setter die gleiche Funktion nutzen und über
    > die Anzahl der Parameter entschieden wird, was passiert. Außerdem gibt es
    > Abkürzungen wie attr als Funktionsnamen, gefühlte tausend verschiedene
    > Möglichkeiten, die selbe Sache zu erreichen etc.
    > Aber das schlimmste: Chaining - wer sich das ausgedacht hat, gehört
    > erschossen.
    >
    > Das ganz hat zu Konsequenz, dass man recht viele eigene Regeln definieren
    > muss, wenn man mit jQuery im Team effektiv lesbaren Code schreiben will.

    An sich ist Chaining gute Sache, aber zugegeben muss man oft rumprobieren, wie rum es richtig ist (welche Funktion kommt vor welche)

    Edit: Ausserdem stimme ich Ihnen zu, bei viele Abkürzungen weiss man grad nicht, obs eine Eigenschaft oder eine Methode ist. Die verwendete IDE ist dann die letzte Hoffnung, die einem Hinweise gibt^^

    Ich vergesse zBsp ständig, ob es so oder so geht:
    myElemnt.text = "hallo";
    oder
    myElement.text("hallo");



    1 mal bearbeitet, zuletzt am 02.09.13 15:10 durch raw.

  7. Re: Und wieder jQuery als Abhängigkeit

    Autor: Tapsi 02.09.13 - 15:08

    Das mag ich immer nicht. Warum alles CSS like. xD
    Was spricht gegen?

    document.getElementById("myButton").style.backgroundColor = "yellow";

    Vorteil ist doch hier weiß man was getan wird. Ich glaube die css Methode ist bei jQuery ist überladen oder? Was ist wenn man Variablen nutzt und die Zweite undefined ist? Ich finde dann obiges Beispiel besser und auch lesbarer, da die Signaturen der Schnittstelle eindeutig zeigen, dass ein Element anhand seiner Id gesucht wird. Bei der jQuery-Variante ist dies nur bei Kenntnis des Selektors möglich.

    Aus meiner Sicht ist kürzerer Quelltext nicht immer automatisch besser.

    EDIT: Ja man sollte den Post davor lesen. XD

    while not sleep
    sheep++



    1 mal bearbeitet, zuletzt am 02.09.13 15:13 durch Tapsi.

  8. Re: Und wieder jQuery als Abhängigkeit

    Autor: Tapsi 02.09.13 - 15:10

    Ich mag bei Fabrikfunktionen ( die in gewissen Maße Strukturen beschreiben ) Chaining ganz gerne.

    Bsp:

    createFlow()
    .do( ... )
    .andThen( ... )
    .andThen( ... )
    .start();

    while not sleep
    sheep++

  9. Re: Und wieder jQuery als Abhängigkeit

    Autor: raw 02.09.13 - 15:12

    Tapsi schrieb:
    --------------------------------------------------------------------------------
    > Das mag ich immer nicht. Warum alles CSS like. xD
    > Was spricht gegen:
    >
    > document.getElementById("myButton").style.backgroundColor = "yellow";
    >
    > ?

    Vielleicht fehlt mir das Grundwissen, aber sind element.style und elemnt.css (cascading STYLE sheet) nicht dieselbe Eigenschaft? Das eine nur JS, das andere JQuery...

  10. Re: Und wieder jQuery als Abhängigkeit

    Autor: Tapsi 02.09.13 - 15:16

    Ich hab den anderen Post bearbeitet.

    Die css Methode von jQuery ist überladen und führt je nach Anzahl der Parameter unterschiedliche Anwendungslogik aus. Je nach Implementierung ( die ist mir gerade nicht bekannt ), kann ein Aufruf wie dieser zu schwer auffindbaren Fehlern führen:

    var a = "color";
    var b = undefined;

    $( ... ).css( a, b );

    EDIT: Ich glaube aber jQuery berücksichtigt einen derartigen Aufruf. Generell will ich aber auf das Problem mit Überladung hinweisen. Dieses ist bei der offiziellen Variante nicht möglich misszuverstehen.

    EDIT2: Ja wird berücksichtigt. Dennoch finde ich die Schnittstelle irreführend, weil diese Lese und Schreibmethode mit unterschiedlichen Rückgabetypen unter einem Namen vereint.

    EDIT3: Das ist der Letzte versprochen. Problematisch ( weil ich sehe gerade man kann auch Listen übertragen... ) ist diese Mechanik immer dann, wenn diese in Zusammenhang mit Variablen verwendet wird. Dies kann, muss aber nicht, eben zu schwer auffindbaren Fehlern führen wenn ein Wert die Ausführung der Logik obwohl der Stack der selbe ist, beeinflussen kann.

    while not sleep
    sheep++



    3 mal bearbeitet, zuletzt am 02.09.13 15:22 durch Tapsi.

  11. Re: Und wieder jQuery als Abhängigkeit

    Autor: Schnarchnase 02.09.13 - 16:07

    lala1 schrieb:
    --------------------------------------------------------------------------------
    > Erzähl mal wie du das meinst mit Beispielen bitte.

    Ein paar Beispiele? Gerne.

    Parameterwirrwarr a la PHP, mal so:
    $.each(collection, function(index, item))
    mal anders:
    $.grep(array, function(item, index))

    $('.foo').css('color', 'red') - setzt die Farbe auf allen Elementen, $('.foo').css('color') holt die Farbe des ersten Elements. Hm?!

    .load() - mal zum hinzufügen eines Listeners fürs load-Event, mal um Daten von einem Server zu laden.

    .bind() - für Eventlistener, in der ECMA-Spezifikation aber zum Setzen des Contexts vorgesehen, absolut verwirrende Namensgebung. Was sich weiter durchzieht und oft wiederholt, was tut .live? .closest? Warum .attr .val usw? Hat es für .attribute, .value usw. nicht gereicht?

    .toggle() - mal um Elemente ein-/auszublenden, mal um alternierende Clickhandler zu setzen.

    .map(index, item) aber $.map(arrayOrObject, function(item, index)) und this ist untershiedlich.

    .get() holt ein DOM-Element, $.get() -> GET-Request.

    .index() arbeitet je nachdem was man als Parameter reingibt komplett anders (was leider auch bei anderen Funktionen vorkommt).

    jQuerys Event-Handling-System ist murks, die Handler hängen im jQuery.cache rum, wer Elemente ohne jQuery-Methoden entfernt, hinterlässt verweiste Objekte im Cache. Das gilt soweit ich weiß nicht nur für Event-Handler und stellt eine hübsche Möglichkeit für Memoryleaks dar.

    Für mich sind da doch ein paar sehr nervige Punkte dabei und über die teilweise unterirdische Codequalität der Plugins haben wir noch gar nicht gesprochen.

  12. Re: Und wieder jQuery als Abhängigkeit

    Autor: Schnarchnase 02.09.13 - 16:13

    dabbes schrieb:
    --------------------------------------------------------------------------------
    > Soll man was eigenes erfinden, was das gleiche macht wie jQuery nur wegen
    > nem hübscheren API-Design ? Was soll das bitte bringen ?

    Was eigenes erfinden sicher nicht. Aber warum überhaupt etwas neues? PrototypeJS ist älter als jQuery und wesentlich konsistener. Mootools dürfte ungefähr das gleiche Alter wie jQuery haben und bietet ebenfalls eine konsistente API.

  13. Re: Und wieder jQuery als Abhängigkeit

    Autor: Schnarchnase 02.09.13 - 16:15

    DanielSchulz schrieb:
    --------------------------------------------------------------------------------
    > Was ist falsch an jQuery? Das ist eine bewährte Lib, die viele Eigenarten
    > einzelner Browser abstrahiert und dem Entwickler ein einheitliches API
    > anbietet.

    Das tun andere Frameworks auch bzw. sie tun es besser. Ich kann mit den jQuery-Hype nach wie vor nicht erklären. jQuery hat nicht einen einzigen handfesten Vorteil gegenüber anderen Frameworks, eher einige Nachteile die mit der Zeit gewaltig nerven.

  14. Re: Und wieder jQuery als Abhängigkeit

    Autor: Schnarchnase 02.09.13 - 16:29

    Geistesgegenwart schrieb:
    --------------------------------------------------------------------------------
    > jQuery und underscore.js sind bei mir quasi die Basislibs die in jedes
    > Webprojekt gehören, und meist auch sowieso von irgend einer Komponente als
    > Abhängigkeit benötigt werde (z.B. von bootstrap).

    Bei mir gibt es keine Basis die immer gleich ist, ich wähle das immer passend zum Projekt aus. In der Regel greife ich bei normalen Seiten zu Mootools und bei Apps zu Enyo. Bootstrap bringt mir zu viel Ballast mit, das brauche ich nicht. Bei HTML5Boilerplate bediene ich mich auch nur selektiv.

    > Gerade ohne deferred/promises kannst du heute keinen wart- und lesbaren
    > Javascriptcode mehr schreiben.

    Tatsächlich? Bisher ist weder mir noch meinen Kollegen aufgefallen, dass mein/unser Code nicht wartbar sein soll. Ich sehe jetzt keinen großartigen Vorteil darin alles in Deferred-Objekte zu stecken, eher einen unnötigen Overhead. Gegen ein praxisbezogenes Beispiel hätte ich aber nichts einzuwenden.

  15. Re: Und wieder jQuery als Abhängigkeit

    Autor: Tapsi 02.09.13 - 16:31

    Hehe. Eventuell müsste man sich dann ja auch eingestehen, dass der eigene Programmierstil eine Quelle des unles- uznd wartbaren Quelltext sein könnte. xD

    while not sleep
    sheep++

  16. Re: Und wieder jQuery als Abhängigkeit

    Autor: Mudder 02.09.13 - 16:32

    @Schnarchnase: (Tapsi du bist zu aktiv)
    Naja auf der einen Seite kann man sagen: Ja, man hätte es vielleicht eindeutiger machen können.
    Auf der anderen Seite kann man aber auch sagen: Statt darauf zu bauen, dass dein Syntax-Highlighter dir den nächsten Codeschnipsel präsentiert, solltest du den Code einfach mal lernen und mit ein wenig logischem Denken weiß man wann welcher Ausdruck verwendet werden muss.

    Allerdings hast du so viele Beispiele genannt, dass ich davon ausgehe du kannst jQuery auch ohne ein Highlighter. Also warum meckerst du? Weil du dich beim Schnellschreiben mal vertust und ein Punkt vergisst?

    Und was die Plugins betrifft: Du kannst den Herd nicht verantwortlich machen, dass der Koch nicht kochen kann.



    1 mal bearbeitet, zuletzt am 02.09.13 16:33 durch Mudder.

  17. Re: Und wieder jQuery als Abhängigkeit

    Autor: Schnarchnase 02.09.13 - 16:33

    hw75 schrieb:
    --------------------------------------------------------------------------------
    > Wer jQuery schlecht findet, der hat entweder nichts mit Javascript im
    > Browser am Hut, oder heute einfach noch nicht genug herumgemault :-)

    Oder er hat schlicht und ergreifend Ahnung von Javascript und kriegt regelmäßig ne Krise wenn er den dahingerotzten jQuery-basierten Code sieht. Die Leute die sich heutzutage gerne jQuery-Entwickler nennen, haben teilweise noch nicht mal die Basics von Javascript verstanden.

    Es gibt nicht nur jQuery, hast du noch nie was von anderen Javascript-Frameworks gehört?

  18. Re: Und wieder jQuery als Abhängigkeit

    Autor: Tapsi 02.09.13 - 16:33

    Mudder schrieb:
    --------------------------------------------------------------------------------
    > @Schnarchnase: (Tapsi du bist zu aktiv)

    Hä?

    while not sleep
    sheep++

  19. Re: Und wieder jQuery als Abhängigkeit

    Autor: Schnarchnase 02.09.13 - 16:36

    Mudder schrieb:
    --------------------------------------------------------------------------------
    > Allerdings hast du so viele Beispiele genannt, dass ich davon ausgehe du
    > kannst jQuery auch ohne ein Highlighter. Also warum meckerst du? Weil du
    > dich beim Schnellschreiben mal vertust und ein Punkt vergisst?

    Ich brauche keine Autovervollständigung, damit liegst du richtig. Wobei ich mich zum Beispiel bei der Parameterreihenfolge aber immer noch hin und wieder vertue und nachschlagen muss. Sowas nervt einfach auf Dauer.

    > Und was die Plugins betrifft: Du kannst den Herd nicht verantwortlich
    > machen, dass der Koch nicht kochen kann.

    Deswegen habe ich es auch nicht als Argument angeführt, sondern nur als Fußnote erwähnt. Das wird ja gerne mal als großer Vorteil von jQuery angepriesen.

  20. Re: Und wieder jQuery als Abhängigkeit

    Autor: Mudder 02.09.13 - 16:58

    Schnarchnase schrieb:
    --------------------------------------------------------------------------------
    > Ich brauche keine Autovervollständigung, damit liegst du richtig. Wobei ich
    > mich zum Beispiel bei der Parameterreihenfolge aber immer noch hin und
    > wieder vertue und nachschlagen muss. Sowas nervt einfach auf Dauer.

    Ok das kannst du aber auch haben, wenn sie Funktionen "einzigartig" machen würden. Wenn sehe es positiv, dass wenn man mal nachschlagen muss ein brauchbare API-Beschreibung zur Verfügung steht - das ist bei Native-JS nicht unbedingt der Fall.

  1. Thema
  1. 1
  2. 2
  3. 3

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. Technischer Energiemanager (m/w/d)
    EnergiData GmbH, Duisburg
  2. SAP WM Junior Berater (m/w/x)
    über duerenhoff GmbH, Albstadt
  3. SAP Nachwuchsführungskraft als Entwicklungsleiter (m/w/x)
    über duerenhoff GmbH, Stuttgart
  4. Junior Professional Projektmanager Plattformentwicklung Lidl Reisen (m/w/d)
    Lidl Digital, Neckarsulm

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (reduzierte Überstände, Restposten & Co.)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Canon: Der endgültige Beweis, dass DRM weg kann
Canon
Der endgültige Beweis, dass DRM weg kann

Endlich gibt auch mal ein Hersteller zu, dass DRM nur der Kundengängelei dient. Es wird Zeit, das endlich zu lassen.
Ein IMHO von Sebastian Grüner

  1. Daan.Tech Bob Geschirrspüler nutzt DRM - und wurde geknackt

IT Trends 2022: Gartners magische Jahresvorschau für ahnungslose Anzugträger
IT Trends 2022
Gartners magische Jahresvorschau für ahnungslose Anzugträger

Bei Gartner sind nicht nur die Quadranten magisch, auch die Jahresvorschau samt Trends hat nur bedingt mit der Realität zu tun.
Ein IMHO von Sebastian Grüner


    Core i5-12400(F) im Test: Der Hexacore mit dem besten Preis-Leistungs-Verhältnis
    Core i5-12400(F) im Test
    Der Hexacore mit dem besten Preis-Leistungs-Verhältnis

    Für unter 200 Euro schlägt der Core i5-12400F den viel teureren Ryzen 5600X, selbst samt Board und DDR4 bleibt das Intel-System günstiger.
    Ein Test von Marc Sauter

    1. Denuvo Intels Alder Lake macht keine DRM-Probleme mehr
    2. AVX-512 Intel macht Alder-Lake-CPUs künstlich langsamer
    3. Alder Lake S Intel bringt günstige Hybrid-Chips plus Boards