1

Onderwerp: LESS The dynamic stylesheet

Hey hey,

Je ziet het steeds vaker voorbij komen. Uitleg en tips hoe je css less kunt gebruiken. Maar ik vroeg me eens af. Hoe denken jullie hierover? Is het iets om echt te gaan gebruiken. En zorgt het ervoor dat het scrijven van front-end code sneller gaat?

Ben benieuwd naar jullie gedachten hierover?
http://lesscss.org/

Front-end developer @ LBi Netherlands
http://lbi.nl/

2

Re: LESS The dynamic stylesheet

Ik gebruik het sinds kort samen met de Less App om te compileren wanneer ik mijn .less file bewaar.
Het is handig om je eigen mixins en variabelen te maken om bepaalde zaken niet steeds te moeten herhalen.
Je moet wel opletten met nested rules bvb, als je niet oplet kan je makkelijk overbodige selectors in je code hebben smile

3

Re: LESS The dynamic stylesheet

Ik gebruik geen Less maar Sass (met Compass), Haml en CoffeeScript. Productiviteit +++, annoyance ---. Vanilla CSS schrijven doe ik werkelijk nooit meer. Deze set is vooral gebruikelijk binnen onder andere de Ruby on Rails community, maar kan eigenlijk overal gebruikt worden (m.u.v. Haml, dat moet je taal wel snappen als je er iets dynamisch in wilt doen).

Voordeel van Sass is, voor zover ik Less goed genoeg ken, dat er bijv. binnen Compass een enorm aantal voorgedefinieerde mixins is. Van box-shadow tot inline-image (om een bestand te base64 encoden en als Data URI te gebruiken).

Heb er een keer een praatje over gegeven op een Fronteers bijeenkomst. Wat mij betreft heeft dit inmiddels zo'n grote impact in de (internationale) front-endwereld dat ik geboekt had moeten worden voor de conferentie wink

4

Re: LESS The dynamic stylesheet

Ik zie twee grote hindernissen die er voor zorgen dat ik dergelijke meta-talen niet gebruik:
1) Ik ben freelancer, en hop van project naar project. Mijn code moet onderhoudbaar en direct begrijpelijk zijn, voor zowel de vaste mensen als de volgende freelancers die er vervolgens mee zullen moeten werken. Een voor-bijna-iedereen onbekende variant van een taal, die een specifieke toolchain nodig heeft voodat deze bruikbaar is in browsers, gaat het gewoon niet worden.
2) Er is geen standaard voor de taal. Het is altijd een project van een klein groepje mensen, zonder enige garantie voor consistentie en support over de lange duur. Dat ze beschikbaar zijn onder open source licenses is hoopvol, en betekent dat als je er echt volledig op vertrouwt, en het project vervolgens wordt opgeheven, dat je niet direct in de problemen komt - maar het is wat mij betreft te nieuw, onzeker en onbewezen om op te willen vertrouwen. De kans is te groot dat er volgend jaar een nieuwe rage is die het project in een hele andere richting stuurt, en dan zit je. Laat ze eerst maar eens met een formeel gespecificeerde standaard komen, en minimaal twee onafhankelijke (volledig interoperable) implementaties. smile

(Tegen allebei de punten kan je natuurlijk inbrengen dat je gewoon de "gecompileerde" versie van de uiteindelijk CSS moet opslaan/doorgeven, etc, maar dat voelt als een cop-out; straks gaat iemand dat editen, krijg je consistentie problemen, etc. Net als met database design wil je data maar 1 keer opslaan.)

5

Re: LESS The dynamic stylesheet

Volgens die redenatie kun je heel open sourceland opdoeken. Hetzelfde kun je zeggen over PHP, Ruby on Rails, jQuery, etc.

6 Laatst bewerkt door Bas van Dorst (16-09-2011 15:51:38)

Re: LESS The dynamic stylesheet

Ik heb het nooit gebruikt, spreek dus niet uit ervaring.
Echter de voorbeelden die ik zie genereren in mijn ogen alleen maar overload aan CSS.

Zie het volgende voorbeeld van mixins (dat LESS op de website gebruikt):

.rounded-corners (@radius: 10px) {
 border-radius: @radius;
 -webkit-border-radius: @radius;
 -moz-border-radius: @radius;
}

#blok-1 {
 .rounded-corners;
}
#blok-2 { 
 .rounded-corners;
}

