Joomla 4 und Bootstrap 4 -> ein Auslaufmodell?

Wenn ich das richtig herauslese, dann möchte Joomal 4 sich so unabhängig wie möglich von externen Bibliotheken machen.

Das gilt insbesondere für jQuery und Bootstrap.
Siehe unter anderem hier und hier.

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.

Hallo,

wie SniperSister schon sagt trifft hier das Sprichwort zu : "einen jeden Recht getan, ist eine Kunst die niemand kann."

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

Zitat von Re:Later

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

Zitat von Re:Later

Ich habe gar nichts gegen die Entfernung von JQuery

Zitat von Re:Later

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.

Zitat von time4mambo

... aber wofür, zum Henker, steht "ES6"? Was bedeuten die beiden Buchstaben?

https://github.com/taniarascia/es6

"ECMAScript"

ECMA = "European Computer Manufacturers Association"

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:

Zitat von Re:Later

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.

Zitat von Re:Later

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.

Zitat von Re:Later

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

Zitat von astrid

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.

Zitat von astrid

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.

Zitat von astrid

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.

Zitat von deltapapa

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:

Guten Morgen,

der Beitrag ist zwar schon etwas älter, aber ich bin jetzt erst drüber gestolpert. Normalerweise bin ich eher der Typ der still recherchiert und weniger schreibt, aber diese Diskussion finde ich dann doch so interessant, das ich meine 5 Cent dazu abgeben möchte.

Da ich hier neu bin, noch ein paar Infos zu meinem Werdegang.

Meine erste Internetseite habe ich 1995 mit Hilfe von Micorsoft Frontpage in HTML erstellt. 1997 musste ich mich dann wegen des Wunsches, nach dynamischer Änderungen des Inhaltes, mit PHP und MySQL auseinandersetzen.

2003 sprach mich dann ein befreundeter Agenturbetreiber darauf an ob ich ihm nicht ein CMS für seine Kunden programmieren könnte.

Ich wusste gar nicht was er meinte und habe es mir von ihm erklären lassen. Ich recherchierte und fand Typo3, Drupal, PHP Nuke, sowie einige andere und unter anderem Mambo. Schnell begeisterte ich mich dafür, weil es intuitiv und schnell erlernbar war.
Das Templating war simpel und aus der Kontakt Komponente konnte man auch alles mögliche basteln. Dann kam der Umstieg auf Joomla.

Irgendwann reichte es nicht mehr die Wünsche mit Joomla einfach zu befriedigen und ich recherchierte wieder. So bin ich auf PyroCMS gestoßen. Damit konnte man wunderbar schnell die gewünschten Anforderungen umsetzen.

Irgendwann ging dem CoreEntwickler Phil Sturgeon aber die Entwicklung von Codeigniter nicht mehr weit und schnell genug, so daß er kurzerhand beschlossen hat Codeigniter durch Laravel zu ersetzen und die folgende Version war eine vollständige Neuentwicklung. Die alte Version wurde auch nur noch ein paar Monate gepflegt.

Zu diesem Zeitpunkt noch eine lebendige Community mit Template und Plugin Entwicklern ist heute tot.

Ich habe mich versucht mit der neuen Version zu beschäftigen und schnell beschlossen das es am gewünschten Ergebnis vollkommen vorbei zielt.

Der Aufwand um das CMS zu installieren war so unglaublich komplex, das es für Otto Normalverbraucher auf einem Shared Hosting unmöglich sein sollte.

Also zurück zu Joomla. Mittlerweile gab es auch reichlich CCK Systeme mit denen man die meisten Wünsche ebenso schnell umsetzen konnte. Für andere Probleme mit früheren Versionen gab es nun auch einfache Lösungen.

Das war mein Weg bis heute und zu Joomla. Natürlich habe ich mich zwischenzeitlich auch mit Wordpress, Drupal, Contao und Processwire beschäftigt.

Neulich habe ich dann eine JUG besucht und ein Wordpress Meetup und musste feststellen das viele Agenturen nur noch Seiten, sei es mit Joomla oder Wordpress, mit Hilfe von Pagebuilder Tools aufsetzen. Die Argumentation war man könne so schnell und vor allem kostengünstig auf die Wünsche der Kunden reagieren.

Der Erfolg der diversen Pagebuilder bestätigt das auch.

Betrachten wir uns jetzt die Entwicklung der Marktanteile der Opensource CMS für den Deutschsprachigen Raum.

Nach Recherchen habe ich folgendes gefunden:

