tami: App Lego - Mozilla veroeffentlicht Bibliothek aus Webkomponenten

  1. Meine Herren!

    http://www.heise.de/developer/meldung/App-Lego-Mozilla-veroeffentlicht-Bibliothek-aus-Webkomponenten-2138577.html?wt_mc=sm.feed.tw.developer

    Ja, das ist eine der interessantesten Entwicklungen derzeit. Polymer ist ein vergleichbares Projekt zu X-Tags und läuft auch schon mit einigen vorgefertigten Elementen auf.

    Man muss sich aber darüber im Klaren sein, dass die Web Components gerade erst in einer sehr frühen Standardisierungs-Phase [w3c Einführung] sind und sich noch sehr viel ändern kann. Für den Produktiveinsatz also noch ein zu hohes Risikio.

    Für Interessierte gibt es hier [gist] noch eine schöne Liste mit passender Lektüre.

    --
    “All right, then, I'll go to hell.” – Huck Finn
    1. Meine Herren!

      Ja, das ist eine der interessantesten Entwicklungen derzeit.

      Wirklich!?

      Polymer ist ein vergleichbares Projekt zu X-Tags und läuft auch schon mit einigen vorgefertigten Elementen auf.

      Man muss sich aber darüber im Klaren sein, dass die Web Components gerade erst in einer sehr frühen Standardisierungs-Phase [w3c Einführung] sind und sich noch sehr viel ändern kann. Für den Produktiveinsatz also noch ein zu hohes Risikio.

      Kann mir mal bitte einer den Sinn & Zweck, bzw. den/ die Vorteil(e) davon erklären?

      Ist das jetzt die endgültige "Zwangshochzeit" von Webseiten und Javascript?

      Gruß Gunther

      1. Meine Herren!

        Ja, das ist eine der interessantesten Entwicklungen derzeit.

        Wirklich!?

        Google und Mozilla investieren viel in diese neue Technologie, große JavaScript-Frameworks wie Ember.js und Angular.js haben bereits ihre Pläne angekündigt und in der Blogger-Szene herrscht reges Interesse und es wird viel gezwitschert. Ich persönlich bin auch begeistert.

        Kann mir mal bitte einer den Sinn & Zweck, bzw. den/ die Vorteil(e) davon erklären?

        Die Wiederverwendbarkeit von Komponenten ist extrem hoch. Eine Komponente exportiert eine Schnittstelle, die über das gewöhnliche DOM adressiert wird und kapselt alle internen Implementations-Details durch das Shadow-DOM vollkommen von der Außenwelt ab. Diese Herangehensweise impliziert auch eine enorme Interoperabilität, weil alle gängigen JavaScript-Frameworks und -Anwendungen sowieso schon DOM sprechen können.

        Ist das jetzt die endgültige "Zwangshochzeit" von Webseiten und Javascript?

        Nein, wieso?

        --
        “All right, then, I'll go to hell.” – Huck Finn
        1. Mein Herr!

          Ja, das ist eine der interessantesten Entwicklungen derzeit.

          Wirklich!?

          Google und Mozilla investieren viel in diese neue Technologie, große JavaScript-Frameworks wie Ember.js und Angular.js haben bereits ihre Pläne angekündigt und in der Blogger-Szene herrscht reges Interesse und es wird viel gezwitschert. Ich persönlich bin auch begeistert.

          Viel gezwitschert wird immer ...! ;-)
          Was begeistert dich denn daran jetzt so?

          Kann mir mal bitte einer den Sinn & Zweck, bzw. den/ die Vorteil(e) davon erklären?

          Die Wiederverwendbarkeit von Komponenten ist extrem hoch. Eine Komponente exportiert eine Schnittstelle, die über das gewöhnliche DOM adressiert wird und kapselt alle internen Implementations-Details durch das Shadow-DOM vollkommen von der Außenwelt ab. Diese Herangehensweise impliziert auch eine enorme Interoperabilität, weil alle gängigen JavaScript-Frameworks und -Anwendungen sowieso schon DOM sprechen können.

          Sorry, aber imho ist das doch nichts anderes als "herkömmliche" Javascript Bausteine, nur mit dem Unterschied, dass diese zusätzlich noch auf Web Components, also custom HTML tags basieren.

          Oder hab' ich etwas falsch verstanden?

          Ist das jetzt die endgültige "Zwangshochzeit" von Webseiten und Javascript?

          Nein, wieso?

          Weil das nach meinem (bisherigen) Verständnis ohne Javascript (beim Client) nicht funktioniert.

          Gruß Gunther

          1. Meine Herren!

            Was begeistert dich denn daran jetzt so?

            Native Elemente und JavaScript-Widgets wachsen näher zusammen.

            Kann mir mal bitte einer den Sinn & Zweck, bzw. den/ die Vorteil(e) davon erklären?

            Die Wiederverwendbarkeit von Komponenten ist extrem hoch. Eine Komponente exportiert eine Schnittstelle, die über das gewöhnliche DOM adressiert wird und kapselt alle internen Implementations-Details durch das Shadow-DOM vollkommen von der Außenwelt ab. Diese Herangehensweise impliziert auch eine enorme Interoperabilität, weil alle gängigen JavaScript-Frameworks und -Anwendungen sowieso schon DOM sprechen können.

            Sorry, aber imho ist das doch nichts anderes als "herkömmliche" Javascript Bausteine, nur mit dem Unterschied, dass diese zusätzlich noch auf Web Components, also custom HTML tags basieren.

            Nehmen wir mal das jQUery-Slider-Widget als "herkömmlichen" Baustein. Das Widget wird zum Beispiel mit $('.slider').slider() zum Leben erweckt. Mit einem Custom-Element kann die Intialisierung deklarativ erfolgen, zum Beispiel durch Verwendung des Tags <my-slider></my-slider>. Aber da liegt tatsächlich kein großer Vorteil, das macht Angular schon lange so ähnlich.

            Interessant wird es, wenn man sich das DOM um den #slider-Container (im externen Beispiel) vorher un nachher ansieht: jQuery fügt heimlich neue Elemente ins DOM ein, so etwa der "Griff" (a-Element), mit dem sich der Slider verstellen lässt. Bei einem Custom-Element hätten wir diesen Griff versteckt vom übrigen DOM ins Shadow-DOM hängen können, damit wäre er vor Seiteneffekten geschützt. Wir könnten ihn nicht durch Traversierung (document.querySelector und co.) erreichen. Damit ist unser DOM vor- und nach der Initialisierung genauso wie wir es erwarten.

            Angenommen wir wollen nun den Slider programmatisch auf den Wert 50 setzen. Mit jQuery würden wir das wie folgt machen: $( ".selector" ).slider({ value: 50 }); mit unserer Komponente dagegen würden wir document.querySelector('my-slider').value = 50; schreiben, also direkt die erweiterte DOM-API nutzen.

            Ist das jetzt die endgültige "Zwangshochzeit" von Webseiten und Javascript?

            Nein, wieso?

            Weil das nach meinem (bisherigen) Verständnis ohne Javascript (beim Client) nicht funktioniert.

            Es werden auch Methoden diskutiert, wie man eine Abwärtskompatibilität zu nicht-Web-Komponent-fähigen Browser erhalten kann. Zum Beispiel durch Verwendung verwandter Tags, statt <fancy-button> könnte man <button is="fancy-button"> schreiben. Dann gibt es für Nutzer mit JavaScript eben Zuckerguss und für die Hardliner weiterhin eine bedienbare, weniger komfortable Lösung.

            --
            “All right, then, I'll go to hell.” – Huck Finn