Compiled CSS krijg je dus dit:

#blok-1 {
 border-radius: 10px;
 -webkit-border-radius: 10px;
 -moz-border-radius: 10px;
}
#blok-2 {
 border-radius: 10px;
 -webkit-border-radius: 10px;
 -moz-border-radius: 10px;
}

Wat is er op tegen om een generieke class te gebruiken?

.round-10 {
 border-radius: 10px;
 -webkit-border-radius: 10px;
 -moz-border-radius: 10px;
}
<div class="round-10">xxx</div>
<div class="round-10">xxx</div>

Overigens kan ik mij voorstellen dat het wel makkelijk is bij gebruik van een color scheme van X kleuren. Zeker als je kleurcodes niet op 1 locatie in de stylesheet staan. Maar volgens mij kun je dit ook gewoon als volgt oplossen:

.c1 {color:red;}
.c2 {color:blue;}
.c3 {color:yellow;}

Dus nee, ik ziet niet direct aanleiding om het te (gaan) gebruiken. Tegenargumenten zijn welkom!

7

Re: LESS The dynamic stylesheet

@Bas

Dan krijg je dus code zoals ze op de site van het Financieel Dagblad gebruiken. Oerlelijk.

8

Re: LESS The dynamic stylesheet

Sander van Lambalgen schreef:

De kans is te groot dat er volgend jaar een nieuwe rage is die het project in een hele andere richting stuurt, en dan zit je.

Als er een andere versie van SASS of LESS zou komen, want net zo populair wordt (een rage dus), dan komt dit waarschijnlijk omdat de nieuwe richting die wordt gekozen door veel mensen als nuttig wordt beschouwd.

Je ziet dit fenomeen ontzettend vaak in de Ruby on Rails wereld, waarbij er elke paar maanden wel weer iets nieuws komt met een eigen visie en iedereen dan vervolgens gaat gebruiken. Zo ben ik in het laatste jaar op het frontend vlak overgestapt van HTML → HAML, CSS → SASS → SCSS (is ook SASS, maar andere syntax) en Javascript → CoffeeScript.

Elke overstap is nuttig geweest en heeft ervoor gezorgd dat ik efficiënter ben gaan werken, maar ik snap ook dat het niet voor iedereen is weggelegd. Het voordeel van SASS, LESS en SCSS is dan weer dat het uiteindelijk gewoon CSS maakt en je opvolger ook daarmee aan de slag kan.

9

Re: LESS The dynamic stylesheet

Arjan Eising schreef:

@Bas

Dan krijg je dus code zoals ze op de site van het Financieel Dagblad gebruiken. Oerlelijk.

Ja oké, daar zetten ze echt alles in classes, van width, padding, margin, hoogte. Ik ben het met je eens dat dat ook niet erg netjes is.

Maar goed als je kijkt naar bijvoorbeeld Facebook, dan ziet de code er ook zo uit:

.prm{padding-right:10px}
.prl{padding-right:20px}
.pbs{padding-bottom:5px}
.pbm{padding-bottom:10px}
.pbl{padding-bottom:20px}
.pls{padding-left:5px}
.plm{padding-left:10px}
.pll{padding-left:20px}
.phs{padding-left:5px;padding-right:5px}
.phm{padding-left:10px;padding-right:10px}
.phl{padding-left:20px;padding-right:20px}
.pvs{padding-top:5px;padding-bottom:5px}
Bij de onderste 4, was shorthand css natuurlijk korter ;)

Misschien allemaal niet erg netjes, maar bij high performance websites is dit wel de meest efficiënte methode.
Ik ben het met je eens dat je het niet voor elk herhalend stukje CSS moet gebruiken, maar in sommige gevallen zie ik het nut er wel van in.
En dan gebruik ik liever <div id="blok" class="round-5"> ipv die dubbele code die LESS genereert. IMHO

10

Re: LESS The dynamic stylesheet

Duidelijke informatie over het gebruik van LESS of andere soort gelijke sets. Ik zie ook in sommige gevallen het nu van LESS er wel van in. Maar bij projecten denk ik niet bruikbaar. Ik ben zelf ook veel met snelheid bezig. En heb zelf een vermoeden dat LESS of iets anders. De website ook trager zal maken.

Front-end developer @ LBi Netherlands
http://lbi.nl/

11

Re: LESS The dynamic stylesheet

Mike Vierwind schreef:

