Themeentwicklung: Alternativen zu LESS?

In der Dokumentation ist ausschließlich von LESS die Rede. Wie ist hier der Stand, gibt es mittlerweile Möglichkeiten, CSS selber zB. mit node-sass zu kompilieren? Gibt es für Shopware Alternativen zu LESS im Jahre 2019? Auch wenn ich mit Grunt kompiliere, muss ich dennoch 2-3 Sekunden auf die Aktualisierung warten, was recht langsam ist.

Paddelboot

Einfach gutes altes CSS und juuut ist…  Wink

Dieser neumodisches Mist kommt eben ohne Compiler nicht aus. Was für einen Sinn macht das dann bitte!?

@Murmeltier schrieb:

Einfach gutes altes CSS und juuut ist…  Wink

Dieser neumodisches Mist kommt eben ohne Compiler nicht aus. Was für einen Sinn macht das dann bitte!?

 

Bevor ich das Frontend eines Webshops in „gutem, altem CSS“ schreibe, wechsle ich lieber den Beruf… Precompiler sind schon eine sehr, sehr nützliche Angelegenheit, um sich in den Stilen nicht tausendmal wiederholen zu müssen, und um alles schön in Komponenten aufteilen zu können, was bei der Entwicklung ungemein hilft. 

Ich bin bloß nicht damit einverstanden, dass Shopware jeden Entwickler dazu „zwingt“, LESS zu verwenden, daher die Frage.

Shopware setzt - wie bei jedem anderen Softwareprojekt auch - klar definierte Frameworks, Komponenten und Standards ein. Im Bereich von CSS hat man sich eben für LESS entschieden. Eine Alternative bietet Shopware nicht an.

Viele Grüße

Sind immer wieder die gleichen Argumente von Euch Precompiler Lovers.

Ich werde es nie verstehen…und sage immer wieder gerne:

“Using js to simulate CSS seems self defeating…”

Das Shopware auf Standards setzt, ist ja auch gut. Wenn ich die Frontend-Dokumentation durchlese, fühle ich mich allerdings wie bei einer Zeitreise zu den Techniken, die vor 3, 4 Jahren aktuell waren - was gerade im Frontend eine lange Zeit ist. Das erschwert es mir, Zugang zu finden zum Entwicklungsprozess, den Shopware von mir verlangt.

Ist LESS denn schon ein Standard??? Ich meine nicht, oder habe ich da was verpasst? Dann müsste SASS, Stylus & Co. das ja auch schon sein…!!! Und Bootsrap ist ja defacto auch kein Standard. Trotzdem nehmen es aber alle her, weil es anscheinend etwas “vereinfacht”. Das sie dafür aber haufenwese unnötigen Code mit in’s Boot holen, spielt ja dabei keine Rolle.  Wink

Ich persönlich sehe davon ab, so etwas zu nutzen, da ich mir - bis auf 1-2 Dinge - immer wider die Frage stelle: Wofür? Aber klar, das ist sicherlich Geschmacksache und jeder soll das so handhaben, wie er mag.

Wie Du jetzt allerdings in Verbindung mit Shopware da etwas anderes benutzen kannst, weiß ich leider echt nicht, sorry.

@Murmeltier‍ Ein Precompiler für CSS macht teilweise Sinn und erleichtert die Pflege von Projekten ungemein. Ich wollte auf so manche Annehmlichkeit nicht mehr verzichten. Ich will hier gar nicht auf Details eingehen, empfehle aber die Beschäftigung mit dem Thema. :wink:

Bei Bootstrap sind wir uns einig. Wobei ich gerade wieder mit Schrecken feststellen musste, wie groß unsere CSS-Datei auch ohne Bootstrap ist. Noch so etwas, das in Angriff genommen werden will.

Zum Thema: Der Code ist in LESS geschrieben. Da wird man wohl nur herumkommen, wenn man das umschreibt und selbst eine SCSS-Struktur inklusive Precompiler “dran schraubt”. Wäre mir ehrlich gesagt zu viel Arbeit für ein klein wenig Zeitersparnis. (Netto dürfte das eher keinen Gewinn ergeben.)

