Joomla 4 und Bootstrap 4 -> ein Auslaufmodell?

  • Moin Moin,


    macht es eigentlich wirklich Sinn, in Joomla 4 Bootstrap 4 einzubauen? Und muss in den Core unbedingt ein Framework wie Bootstrap verankert sein?

    Hintergrund: Bootstrap 5 wird kein jQuery mehr enthalten: https://blog.getbootstrap.com/2019/02/11/bootstrap-4-3-0/ (Text ganz unten)

    Angefangen darüber nachzudenken habe ich durch diesen Tweet: https://twitter.com/dgrammatiko/status/1098951335725150209


    Da gehts ja primär um die Diskussion IE11 unterstützen ja/nein, aber das kann doch eigentlich die Vorgabe sein, oder?


    Da ich selber gerade mit den jQuery Problemen zu kämpfen habe, freue ich mich natürlich auf Bootstrap 5, jedoch vermute ich, das Joomla 3.x und auch Joomla 4.x damit ihre Probleme haben werden, wenn dort noch die BS 4 drinnen werkelt.

  • Die Frage „Framework oder nicht“ ist schon seit vielen Jahren heiß diskutiert. Im wesentlichen gibt es dabei 4 Interessengruppen:


    1. Extensionentwickler: die wollen sicherstellen, dass ihre Extensions in jedem Template gut aussehen und „JS-Krimskrams“ wie Modale, Tooltips, Smoothscroll und co überall funktionieren. Hier macht ein Framework im core Sinn, weil es dadurch ein Grundset an Funktionen und Styles mitbringt, auf die Entwickler aufbauen können.


    2. Template-Entwickler: Template Devs möchten gerne mit dem Framework ihrer Wahl arbeiten, das möglichst modern und sexy sein soll. Ein Framework im Core wäre aus ihrer Sicht schnell veraltet und daher kein Tool der Wahl mehr.


    3. Die Puristen: wollen garkeine Frameworks, weil sie den Markup-Müll und den Performance-Impact vermeiden wollen.


    4. Die Core-Maintainer: wollen am liebsten eine externe Lösung, da uns die Ressourcen für ein eigenes Framework fehlen, gleichzeitig fürchten sie, das Framework weiter zu maintainen wenn der offizielle Support schon abgelaufen ist.


    Dimtris ist extremer Vertreter der Puristen, das ist zur Einordnung seines Tweets wichtig.


    Eine Lösung, die alle zufrieden macht, ist schwer.

  • Okay,


    vielen Dank euch dreien. Ich sehe mich da so ein bisschen in 2, aber ich würde mich (noch) nicht Template Entwickler nennen :-)


    Das macht die Einordnung der Dinge für mich etwas einfacher, man liest so viel mit, und manchmal ist es echt schwer, den Überblick über die "Fronten" zu behalten...


    Ich wünsche euch noch ein schönes WE,

    deltapapa

  • Da ich selber gerade mit den jQuery Problemen zu kämpfen habe

    Was denn für Probleme? Nach meiner Erfahrung kann man die alle lösen. Und auch Joomla 3 mit höheren Versionen, sowohl JQuery als auch BS betreiben. Im blödsten Fall braucht man 1 zusätzliches Plugin.


    Nur paar lose Gedanken:


    JQuery ist auch für Newbies relativ schnell erlernbar und korrigierbar.


    Außerdem sollte man sich mal anschauen, was es für Folgen hat, dass Joomla 4 jetzt auf ES5 bzw. ES6 umstellt. Es gibt nämlich kaum mehr Leute, die im JS-Bereich mitarbeiten können oder wollen. Und wenn dgrammatico mal keine Zeit/Lust hat, bleiben viele JS-verursachte, trivialste Fehler ewig liegen. Stattdessen werden dauernd neue "Genialitäten" nachgeschoben. Programmieren muss man den Kram für Joomla 4 in perfektem ES6 und dann via Konsole nach ES5 kompilieren und dann minifizieren und dann testen und dann von vorne, wenn was nicht klappt. Überfordert nicht nur Anfänger unter den Mithelfern, liest man regelmäßig in Kommentaren. Vom Zeitaufwand für ein einzelnes JS-Fitzel und Aufsetzen einer solchen Arbeitsumgebung, die ständig aktuell zu halten ist, ganz zu schweigen.


    Außerdem sind da viele sehr starre und unflexible, "eingemeißelte" JS-CSS-Programmierungen darunter, zumindest derzeit noch, weiß ich aus Spielereien mit eigenen Backend-Templates für Joomla 4. Weitaus zeitaufwendiger umzubiegen als das in Joomla 3 möglich ist. Stichwort "Markup-Müll", der einen genauso zwingt wie zuvor BS2-Markup-Müll seine Erweiterungen und Templates anzupassen.


    IE11 einfach auszuschließen, was bedeutet das für viele Seitenbetreiber? Nur weil ich den Browser nicht mag? Wird viele nur dazu verleiten, ewig Joomla 3 über EOL weiterzuverwenden, wenn man einfach was raushaut.


    Außerdem liefert letztlich Joomla-4-Core nur noch BS4/JQuery mit aus, so, dass man es nutzen kann, aber nicht muss (wenn man clever genug ist). Wenn du dir anschaust, wie viele Erweiterungen auf JQuery bauen und auch weiterhin werden, ist das auch absolut richtig so.


    Außerdem ist es ja nicht so, dass BS5 dann ohne JS und ohne "starres, eigenes, inkompatibles CSS" daherkäme. Es ist halt nur nicht mehr JQuery. Und das JS ist dann auch "festgemeißelt". Muss man sich also zusätzlich einarbeiten, wenn man was umbiegen will.


    Bei den Ladezeiten/Größe für/von JQuery wird von den Puristen auch gerne übertrieben, weil sie sich immer nur Einzelsituationen anschauen und so tuen, als müsste für jede EInzelsituation JQuery neu geladen werden. Wenn man sich dann anschaut, wie viel redundanten Code die für jedes einzelne Pimpelpampel produzieren... So werden aus paar Sachen, die mit JQuery paar Zeilen benötigen, undurchschaubare Riesendateien.


    Ich habe gar nichts gegen die Entfernung von JQuery, aber dann sollte die ach so moderne Alternative auch kein Bremser für die Weiterentwicklung und/oder Tester sein. Und das ist sie im Moment.

  • Bei den Ladezeiten/Größe für/von JQuery wird von den Puristen auch gerne übertrieben, weil sie sich immer nur Einzelsituationen anschauen und so tuen, als müsste für jede EInzelsituation JQuery neu geladen werden. Wenn man sich dann anschaut, wie viel redundanten Code die für jedes einzelne Pimpelpampel produzieren...

    Dazu ein Einwand, der bei der Performance-Diskussion gerne übersehen wird: selbst wenn der JS-Berg, den Jquery da so lädt, gecached worden ist, muss der Kram trotzdem bei jedem Rendervorgang geparst und ausgeführt werden, was deutlich mehr Zeit in Anspruch nimmt, als der eigentliche Download. 50kb sind da deutlich „teurer“ als ein 50kb Bild. Erschwerend kommt dabei hinzu dass es einbindungsbedingt Render-Blocking ist, was es für die gefühlte Geschwindigkeit nochmal teurer macht.

  • Gebe ich dir ja recht für Seiten, die das nötig haben, wirklich schnellstmöglich zu laden und um jede Millisekunde feilschen müssen. Da kommt dann oft auch die von dir genannte "gefühlte Geschwindigkeit" ins Spiel.


    Und die in Teilen redundanten Codes, die ich oben erwähne, müssen auch eingebunden werden und geparst und ausgeführt. Wir landen dann bei tatsächlichen Geschwindigkeitsgewinnen, die für viele Seiten "gefühlt" vollkommen unerheblich sind.


    Dazu kommt, dass es sowieso sehr lange dauern wird, bis Erweiterungsprogrammierer auf JQuery verzichten werden, weil sie Ihre Vanilla-Codes deutlich intensiver, browserübergreifend testen werden müssen und sich nat. in diesem Bereich auch einarbeiten müssen. Unter'm Strich nat. ein großes Plus für kommerzielle Anbieter, die so was mit gößerer Man-Power leisten können und mit "Super-Geschwindigkeitsgewinnen" werben können.


    Die meisten Seiten die ich als Popel-Webbastel-Anbieter so sehe, haben jedenfalls ganz andere Probleme bzgl. Geschwindigkeit als JQuery ;-)

    Ich habe gar nichts gegen die Entfernung von JQuery

  • Dazu kommt, dass es sowieso sehr lange dauern wird, bis Erweiterungsprogrammierer auf JQuery verzichten werden, weil sie Ihre Vanilla-Codes deutlich intensiver, browserübergreifend testen werden müssen und sich nat. in diesem Bereich auch einarbeiten müssen.

    Den Einarbeitungsaufwand halte ich für überschaubar. Gerade in ES6 sind viele APIs dazu gekommen, die an JQuery-Verhalten angelehnt sind und den Umstieg daher relativ leicht machen. Eine gute Ressource hierfür ist:

    http://youmightnotneedjquery.com

  • Persönlich freue ich mich über jeden Extension Entwickler, der den Schritt in Richtung Vanilla macht, da es für mich als Purist bedeutet dass ich zumindest die Option habe, Seiten ohne JQuery zu betreiben - und ich denke das sollte auch letztlich die Grundanforderung an eine wie auch immer geartete Lösung dieser Thematik sein: es muss die Option geben, das Standardverhalten so umzubiegen, das es auf den eigenen Usecase passt.

  • Letztlich sind das JavaScript-Varianten, die Browser "eben alleine können", also ohne Zuladen von irgendwelchen extra Bibliotheken wie JQuery. Ganz unter'm Strich also alles "Vanilla"-JavaScript-Varianten bzw. "autarkes, stinknormales JavaScript".


    Und das derzeitige Problem ist eben, dass ES6 z.B. von IE11 wenigstens in großen Teilen nicht unterstützt wird (https://caniuse.com/#search=es6). ES5 verstehen mittlerweile die meisten aktuellen Browser (https://caniuse.com/#search=es5).


    Deshalb ja auch das Gezeter, das ich in Post #6 schreibe:

    Programmieren muss man den Kram für Joomla 4 in perfektem ES6 und dann via Konsole nach ES5 kompilieren und dann minifizieren

    Derzeit liegen also für jede JS-Datei mehrere in Joomla 4 rum. Beispiel core.js


    core.es6.js
    core.es6.min.js
    core.js
    core.min.js


    Erweiterungsprogrammierern kann das aber letztlich wurst sein, so weit es keine Core-Erweiterungen werdden sollen, so lange sie ihr JS so schreiben, das es kein JQuery extra zuladen muss.


    Es ist tatsächlich so, dass das Umschreiben kleinerer Dateien und Schnipsel nicht die Welt ist. Also so Kram, was man oft als schnelle Lösung in Foren findet für Kleinkram. Ganz anders sieht das aber bei komplexeren Skripten aus, wenn man eben nicht aus "dieser Programmiererwelt" kommt oder eben Fremdbibliotheken wie z.B. Venobox oder Flexslider verwendet.


    Wenn ich also ein beschränktes Kontingent für Weiterbildung in meinem Beruf habe, werde ich so lange JQuery verwenden bis ich Zeit und Bock habe, bevor ich anderes, wie Einarbeitung in andere CMS oder Joomla4 liegen lassen. Darauf wollte ich oben auch hinaus.

  • Ich habe gar nichts gegen die Entfernung von JQuery, aber dann sollte die ach so moderne Alternative auch kein Bremser für die Weiterentwicklung und/oder Tester sein. Und das ist sie im Moment.

    Ich sehe es nicht so, dass die Entfernung von jQuery der Hauptgrund für weniger Tester und Mitarbeiter ist. Vielleicht ein paar. Aber das ist bei jeder Änderung so – auch wenn es sich um eine Verbesserung handelt. Und die Umstellung auf ES6 ist meiner Meinung nach eine Verbesserung. Ich glaube eher, dass die Notwendigkeit Node.js und Composer zu installieren für viele Tester eine Hürde darstellt - auch wenn ich die Gründe hierfür auch verstehe.


    Derzeit liegen also für jede JS-Datei mehrere in Joomla 4 rum. Beispiel core.js


    core.es6.js
    core.es6.min.js
    core.js
    core.min.js

    Streng genommen liegt nur eine Datei im Joomla 4 herum, die core.es6.js. Alle anderen werden aus dieser mithilfe von einem Befehl generiert.

    Joomla bietet somit die neueste Technik lässt aber den IE11 nicht im Stich - eine gute Lösung die bei Entwicklern eine Einarbeitung voraussetzt.

    Schneller ist nicht unbedingt immer besser ....

  • Ichglaube eher, dass die Notwendigkeit Node.js und Composer zuinstallieren

    Um Installation geht es nicht, sondern darum, dass man alle Nase lang sein System aktualisieren muss. Das ist auch Zeit, die beim Testen verloren geht bis hin zur Aufgabe. Ich habe keine 3 Rechner und eigenen Server bei mir zu Hause rumstehen, sondern muss mich entscheiden, welches Betriebssystem ich laufen haben möchte.

    Streng genommen liegt nur eine Datei im Joomla 4 herum

    Ich arbeite mit den Joomlas, die Nutzer installieren und nicht irgendwelchen Vorversionen und da liegen die Dateien alle drinnen und wenn der nächste Schritt durchgeht, kommen jetzt auch noch gz-Dateien dazu und neue Umleitungen auf diese in der htaccess. Und erste Tests bei stinknormalem Provider zeigen mir, dass hier entweder wieder von Tools und Umgebungen ausgegangen wird, die die "richtigen" gz-Dateien erzeugen oder irgendwelche besonderen Server-Umgebungen benötigt werden, damit Joomla nicht abschmiert.


    So, und wie soll jetzt der Normaluser, der hier im Forum mit einer gewünschten CSS-Änderung landet, bedient werden? Lösche die gz-Datei oder deaktiviere die gz-Zeilen in der htaccess, vergiss nicht den Browsercache zu löschen, dann lösche die min-Datei, weil die zwangsweise geladen wird, dann siehst du, was Sache ist, korrigiere den Fehler, dann installierst du dir node.js und composer, am besten auf einem zusätzlichen Linux-Rechner, aber unbedingt darauf achten, dass die Versionen kompatibel sind zu build-Tools des Joomlas passen ... ... Oder nutze eine user.css, damit noch mehr geladen werden muss. Oder nutze den Debug-Mode, der aber extrem viel anderes Zeugs zulädt, dass du Pech haben kannst und im Bereich JS dein Fehler plötzlich gar nicht mehr zu sehen ist oder, weil du dich als SuperUser anmelden musst, für den dann wieder weiteres Zeugs zugeladen wird und die Seite verfälscht.


    Man kann auch an Usern vorbei-optimieren. Wären das Features und Skripte, die dann auch Nichtprogrammierern in einem installierten Joomla ohne Lehrgänge zur Verfügung stünden, würde es mich gar nicht stören.

    eine gute Lösung die bei Entwicklern eine Einarbeitung voraussetzt.

    Und wenn ES6 veraltet ist, werden wir aufgefordert ESX zu lernen, was dann zu es6 zu es5 zu gz kompiliert wird.


    Wenn du die Zeit hast. Joomla4 braucht Leute, die die alten Leichen im Bereich JS endlich mal korrigieren.

  • Was ich cool finden würde, wäre die Möglichkeit, den Pfad zu jQuery, Bootstrap (js und css) oder jedem anderen JS Framework speichern bzw angeben zu können, z.B. in der config Datei.

    Wenn das System (egal ob Extension oder Template) dann jQuery, Bootstrap oder was immer benötigt, holt er sich die entsprechende Datei aus dem Pfad. Wenn dort nichts ist, läd er die Standard JS Bibliothek.

    Das ist natürlich sehr einfach und pragmatisch gedacht, aber so könnte man diesen ganzen Problemen bei Einbindung von Scripten vllt etwas entgegen kommen...

  • Was ich cool finden würde, wäre die Möglichkeit, den Pfad zu jQuery, Bootstrap (js und css) oder jedem anderen JS Framework speichern bzw angeben zu können, z.B. in der config Datei.

    Wenn das System (egal ob Extension oder Template) dann jQuery, Bootstrap oder was immer benötigt, holt er sich die entsprechende Datei aus dem Pfad. Wenn dort nichts ist, läd er die Standard JS Bibliothek.

    Das ist natürlich sehr einfach und pragmatisch gedacht, aber so könnte man diesen ganzen Problemen bei Einbindung von Scripten vllt etwas entgegen kommen...

    Das ist ohne Probleme möglich, per Override und/oder (imho der bessere aber bisschen aufwändigere Weg) indem man genau diese Pfade per HTMLHelper Überschrieb (Plugin) setzt z.B: