Themeentwicklung: Alternativen zu LESS?

Shopware 5 Installation/Einstieg
21

LESS und SCSS sind ja nicht wirklich neu – und sicher nicht mehr „hipp“ oder „trendy“. Das Shopware auch etwas zu Bloatware neigt, ist offensichtlich. Eigentlich ist das fast normal bei wachsender Software. Ausgerechnet LESS ist ein schlechtes Beispiel. Zumal ein Precompiler keinen Einfluss auf die Shop-Performance hat. (Oder wenn dann einen positiven Effekt, wegen der oben schon erwähnten, automatischen, optional zuschaltbaren Minimierung usw.)

Zu den anderen genannten Sachen:

  • jQuery war lange Zeit nicht wegzudenken, weil Browser mit extrem unterschiedlichen Feature-Sets unterstützt werden mussten. Der Markt hat sich inzwischen weitgehend bereinigt. (Wie auch immer man im größeren Zusammenhang dazu stehen mag.) Zusätzlich ist normales JS inzwischen auch nicht mehr das gleiche, wie vor 10 Jahren. Es macht also Sinn eine Schicht rauszuschmeißen. (Auch so von wegen Performance …)
  • ExtJS ist aaaaaaalt und laaaangsam. Seit wann nutzt Shopware das? Man kann also schwerlich sagen, dass das nach kurzer Nutzung ausgemustert wird. Ich bin nicht unbedingt ein VueJS-Fan, aber es ist deutlich leichter, moderner und einfacher zu handhaben. (Stichwort: Wartung! Stichwort: Performance!)
  • Twig ist nicht wirklich neu. Smarty ist einfach uralt und im Vergleich relativ langsam. Ich sag’s mal so: Wenn es nach mir ginge, würde mir PHP allein reichen. Template-Sprachen sollen es Nicht-Software-Entwicklern wohl vereinfachen. Ich empfand es immer als Ebene, die man nicht unbedingt braucht. Von daher: positiv egal, welches der beiden genutzt wird. Wenn Twig Vorteile bietet: OK. Weit verbreitet ist es jedenfalls.

So von wegen „ob es sich durchsetzt oder nicht“. Alle genannten Dinge haben sich bereits durchgesetzt und werden seit Jahren in größeren Projekten erfolgreich verwendet. Mir fällt dazu auch noch ein, dass Shopware eigenen Overhead rausnimmt und auf „Standard-Symfony“ setzen will. Zwei Daumen hoch! Konnte man die Entwicklung so absehen? Nein. Software und das ganze Drumherum sind in stetem Fluss. Man muss sich ja nur mal die ganzen Änderungen bei den von Dir bevorzugten „Basis-Technologien“ ansehen. HTML, CSS und JS haben sich in den letzten Jahren massiv verändert und das wird so weiter gehen. Und dann das Gezerre um HTML 5 (zwischendurch auch mal XHTML … dann wieder nicht) zusammen mit dem „Living Standard HTML 5“ und CSS 2, nein 2.1, nein 3, nein doch nicht, …

tl;dr: Mir scheint, dass Du Dinge in Beziehung zueinander setzt, die nichts/wenig miteinander zu tun haben.

Auf Shopware 6/next freue ich mich übrigens. Was man so hört und sieht, wagt man hier einen gewissen Neuanfang. Für den Umstieg wird man sich Zeit lassen können, weil die 5er wohl noch lange unterstützt wird und es eine ganze Weile dauern wird, ehe 6/next produktiv einsetzbar sein wird.

Ist natürlich alles nur meine Meinung …

22

>Ja klar, mach doch.

Ja klar mach ich, was denn sonst :=). Und das hier hattest du mitbekommen?

@paddelboot schrieb:

Im Grunde ist alles halb so wild, weil die Dokumentation selber erwähnt, dass man den Kompiler seiner Wahl verwenden kann, und das kompilierte CSS dann einfach entsprechend registriert. https://developers.shopware.com/designers-guide/less/#why-less?
 

23

@paddelboot‍

Na dann ist ja alles gut! :slight_smile:

@naturdrogerie‍

Mit hip und trendy meine ich auch nicht unbedingt LESS, sondern eher den anderen Quatsch. Beispiel: Da wird Typescript, CoffeScript und Tod und Teufel erfunden, was aber meistens - keinerlei großartigen Vor- oder Nachteile bietet. Im Gegenteil, mann muss noch 'ne neue Syntax erlernen und braucht - im schlimmsten Fall dann noch mehr Zeugs (Transpiler), um alles am Laufen zu halten. Raus kommt dann aber eben auch nur Java Script! So etwas will ich dann auch nicht wirklich verstehen, sorry. Ähnlich sehe ich das eben auch mit den CSS-Präprozessoren.

Und natürlich begrüße ich die Weiterentwicklung von HTML, CSS und Java Script. Keine Frage. Mir stellt dann aber eben noch viel mehr die Frage, warum es dann mittlerweile zig Webframeworks gibt, wenn - so wie Du es richtig erkannt hast - sich doch da etwas getan hat in den letzten Jahren!? Zudem, als Gezerre würde ich das auch nicht verstehe. Es entwickelt sich halt und - vor allem - es ist STANDARD! Was Browserhersteller und andere Firmen dann daraus machen, liegt dann nicht mehr in unserer Hand.

Long story short: Nicht jede neue Entwicklung ist also immer gleich nur positiv zu bewerten. Du sagst ja selber, das Dir eigentlich PHP vollkommen ausreichen würde!  Nix anderes - nur in einer etwas überzogener Form - will ich hier kundtun. Es gibt nämlich immer zwei Seiten einer Medaille! Aber klar, wer Bock auf sowas hat, soll sich das reinziehen, ich tu es mir erst mal nicht an. Wink

N8! Smile

24

Nun ja … PHP als „Template-Engine“ würde mir deshalb ausreichen, da es (schon dem Namen nach) ein Präprozessor ist – ähnlich wie LESS.

25

@naturdrogerie schrieb:

Nun ja … PHP als „Template-Engine“ würde mir deshalb ausreichen, da es (schon dem Namen nach) ein Präprozessor ist – ähnlich wie LESS.

Smarty stört die Lesbarkeit der HTML-Syntax, die ja mit den semantischen Elementen (section, article usw) eigentlich erhöht werden sollte. Ich sehe einfach überall nur {block}.

26

Warum man auf Twig oder genrell Template Sprachen setzt ist eigentlich relativ schnell erklärt: https://twig.symfony.com/

27

@Shopwareianer‍ Mhmja. Escaping und ein wenig nettere Syntax kann man als Pluspunkte gelten lassen. Andererseits muss das Escaping ja nicht unbedingt in der View stattfinden. Ist aber wohl Geschmacksache.

Als Negativpunkte sehe ich unter anderem, dass man sich mit noch einer Sprache und deren Gepflogenheiten auseinandersetzen muss – für einen in meinen Augen eben nicht soooo hohen Nutzwert. Ich kann aber nur betonen: Das ist meine persönliche Sicht als Entwickler. (TWIG kenne ich aus anderen Projekten. Stellt für mich also keine echte Hürde dar.)

Manchmal denke ich an die Zeit zurück, in der ich vornehmlich Java-Gedöns entwickelt habe. Da gab es Java, vielleicht noch XML und SQL (dank Framework meistens eher nicht) – und wenn es ganz krass kam, hatte man noch irgendwelche kruden Definitionsdateien (die ersten Iterationen von EJB), die aber zumeist von den Dev-Tools automatisch angelegt wurden. Oder mal lustige Projekte mit OpenGL (eine wirklich furchtbare Sprache). Ich muss aber zugeben: Zu der Zeit war alles in Bezug auf Frontend absolut pain in the ass. Keine Ahnung, ob das inzwischen besser geworden ist.

Webentwicklung: HTML, CSS, JS, Twig/Smarty, PHP, JSON, ggf. XML (SOAP), SQL und dann all die kleinen Helferlein wie jQuery (o.ä.), LESS/SCSS, … Ich kann schon verstehen, wenn der eine oder andere sich fragt „Muss es wirklich noch etwas neues sein?“. Mir macht das ja durchaus Spaß. :wink:

28

@naturdrogerie‍ Als Negativpunkte sehe ich unter anderem, dass man sich mit noch einer Sprache und deren Gepflogenheiten auseinandersetzen muss – für einen in meinen Augen eben nicht soooo hohen Nutzwert. 

mh - Also ich muss sagen, die Template Engines tun sich da alle nicht viel. Egal ob es jetzt Twig ist, Blade, smarty, handlebars oder sonst was. In den meisten Fällen hat man sich ja nach weigen Stunden eingearbeitet. 

Webentwicklung: HTML, CSS, JS, Twig/Smarty, PHP, JSON, ggf. XML (SOAP), SQL und dann all die kleinen Helferlein wie jQuery (o.ä.), LESS/SCSS, … Ich kann schon verstehen, wenn der eine oder andere sich fragt „Muss es wirklich noch etwas neues sein?“.

Klar kann ich auch verstehen, aber: Diese ganzen Tools werden ja von ihm nur fertig gemacht und er sieht den eigentlichen Nutzen überhaupt nicht. Wenn man schon sagt, dass Typescript keine nennenswerten Vorteile bietet … Naja … 

Die Entwicklung von vor 10 Jahren zu heute hat sich ja extrem gewandelt. Und aktuell geht es ja massiv schnell. Man muss extrem viel lernen, wenn man immer auf dem aktuellsten Stand sein will. Aber das gehört nun einmal heute dazu.

Die ganzen Tools haben ihren ganz eigenen Nutzen. Mit Typescript etwa kann ich vor allem größere Projekte viel besser Strukturieren, Typisieren, Objekt orientiert arbeiten und sauberen Code schreiben. Vor allem wenn mehrere Leute an einem Projekt arbeiten ist das imens wichtig.

Dasselbe gilt genauso für Sass/Less usw.

Ebenso natürlich Template Engines. Alles hat seinen ganz eienen Nutzen. Alles zu verfluchen nur weil man es selbst nicht lernen will ist falsch. Aber ja - Mir macht es auch extrem Spaß, vor allem sich in neue Dinge rein zu arbeiten. Und die kommen ja in den letzten Jahren am laufenden Band, aber es ist doch schön, wenn da so viel Bewegung drin ist - Gerade in der Open Source Community  Angry-Face

29

Naja, man muss nicht jedes Framework bzw. Toolkit, denn meistens ist es nicht mehr, in den Himmel loben. Man sollte sich vorher auch mal fragen, was man sich da an’s Bein bindet!? Vor allem sollte man sich fragen:

  1. Laufzeit des Projekts? Also was mache ich wenn das Toolkit nicht mehr weiterentwickelt wird?
  2. Lizenz-Problematik - Also wie sieht es mit der Lizenz aus? Facebook hätte damals z.B. REACT fast kaputt lizensiert und ist nur aufgrund eine großen Wirbels der Community zurückgerudert! Oder um bei Shopware zu bleiben kann man ja auch z.B. auch noch das Ioncube Desaster benennen!

Es ist also meistens so, das die Entscheidung für ein Framework nämlich viel zu früh getroffen wird. Und nur weil ein Framework bei der Community gerade hoch im Kurs steht heißt das noch lange nix. Der Einsatz eines Frameworks sollte immer sehr gut überlegt sein. Viele Entscheidungen müssen dabei berücksichtigt, viele Szenarien abgewogen werden. Es gibt also nicht immer nur Vorteile beim einsatz eines Toolkits, sondern immer auch Nachteile! Wer das nicht sehen will, muss blind sein, sorry.

