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


  1. Re: Und wieder jQuery als Abhängigkeit

    Autor: GodsBoss 02.09.13 - 17:20

    > 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.

    Nein, eben nicht. Logisches Denken kann nicht erklären, warum bei $.map der Index als zweites und bei $(...).map der Index als erstes kommt. Das muss man auswendig lernen. Damit handelt es sich um eine zusätzliche, komplett überflüssige Belastung gegenüber dem Nutzer der Schnittstellen.

    > 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?

    Er „meckert“ über die hässliche uneinheitliche API? Das kann man nicht nur dann, wenn man eine API beherrscht, sondern gerade dann!

    Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.

  2. Re: Und wieder jQuery als Abhängigkeit

    Autor: Schnarchnase 02.09.13 - 17:23

    Ja das schon. Ich denke im Punkt Doku kann man jQuery nichts vorwerfen, die war schon immer sehr gut.

  3. Re: Und wieder jQuery als Abhängigkeit

    Autor: Tapsi 02.09.13 - 17:23

    Darf ich noch einmal zusammenfassen?

    Man überlad einfach keine Methoden mit unterschiedlicher Semantik.

    while not sleep
    sheep++

  4. Re: Und wieder jQuery als Abhängigkeit

    Autor: DanielSchulz 02.09.13 - 17:50

    Genau solche Low-Level-Optimierungen meine ich: wenn man lieber keine geerbten Variablen ansprechen sollte sondern diese immer vorher in eine Lokale umwandelt. Das bringt nicht einmal bei extremer Schachtelung messbare Erfolge:
    https://github.com/danielschulz/JavaScriptPerformanceEvaluation/blob/master/JavaScriptPerformanceEvaluation/src/main/webapp/cases/chaining/scopeChains/scopeChains.html

  5. Re: Und wieder jQuery als Abhängigkeit

    Autor: DanielSchulz 02.09.13 - 17:53

    dito.
    Zudem, wenn man nur Teile aus jQuery benötigt sollte man aktiv nach SelectorJS oder Prototype suchen. Wobei ich Prototype nur für Umgebungen mit bekannten Projekten empfehle: da sie die Prototypen selbst verändern sollte man wissen ob das nicht Teilen der App Probleme macht. Daher sollte eine Lib/Framework am besten nicht Änderungen an Prototypen erfordern.

  6. Re: Und wieder jQuery als Abhängigkeit

    Autor: Tapsi 02.09.13 - 18:02

    Yep !

    Dies ist mir sogar bei der Firma aufgefallen wo ich arbeite. Dort wurde bei der Technik PrototypeJS und jQuery gleichzeitig ( durch Abhängigkeit drüber liegender Frameworks ) verwendet. Ende vom Lied war, dass eine Event-Funktion auf der Oberfläche schlichtweg in einem Anwendungsfall nicht funktionierte und keiner wusste sich zu helfen.

    Hier durfte ich dann man helfen und fast heulen als ich das sah. XD
    ich war zwar nicht involviert ( bin nicht in der Systemtechnik ), aber lernen konnte ich daraus auch. Dies war genau, was ich hier zuvor meinte, dass viele ohne nachzudenken einfach solche Frameworks zusammenklatschen, weil manche nicht darauf achten oder gar nicht wissen, dass sich selbige teilweise überschneiden in deren Wirkungskreis.

    while not sleep
    sheep++

  7. Re: Und wieder jQuery als Abhängigkeit

    Autor: Schnarchnase 02.09.13 - 18:49

    Das Erweitern von Prototypen entspricht der Natur von Javascript. Es ermöglicht elegante Lösungen, welche ohne nicht möglich wären, zum Beispiel Function.prototype.bind oder Array.prototype.indexOf - die gab es auch schon vor ES5 als Implementationen. Ohne die Prototypen zu erweitern wäre das nicht möglich gewesen, ebensowenig wie Polyfills.

    Pauschal die Finger von Prototypen zu lassen ist Quatsch. Eigentlich sollte man nur von einem einzigen die Finger lassen und das ist der Object-Prototype.

  8. Re: Und wieder jQuery als Abhängigkeit

    Autor: GodsBoss 02.09.13 - 19:01

    > Das Erweitern von Prototypen entspricht der Natur von Javascript. Es
    > ermöglicht elegante Lösungen, welche ohne nicht möglich wären, zum Beispiel
    > Function.prototype.bind oder Array.prototype.indexOf - die gab es auch
    > schon vor ES5 als Implementationen. Ohne die Prototypen zu erweitern wäre
    > das nicht möglich gewesen, ebensowenig wie Polyfills.
    >
    > Pauschal die Finger von Prototypen zu lassen ist Quatsch. Eigentlich sollte
    > man nur von einem einzigen die Finger lassen und das ist der
    > Object-Prototype.

    Was die nativen ECMAScript-Prototypen angeht, ja. Ansonsten sollte man aber auch besser die Finger von den Host-Objekt-Prototypen machen, s. z.B. What's wrong with extending the DOM?.

    Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.

  9. Re: Und wieder jQuery als Abhängigkeit

    Autor: MasterKeule 03.09.13 - 14:32

    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. [...]

    Ich denke, das ist Geschmackssache. Ich z.B. bin kein Fan vom "Getter/Setter"-System und bevorzuge properties oder eben das, was die jQuery-API macht: Eine Funktion für Getter und Setter gleichzeitig.
    Ich kann das überhaupt nicht sehen, wenn eine API von Gettern/Settern für jedes einzelne Attribut zugemüllt ist.

  10. Re: Und wieder jQuery als Abhängigkeit

    Autor: Schnarchnase 04.09.13 - 12:14

    Zugemüllt, weil du lesen kannst was die Funktion tut? Oh man.

  11. Re: Und wieder jQuery als Abhängigkeit

    Autor: MasterKeule 28.09.13 - 00:50

    Schnarchnase schrieb:
    --------------------------------------------------------------------------------
    > Zugemüllt, weil du lesen kannst was die Funktion tut? Oh man.

    [ ] Du hast verstanden, was Properties sind

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