En heb zelf een vermoeden dat LESS of iets anders. De website ook trager zal maken.

Waarom? Er komt gewoon CSS uit, en die wordt maar één keer gebakken (en komt daarna gewoon uit cache of een statisch bestand). De snelheid waarmee CSS geparsed kan worden door een browser is exact hetzelfde als bij "vanilla" CSS. Less/Sass zorgen er niet voor dat je geen inefficiënte code kan schrijven, maar dat doet vanilla CSS ook niet. Ook daar zijn er hele volksstammen die 10 niveau's diep nesten, etc. Kwaliteit van code zit niet in de taal die je gebruikt, maar in de kwaliteit van de programmeur.

12

Re: LESS The dynamic stylesheet

Bas van Dorst schreef:

Ik heb het nooit gebruikt, spreek dus niet uit ervaring.
Echter de voorbeelden die ik zie genereren in mijn ogen alleen maar overload aan CSS.

Ik ken de voorbeelden niet, maar als er een overload aan CSS ontstaat dan komt dat doordat de developer niet weet wat 'ie doet. Dat zijn waarschijnlijk de mensen die ook bij vanilla CSS rommel schrijven.

Wat is er op tegen om een generieke class te gebruiken?

Het voorbeeld dat Less gebruikt lijkt mij een prima voorbeeld van hoe de techniek werkt. Of je het wel/niet zo wilt gebruiken is aan de developer. Ik hoop dat die prima zelf kunnen denken en weten hoe Less/Sass code compileren.

Tegen generieke classes heb ik op zich niets, maar jouw voorbeeld is wat mij betreft redelijk "ranzig". Ook classnames zouden semantisch moeten zijn imo. .round-10, .padding-20, .box-shadow-5-5-10-black... Als je die rounded corners later een radius van 20px wilt geven en je moet daarvoor je HTML aanpassen, dan doe je wat mij betreft iets niet goed. Ook niet in een high performance of high traffic omgeving. Er zijn meer wegen die naar Rome leiden als het om herbruikbaarheid en semantiek gaat.

Dus nee, ik ziet niet direct aanleiding om het te (gaan) gebruiken. Tegenargumenten zijn welkom!

Het beste argument: probeer het eens op één project (desnoods een hobby-ding) en zie hoe je opeens sneller bent geworden. SCSS, een syntax van Sass (zoals hierboven genoemd), is een mooi uitgangspunt denk ik. Gewoon CSS, maar met wat extra's smile Met bijv. Compass erbij worden de mogelijkheden nog uitgebreider. Waarom met de hand (of een externe tool) sprites bakken als het in "CSS" kan? Of Data URI's encoden? Grids maken (als design aid)?  Vendor prefixes typen (zelfs als het één keer per document is, wat natuurlijk nooit zo is)? Variabelen kunnen gebruiken?

Ik geef je graag een keer een demo!

13

Re: LESS The dynamic stylesheet

Tegen generieke classes heb ik op zich niets, maar jouw voorbeeld is wat mij betreft redelijk "ranzig". Ook classnames zouden semantisch moeten zijn imo. .round-10, .padding-20, .box-shadow-5-5-10-black...

Het is niet erg netjes dan ben ik met je eens, in de meeste gevallen maak ik zelf ook gebruik van de naamgeving: xs/s/m/l/xl. Dat round-10 gaf ik als voorbeeld omdat LESS een soortgelijk voorbeeld met rounded corners op de website had staan.

Het beste argument: probeer het eens op één project (desnoods een hobby-ding) en zie hoe je opeens sneller bent geworden. SCSS, een syntax van Sass (zoals hierboven genoemd), is een mooi uitgangspunt denk ik.

Eens! Ik sta er ook niet negatief tegenover, dus wil dit zeker eens gaan testen.

Wat is de ervaring van anderen op dit gebied? Een korte zoekopdracht leert mij dat de syntax niet overal hetzelfde is. LESS, SASS en HSS lijken in de hoofdlijnen wel hetzelfde, maar hebben bijvoorbeeld alle 3 een andere syntax. Welke heeft jullie voorkeur?

SASS:    $blue: #3bbfce;
LESS:    @blue: #3bbfce;
HSS:     var blue = #3bbfce;

14

Re: LESS The dynamic stylesheet

Het werken met LESS (wat mijn voorkeur heeft boven Sass) heeft mijn werk sterk vereenvoudigd. Voor hele grote projecten is dit zeer waardevol. Hier een voorbeeld hoe ik het gebruik. Tips of verbeteringen zijn altijd welkom.
http://www1.lunatech.com/~egor/fep/less.html

Voor kleinere projecten waarbij ik soms Expression Engine gebruik is inmiddels ook een LESS processor beschikbaar.
http://devot-ee.com/add-ons/eeless

Web designer
Work:Lunatech Research
Twitter: @dutchcelt
Blog: dutchcelt.nl

15

Re: LESS The dynamic stylesheet

Bas van Dorst schreef:

LESS, SASS en HSS lijken in de hoofdlijnen wel hetzelfde, maar hebben bijvoorbeeld alle 3 een andere syntax. Welke heeft jullie voorkeur?

Ik heb (te) weinig ervaring met Less, maar voor variabelen vind ik zelf Sass mooier dan Less. @ heeft in CSS al een betekenis (voor @import e.d.), dus ik zie liever $. Voordeel van Sass is dat je Compass hebt dat honderden dingen kan doen. Heeft Less ook zoiets?

16

Re: LESS The dynamic stylesheet

Roy Tomeij schreef:
Bas van Dorst schreef:

LESS, SASS en HSS lijken in de hoofdlijnen wel hetzelfde, maar hebben bijvoorbeeld alle 3 een andere syntax. Welke heeft jullie voorkeur?

Ik heb (te) weinig ervaring met Less, maar voor variabelen vind ik zelf Sass mooier dan Less. @ heeft in CSS al een betekenis (voor @import e.d.), dus ik zie liever $. Voordeel van Sass is dat je Compass hebt dat honderden dingen kan doen. Heeft Less ook zoiets?

De syntax verschillen tussen LESS en Sass is inderdaad persoonlijke voorkeur. De mixins syntax van LESS is prachtig in z'n eenvoud en de indent methode van Sass is ook weer heel fraai. "Look mom! No braces!"

Mijn keuze voor LESS is dat het meer op CSS lijkt en voor een CSS'er leesbaarder kan zijn. Zeker wanneer men mixins gebruikt. Ik raad dan ook specifieke features af die, bijvoorbeeld, onderhoud nog moeilijker maken. Nesting is in die opzicht niet zonder meer aan te raden. Client-side processing is zeker geen goed idee.

Compass is heel mooi maar voegt wel extra lagen complexiteit toe. We moeten eerder de vraag stellen of we überhaupt een pre-processor willen toepassen. Voor kleinere projecten kun je prima zonder. Voor grotere projecten kan het een voordeel zijn, mits je het goed en gedocumenteerd inricht. (Hoe pas je het toe? Hoe ga je met updates om? enz.)
Wil je afhankelijk worden van Compass die weer afhankelijk is van twee andere partijen? Sass en 960 Grid bijvoorbeeld.
Je moet maar zin in support hebben.

Web designer
Work:Lunatech Research
Twitter: @dutchcelt
Blog: dutchcelt.nl

17

Re: LESS The dynamic stylesheet

960 Grid heeft een extension voor Compass, maar Compass kan prima zonder (ik include het dan ook nooit). Sass (en Haml & CoffeeScript for that matter) zijn bij ons volledig ingeburgerd, en veel van onze klanten komen naar ons júist omdat we die talen gebruiken. Hoe klein een project ook is, wij dan per definitie géén vanilla CSS, omdat het in mijn ervaring altijd meer werk is (als je de weg weet in de alternatieven). Je wilt al snel een sprite maken of een Data URI encoden; dat is juist complexer zónder Compass.

Aan afhankelijkheid doe je verder niets. Wij zijn ook afhankelijk van Rails, Rails weer van Ruby, etc. Dat nemen we graag op de koop toe. Qua documentatie geldt hetzelfde als voor vanilla CSS: die moet goed genoeg zijn om mee te kunnen werken voor een nieuwe developer. Omdat je juist herbruikbare componenten maakt, een duidelijke structuur gebruikt, etc. kan dat zelfs met minder documentatie dan wanneer je het wiel zelf opnieuw uit gaat vinden.

PS: Sass komt op korte termijn met content blocks in mixins, ben ik zelf erg van gecharmeerd: https://gist.github.com/1215856

PS2: SCSS (default syntax voor Sass) is exact hetzelfde als CSS in principe.

18

Re: LESS The dynamic stylesheet

Zowel LESS als Sass/SCSS hebben veel te bieden en ik zou ze zeker beiden proberen. Zoals je hierboven kunt lezen de overwegingen zijn legio. Werk je met een intern team of werk je altijd met externen? Zijn de tools beschikbaar voor jouw platform? Sluiten deze tools goed op je workflow aan? Enz. Zelfs dan zie ik geen winnaar. Wat van belang is hoe je het toepast, en welke afspraken je daar voor maakt. Om op de originele vraag terug te komen: Het is zeker het overwegen waard want er valt veel voordeel te behalen.

Web designer
Work:Lunatech Research
Twitter: @dutchcelt
Blog: dutchcelt.nl

19

Re: LESS The dynamic stylesheet

Mooie conclusie Egor!

20

Re: LESS The dynamic stylesheet

Ik sluit me helemaal aan bij Egor: mijn voorkeur gaat ook uit naar LESS omdat het 'dicht bij CSS blijft'  en niet meer doet dan ik(!) wil.

Verder ben ik meer van de 'compile at build time': en dat kan met tools als Less.app prima (met compass etc. natuurlijk ook).

In het begin liep ik met LESS nog wel eens tegen bugs aan zoals het feit dat de syntax voor CSS animaties en Media Queries compilatie brak enzo maar tegenwoordig gaat dat veel beter.

De uiteindelijke CSS is erg afhankelijk van hoe je het gebruikt denk ik. Ik gebruik LESS zoals gezegd heel selectief (enkele mixins, variables en wat calcs. enz) en vind de output reuze meevallen.

Anyway, ik kan weinig toevoegen aan Egor's conclusie behalve dat ik denk dat je in een team uiteraard dit samen moet afspreken. Het lijkt mij persoonlijk vervelend als ik nu opeens met de SCSS file van iemand anders moet werken terwijl ikzelf een beetje een LESS workflow heb gemaakt wink

21

Re: LESS The dynamic stylesheet

Had in eerste instantie enige aarzeling om hiermee te beginnen, maar gelukkig was daar een paar weken terug een nieuw project bij de Rabo, waar ik momenteel aan het freelancen ben. Dat project is helemaal HTML5 Boilerplate, en ... Less! De eigen ontwikkelaar had dat al gestart, dus ik kon mooi instappen. Ik moet zeggen: geweldig! je hebt het snel onder de knie, en je werkbestand wordt er heel overzichtelijk van (als je het goed opzet natuurlijk).

Ik gebruik het nu ook voor mijn eigen projectjes, waar nuttig. Zal denk ik altijd wel met vanilla CSS te maken houden, en misschien is dat maar goed ook  cool

Er is wat mij betreft wel één nadeel: foutopsporing via Firebug is een stuk lastiger, want die verwijst naar een regel in de compiled CSS, en dat koppelt weer lastig terug naar je Less file, zeker als je daar even niet meer in gewerkt hebt. Naja, houdt de geest lenig  smile

Keep It Simple, Stupid.

22

Re: LESS The dynamic stylesheet

O ja: Voor zover ik weet is de enige editor die een .less bestand qua syntax coloring en code completion ook echt als css kan behandelen, Coda. Textmate, Textwrangler en DW bakken er niks van op de een of andere manier.
Zijn er naast Coda nog meer dit dit kunnen? Codekit?

Keep It Simple, Stupid.

23

Re: LESS The dynamic stylesheet

Als frontender-in-opleiding moet ik zeggen dat het ontzettend verleidelijk is om frameworks zoals LESS en SASS te gaan gebruiken. Daarentegen ben ik erg blij dat ik er nog niet aan begonnen ben, omdat ik nu pas na een tijd lang vanilla css te hebben geschreven begin te begrijpen wat de compile slag van deze code produceert. Met het handmatig schrijven van "object oriented" (gevaarlijke term) LESS output wordt je met de neus op de feiten gedrukt.

Als je echt goed weet waar je mee bezig bent zie ik zeker het voordeel, maar zoals Sander al zegt werk je vaak in projecten met andere developers en wordt vaak voor de common divider gekozen. In greenfield zou je het wellicht gewoon kunnen opleggen, is het concept en de denktrend eenvoudig genoeg voor elke frontend dev? Voor mijn gevoel staat of valt het nog steeds met de (opvolging van) namingconventies em het helder opdelen in herbruikbare componenten.