Vom Dezember 2009

Zitat

Laut heise.de hat TYPO3 einen Marktanteil von 44%, Joomla 23%, Wordpress 15%, Drupal 10%.

2019 sieht es so aus

Alle Angaben ohne Gewähr. Aber meine Wahrnehmung war subjektiv auch so, das Joomla im letzten Jahrzehnt im deutschsprachigen deutlich mehr Verbreitung hatte als Wordpress.

Hier noch ein Zitat von André Morre Grafik-Design

Zitat

Der Erfolg von WordPress, welches ursprünglich gar kein vollwertiges CMS, sondern schlicht ein Blog-System sein wollte, ergibt sich einerseits durch die für ein CMS relativ einfache Installation und der anwenderfreundlichen Handhabung des Backends. Aber vor allen Dingen auch durch die unendliche Vielfalt an Plugins, Add-ons und Themes. Allein an diesen Erweiterungen gibt es mehr, als es TYPO3 Installationen auf der Welt gibt!

Einen weiteren großen Schub nach vorne haben WordPress sicherlich die neuen PageBuilder wie DIVI, Elementor und Visual Composer beschert, mit denen eine WordPress Installation quasi zum Webbaukasten mit Liveview wird, jedoch mit dem großen Vorteil, dass der Nutzer unabhängig vom Anbieter wie Wix oder Squarespace ist.

Zwar sollte und muss dies kein Anspruch an professionelle CMS wie TYPO3 und Drupal sein, da diese das Ziel verfolgen mit individueller Programmierung und Design professionelle Webseiten und Webanwendungen für eine professionelle Kundschaft zu erstellen, dennoch müssen auch deren Backends letztlich von Redakteuren und Mitarbeitern des Seiteneigentümers bedient werden. Und wirft man einen Blick auf die Backends dieser Systeme, so hat man doch den Eindruck, in den Schlund eines CMS-Dinosaurias zu schauen, der irgendwie den Anschluss an moderne Websysteme verpasst hat.

Über den großen Marktanteil, den TYPO3 mit seiner eigenen Sprache TypoScript in Deutschland hat, schüttelt man jenseits des großen Teichs nur den Kopf. Weltweit hat das CMS in den letzten 10 Jahren über 75% seines Marktanteils eingebüßt. Das Festhalten an diesem hoffnungslos veraltetem System kann eigentlich durch nichts begründet sein, außer durch Gewohnheit, die sich in zu vielen Webagenturen des Landes eingeschlichen hat. In sofern schließe ich mich in diesem Fall den Amerikanern an und prophezeie diesem System mit der nächsten IT-Generation vom Markt zu verschwinden.

Ich sehe dies ähnlich. Je mehr Entwickler (Template oder Extension) sich wegen fehlender Marktanteile von Joomla abwenden, desto mehr wird es zu einem Nischensystem verkommen.

Zitat

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

Tja ich bin nur im Privatleben Webseitenentwickler und keine Agentur die auf den einen großen Fortune 500 Auftrag hofft. Ich würde wohl dann auch zu dem einfacheren System, welches meine Bedürfnisse befriedigt, wechseln. Auch wenn ich dessen Backend zum Kotzen finde.

Warum? Ich bin nicht bereit mir bei jedem neuen Projekt die neuesten Gimmicks anzueignen, welche ich nicht wirklich brauche und den User der Webseite schon gleich gar nicht tangiert.

Ich habe sicher schon etliche Projekte in den vergangenen zwei Jahrzehnten umgesetzt. Sicherlich hauptsächlich für Vereine, kleine Handwerksbetriebe, etc., aber bisher waren "Markup-Müll und Performance Impact" definitiv kein Thema.

Auch war meinen Kunden es gleichgültig ob ich ein Template Framework, einen PageBuilder, oder ein HTML oder Bootstrap Template verwendet habe. Sie hätten ohnehin nicht verstanden was ich damit meine.

Sie wollten Ihre Corporate Identity erkennen können und die Seiten selbst pflegen und das mit dem geringst möglichen Einarbeitungsaufwand. Dafür verwende ich im aktuellen Joomla das Tool Form2Content.

Früher haben sie mir ein Fax oder eine Mail mit den gewünschten Änderungen geschickt. Das war ihnen auf Dauer zu umständlich und auch zu teuer.

So das waren jetzt meine 5 Cent zu dem Thema und ich hoffe das ich in 10 Jahren mal wieder in einem Joomla Forum meine 5 Cent loswerde.

VG Tom