Neues Thema


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. Informatiker (m/w/d) für IT Servicedesk - IT Helpdesk/IT Support 1st + 2nd Level
    Rail Power Systems GmbH, München
  2. Business Intelligence Entwickler (IBM Planning Analytics/TM1) (m/w/d)
    Hays AG, Frankfurt am Main, Köln, Mannheim, deutschlandweit (Homeoffice)
  3. IT-Prozess- und Workflow-Entwickler (m/w/d)
    GASCADE Gastransport GmbH, Kassel
  4. Senior Webdesigner (m/w/d)
    Artprojekt Communication & Event GmbH, Berlin

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 491,20€
  2. (u. a. Anno 1800 - Investorenausgabe für 39,99€, God of War für 31,99€, RDR 2 Ultimate...
  3. (u. a. Watch Dogs Legion - Gold Edition für 29,99€, Immortal: Fenxy Rising - Gold Edition für...
  4. 99€ statt 124,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Linux: Nvidias große schöne Open-Source-Schummelei
Linux
Nvidias große schöne Open-Source-Schummelei

Die Kunden nerven, die Konkurrenz legt vor und die Linux-Entwickler bleiben hart. Das führt zu einem Wandel bei Nvidia, der gerade erst anfängt.
Eine Analyse von Sebastian Grüner

  1. Linux-Kernel Netfilter-Bug gibt Nutzern Root-Rechte
  2. Linux Kernel-Hacker veröffentlichen Richtlinie für Forschung
  3. Dirty Pipe Linux-Kernel-Lücke erlaubt Schreibzugriff mit Root-Rechten

Sid Meier's Pirates angespielt: Kaperfahrt in der Karibik
Sid Meier's Pirates angespielt
Kaperfahrt in der Karibik

Mit Pirates schuf Sid Meier vor 35 Jahren einen Klassiker. Wie spielt sich das frühe Open-World-Abenteuer heute?
Von Andreas Altenheimer


    WLAN erklärt: So erreichen Funknetzwerke Gigabit-Datenraten
    WLAN erklärt
    So erreichen Funknetzwerke Gigabit-Datenraten

    Mehr Antennen, mehr Frequenzbänder, mehr Bandbreite: Hohe Datenraten per Funk brauchen viele Ressourcen - und eine effektive Fehlerbehandlung.
    Von Johannes Hiltscher

    1. 802.11be Qualcomm steigt in die Welt von Wi-Fi 7 ein
    2. Im Maschinenraum Die Funktechnik hinter WLAN
    3. 802.11be Broadcom stellt komplettes Wi-Fi 7 Chip-Portfolio vor