@naturdrogerie‍

Danke, hab mich schon mit dem Mist auseinandergesetzt und deswegen bleibe ich auch beim guten alten CSS Standard!  Wink

Mir ist nämlich guter und schlanker Code viel lieber als überfrachtete Frameworks und sonstiges Gelumpe aller Art. Dieser neumodische Schnick Schnack bringt mich nämlich auch nicht wirklich weiter, da - in dem Fall - hinten ja wieder nur CSS rauskommt! Ganz toll!

Der ganze Müll kommt leider von irgendwelchen Programmierern, die CSS nie wirklich verstanden haben. Damit sich das Ganze dann wie eine “richtige” Programmiersprache anfühlt, haben sie so Dinge wie Variablen, Loops und andere Dinge integriert. Wow, ganz toll…

Es gibt sicherlich in LESS oder SASS ein zwei Funktionen, die ok sind, aber dafür gleich so viel Mist mit an Bord zu nehmen finde ich gelinde gesagt unnötig wie ein Kropf. Man braucht sich dann auch später nicht zu wundern, wenn Google Pagespeed mal wieder vorschlägt, die zu ladenden Dateien zu komprimieren bzw. zusammenzufassen!

Wenn ich dann noch solche Argumente höre wie:

“Wenn Du mal die komplette Farbe ändern willst, ja dann brauchst Du ja Stunden…”

oder

“Oder ich habe keinen Bock mich zig mal zu wiederholen…”

Hahah, so ein Mist! Ich sag immer: Behersche Deine Coding Tools und Du bist wahrscheinlich 10x so schnell! Vor allem kackt Dir bei einem Fehler in Deiner CSS Datei nicht gleich die ganze Seite ab. Machst Du aber einen Fehler in Deiner SW-LESS Datei und kompilierst dann den Shop, dann kann es schon mal sein, das Dein Shop plötzlich nicht mehr da ist! Sehe ich ja hier im Forum jeden Tag auf’s neue…

Richtig tolle Entwicklung sag ich da nur und deswegen mache / nehme ich lieber nur das, was ich wirklich für ein Projekt benötige. Nicht mehr und nicht weniger…  Wink

 

1 „Gefällt mir“

@Murmeltier schrieb:

Sind immer wieder die gleichen Argumente von Euch Precompiler Lovers.

Ich werde es nie verstehen…und sage immer wieder gerne:

„Using js to simulate CSS seems self defeating…“

Dann hast du aber wohl noch nie komplexe Projekte geschrieben.

Precompiler sind heute fast gar nicht mehr weg zu denken … Alleine die ganzen strukturieren Verschachtelungen, Funktionen, mixins, Variablen usw.

Die Leute die sicher darüber beschweren sind dann aber oft die, welche sich nicht in neue Dinge rein arbeiten wollen, oder das Prinzip dahinter nicht verstehen.

Heute schreibt kein professioneller Entwickler noch mit reinen blanko CSS - Zumindest sind mir keine bekannt. 
Alleine die ganzen Prefixes für verschiedene Browser usw. Okay - Manche Editoren könneen die direkt mit einfügen, aber würdest du was ändern wollen müsstest du es an hunderten Stellen ändern. Anders als wenn du es bspw. über ein mixin machst usw.  Aber allein was man mit Autoprefixer an Zeit und Umstand spart … 

Es gibt sicherlich in LESS oder SASS ein zwei Funktionen, die ok sind, aber dafür gleich so viel Mist mit an Bord zu nehmen finde ich gelinde gesagt unnötig wie ein Kropf.

ein, zwei Funktionen?  Angry-Face
Setz dich doch erst einmal wirklich damit auseinander, lerne es, verstehe es - Dann wirst du darüber anders denken. 

Hahah, so ein Mist! Ich sag immer: Behersche Deine Coding Tools und Du bist wahrscheinlich 10x so schnell! Vor allem kackt Dir bei einem Fehler in Deiner CSS Datei nicht gleich die ganze Seite ab. Machst Du aber einen Fehler in Deiner SW-LESS Datei und kompilierst dann den Shop, dann kann es schon mal sein, das Dein Shop plötzlich nicht mehr da ist! 

Dafür gibt es ja Tools, welch direkt bei der Entwicklung einen Fehler schmeißen, sofern du dich verschrieben hast. Indem Fall meckert Grunt, falls ein Fehler vorhanden ist. Bei normalen CSS hättest du bspw. keine Fehlermeldung. Und das der Shop nicht mehr da ist, aufgrund von einem Fehler ist mir nicht bekannt - Da schmeißt ja der Compiler im Backend sogar vorher einen Fehler raus. 

Der ganze Müll kommt leider von irgendwelchen Programmierern, die CSS nie wirklich verstanden haben. Damit sich das Ganze dann wie eine „richtige“ Programmiersprache anfühlt, haben sie so Dinge wie Variablen, Loops und andere Dinge integriert. Wow, ganz toll…

Sorry - Aber viel mehr Unsinn geht eigentlich gar nicht …
Da wirst du dann aber wohl mit Shopware 6 abwandern und dich vergraben. Node, Vue, Nuxt.js, Compiler, Webpack  … uvm … - Da wirst du dich freuen  Angry-Face 

@Murmeltier‍ Das Argument mit Pagespeed kann ich nicht nachvollziehen. Bei LESS (und SCSS) ist ja gerade der Vorteil, dass man in mehreren Dateien arbeiten kann (Pluspunkt: Übersicht) und am Ende kommt eine CSS-Datei heraus, die dann nach Wunsch auch noch minimiert ist und Fallbacks bis Browser X drin hat oder nicht. Zudem sollte dieser Prozess auch für eine Validierung sorgen, was wiederum zu vollständig validem CSS-Code führt.

Vielleicht liegt es auch daran, dass ich tatsächlich in der Entwickler-Welt zu Hause bin. Von daher sehe ich die Vorteile. Und man kann trotz LESS/SCSS selbstverständlich auch ganz normalen CSS-Code schreiben. Die Validierung beim Compile-Prozess bekommt man trotzdem gratis dazu. :wink:

Du merkst schon: Ich sehe weniger die Vorteile darin, dass man Variablen hat oder einen Code im Zweifel nur einmal schreiben muss. Mir geht es viel mehr um Robustheit und Wartbarkeit. Ich kann gar nicht aufzählen, wie oft Wartungskosten unterschätzt werden. Was uns dann auch wieder zurück zum Thema führt: Sollte man sich wirklich die Mühe machen alles in SCSS selbst nachzubauen, muss man den Kram komplett selbst warten.

Wie ist hier der Stand, gibt es mittlerweile Möglichkeiten, CSS selber zB. mit node-sass zu kompilieren? Gibt es für Shopware Alternativen zu LESS im Jahre 2019? Auch wenn ich mit Grunt kompiliere, muss ich dennoch 2-3 Sekunden auf die Aktualisierung warten, was recht langsam ist.

Wieso im Jahr 2019? Es ist ziemlich ausgewogen zwischen Less & Sass. Less ist nicht tot, ganz im Gegenteil.

Ob du nun Less oder Sass kompilierst macht keinen Unterschied. Und zwei Sekunden ist doch nicht wild, dass ist ganz normal. Wenn du jetzt wirklich nur ein mini Projekt hast ohne die ganze Theme Konfiguration, Kompilierungen von dutzenden Dateien usw. geht es sicherlich schneller. Sicherlich kann man auch Prozesse & Strukturen optimieren, aber das wird sicherlich mit der neuen 6er Version kommen - Sofern sie denn 6 heißt  Angry-Face

@Murmeltier​

Du erinnerst mich an einen Kandidaten, der sich letzte Woche bei uns vorgestellt hat. Er programmiert seit Jahren plain PHP - kein OOP, keine Frameworks, keine developer tools, keine IDE etc pp - bezeichnet sich als Senior Entwickler und wollte knapp 50.000,- EUR im Jahr dafür haben. Die Argumentation war im Prinzip die gleiche: „diesen neumodischen Schnickschnack braucht kein Mensch - ich brauchte das noch nie und kann auch alles prozedual in PHP lösen“. Er hat anscheinend seit Jahren Scheuklappen auf und kennt den berühmten Blick über den Tellerrand nicht.

