Stefan, Schepp und Peter regen sich über das Thema der Woche auf und beenden die Sendung mit ein paar interessanten Links.
Schaunotizen
- [00:00:09] jQuery considered harmful
- Lea Verou liefert einen der weniger guten Anti-jQuery-Artikel der letzten Monate ab. Weil sie sich vor Wrapper-Elementen und Technologie-Lockdown fürchtet, schlägt sie vor auf jQuery zu verzichten. Dass jQuery zahllose Browserbugs (nicht nur im IE) repariert und durch seine API und seine Plugins Webentwicklern das Leben sehr viel einfacher machen kann, wird übersehen – auch wenn es um jQuery-Alternativen wie Zepto und Shoestring geht. Nur in Ausnahmefällen können wir uns vorstellen, auf jQuery zu verzichten; Schepp berichtet von einem solchen Ausnahmefall. Am Ende richtet sich unser Unverständnis auf Leas Technik zur Erweiterung der DOM-Prototypen „ohne“ Kollisionen. Dass das grundsätzlich eine dumme Idee ist ist seit Ewigkeiten bekannt und würde selbst durch die Symbols in ECMAScript 6 nur ein wenig besser.
- Git Large File Storage
- Git-Erweiterung für große Binärdateien (PSD etc).
- Understanding the Real Advantages of Using ESLint
- Wie sich ESLint zu JSHint verhält und warum es rockt.
- Gulp-Rezepte
- Gulp-Guru Stefan sammelt Lösungen für häufige Probleme mit dem trendigsten Buildsystem aller Zeiten.
[00:43:48] Keine Schaunotizen
Kommentare
Martin G. #
Geschrieben am 2.05.2015 um 11:18
Hallo,
wiedermal eine schöne Sendung.
Ich mag jQuery, nicht wegen den Wrappern, die sind nervig, sondern wegen der Pipe Architektur.
Ich möchte euren rant auch nicht schlecht machen oder sagen das jQuery schlecht ist, aber ich würde gerne ein paar Gedanken beitragen
jQuery belegt genauso ein „Name-Space“ wie prototype Funktionen auch. Nur halt an einer anderen Stelle. Überscheidungen sind hier nur ausgeschlossen, weil jeder jQuery kennt.
Die Idee mit dem Symbol-NameSpace ist recht gut. Wenn eine Library-Symbol-Konstanten ausliefert haben diese die gleiche Sichtbarkeit wie ein $ oder jQuery. Es gibt also kein Unterschied im Handling vom String video.fw.addClass und dem Symbol cideo[fw].addClass:
Peter #
Geschrieben am 2.05.2015 um 11:42
Dass jQuery genau so einen Namen belegt wie eine Prototype-Property würde ich nicht sagen. Zum einen kann man eine lästige globale Variable ja einfach ignorieren bzw. „ersetzen“, indem sie in einem lokalen Scope shadowed. Und in Zukunft wird das, was heute das globale
$ist, durchaus keine globale, sondern eine lokale und frei wählbare Variable sein – Module sei Dank.Prototype-Properties kann man nicht shadowen oder in Zukunft mit Modulen in einen lokalen Scope zwingen. Die sind immer da und stehen immer im Weg.
Martin G. #
Geschrieben am 2.05.2015 um 12:29
Das mit dem Module kannte ich noch nicht. Ansonsten sollte man sowieso nie im gobalen Scope arbeiten.
Mich stört sowieso am meisten, das ich HTML Objecte nur mit Wrappern ummschließen und nicht mit meiner eigenen Klasse erweitern kann.
Das würde das Prototype Problem aufheben, da es die orginal Klasse nicht anfasst und im schlimmsten Fall neue Standardfunktionen einfach ersetzt ohne Sie anzufassen.
Leider ist das ja nicht möglich.
Das hätte ein guter Zwischenweg zwischen Wrapper und Prototype sein können.
Ich wünschte mir nur, das die Weiterentwicklung der Sprache schnell voran schreitet, so das man nicht so viele „Ticks“ verwenden muss um vernünftig damit zu Arbeiten.
Peter #
Geschrieben am 2.05.2015 um 12:38
Web Components?
Angesichts der Tatsache, dass bei JavaScript jede Weiterentwicklung, sollte sie einen Bug enthalten niemals nachträglich repariert werden kann, bin ich total für den langsamen Ansatz. Sollen die schlauen Köpfe sich bloß alle Zeit der Welt lassen. Alles, nur nicht noch mehr „bad parts“ bitte.
Martin G. #
Geschrieben am 2.05.2015 um 13:03
Ich habe das so verstanden, das man damit doch nur neue Elemente auf Basis von Simplen Elementen baut.
Das eigentlich Problem ist ja, das man immer mit Wrapped Element und Element jongliert, das ist nicht das ganz große Problem, da man einfach variablem wie element und $element nutzt, aber es wäre ja schon schön wenn man das normale element so erweiter kann, das es neue Funktionen hat, aber gleichzeitig auch so weiterverwendet werden kann, wie das ursprüngliche Objekt. So das auch native Funktionen dieses Object immernoch anerkennen.
Einfache Bugs können repariert werden. Unser Problem sind Fehler im Konzept.
Natürlich, wenn ein Bug lang genug existiert, das er zu einem Feature wird, ist das auch ein Problem, aber dies darf bei den modernen Browsern mit ihren kurzen Releasezeiten nicht mehr vorkommen.
Und was ich mit Weiterentwicklung meine, sind nicht großartige brandneue Konzepte, sondern Dinge, die seid Ewigkeiten funktionieren.
Wie z.b. eine vernünftige Klassenstruktur.Mit richtiger „extension“ und „interfaces“.
Auch die „bad parts“ sind ein Problem, wahrscheinlich würde ein sauberer Schnitt helfen, ein oder so wie beim Strickt mode ein ‚js2 mode‘ oder sowas.
Peter #
Geschrieben am 2.05.2015 um 13:18
Es gibt zwei Varianten: einerseits komplett neue Elemente erfinden, andererseits Type Extensions, wo man Objekt in die Prototype-Chain anderer Elemente einfügt. Somit könnte man durchaus eine eigene Funktion so einbauen, dass es sich anfühlt, als wäre es eine Erweiterung des Prototypen. Der Haken ist, dass das nur einmal geht, Type Extensions von Type Extensions gibt es nicht.
Was sind einfache Bugs und wie soll das gehen? Normalerweise wird ein (auch verbuggtes) Feature, sobald es einmal ausgerollt ist, von Entwicklern sofort zum Bau neuer Websites verwendet. Eine „Reparatur“ würde dazu führen, dass die neuen Webseiten in dem Browser, der die „Reparatur“ ausführt, nicht mehr funktionieren. Weil das nicht besonders gesund für den Marktanteil der fraglichen Browser wäre, passiert das nie. Niemals nie.
Dass „vernünftige Klassenstrukturen“ etwas gutes sind, ist keinesfalls Konsens.
Wird nicht passieren. JavaScript gibt es seit 15 Jahren und ist jetzt in dem Zustand, in dem es ist. Nochmal neu anfangen und 15 Jahre warten und hoffen dass es besser wird? Wird nicht passieren. Ein JavaScript 2.0 entwickeln und parallel das Alte weiterpflegen, d.h. den doppelten Aufwand betreiben? Wird nicht passieren. Noch mehr Sondermodi und strictere und strictere Strict Modes einführen? Wird nicht passieren.
Ich bin mir da relativ sicher :)
Peter #
Geschrieben am 2.05.2015 um 13:19
Korrektur: JS gibt es natürlich seit 25 Jahren.
Hans #
Geschrieben am 4.05.2015 um 14:06
Korrektur 2: JavaScript gibts seit 1995. Ist damit also 20 Jahre.
Die wichtigen Dinge… ;)
Peter #
Geschrieben am 4.05.2015 um 14:09
Hans hat natürlich Recht und ich bin ein Vollhuhn.
Martin G. #
Geschrieben am 2.05.2015 um 13:41
sobald es einmal ausgerollt ist, von Entwicklern sofort zum Bau neuer Websites verwendet
Das Internet läuft nicht auf einer spezifischen Engine, jeder Web-Entwickler muss je nach Zielgruppe viele verschiedene Browser Berücksichtigen.
Wenn also nicht alle den gleichen Bug haben, wird es recht schwierig sich darauf fest zu fahren.
Generell gibt es doch im Gegensatz zu früher ein Standard, welcher von den Browser Herstellern versucht wird umzusetzen. Eine unabsichtliche Abweichung, vor allem wenn es schon beliebte Frameworks gibt, welche es bereits richtig machen sollte für den Marktanteil genauso ungesund sein.
Dass “vernünftige Klassenstrukturen” etwas gutes sind, ist keinesfalls Konsens.
Was ist innerhalb einer Sprache wie Javascript die alternative? Der aktuelle Zustand kann es kaum sein.
Wird nicht passieren.
Habe ich auch nie behauptet.
Martin G. #
Geschrieben am 2.05.2015 um 13:44
Entschuldige, ich habe wohl die Quotes nicht richtig gesetzt.
Peter #
Geschrieben am 2.05.2015 um 14:00
Ich bezog mich auf Bugs in den Specs, die durch übereilte Entwicklung entstehen. Nicht auf Implementierungsfehler, die sind in der Tat kein Problem.
Weiß nicht. Vielleicht gibt es ja gar keine Alternative (für was genau eigentlich?).
Daniel #
Geschrieben am 2.05.2015 um 14:03
> Was ist innerhalb einer Sprache wie Javascript die alternative? Der aktuelle Zustand kann es kaum sein.
JavaScript ist dynamisch, funktional und prototypisch. Und das ist auch gut so. Die Paradigmen sind schlicht anders als in streng typisierten und Klassenbasierten Sprachen. Das „klassen-artige“ wurde (und wird leider auch in ES6) primär deswegen darüber gestreut, um Entwicklern aus der Java(-artigen) Welt den Einstieg leichter zu machen. Man kann z.b. mit JavaScript Klassen nachbilden, jedoch nicht andersherum mit Java prototypische Strukturen nutzen. Das allein zeigt, dass der prototypische Ansatz sehr flexibel ist.
Sehr interessant, wenn auch manchmal streitbar sind die Artikel von Eric Elliot:
https://medium.com/@_ericelliott
und sein Buch „Programming JavaScript Applications“
http://www.amazon.de/gp/product/1491950293/ref=s9_simh_gw_p14_d0_i1?pf_rd_m=A3JWKAKR8XB7XF&pf_rd_s=center-2&pf_rd_r=1R120MPEW105TKKXQY3J&pf_rd_t=101&pf_rd_p=455353687&pf_rd_i=301128
Open your mind, and your code will follow ;)
Daniel #
Geschrieben am 2.05.2015 um 14:20
Ich bin auch ein großer Freund von jQuery und danke mindestens einmal pro Monat John Resig für seinen Beitrag zur Webentwicklung. Es ist und bleibt sicher noch eine ganze Weile das Schweizer Taschenmesser, welches jeder Frontend-Entwickler beherrschen sollte.
Das die genannten Alternativen keine sind, darüber brauchen wir nicht streiten. Dennoch sehe ich andere Alternativen.
Ich habe mich in letzter Zeit intensiv mit React beschäftigt und sehe gerade in diesen deklarativen, Virtual-DOM-artigen Ansätzen viele interessante Möglichkeiten. Vor allem fällt mir auf, dass ich jQuery kaum noch benötige oder nutze. Schlicht, weil ich es durch die vollständige Abstraktion des DOMs und seiner Events nicht muss – das übernimmt ja React. Wenn man den „reinen“ React Weg beschreitet, muss man keine DOM Nodes nativ anhängen oder löschen. Keine CSS-Klassen direkt „adden/removen“. Keine Events direkt ans DOM hängen. Alles läuft über states und props und synthetische Events. Man deklariert seinen render-Output und React kümmert sich um den Rest. Dabei ist es erstaunlich abwärts kompatibel (https://facebook.github.io/react/docs/working-with-the-browser.html). Als Alternative für AJAX kann ich Superagent (https://visionmedia.github.io/superagent/) empfehlen.
Das alles soll nicht heißen, dass man jQuery nicht nutzen soll/darf – man braucht es einfach nicht mehr so häufig. Ich könnte mir vorstellen, dass sich dieser Trend im Zuge des Virtual DOM und Isomorphic JS Hypes fortsetzt. Auch Angular2 und Ember scheinen auf den Zug aufzuspringen.
Peter #
Geschrieben am 2.05.2015 um 14:42
Glaube nicht dass man React und jQuery miteinander vergleichen sollte. Das eine ist eine vergleichsweise komplizierte Totalabstraktion, das andere ein Helferlein, das man auch ohne viel Ahnung von irgendwas benutzen kann.
Daniel #
Geschrieben am 2.05.2015 um 14:51
Vergleiche ich ja auch nicht :) – ich *stelle nur fest*, dass man im Kontext von solchen Frameworks auf große Teile von jQuery verzichten kann, da sie quasi schon eingebaut sind.
Peter #
Geschrieben am 2.05.2015 um 15:05
… bis dann das erste UI-Widget-jQuery-Plugin gebraucht wird. Ich glaube wirklich nicht, dass es eine Bedeutung hat, ob man solchen MVC-Krempel einsetzt. Früher oder später muss man an dem vorbei irgendwas hinfummeln und dann ist wieder jQuery angesagt.
Christoph #
Geschrieben am 2.05.2015 um 15:22
Nun, die Ruby-Welt nutzt das Monkey-Patching ja sehr intensiv: Ganz wunderbar wenn man im Projekt dann 3 Libraries hat, die überall to_json Methoden dran kleben. Und je nach Versionen der Frameworks sind die dann mal kompatibel (ob durch Zufall oder gewollt – kann man vielfach nur Raten) oder dann auch plötzlich nciht mehr – dann steht man da.
Auch die Idee Testing-DSLs auf die Art zu machen stammt ja aus der Ruby-Welt: Auch das funktioniert halt nur gut, solange es 1 Standard-Testing-Framework gibt, so dass der Rest dessen Namenskonventionen respektiert.
Ich würde dem in jedem Fall aus dem Weg gehen.
Christoph #
Geschrieben am 2.05.2015 um 17:44
Ein paar Kommentare von euch waren einfach nur Beschissen – so richtig schlechtes Internet-Niveau:
– „wahrscheinlich zu viel Alkohol, viel Hitze“ – für sowas sollte man sich eigentlich entschuldigen.
– „Thomas Fuchs arrogant“ – warum ad hominem? Dann auch noch ohne Argumente?
– „die Madame“…“sie ist halt eine Meinungsmacherin“… „die mag das ja auch das sich in Szene setzen“… – da schwingt durchaus ein gesunder Sexismus mit.
Nur Peter war sachlich. Trauriger Auftritt der alles hatte was Forendiskussionen z.B. bei Heise „ausmachen“.
Noch ein Nachtrag zum Post zuvor: Dennoch muss man sagen funktioniert das in der Ruby-Welt über die Jahre im grossen und ganzen sehr Schmerzfrei. Und auch z.B. C# (Extension Methods) und Scala (Implicits) machen ähnliches – es ist einfach nicht so abwegig wie ihr tut und funktioniert vielfach sehr gut. Eigentlich könnte man der Vorwurf der Uninformiertheit an euch zurück geben – aus eurer JS-Welt scheint ihr schon lange nicht mehr herausgekommen zu sein.
So, genug aufgeregt. Noch ein schönes Rest-Wochenende.
Peter #
Geschrieben am 3.05.2015 um 17:25
Die anderen Sprachen erlauben meines Wissens etwas weniger brutale Monkey-Patch-Methoden als JS, wo das Zumüllen globaler Objekte die einzige existierende Möglichkeit ist. Nun könnte man sicher in JS Alternativen einführen, was ja mit Zeug wie
class MyArray extends Array {}in ES6 teilweise auch schon passiert. Das hilft nur relativ wenig wenn es um DOM geht und wenn man das globale Zumüllen nicht abschaffen oder abschalten kann.Stefan #
Geschrieben am 4.05.2015 um 14:28
In anderen Sprachen sind die Umgebungen und Erweiterungsmöglichkeiten auch viel besser kontrolliert und sprachlich festgehalten. C# und Java setzen ja mit dem Interface-Konzept direkt darauf und motivieren sogar zu erweiterbaren Konstrukten. (Allerdings ist dort auch der Weg, dass man von Klassen der Laufzeitumgebung eher ableitet anstatt noch etwas dranzustückeln) Wenn unsere Runtime allerdings auf einer dem Implementierungsstand hinterherhinkenden Spezifikation basiert und sich nach Gutdünken nicht nur alle sechs Wochen ändern kann, sondern man es im schlimmsten Falle mit allen Versionen gleichzeitig zu tun hat, steht man halt schnell damit an.
Schepp #
Geschrieben am 5.05.2015 um 15:40
Ach Christoph, unser Podcast muss zum einen ja nicht immer sachlich sein. Viel wichtiger ist, dass er authentisch ist. Zum anderen habe ich Lea schon persönlich getroffen und gesprochen, auf Konferenzen, auf Parties und auch einfach nur im Flieger. Glaub mir, ich weiß wovon ich rede. Und ich könnte noch viel mehr berichten, das hier aber tatsächlich nicht zu suchen hat. Das Ding ist, Lea könnte viel mehr anschieben, wenn sie nicht so abgehoben und narzistisch wäre. Das Hauptproblem ist, dass sie eine große Anhängerschaft hat, darunter auch viele Herren, die vielleicht sogar ein wenig verschossen in sie sind, die nicht unbedingt hinterfragen, was sie vorbetet. Mit 56.000 Followern trägt man eine gewisse Verantwortung, und die heißt nicht Artikel zu schreiben, die behaupten dass jQuery schädlich ist (der dann doch Zepto empfiehlt).
Worin Du „gesunden Sexismus“ herausliest weiß ich nicht. Weil ich „die Madame“ sage, wo ich „der Herr“ sagen würde? Ich würde das eher genderfreie Antipathie nennen.
Apropos „der Herr“: Dass ich persönlich finde, Thomas Fuchs arrogant (und auch immer sehr negativ) ist, muss ich ja in einem Podcast nicht zwangsläufig weiter darlegen. Du kannst Dir ja anschauen, wie zuvorkommend er mit Leuten auf Github umgeht, oder auf Twitter. TL;DR: Eigentlich hat es keiner drauf, außer er. Kann man machen, aber dann kann man nicht erwarten, dafür gemocht zu werden. Vielleicht ist er mittlerweile ja ganz anders drauf, aber ich lese seinen Kram seit rund zwei Jahren aufgrund des eben Genannten nicht mehr.
Jo #
Geschrieben am 4.05.2015 um 13:35
Hey,
wenn ihr schon über einen Artikel ranted, wär es super, wenn sich wenigstens alle Beteiligten die Mühe machen würden, sich den Artikel auch durchzulesen.
Danke
Peter #
Geschrieben am 4.05.2015 um 13:37
Präzisiere?
Daniel #
Geschrieben am 4.05.2015 um 13:45
Schepp @ 1:17
„… habe es mir im Großen und Ganzen auch erspart zu lesen …“
Das fand ich auch sehr merkwürdig. Den Kritikpunkten von Christoph stimme ich ebenfalls zu.
Schepp #
Geschrieben am 5.05.2015 um 15:08
Letztendlich reicht mir der provokative Titel wie auch das Fazit: „jQuery schadet, weil Vendor Lock-in. (Und wenn schon $-Wrapper dann nehmt Zepto)“. Dazu habe ich auch durch die Diskussionen auf Twitter einiges an Kontext gesammelt, wo Leute mit Lea über Ihren Artikel diskutiert haben. Entscheidend ist, dass sie die Leute ermutigt, kein jQuery mehr zu verwenden. Und das ist ein großer Fehler, der bei ihrer Followerschaft eine große Tragweite hat.
Olong #
Geschrieben am 4.05.2015 um 13:39
Haben sie doch getan!
Irgendeiner #
Geschrieben am 19.05.2015 um 20:53
Ich fand die Folge recht amüsant. Spätestens wenn man anfängt alles mit jQuery zu beschmeißen was auch nur ähnlich wie eine Website aussieht, ist ein „jQuery considered harmful“ durchaus angebracht. Meiner Meinung nach wird viel zu selten wirklich darüber nachgedacht welche Bibliothek angebracht wäre und welche nicht. Bringt ihr nicht so gerne den Spruch „Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel“?
Etwas schade ist es schon, dass keiner von euch die Problematik mal kritisch hinterfragt hat.
Schepp #
Geschrieben am 19.05.2015 um 23:24
Ich für meinen Part habe sehr wohl Projekte, die ich auch ohne jQuery baue, z.B. zuletzt die Seite der Webworker NRW. Sogar mit jQuery-freiem Bilderslider! Bei allem, das größer skaliert als diese schlanke Microsite und das nicht auf Dritte-Welt-Länder und Feature Phones abzielt, und das ist die Mehrzahl der Projekte, halte ich den Verzicht auf jQuery für maximal unklug. Die Argumente für jQuery sind Verständlichkeit, Effizienz, Robustheit und Flexibilität. Nachteile? Was denn? Extra Ladezeit? Bezweifle ich ernsthaft, dass man das im Gesamtgefüge spürt. Man merkt vielleicht, wenn man hinterher noch zig jQuery-Plugins hinterherschaufelt. Aber das ist was anderes.
Irgendeiner #
Geschrieben am 20.05.2015 um 12:24
Das zeigt doch sehr schön, dass man eben nicht immer jQuery braucht, sobald Javascript ins Spiel kommt. Genau das hat mir in der Diskussion etwas gefehlt. Es hörte sich leider sehr nach einem Jemand-sagt-etwas-böses-über-jQuery-Beißreflex an, auch wenn ihr das vielleicht gar nicht so gemeint habt. Es gibt da draußen sehr viele Microsites, bzw. würde ich das für jede durchschnittliche 08/15 Website mit ein paar Informationen und Bildern geltern lassen, wo man eigentlich kein ausgewachsenes Framework braucht.
Bei aufwändigen Seiten würde ich darauf auch nicht verzichten wollen, wobei ich bei einem aktuellen Projekt an Mootools gebunden bin und im Gegensatz zu Projekten mit jQuery nichts vermisse. Ich halte diese Frameworks für leicht austauschbar, egal ob sie jQuery, Mootools, Dojo, Qooxdoo oder sonstwie heißen. Den unumstößlichen Qualitätsvorteil den ihr da jQuery attestiert gibt es meiner Meinung nach so nicht.
Als nächstes Thema würde ich hier noch die MV*-Frameworks hinzuziehen. In der Regel braucht man dann meiner Meinung nach kein zweites mehr mit reinziehen. Oben wurde React angesprochen, ich habe mich in letzter Zeit intensiver mit Mithril auseinandergesetzt, die funktionieren vom Prinzip her ähnlich, beide mit virtuellem DOM. Sortierungen und Filter lassen sich zum Beispiel sehr leicht auf Basis des VDOM umsetzen, um das Rendering kümmert sich das Framework.
Vielleicht erklärt dieser Beitrag auch für Peter was ich mit „Problematik“ meine. Die Problematik ist meiner Meinung nach nicht, dass jQuery schlecht wäre (das ist es nicht), sondern dass es gleichwertige Alternativen und je nach Anwendungsfall sogar besser geeignete Software gibt. Man sollte die Aufgabenstellung im Blick haben und das passende Tool auswählen. Das darf gerne, aber es muss nicht auf jQuery hinauslaufen.
Peter #
Geschrieben am 20.05.2015 um 13:24
Mootools ist keine gleichwertige Alternative. Mootools macht genau den Fehler, den Lea Verou mit ihrern jQuery-Ersatz-Funktionen macht: globale Prototypen erweitern. Auf der Oberfläche scheint Mootools das gleiche zu machen wie jQuery, aber es richtet im Zuge dessen extrem viel Flurschaden an. Dass man globale Objekte nicht extenden sollte, ist seit Ewigkeiten bekannt. Nur weil Mootools es trotzdem macht, wurde z.B. die Entwicklung von ES6 beeinträchtigt, weil eben zu viele Webseiten sich durch Mootools zu viel kaputtmachen lassen (ggf. ohne dass es im ersten Moment groß auffällt).
Ich sage auch viel Böses über jQuery. Ich hatte heute eine Schulung über asynchrones JavaScript, in der ich ohne Ende auf jQuery-Promises eingedroschen habe. Nur: außer Promises macht jQuery eben sehr viel richtig, was andere (auf unauffällige Art und Weise) falsch machen. Und jQuery repariert genau die Browserbugs, von denen die meisten (Menschen und jQuery-„Alternativen“) keine Ahnung haben.
Daher ist eben der einzig sinnvolle Default, jQuery zu verwenden. Und wenn ganz bestimmte Umstände vorliegen, kann man ggf. auch mal drauf verzichten (wie Schepp ja auch schrieb). Nur wann hat man das schon mal?
Irgendeiner #
Geschrieben am 20.05.2015 um 14:19
Ob Mootools unter der Haube etwas „falsch“ macht oder nicht, macht es nicht weniger zu einer Alternative. Es löst die gleichen Probleme wie jQuery und bisher sind zumindest bei diesem konkreten Projekt keine Bugs bekannt vor denen uns eine andere Bibliothek bewahrt hätte. Da ich nicht in der Position bin um über die verwendete Software zu entscheiden, muss ich eh mit dem leben was mir vorgesetzt wird, aber das war aus Entwicklersicht bisher auch kein Problem. Bei Dojo, Qooxdoo und all den anderen lassen sich sicher auch Kritikpunkte finden, dennoch sind es Alternativen.
Ich habe noch kein überzeugendes Argument gehört, warum jQuery der einzig sinnvolle Default sein sollte. Es ist nur eine Bibliothek unter vielen und genau so sollte man damit umgehen. Der einzig sinnvolle Default ist meiner Meinung nach keine Bibliothek zu setzen und nur bei Bedarf eine zu evaluieren. Monokultur war noch nie gut.
Peter #
Geschrieben am 21.05.2015 um 12:05
Wenn wir „it works for me“ als Antwort zulassen wollen, kann ich dir kein „überzeugendes Argument“ bieten.
Irgendeiner #
Geschrieben am 21.05.2015 um 21:59
Das finde ich jetzt zu einfach. Ich denke wir sind uns einig, dass so ein Framework uns Arbeit abnehmen und etwas syntaktischen Zucker für die tägliche Arbeit bieten soll?! Das tun alle hier genannten und sicher noch mehr, damit ist das für mich mehr als „it works for me“, sondern rein objektiv betrachtet eine vielzahl von Alternativen.
Gut bei Mootools gibt es Kritikpunkte, aber was macht jQuery jetzt besser als alle anderen? Was ist das Killerfeature? Ich arbeite oft mit jQuery, sehr viel häufiger als ich noch mit Mootools oder anderen Frameworks in Berührung komme, aber genau dieses „Killerfeature“ ist mir noch nicht untergekommen.
Ich hatte in einem Webpodcast mehr Differenzierung erwartet, das hat mich enttäuscht und deshalb habe ich meinen Kommentar hier geschrieben. Nicht weil ich etwas gegen jQuery habe oder den Artikel von Lea so gut finde (ich habe ihn nicht mal gelesen).
Schepp #
Geschrieben am 21.05.2015 um 12:15
Ich verstehe immer noch nicht, was das Problem an jQuery ist. Monokultur?
Monokultur ist ja durchaus nicht schlecht, weil ein Kampf gekämpft ist und man sich auf bestimmte Standards verlassen kann. Und man kann sich auf darauf aufbauende Dinge konzentrieren. Ein Architekt fängt ja nun auch nicht an, ständig die Beton-Zusammensetzungen, oder die Art, Statik zu berechnen in Frage zu stellen. Beides ist etabliert.
Davon abgesehen plädiert Lea ja eben nicht für ein anderes etabliertes Framework, sondern sie schlägt vor, dass jeder wieder sein eigenes auf ihren Ideen basierendes Inselkonstrukt entwickelt. Für den Lerneffekt des Einzelnen sicher nett, aber der Sache halt einfach nicht dienlich.
Irgendeiner #
Geschrieben am 21.05.2015 um 22:13
Das Problem ist nicht jQuery, sondern wenn man es einfach immer – auch ohne Notwendigkeit – hernimmt. Das tust du ja offensichtlich auch nicht, aber so wie es in der Sendung rüber kam, war genau das die Empfehlung für den Hörer. Wie oben schon gesagt habe ich den Artikel von Lea gar nicht gelesen, sondern nur eure Reaktionen darauf angehört. Die Vehemenz mit der ihr jQuery verteidigt und gegen die Autorin geschossen habt fand ich schon befremdlich. Ich hätte mir da ein kritisches Herangehen gewünscht.
Schepp #
Geschrieben am 23.05.2015 um 07:14
Werden wir nächstes mal machen, versprochen. Dank Dir auf jeden Fall für Deinen Input.
Peter #
Geschrieben am 23.05.2015 um 11:36
Wie genau muss ich mir das vorstellen, jQuery zu benutzen ohne es zu brauchen? Binde ich das einfach ein oder verwende das nicht? Das kann ja wohl nicht sein. Oder verwende ich das für Dinge, die andere (nicht ich) ohne jQuery machen würden? Weil dann bräuchte ich es ja doch, denn anders bekomme ich es ja nicht. Oder verwende ich es, weil ich, obwohl ich auch ohne könnte, damit schneller bin? Das fände ich legitim, Produktivität geht vor. Oder verwende ich es, weil ich selbst zwar auch ohne klarkomme, aber das nicht auf jedes aktuelle oder möglicherweise zukünftige Teammitglied zutrifft? Je einfacher es andere haben, umso besser (meine Meinung). Und wenn es um mich persönlich geht, greife ich meist dazu, weil ich die enorme Browser-Bug-Liste nicht im Kopf habe (würde behaupten: gar nicht im Kopf haben kann) und die bereits diskutieren „Alternativen“ zu viel Flurschaden anrichten.
Viele „Alternativen“ haben so ihre Pluspunkte. Mootools hat z.B. ein API-Design, das man, wenn man nicht weiß welcher Flurschaden entsteht, besser finden kann. Nur wenn man einigermaßen ernsthaft abwägt, kann es nur einen Sieger geben.
Irgendeiner #
Geschrieben am 26.05.2015 um 14:06
Interessiert es dich wirklich? Ich meine deine leidenden Tweets lassen das nicht so recht vermuten, das klingt eher als wäre es dir lästig zu diskutieren.
Ja möglicherweise braucht man gar kein Framework. Oder man möchte nur ein paar Animationen erstellen und würde dafür aufgrund der besseren Performance eh auf Velocity zurückgreifen. Braucht man dann jQuery? Vielleicht schon, wenn man noch viel mit dem DOM oder Events hantiert, vielleicht aber auch nicht, weil man sich eigentlich nur auf die Animation konzentriert. Was wenn ich ein sehr umfangreiches Projekt habe und Teile bei Bedarf nachgeladen werden sollen? Da böte sich zum Beispiel Dojo an, das setzt von Grund auf auf eine asynchrone Struktur, sogar teile des Frameworks werden nur bei Bedarf geladen. Die MVC-Frameworks die auf einem VDOM basieren wurden ja schon genannt, also ja es gibt durchaus genügend Gelegenheiten die mir einfallen, wo ich nicht zu jQuery greifen würde.
Die Bugliste kenne ich, ich finde es gut, dass dort so viel Bugfixing betrieben und auch die Probleme in dem Dokument festgehalten werden. Ich kann mir nur nicht recht vorstellen, dass andere Frameworkentwickler keinen Wert darauf legen. Die werden auch ihre Bugs korrigieren und für browserübergreifend gleiches Verhalten sorgen. Das liegt eigentlich in der Natur eines Javascript-Frameworks, denn sonst bräuchte man es nicht.
Häng dich doch nicht so an Mootools auf, das habe ich als Beispiel genannt, weil ich es gerade in einem Projekt verwende. Bei den anderen Frameworks ist mir kein „Flurschaden“ bekannt. Und jQuery als Grund für Teammitglieder die nichts anderes können finde ich schon äußerst abenteuerlich. Also ich mag nicht mit Leuten zusammen arbeiten, die Javascript als Sprache nicht beherrschen oder/und nicht fähig sind sich in andere Software einzuarbeiten.
Ich glaube aber wir drehen uns langsam im Kreis. Mir ging es nur darum, dass man jQuery nicht als alternativlos darstellen sollte, weil es eben das nicht ist. Es steht jedem frei zu verwenden was er möchte, ich hätte nur in einem Fach-Podcast wie diesem hier eine differenzierte Auseinandersetzung erwartet. Ich werde euch jedenfalls als Hörer treu bleiben und hoffe, dass ihr das Für und Wider in Zukunft so gut beleuchtet wie ihr das fast immer getan habt.
Peter #
Geschrieben am 30.05.2015 um 15:38
Interesiert es mich ernsthaft? Natürlich nicht! Soll doch jeder machen was er/sie will.
Leide ich? Nein, eher bin ich leicht amüsiert ob das alljährlichen Wiedergänger-Themas. Jedes Jahr poppt es wieder hoch und der Inhalt der „Debatte“ ist jedes Mal der exakt gleiche:
„jQuery ist doof, übt Verzicht!“
„jQuery fixt Bugs und macht das DOM benutzbar“
„Wir meinten mit ‚Verzicht‘ eigentlich $andere_library“
„$andere_library hat folgende Nachteile: …“
„Wir meinten mit $andere_library eigentlich $ganz_andere_library unter $besondere_umstaende“
„Unter $besondere_umstaende vielleicht, aber wann hat man die schon mal…“
„Siehste? jQuery ist doof, übt Verzicht!“
„…“
Und so weiter. Richtig lästig ist das auch nicht. Ich ärgere mich höchstens, dass ich vom letzten und vorletzten und vorvorletzen und vorvorvorletzen Mal nicht meine Antworten aufgehoben habe und sie immer wieder neu formulieren muss. Aber das ist ja meine eigene Schuld und wird nicht wieder passieren.
Ich höre aber jetzt auf, weil ich nicht das Gefühl habe, dass das hier noch zu etwas führt. Mach du mal wie du meinst :)
Peter #
Geschrieben am 20.05.2015 um 08:50
Erkläre mir die Problematik an der „Problematik“.
RSS-Feed zu diesem Beitrag
Kommentare sind für diesen Beitrag geschlossen.