Matthias Scharwies: Heise entfernt jQuery

Servus!

Grad gefunden:

Technische Schulden entfernen

Heise untersucht Webseiten und ersetzt jQuery durch Vanilla JS.

Herzliche Grüße

Matthias Scharwies

--
"I don’t make typos. I make new words."
  1. Hallo,

    jquery abzuschaffen finde ich gut und sinnvoll. Den Lobgesang auf dieses Framework in dem Bericht finde ich Quatsch (...fast unumgängliches Tool für die Frontend-Entwicklung...) und nicht zutreffend.

    Danke für den Lesehinweis.

    lg.

    1. Tach!

      jquery abzuschaffen finde ich gut und sinnvoll. Den Lobgesang auf dieses Framework in dem Bericht finde ich Quatsch (...fast unumgängliches Tool für die Frontend-Entwicklung...) und nicht zutreffend.

      "... war besonders zu seiner Anfangszeit ...". Die Alternative wäre gewesen, alle Browsereigenheiten von damals selbst zu berücksichtigen, bei generell umständlicherem Code. Dass heutzutage alles in Vanilla zu erledigen geht, was damals jQuery zu verbessern angetreten ist, ist zum Teil wohl auch jQuery zu verdanken, weil es gezeigt hat, dass es besser gehen kann.

      Aber auch heute ist es mitunter noch eine Nasenlänge voraus. Wo man in Vanilla zwischen document.querySelector(...) und document.querySelectorAll(...) unterscheiden muss, inklusive der Folgeverarbeitung. kommt jQuery immer noch mit einem simplen $(...) aus, das man, egal wieviele Elemente selektiert werden, mit denselben jQuery-Methoden bedienen kann.

      dedlfix.

      1. @@dedlfix

        Aber auch heute ist [jQuery gegenüber Vanilla-JavaScript] mitunter noch eine Nasenlänge voraus.

        An welchen Stellen sollte das der Fall sein?

        Wo man in Vanilla zwischen document.querySelector(...) und document.querySelectorAll(...) unterscheiden muss

        Man kann in Vanilla-JS zwischen document.querySelector(...) und document.querySelectorAll(...) unterscheiden; jQuery bietet die Möglichkeit gar nicht erst.

        inklusive der Folgeverarbeitung. kommt jQuery immer noch mit einem simplen $(...) aus

        document.querySelectorAll(...).forEach(...) mag etwas längerer Code sein, ist dafür aber selbsterklärend. Man hat besseren Überblick, was man da tut.

        mit denselben jQuery-Methoden bedienen kann.

        In denen der ein oder andere Design-Fehler steckt.

        LLAP 🖖

        --
        „Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
        1. Tach!

          Wo man in Vanilla zwischen document.querySelector(...) und document.querySelectorAll(...) unterscheiden muss

          Man kann in Vanilla-JS zwischen document.querySelector(...) und document.querySelectorAll(...) unterscheiden; jQuery bietet die Möglichkeit gar nicht erst.

          Und was hat man dann davon? Ob man bei einem Element selbiges bearbeitet oder eine Schleife über ein Element laufen lässt, bleibt sich prinzipiell gleich, führt beides zum Ergebnis.

          mit denselben jQuery-Methoden bedienen kann.

          In denen der ein oder andere Design-Fehler steckt.

          Wenn das ein Ausschlusskriterium ist, was empfiehlst du dann statt Vanilla-Javascript?

          dedlfix.

        2. inklusive der Folgeverarbeitung. kommt jQuery immer noch mit einem simplen $(...) aus

          document.querySelectorAll(...).forEach(...) mag etwas längerer Code sein, ist dafür aber selbsterklärend.

          Da stimme ich zu, ich würde es aber etwas anders formulieren. "Selbstsprechend" ist zu hoch gegriffen, aber der Code kommuniziert eine grobe Intention.

          Man hat besseren Überblick, was man da tut.

          Da stimme ich nicht zu. In der natürlichen Kommunikation spielt neben der Formulierung auch die Intonation eine elementare Rolle. So ist es auch mit Kommunikation über das Medium Quelltext. jQuery betont den Selektor und rückt Boilerplate-Code in den Hintegrund. Natives DOM ist dagegen monoton, unpointiert. Natives DOM legt größeren Wert auf verständliche Bezeichner. jQuery hingegen legt mehr Gewicht auf eine hohe signal-to-noise ratio.

        3. Lieber Gunnar,

          document.querySelectorAll(...).forEach(...) mag etwas längerer Code sein, ist dafür aber selbsterklärend.

          ... und funktioniert leider noch nicht in allen Browsern garantiert.

          Liebe Grüße

          Felix Riesterer

          1. @@Felix Riesterer

            document.querySelectorAll(...).forEach(...) mag etwas längerer Code sein, ist dafür aber selbsterklärend.

            ... und funktioniert leider noch nicht in allen Browsern garantiert.

            Kein JavaScript funktioniert in allen Browsern garantiert.

            LLAP 🖖

            --
            „Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
            1. Lieber Gunnar,

              Kein JavaScript funktioniert in allen Browsern garantiert.

              jetzt spiel' doch nicht gleich den beleidigten, bloß weil das von Dir hier als überlegen angeführte NodeList.forEach noch nicht in allen Browsern implementiert ist.

              Liebe Grüße

              Felix Riesterer

              1. @@Felix Riesterer

                Kein JavaScript funktioniert in allen Browsern garantiert.

                jetzt spiel' doch nicht gleich den beleidigten, bloß weil das von Dir hier als überlegen angeführte NodeList.forEach noch nicht in allen Browsern implementiert ist.

                Das tue ich auch nicht. Ich wollte auf das Prinzip von progressive enhancement hinweisen. Leider ist das hier immer wieder nötig.

                LLAP 🖖

                --
                „Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
                1. Tach!

                  Ich wollte auf das Prinzip von progressive enhancement hinweisen. Leider ist das hier immer wieder nötig.

                  Mir ist funktionierende Software lieber als Fehlermeldungen von Kunden, bei denen bestimmte Teile nicht laufen.

                  Ich sehe es als einfacher an, eine Bibliothek mit Altbrowserunterstützung zu nehmen, und dann einheitlich zu arbeiten, als je nach Wichtigkeit des Features mal modere mal kompatible Programmierung zu verwenden. Auch Transpiler nach Alt-Code und Polyfills sind besser als nicht funktionierende Features auf einigen Kundengeräten.

                  Die Entscheidung, wie man etwas löst, ist letztlich projekt- und zielgruppenabhängig und kann nicht allgemeingültig mit PE geklärt werden.

                  dedlfix.

        4. Hallo Gunnar Bittersmann,

          inklusive der Folgeverarbeitung. kommt jQuery immer noch mit einem simplen $(...) aus

          document.querySelectorAll(...).forEach(...) mag etwas längerer Code sein, ist dafür aber selbsterklärend.

          Wenn mans weiß, ist $(…) genauso selbsterklärend, wie # oder […] auf der CSS-Seite.

          Bis demnächst
          Matthias

          --
          Pantoffeltierchen haben keine Hobbys.
          ¯\_(ツ)_/¯
          1. Tach!

            document.querySelectorAll(...).forEach(...) mag etwas längerer Code sein, ist dafür aber selbsterklärend.

            Wenn mans weiß, ist $(…) genauso selbsterklärend, wie # oder […] auf der CSS-Seite.

            Außerdem setzt es voraus, dass querySelector/-All selbsterklärend sei. getElementById usw. ist ja quasi ein verständlicher Satz, was man von querySelector nicht unbedingt sagen kann. Man muss da auch wissen, was diese Funktion macht. getElementBySelector und getElementsBySelector wäre sprechender und eine Fortsetzung zu dem, was man bereits hat.

            Andererseits sehe ich nicht, dass immer alles selbsterklärend sein müsse. Wenn sich Code einfach lesen lässt, ist das zwar prinzipiell erstrebenswert, aber das Wissen um solche grundlegenden Funktionalität und Funktionen sollte man voraussetzen dürfen. Nebst der Bereitschaft, im Zweifelsfall in der Dokumentation nachzuschauen.

            dedlfix.

          2. @@Matthias Apsel

            Wenn mans weiß, ist $(…) genauso selbsterklärend, wie # oder […] auf der CSS-Seite.

            Du schreibst in Oxymora.

            Außerdem meinte ich das nicht, sondern: document.querySelectorAll(...).forEach(...) sieht man an, dass eine Menge von Elementen ausgesiebt und dann über diese iteriert wird. $(...) sieht man das nicht an.

            LLAP 🖖

            --
            „Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
            1. Tach!

              Außerdem meinte ich das nicht, sondern: document.querySelectorAll(...).forEach(...) sieht man an, dass eine Menge von Elementen ausgesiebt und dann über diese iteriert wird. $(...) sieht man das nicht an.

              Macht aber nichts weiter. Das ist das Grundprinzip von jQuery, dass es eine Ergebnismenge liefert, auf die dann die Methoden angewendet werden. Das lernt man gleich am Anfang.

              dedlfix.

              1. Hallo dedlfix,

                wenn's denn so einfach wäre. Das ist einer der ekligsten Design-Quirks von jQuery: Die jQuery-Funktion (bzw. die $ Funktion) ist ein Schweizer Taschenmesser mit derzeit 9 Überladungen. 4 liefern ein Wrapped Set um DOM Elemente, eine liefert ein leeres Wrapped Set. Eine wrapped ein JS-Objekt um das jQuery4854323423-Attribut anzukleben. Zwei erzeugen ein DOM Element aus einem HTML String, wahlweise in einem Fremddokument ODER mit einer Art Action-Objekt zum INitialisieren - aber nicht beides, und eine weitere Überladung registriert einen Ready-Handler. Eine DWIM[1]-Funktion, die so scharfsinnig ist, dass man sich daran in den Finger schneidet.

                Außerdem ist sie ein Container-Objekt für gefühlt 1000 Helper, die nur entfernt mit DOM-Queries zu tun haben.

                Und dann wird da pro Version noch mehr Kram deprecated als bei PHP, und da ist das schon ätzend. Ich gebe zu, wenn man sich dran gewöhnt hat, ist jQuery sehr bequem und bringt eine Menge mit. Aus Sicht von Software-Engineering und Versionsstabilität ist das Ding - meiner Ansicht nach - die Hölle.

                Rolf

                --
                sumpsi - posui - clusi

                1. Do What I Mean ↩︎