War ein sehr „interessanter“ Kandidat.

Viele Grüße

1 „Gefällt mir“

Wer gegen Precompiler argumentiert, dem ist es vermutlich auch egal, wenn ein anderer Entwickler das Projekt anfassen muss und sich durch die 7000 Zeilen CSS wühlen muss, um den Widget-Stil zu finden, anstatt schnell unter /components/widget.scss nachschauen zu können. Wobei ich zugeben muss, dass die Konfiguration eines Task Runners wie Grunt nicht gerade Spaß macht und Eingangs recht viel Zeit kosten kann.

 

>Und zwei Sekunden ist doch nicht wild, dass ist ganz normal

Was ich mir zumuten will bei der Entwicklung, das entscheide ich ganz gerne selber :wink: Und 2-3 Sekunden dazusitzen, bis der Kompiler seine Arbeit getan hat, wird unglaublich zäh, wenn ich ein komplettes Theme entwickeln soll.

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. Getting started with LESS?

@paddelboot schrieb:

Was ich mir zumuten will bei der Entwicklung, das entscheide ich ganz gerne selber ;) Und 2-3 Sekunden dazusitzen, bis der Kompiler seine Arbeit getan hat, wird unglaublich zäh, wenn ich ein komplettes Theme entwickeln soll.

Ohhh - Entschuldige bitte  Angry-Face 

Also ich entwickel seit Jahren Themes - Und ich sitze auch nicht 3 Sekunden da und warte. Ich speicher automatisch immer, lasse ggf Browsersync laufen und alles ist gut. Du hast fast überall diese Wartezeit - Es kommt wie gesagt auf die Komplexität der Projekte an.  Wo braucht denn ein Compiler 1 Sekunde oder weniger? Das habe ich noch nicht gsehen, vor allem bei größeren Projekten / Files.

Wenn da 30 Dateien kompiliert werden müssen usw. dann dauert das eben seine Zeit. Und ob du nun Less oder Sass hast spielt da keine Rolle.

Bzgl. Sass: Ich nutze beides intensiv, aber den überkrassen Vorteil hat keiner von beiden, zumindest meiner Meinung nach. Aber ich finde Sass auch etwas angenehmer. Aber bei Shopware hast du ja bereits alles fertig drin - Von daher ist das Peng.

Deine Ausgangsaussage mit „im Jahr 2019“ hörte sich so an, als wäre Less total out und wird nicht mehr genutzt - Was ja nicht der Fall ist.

Anyway - Dann mal happy Coding mit Sass und sag bescheid wie es läuft  Thumb-Up

>Wo braucht denn ein Compiler 1 Sekunde oder weniger?

libsass zum Beispiel.

@paddelboot schrieb:

>Wo braucht denn ein Compiler 1 Sekunde oder weniger?

libsass zum Beispiel.

Okay, falsch formuliert: Ich meinte vielmehr - Wo braucht ein Compiler 1 Sekunde, wenn du bspw. 30 Files hast welche kompoliert werden müssen?

Wenn ich jetzt bspw. nur eine Datei habe wo relativ wenig drin ist, dann klar - Geht das ratz fatz.

Aber bei Shopware hast du ja eine große Anzahl an einzelnen Dateien, dann kommt noch das Javascript hinzu usw. Das dauert dann halt ein klein wenig.

Wobei klar - Theoreitsch gesehen könnte man sich einen eignen Compiler bauen der wirklich auch nur die eigenen Theme Dateien kompiliert. Und die Core Responsive Datien außen vor lässt. So hätte man dann eine sehr minimalsitische Datei. Das würde sicherlich dann ratz fatz gehen. Sowohl mit Sass, als auch Less. Müsste man sich dann aber eben umbauen.

Ich habe hier auch Projekte mit node-sass - Aber übertrieben schneller ist das kompilieren da auch nicht wirklich.

Kannst ja mal bescheid sagen, wenn du es vollbracht hast :slight_smile:

node-sass kannst du ja relativ simpel in deinen Grunt Task mit einbauen.

@EikeWarneke‍

Ja, sicherlich auch keine Herangehenweise, alles immer kategorisch abzulehnen, keine Frage, aber ich muss auch nicht auf jeden hippen Zug ausfpringen, nur weil’s gerade im Internet rumgeistert und 3 hippe Influnecer Websites es als das Non-Plus-Ultra anpreisen. Bootstrap ist nur eines dieser Beispiele. Seit dem sehen auch fast alle Websites gleich aus. Ganz toll! Nur komischerweise konnte wir die ganze Zeit auch ohne Bootstrap tolle responive Websites basteln… Wink

Egal…, ich sehe das ja bei Eurem Baby hier:

In Shopware wird alles hineingestopft, was es gerade so an neuen und tollen Features am Markt gibt. Und dann, keine 2 Jahre später sind diese hippen und tollen Dinge schon wieder out oder doch nicht mehr so toll… und dann wird wieder was neues, tolles in SW hineingepackt. Scheiss drauf, ob es sich durchsetzt oder nicht. Ich erinnere nur an die tolle Verschlüsslung von Plugins! Wink

Egal, als rein mit den neuen Technologien. Ist ja gerade hipp und trendy. Und ach ja, bevor wir es vergessen, Perfomance interessiert uns dabei nicht wirklich! Installiere Dir einfach nur Chrome und kauf Dir gleich noch ein XENON Server mit 100 Cores und 200GB Ram von einem Shopware zertifizierten Provider Du Lurch…,  dann kannst Du auch wieder mit unserem Superbaby spielen! Wink

Und dann kommt aber irgendwann plötzlich Shopware 6 und dann ist eben nicht mehr getan mit einem simplen betätigen des Update Knopfes! Weil man ja die alten, nicht mehr so hippen Technolgien weg kriegen musste! Aus jQuery wird Vanilla JS, aus ExtJS wird Vue JS und aus Smarty wird Twig(s) - sonst ändert sich nix. Das Backend kupfern wir dann noch schnell von Wordpress ab! Scheint ja zu funktionieren.

Und ansonsten bist DU ja selber schuld, wenn Du nicht mit der Zeit gehst. Zieh Dir doch mal schnell hunderte von Framworks und API’s rein, Du Depp. Und wenn Du es nicht drauf hast, dann such Dir gefälligst einen Shopware Evangelist (man ziehe sich das Wort mal rein) der Dir für eine Fantastillionen Euro den Webshop zum Laufen bringt!  So kann man natürlich auch argumentieren, klar - aber manchmal sollte man eben auch das Hirn einschalten, sich nicht blenden lassen und eben längerfristig planen.

Scheinbar können das die Deutschen aber nicht so gut. Sieht man ja an unserer Entwicklung momentan. Wir sind abgehängt! Die Musik spiel in Zunkunft wo anders. Egal, ich schweife ab und deshalb nun wieder back to Topic:

“Crappy HTML leads to crappy CSS” und dann braucht man eben LESS und SASS um das Ganze wieder in die richtigen Bahnen zu lenken. Wink

Schöne Grüße…

Sass/SCSS (darum geht es hier) gibt es laut Wikipedia seit 2007. Was genau ist daran jetzt eine Modeerscheinung?

Mag sein, dass gerade im Frontendbereich die Technologien fast schneller wechseln, als man sie lernen kann. Zu sagen, Spaghetticode sei die Lösung, weil man mit etwas Übung sich darin genauso schnell zurechtfindet - zumindest, wenn die Suppe von einem selber stammt - bringt uns auch nicht weiter.

Und ganz nebenbei, mit einem Precompiler zu arbeiten macht mehr Spaß , zumindest mir! Ein ganz wichtiger Aspekt bei der täglichen Arbeit.

1 „Gefällt mir“

Ja klar, mach doch. Beschwere Dich dann aber auch nicht, wenn es nicht der ist, Der Dir gerade lieb und heilig ist! Denn das war ja der Anfang dieser Diskussion… :slight_smile:

Und von Spaghetti Code hat hier niemand was gesagt…  Wink