Der Einsatz von Framworks mag also bei kurzweiligen Projekten noch ok sein, bei langfristigen Projekten aber, kann es aber auch schnell zu einem Desaster ausarten. Man denke nur an ein Major Update. Schnell können da grundlegende Funktinonalitäten über den Haufen geworfen werden und dann kann man ja mal versuchen, das ganze wieder los zu werden. Viel Spaß dabei…

30

Es ist also meistens so, das die Entscheidung für ein Framework nämlich viel zu früh getroffen wird. Und nur weil ein Framework bei der Community gerade hoch im Kurs steht heißt das noch lange nix.

Wenn du von meistens sprichst, hört sich das so als würde der Großteil die Entscheidungen falsch treffen welche auf Frameworks setzen. Und das ist einfach nicht der Fall. Natürlich will es gut überlegt sein - Aber wer weiß schon was in 5 Jahren ist. Das Web entwickelt sich so rasant schnell, da kann es in 5 Jahren schon was neues geben. Und ich denke Shopware wird sich da auch gut Gedanken gemacht haben.

Aktuell entwickelt bspw. Google aktiv an Flutter, was sicherlich das nächste große Ding werden kann. Eine Code Base mit kompilierten nativen Code für alle Plattformen. Dann kommt in Zukunft sicherlich die AR hinzu usw. Schau dir mal das hier an: https://twitter.com/jmj/status/1119990758423928832

So etwas wird in naher Zukunft sicherlich 1zu1 verschmelzen mit Onlineshops. Online „anprobieren“, dass System berechnet die exakte Größe, weniger Rückläufer usw.
Und jetzt bilde das mal mit reinen Vanilla Javascript ab - Da schreibst du dich tot dran.

Das ist ja alles ein laufender Prozess. In 5 Jahren kann React, Vue & Angular schon wieder tot sein, klar - Aber das gehört im Web eben dazu, das es und man sich selbst ständig weiter entwickelt.

Und bzgl. der Lizenz: Vue.js wird durch die Community finanziert als auch Sponsoren - Shopware gehört da ja mittlerweile auch zu. Vue.js ist ja mittlerweile icht mehr nur Evan You, sondern ein ganzes Dev Team und viele Contributor. Das ist ein ganzes Ecosystem. Ähnlich wie Laravel & Co. Bei Vue.js wirst du sicherlich keine Lizenz Probleme haben, wie es bei einem Framework sein kann wie eben etwa React wo eine ganze Firma hinter steht. Oder Google bei Angular. 

Es hat alles seine Vor & Nachteile. Aber alles zu verteufeln wie etwa auch Typescript usw. ist nicht der richtige Weg.

31

Verteufel tut hier keiner was, ganz bestimmt nicht. Auch “fertig machen” - wie Du so schön gesagt hast - macht hier keiner was. Ich frage lediglich nach dem Sinn oder Unsinn einer Technologie! Zudem gehe ich halt auch mit offenen Augen durch die Welt und lass mich eben nicht gleich von jedem cleverem Marketing Schachzug blenden. Es gibt zum Glück auch noch genug Entwickler, die das ähnlich sehen, von daher stehe ich mit dieser Meinung auch nicht ganz alleine da. Man kann natürlich auch -. wie Du das tust - alles Neue immer gleich hoch in den Himmel loben, klar. Ob das aber immer der bessere Weg ist, wage ich zu bezweifeln, denn hinter allen Technologien stecken immer auch Risiken! Das solltest auch Du wissen…

 

32

@Murmeltier schrieb:

Verteufel tut hier keiner was, ganz bestimmt nicht. Auch „fertig machen“ - wie Du so schön gesagt hast - macht hier keiner was.

Grin Grin Grin 

33

Nicht aus dem Kontext reissen, sondern lernen und verstehen!  Wink