Gebruik van SASS of LESS

[Verwijderd]

Goededag,

Ik ben al een tijdje bezig met webdesign met als later doen eventueel wat te front-enden.

Maar ben echter al ong 1 jaar actief bezig en wil verder dan de gewone css.
Vandaar dat ik twijfel om mij SASS of LESS aan te leren. Echter twijfel ik een beetje tussen de 2. Ze lijken me beide namelijk aantrekkelijk om te leren.

Maar nu is mijn vraag hebben jullie recent goede ervaring met SASS of LESS. Iemand die mij kan helpen bij mijn keuze? En zijn er namelijk ook mensen die 1 van beiden op het werk gebruiken?

[BtM909]

Toen je ging [google=sass or less], wat vond je van de diverse websites die er uitgebreid over praten?

[TheNephilim]

Wij gebruiken hier LESS. Die keuze was voor ons snel gemaakt, omdat we voor (bijna) al onze projecten Bootstrap als basis gebruiken.

[Verwijderd]

BtM909 schreef op maandag 13 januari 2014 @ 15:32:
Toen je ging [google=sass or less], wat vond je van de diverse websites die er uitgebreid over praten?

Dat is zo maar ik stel het liever nogmaals op een forum. Zodat er eventueel intressante discussies naar boven kunnen komen

[Verwijderd]

TheNephilim schreef op maandag 13 januari 2014 @ 15:34:
Wij gebruiken hier LESS. Die keuze was voor ons snel gemaakt, omdat we voor (bijna) al onze projecten Bootstrap als basis gebruiken.

Word je dan enige beperking gewaar?

[Bosmonster]

Persoonlijk heb ik aan beiden een hekel, want het voegt onnodige complexiteit en abstractie toe aan een op zichzelf zeer eenvoudige en recht-toe-recht-aan taal. Er lijkt momenteel een soort hype te zijn om simpele dingen heel ingewikkeld te maken en daardoor springen de NodeJS projecten je vandaag de dag om de oren. Alles lijkt ineens gecompiled, gepackagemanaged en geautomatiseerd te moeten worden

Speel dus vooral zelf met beiden (SASS is tegenwoordig iets gebruikelijker dan LESS, waar ik niet zo heel veel meer van hoor eerlijk gezegd, op Bootstrap na). Dan kun je zelf een conclusie trekken wat voor jou het fijnste werkt en of je het wel echt nodig hebt.

[ Voor 21% gewijzigd door Bosmonster op 13-01-2014 16:01 ]

[BtM909]

Verwijderd schreef op maandag 13 januari 2014 @ 15:35:
[...]


Dat is zo maar ik stel het liever nogmaals op een forum. Zodat er eventueel intressante discussies naar boven kunnen komen

Een discussie ontstaat door een goede stelling. Jij stelt op dit moment gewoon een helpdeskvraag

[TheNephilim]

Verwijderd schreef op maandag 13 januari 2014 @ 15:35:
[...]


Word je dan enige beperking gewaar?

Tot zover niet. Ik heb SASS nooit echt gebruikt, dus misschien zijn er bepaalde verschillen die de moeite waard zijn. Echter doen ze beide ongeveer hetzelfde, het doel en het resultaat zijn hetzelfde. Ik zou gewoon eens kijken naar de syntax en toolset voor beide 'talen' en dan kijken welke je het meest aanspreekt. Bijv. een plugin (of liever native ondersteuning) voor je favoriete IDE, LESS bestanden van front-end libs die je veel gebruikt, etc.

[Verwijderd]

BtM909 schreef op maandag 13 januari 2014 @ 15:56:
[...]

Een discussie ontstaat door een goede stelling. Jij stelt op dit moment gewoon een helpdeskvraag

Mijn excuses was verre van mijn bedoeling

[Barryvdh]

Wij gebruiken ook Less, voornamelijk vanwege Bootstrap.
Doet perfect wat we er van verwachten.
We gebruiken verder niet zo'n ingewikkelde functies, vooral alleen de variabelen en het nesten van css. Maar dat kan met allebei prima.

[TheNephilim]

Bosmonster schreef op maandag 13 januari 2014 @ 15:54:
Persoonlijk heb ik aan beiden een hekel, want het voegt onnodige complexiteit en abstractie toe aan een op zichzelf zeer eenvoudige en recht-toe-recht-aan taal. Er lijkt momenteel een soort hype te zijn om simpele dingen heel ingewikkeld te maken en daardoor springen de NodeJS projecten je vandaag de dag om de oren. Alles lijkt ineens gecompiled, gepackagemanaged en geautomatiseerd te moeten worden

Speel dus vooral zelf met beiden (SASS is tegenwoordig iets gebruikelijker dan LESS, waar ik niet zo heel veel meer van hoor eerlijk gezegd, op Bootstrap na). Dan kun je zelf een conclusie trekken wat voor jou het fijnste werkt en of je het wel echt nodig hebt.

Ben ik het wel deels mee eens, maar toch zitten er ook voordelen aan die het simpel houden.

• @import; Netjes en simpel één stylesheet in plaats van meerdere.
• @brand-primary; Niet steeds die ene #019740 hoeven copy-pasten of onthouden.
• .translate(@x; @y); Doormiddel van mixins niet steeds de browser vendor prefixes uit hoeven typen.

Met de verschillende tools om het te compilen word het er echt een stuk makkelijker van.

[Verwijderd]

TheNephilim schreef op maandag 13 januari 2014 @ 16:18:
[...]


Ben ik het wel deels mee eens, maar toch zitten er ook voordelen aan die het simpel houden.

• @import; Netjes en simpel één stylesheet in plaats van meerdere.
• @brand-primary; Niet steeds die ene #019740 hoeven copy-pasten of onthouden.
• .translate(@x; @y); Doormiddel van mixins niet steeds de browser vendor prefixes uit hoeven typen.

Met de verschillende tools om het te compilen word het er echt een stuk makkelijker van.

Het is maar ik overweeg het inderdaad deels om de mixins te vergemakkelijken. En om alles zo dynamisch te maken. Maar beide komen mooi in aanmerking maar wil dat het ook deels user-friendly is

[funkeey]

User-friendly code?

[TheNephilim]

Verwijderd schreef op maandag 13 januari 2014 @ 16:25:
[...]


Het is maar ik overweeg het inderdaad deels om de mixins te vergemakkelijken. En om alles zo dynamisch te maken. Maar beide komen mooi in aanmerking maar wil dat het ook deels user-friendly is

User-friendly?

Over welke users heb je het? Bezoekers van je website, of mensen waarmee je samenwerkt oid?

[Verwijderd]

TheNephilim schreef op maandag 13 januari 2014 @ 16:26:
[...]


User-friendly?

Over welke users heb je het? Bezoekers van je website, of mensen waarmee je samenwerkt oid?

User friendly daar bedoel ik inderdaad degene mee waar ik mee samenwerk in sommige projecten

[418O2]

Als je je Less netjes schrijft is het prima leesbaar.

Ik gebruik het vrij vaak en met name met responsiveness is het gewoon heel makkelijk.

Cascading Stylesheet:

.container-with-blocks {
    position: absolute;
    bottom:0;
    left:15%;
    width:70%;
    @media (max-width: @screen-md-min) {
        width:100%;
        left:0;
    }
}

vind ik een stuk makkelijker lezen dan wanneer je het vanilla schrijft.

[TheNephilim]

Verwijderd schreef op maandag 13 januari 2014 @ 16:28:
[...]


User friendly daar bedoel ik inderdaad degene mee waar ik mee samenwerk in sommige projecten

LESS is meer een kwestie van 'gebruiken' dan van 'leren'. Dat geldt overigens ook voor SASS, dus dat zal niet veel verschil gaan maken.

Nogmaals, ga eens met wat tools aan de slag en kijk wat je bevalt. Ik gebruik Recess, maar WinLess werkt ook goed.

[Verwijderd]

TheNephilim schreef op maandag 13 januari 2014 @ 16:31:
[...]


LESS is meer een kwestie van 'gebruiken' dan van 'leren'. Dat geldt overigens ook voor SASS, dus dat zal niet veel verschil gaan maken.

Nogmaals, ga eens met wat tools aan de slag en kijk wat je bevalt. Ik gebruik Recess, maar WinLess werkt ook goed.

Ga ik zeker doen! en ps een front-end moet die sql en of php kennen?

[418O2]

Verwijderd schreef op maandag 13 januari 2014 @ 16:34:
[...]


Ga ik zeker doen! en ps een front-end moet die sql en of php kennen?

Nee.

Maar het is wel handig. Helemaal als je met een erg klein team werkt.

[Verwijderd]

418O2 schreef op maandag 13 januari 2014 @ 16:36:
[...]

Nee.

Maar het is wel handig. Helemaal als je met een erg klein team werkt.

Want zou het nu als hobby willen houden en op het eind van mijn studie zou ik graag de front-end ingaan. Maar weet niet bepaald wat vandaag de dag de eisen zijn op de markt.

[perpixel]

Wij gebruiken voornamelijk sass. voor mij juist een stuk overzichtelijker dan css. Juist omdat je meerdere files maakt en het toch compiled naar 1 css bestand. De inhoud van dat css bestand zie ik nooit, maar al mijn modules zijn netjes van elkaar gescheiden.

Verder is het bij ons zo dat de front-ender kan html-en/css-en/javascripten en de basis van php/mySQL kent om alle kleine aanpassingen te doen. In principe bouw ik een site zelf en zijn de back-enders er voor het bouwen van grote modules.

[Bosmonster]

Ow ik ontken niet dat er handigheden inzitten hoor, maar het zijn allemaal redelijk kleine dingen die geen uren werk schelen. Dit terwijl ik juist wel veel tijd kwijt ben aan debuggen bijvoorbeeld. Nu kun je (in SASS iig) wel weer regelnummers in de comments laten zetten of sourcemaps gebruiken, maar uiteindelijk zijn het weer symptomen die je gaat lopen bestrijden. Om het nog maar niet te hebben over een backend developer die even wat wil aanpassen en de build-files edit Helaas zijn dit soort zaken lastig te managen in een club van 150+ man, waar slechts een klein deel van de projecten LESS of SASS gebruiken.

Al met al is mijn conclusie tot nu toe: zitten leuke vindingen in, maar het kost vaker tijd dan dat het tijd oplevert tijdens het ontwikkelen.

Ik kan me wel goed voorstellen dat, zeker bij kleinere bedrijven of individuen, het een heel stuk makkelijker in te passen is

Verwijderd schreef op maandag 13 januari 2014 @ 16:25:
[...]


Het is maar ik overweeg het inderdaad deels om de mixins te vergemakkelijken. En om alles zo dynamisch te maken. Maar beide komen mooi in aanmerking maar wil dat het ook deels user-friendly is

Blijf wel zelf opletten en niet domweg voor elke css3-property mixins gebruiken die alle vendor prefixes toevoegen. Voor veel heb je er helemaal niet meer nodig bijvoorbeeld (border-radius) of bijvoorbeeld alleen webkit oid.

TheNephilim schreef op maandag 13 januari 2014 @ 16:31:
[...]


LESS is meer een kwestie van 'gebruiken' dan van 'leren'. Dat geldt overigens ook voor SASS, dus dat zal niet veel verschil gaan maken.

Nogmaals, ga eens met wat tools aan de slag en kijk wat je bevalt. Ik gebruik Recess, maar WinLess werkt ook goed.

Gewoon Compass of Less (evt met watch-less oid) via de Terminal toch?

Terminal-typen hoort ook helemaal bij de hype!

[TheNephilim]

Bosmonster schreef op maandag 13 januari 2014 @ 16:58:

[...]

Gewoon Compass of Less (evt met watch-less oid) via de Terminal toch?

Terminal-typen hoort ook helemaal bij de hype!

Haha, gewoon

recess --compress custom.less > ../css/custom.min.css

in de command line . De watcher moet ik nog eens instellen, kan ook in m'n IDE (PhpStorm).

[Verwijderd]

TheNephilim schreef op maandag 13 januari 2014 @ 17:10:
[...]


Haha, gewoon

recess --compress custom.less > ../css/custom.min.css

in de command line . De watcher moet ik nog eens instellen, kan ook in m'n IDE (PhpStorm).

Ik loop lekker op Brackets nu

[Bosmonster]

Owja, ik gebruik Webstorm, daar kan het ook in tegenwoordig.

[Johnny]

Bosmonster schreef op maandag 13 januari 2014 @ 16:58:
Al met al is mijn conclusie tot nu toe: zitten leuke vindingen in, maar het kost vaker tijd dan dat het tijd oplevert tijdens het ontwikkelen.

Dit is ook onze ervaring. We hebben heel veel projecten die jarenlang onderhouden worden en dat ook vaak door verschillende personen. Het feit dat de inspector in de browser niet meer te gebruiken is maakt het debuggen veel tijdrovender terwijl de tijdsbesparing van LESS/SASS minimaal zijn.

We zijn dus terug gegaan naar plain CSS, netjes ingesprongen en opgedeelde in kleine bestanden, af en toe met comments. We hebben een server side minifier die makkelijk aan en uit te zetten is. Dit werkt voor ons tot nu toe het beste.

[ Voor 5% gewijzigd door Johnny op 13-01-2014 17:30 ]

[TheNephilim]

Johnny schreef op maandag 13 januari 2014 @ 17:29:
[...]


Het feit dat de inspector in de browser niet meer te gebruiken is maakt het debuggen veel tijdrovender terwijl de tijdsbesparing van LESS/SASS minimaal zijn.

Mwah, in bijvoorbeeld Chrome zie je gewoon de styles die van toepassing zijn. Makkelijker dan in een stylesheet zoeken naar de juiste classes en dergelijke. De less/css file heb je toch open staan in je IDE, waarom zou je er in de browser nog eens naar willen kijken?

[Johnny]

TheNephilim schreef op maandag 13 januari 2014 @ 17:31:
[...]


Mwah, in bijvoorbeeld Chrome zie je gewoon de styles die van toepassing zijn. Makkelijker dan in een stylesheet zoeken naar de juiste classes en dergelijke. De less/css file heb je toch open staan in je IDE, waarom zou je er in de browser nog eens naar willen kijken?

Omdat je anders niet weet welke stijlregels verantwoordelijk zijn voor de opmaak van een bepaald element omdat zowel het regelnummer als de selector zijn helemaal anders zijn. Voordat er inspectors waren deden we het allemaal zonder, maar als je er eenmaal goed mee overweg kan is het een enorm krachtige tool die meer tijd bespaart dan LESS of SASS.

[418O2]

Er is tegenwoordig zoiets als een sourcemap he

https://developers.google...ls/docs/css-preprocessors

[ Voor 46% gewijzigd door 418O2 op 13-01-2014 20:53 ]

[Ramon]

Bosmonster schreef op maandag 13 januari 2014 @ 15:54:
Persoonlijk heb ik aan beiden een hekel, want het voegt onnodige complexiteit en abstractie toe aan een op zichzelf zeer eenvoudige en recht-toe-recht-aan taal. Er lijkt momenteel een soort hype te zijn om simpele dingen heel ingewikkeld te maken en daardoor springen de NodeJS projecten je vandaag de dag om de oren. Alles lijkt ineens gecompiled, gepackagemanaged en geautomatiseerd te moeten worden

Wat is precies die complexiteit die het toevoegt dan? Je kan het exact zo gebruiken als CSS, de enige complexiteit die het dan toevoegt is die van het moeten compilen, dat kan ik nou niet echt complex noemen, vergeleken met de voordelen van nesting, mixins enzo. Zeker als je Compass gebruikt krijg je een hele hoop kant en klare mixins die het allemaal erg leuk maken om te css'en, vind ik.

Johnny schreef op maandag 13 januari 2014 @ 20:28:
[...]

Omdat je anders niet weet welke stijlregels verantwoordelijk zijn voor de opmaak van een bepaald element omdat zowel het regelnummer als de selector zijn helemaal anders zijn. Voordat er inspectors waren deden we het allemaal zonder, maar als je er eenmaal goed mee overweg kan is het een enorm krachtige tool die meer tijd bespaart dan LESS of SASS.

Dat weet je wel hoor, sass/compass heeft een debug mode waardoor je in de inspector van je browser exact kan zien in welk scss bestand en regel de css-rule wordt gedefinieerd. Met andere woorden je kan je inspector én je sass tegelijkertijd gebruiken waardoor je nog meer tijd bespaard

Johnny schreef op maandag 13 januari 2014 @ 17:29:
[...]


Dit is ook onze ervaring. We hebben heel veel projecten die jarenlang onderhouden worden en dat ook vaak door verschillende personen. Het feit dat de inspector in de browser niet meer te gebruiken is maakt het debuggen veel tijdrovender terwijl de tijdsbesparing van LESS/SASS minimaal zijn.

Nog iemand die blijkbaar fout geïnformeerd is als het zo was dat je inspector niet meer bruikbaar zou zijn, was ik het totaal met je eens, sass zou dan zeer onhandig zijn, maar dat is dus niet zo..... Dat de tijdsbesparingen minimaal zijn ben ik het ook totaal niet mee eens. Alleen het nesten al scheelt een hele hoop hersen-dodend typewerk.

We zijn dus terug gegaan naar plain CSS, netjes ingesprongen en opgedeelde in kleine bestanden, af en toe met comments. We hebben een server side minifier die makkelijk aan en uit te zetten is. Dit werkt voor ons tot nu toe het beste.

Zonde.

Bosmonster schreef op maandag 13 januari 2014 @ 16:58:
Om het nog maar niet te hebben over een backend developer die even wat wil aanpassen en de build-files edit Helaas zijn dit soort zaken lastig te managen in een club van 150+ man, waar slechts een klein deel van de projecten LESS of SASS gebruiken.

Kwestie van afspraken maken. En al een backender de compiled files gaat editten ipv de sass heb je dus a) slechte project documentatie en b) is hij gewoon zijn veranderingen kwijt bij een nieuwe compile, dat lijkt me de snelste manier om te leren....

Ik snap dat mensen graag blijven steken bij wat ze kennen maar in dit geval vind ik dat echt zonde, zonde van je plezier in het css'en, zonde van de tijd die je bespaart en zonde van al de mooie dingen die je kan doen met nesting, mixins, variabelen, etc.

[Bosmonster]

Ramon schreef op maandag 13 januari 2014 @ 21:30:
[...]
Wat is precies die complexiteit die het toevoegt dan? Je kan het exact zo gebruiken als CSS, de enige complexiteit die het dan toevoegt is die van het moeten compilen, dat kan ik nou niet echt complex noemen, vergeleken met de voordelen van nesting, mixins enzo. Zeker als je Compass gebruikt krijg je een hele hoop kant en klare mixins die het allemaal erg leuk maken om te css'en, vind ik.

De complexiteit die het toevoegt is dat er compilers geinstalleerd en geconfigureerd moeten zijn, er extra documentatie nodig is (zie onder), je dingen als source maps nodig hebt om weer normaal te kunnen debuggen, projectcode een stuk ontoegankelijker wordt, tientallen developers er een taal bij moeten leren, de kans op fouten toeneemt, etc.

Tuurlijk kun je normale CSS schrijven in SASS, maar dat neemt het hele idee wel een beetje weg natuurlijk

Dat weet je wel hoor, sass/compass heeft een debug mode waardoor je in de inspector van je browser exact kan zien in welk scss bestand en regel de css-rule wordt gedefinieerd. Met andere woorden je kan je inspector én je sass tegelijkertijd gebruiken waardoor je nog meer tijd bespaard

Source maps dus. Dat voegt weer een hoop problematiek toe, die helemaal niet nodig was om mee te beginnen.

Nog iemand die blijkbaar fout geïnformeerd is als het zo was dat je inspector niet meer bruikbaar zou zijn, was ik het totaal met je eens, sass zou dan zeer onhandig zijn, maar dat is dus niet zo..... Dat de tijdsbesparingen minimaal zijn ben ik het ook totaal niet mee eens. Alleen het nesten al scheelt een hele hoop hersen-dodend typewerk.

Een goede IDE scheelt je net zoveel, zo niet meer hersendood typewerk. En niemand ontkent dat een precompiler je typewerk scheelt. Alleen blijkt het in sommige omgevingen (zoals bij Johnny of bij mij) uiteindelijk op andere punten juist veel tijd in te leveren. En dan moet je een afweging maken.

Kwestie van afspraken maken. En al een backender de compiled files gaat editten ipv de sass heb je dus a) slechte project documentatie en b) is hij gewoon zijn veranderingen kwijt bij een nieuwe compile, dat lijkt me de snelste manier om te leren....

Was het maar zo simpel. Ik neem voor het gemak even aan dat je niet bij een erg groot bedrijf werkt, want "even afspraken maken" en/of "wat extra documentatie" is wel een erg simplistisch beeld. We hebben alleen al een service afdeling van 30 man ofzo die werken aan honderden projecten van de afgelopen jaren (zij maken niet zelf de sites). Dit kan alles zijn, Sharepoint, .NET, php etc.

Ik snap dat mensen graag blijven steken bij wat ze kennen maar in dit geval vind ik dat echt zonde, zonde van je plezier in het css'en, zonde van de tijd die je bespaart en zonde van al de mooie dingen die je kan doen met nesting, mixins, variabelen, etc.

Ik snap heel goed dat het voor veel mensen en/of omgevingen prima werkt en zelfs tijd bespaart. Maar ik denk ook dat je zelf even verder moet kijken dan je neus lang is en moet accepteren dat een precompiler geen heilige graal is.

[InZane]

Verwijderd schreef op maandag 13 januari 2014 @ 15:30:
Maar nu is mijn vraag hebben jullie recent goede ervaring met SASS of LESS. Iemand die mij kan helpen bij mijn keuze? En zijn er namelijk ook mensen die 1 van beiden op het werk gebruiken?

Omdat ik voornamelijk met .NET (MVC) projecten bezig ben, heb ik voor LESS gekozen. Dat wordt namelijk out of the box ondersteund in Visual Studio.
Moet eerlijk zeggen dat ik pas sinds enkele maanden nieuwe projecten standaard op zet met LESS. Bevalt me prima, maar ik moet me er wel een keer écht in gaan verdiepen.
Gebruik nu voornamelijk variabelen en mixins.

[Sebazzz]

Editor-ondersteuning wel of niet ondersteunen maakt m.i. wel echt het verschil in productiviteit.

[MoietyMe]

Waar bij mij de voorkeur voor LESS boven SASS vandaan komt is o.a. ondersteuning in VS—de gekozen ontwikkelomgeving op mijn werk, client-side usage voor development en Bootstrap.

De syntax van SASS vind ik eerlijk gezegd wat netter, maar dat weegt op dit moment niet zwaarder dan de voordelen van LESS.

[_Thanatos_]

Ik denk dat het niet zoveel uitmaakt welke je kiest.

Wat veel belangrijker is, is dat je één keuze maakt en ze niet allebei of door elkaar gaat gebruiken. Ook moet je niet voor een van de twee kiezen omdat het hip is of omdat het "erbij hoort" ofzo. Je moet het wel echt nodig hebben.

Ik vind zelf ook dat je behoorlijk gedreven met CSS moet zijn voordat je toe bent aan een dergelijke preprocessor. De mate waarin je kunt inschatten wat er nou feitelijk naar de browser gaat, neemt immers explosief toe, en het debuggen van je code wordt er beslist niet makkelijker op. Het kan allemaal wel, maar alleen als je je ontwikkelomgeving goed inricht, en dondersgoed doorhebt wat het betekent als je ingewikkelde SASS/LESS constructies bouwt (antwoord: soms exorbitant verbose en inefficiente css).

[ Voor 48% gewijzigd door _Thanatos_ op 15-01-2014 13:01 ]

[Barryvdh]

Overigens is de sass versie nu ook 'officieel': https://github.com/twbs/bootstrap-sass
(Of in elk geval onder dezelfde twbs organisatie op Github)

[MueR]

offtopic:
Als ze nu nog eens een jquery-loze versie maken wordt Bootstrap misschien nog interessant...

[Verwijderd]

Good Fella schreef op woensdag 15 januari 2014 @ 00:40:
Waar bij mij de voorkeur voor LESS boven SASS vandaan komt is o.a. ondersteuning in VS—de gekozen ontwikkelomgeving op mijn werk, client-side usage voor development en Bootstrap.

De syntax van SASS vind ik eerlijk gezegd wat netter, maar dat weegt op dit moment niet zwaarder dan de voordelen van LESS.

Dus in de states gebruiken meer LESS dan sass?

[Caelorum]

Je weet dat VS de afkorting is voor Visual Studio he?

[Bosmonster]

Caelorum schreef op donderdag 16 januari 2014 @ 14:05:
Je weet dat VS de afkorting is voor Visual Studio he?

Je weet dat ie waarschijnlijk een grapje maakte he?

(of die geslaagd is of niet laat ik in het midden )

[Barryvdh]

MueR schreef op donderdag 16 januari 2014 @ 13:08:

offtopic:
Als ze nu nog eens een jquery-loze versie maken wordt Bootstrap misschien nog interessant...

Je kan het toch gewoon gebruiken zonder jQuery, gewoon de javascript componenten niet gebruiken
En zo te zien heeft iemand al een poging gedaan om het vanilla te maken: https://github.com/tagawa/bootstrap-without-jquery
Of bijv. een Angular versie, zonder jQuery: https://github.com/angular-ui/bootstrap

[418O2]

Als je een lean applicatie wil gebruiken moet je sowieso geen bootstrap gebruiken, imo

[MueR]

418O2 schreef op donderdag 16 januari 2014 @ 14:36:
Als je een lean applicatie wil gebruiken moet je sowieso geen bootstrap gebruiken, imo

Ligt aan je usecase. De admin sectie voor een website is een bootstrap prima geschikt voor. Lekker rap gridjes maken enzo. Voor een front-end geef ik inderdaad de voorkeur aan wat meer zelf doen. Al heb ik daar altijd gruwelijk spijt van als ik formuliertje 684 zit te layouten, want uiteraard zijn ze allemaal net een beetje verschillend.

[418O2]

MueR schreef op donderdag 16 januari 2014 @ 14:42:
[...]

Ligt aan je usecase. De admin sectie voor een website is een bootstrap prima geschikt voor. Lekker rap gridjes maken enzo. Voor een front-end geef ik inderdaad de voorkeur aan wat meer zelf doen. Al heb ik daar altijd gruwelijk spijt van als ik formuliertje 684 zit te layouten, want uiteraard zijn ze allemaal net een beetje verschillend.

Ik geef persoonlijk geen klote.

Ik bouw alleen maar webapps en alle tijd die ik bespaar met bootstrap zijn de gebruikers in geen 1000 jaar kwijt aan wachttijd. Die ene keer 140kb inladen...

* 418O2 rent

[Verwijderd]

Bosmonster schreef op donderdag 16 januari 2014 @ 14:08:
[...]


Je weet dat ie waarschijnlijk een grapje maakte he?

(of die geslaagd is of niet laat ik in het midden )

Ik dacht aan de states....

[Bosmonster]

MueR schreef op donderdag 16 januari 2014 @ 14:42:
[...]

Ligt aan je usecase. De admin sectie voor een website is een bootstrap prima geschikt voor. Lekker rap gridjes maken enzo. Voor een front-end geef ik inderdaad de voorkeur aan wat meer zelf doen. Al heb ik daar altijd gruwelijk spijt van als ik formuliertje 684 zit te layouten, want uiteraard zijn ze allemaal net een beetje verschillend.

Je kunt ook alleen de formulier styling overnemen toch?

[Nedra]

Ik gebruik zelf voornamelijk SASS, maar ik heb geen giga voorkeur. Omdat ik wel duidelijk de keuze had gemaakt om met SASS om te gaan ken ik het beter dan LESS. Wel heb ik geleerd om met LESS te werken aangezien ik soms met projecten meewerk waar de voorgangers al gekozen hebben voor LESS.

Daarnaast valt er weinig in te brengen tegen de 'puristen' hier, elke vorm van pre-processor is natuurlijk weer een extra laagje complexiteit op een hele duidelijke taal (of regelset zou ik eigenlijk moeten zeggen). Echter, ik vind het uitermate handig. Ook het structureren van bestanden wordt ik erg blij van en is, als het een beetje duidelijk gedaan is, erg handig bij grote projecten.

[TheNephilim]

MueR schreef op donderdag 16 januari 2014 @ 14:42:
[...]

Ligt aan je usecase. De admin sectie voor een website is een bootstrap prima geschikt voor. Lekker rap gridjes maken enzo. Voor een front-end geef ik inderdaad de voorkeur aan wat meer zelf doen. Al heb ik daar altijd gruwelijk spijt van als ik formuliertje 684 zit te layouten, want uiteraard zijn ze allemaal net een beetje verschillend.

Als je dan al 'rap gridjes' wil maken, waarom dan niet ook jQuery gebruiken?

[MueR]

TheNephilim schreef op vrijdag 17 januari 2014 @ 10:13:
[...]


Als je dan al 'rap gridjes' wil maken, waarom dan niet ook jQuery gebruiken?

Omdat jQuery imho nog altijd een effects library is (neen, stopt uw hooivorken maar weg). Ik prefereer de stijl van Mootools, dat ligt imho dichter bij fatsoenlijk OOP.

[Bosmonster]

MueR schreef op vrijdag 17 januari 2014 @ 10:28:
[...]

Omdat jQuery imho nog altijd een effects library is (neen, stopt uw hooivorken maar weg). Ik prefereer de stijl van Mootools, dat ligt imho dichter bij fatsoenlijk OOP.

Das ook raar, aangezien je jQuery ook kan builden zonder die paar effectjes.

Of je Mootools wilt gebruiken moet je helemaal zelf weten natuurlijk, maar jQuery een effects-library noemen is wel heel kort door de bocht. (of je hebt de afgelopen 5 jaar niet meer serieus naar jQuery gekeken).

Het feit dat bijna 70% van de top websites jQuery gebruikt zegt denk ik genoeg over dat het echt wel meer is dan een "effects-library"...

[ Voor 37% gewijzigd door Bosmonster op 17-01-2014 11:12 ]

[Verwijderd]

Ook ik ben een tijdje bezig met html css ect.
Nu is mijn vraag wat is het voordeel van het gebruik van less? Wat ik er over gelezen heb is dat je bepaalde style meerdere keren kan gebruiken waardoor je minder code hebt?
En klopt het dat je door middel van deze site http://winless.org/online-less-compiler je less/sass code kan omzetten naar css ofzo?

[Barryvdh]

Verwijderd schreef op vrijdag 17 januari 2014 @ 15:44:
Ook ik ben een tijdje bezig met html css ect.
Nu is mijn vraag wat is het voordeel van het gebruik van less? Wat ik er over gelezen heb is dat je bepaalde style meerdere keren kan gebruiken waardoor je minder code hebt?
En klopt het dat je door middel van deze site http://winless.org/online-less-compiler je less/sass code kan omzetten naar css ofzo?

Dat zie je toch dat dat kan
Hier staat wat het kan ook http://www.lesscss.org/ en http://sass-lang.com/

[418O2]

Ik zou eerst even vanilla CSS leren

[Verwijderd]

418O2 schreef op vrijdag 17 januari 2014 @ 15:55:
Ik zou eerst even vanilla CSS leren

Enige motivatie voor?

[418O2]

Verwijderd schreef op vrijdag 17 januari 2014 @ 17:37:
[...]


Enige motivatie voor?

Omdat je eerst css moet snappen voor je dingen als less gaat gebruiken.

Ik overweeg om over te stappen naar Sass. Ik mis de sourcemaps echt onwijs

[Verwijderd]

418O2 schreef op vrijdag 17 januari 2014 @ 17:39:
[...]

Omdat je eerst css moet snappen voor je dingen als less gaat gebruiken.

Ik overweeg om over te stappen naar Sass. Ik mis de sourcemaps echt onwijs

CSS snap ik voor een groot deel daar niet van....

[Ronnyrr]

Ik gebruik ook LESS. Ben, zoals vele hier lees ik, ermee in aanraking gekomen door Bootstrap.
Heb nog nooit SASS geprobeerd, maar vind LESS en in combinatie met Bootstrap echt ideaal werken.

Vind het echt een grote toevoeging hebben op mijn schrijf wijze.
Het schrijft veel lekkerder weg, ziet er veel overzichtelijker uit. Ik zou niet meer terug willen naar CSS laat ik heb zo zeggen.

In mijn editor (PHPStorm) zit trouwens een automatische compiler ingebouwd, ideaal.

[MoietyMe]

418O2 schreef op vrijdag 17 januari 2014 @ 17:39:
[...]

Omdat je eerst css moet snappen voor je dingen als less gaat gebruiken.

Ik overweeg om over te stappen naar Sass. Ik mis de sourcemaps echt onwijs

LESS heeft sinds 1.5 ook sourcemaps

[418O2]

Good Fella schreef op zaterdag 18 januari 2014 @ 03:15:
[...]

LESS heeft sinds 1.5 ook sourcemaps

Serieus? Ik kan alleen een buildscript vinden die dat erin hackt.

[Anima-t3d]

-Je moet eerst CSS kunnen alvorens complexer te gaan naar LESS/SASS
-Je kan comandline gaan of een tool gebruiken zoals PrePros of CodeKit (mac)
-Je hoeft niet alles te gebruiken, je kan eenvoudig beginnen door nesting en variabelen te gebruiken. Zo kan je variabelen: kleur, accentkleur en tint declareren en indien de klant andere kleuren wilt, pas je de waarde aan en wordt overal aangepast. Daarbuiten heb je extra handige mixins/functies, maar die kun je leren als je eenmaal wat ervaring hebt.

Ikzelf gebruik SASS met PrePros lekker handig, niks complex!

[Verwijderd]

Maar heeft iemand hier in zaal toevallig een editor met coand line ondersteuning voor een linux

[ Voor 8% gewijzigd door Verwijderd op 18-01-2014 12:44 ]

[eL_Jay]

Verwijderd schreef op maandag 13 januari 2014 @ 16:34:
[...]


Ga ik zeker doen! en ps een front-end moet die sql en of php kennen?

nee, maar er is afaik weinig vraag naar dedicated front-enders. In Eindhoven willen ze in ieder geval voornamelijk back-enders die ook front-end kunnen

[Nedra]

Oh ik denk dat er best wat vraag is naar front-enders, maar er is een beetje een verschil in de definitie er van. In mijn hoofd moet een front-ender PHP en SQL kunnen, of op z'n minst begrijpen, om het front end uit te bouwen met wat de back-end devvers gebouwd hebben.

@Animata-t3d - wat is het verchil tussen prepros of codekit? Ik doe op dit moment alles via de command line, samen met de live-reload app. Wil voor de gein eens codekit gebruiken

@ziekhoof, wat bedoel je daar precies mee? Wil je vanuit je editor ook gelijk linux commands invoeren? Over het algemeen is het idee dat je een terminal / command prompt draait voor je pre-processors etc, en dat je een 'gewone' text editor (sublime2, notepad++, noem 't op) gebruikt voor developing. Of zeg ik nu iets heel logisch?

[Anima-t3d]

Nedra schreef op zaterdag 18 januari 2014 @ 13:00:
Oh ik denk dat er best wat vraag is naar front-enders, maar er is een beetje een verschil in de definitie er van. In mijn hoofd moet een front-ender PHP en SQL kunnen, of op z'n minst begrijpen, om het front end uit te bouwen met wat de back-end devvers gebouwd hebben.

Door de verschillende (on)bekwame HR managers die vacatures schrijven is er een warboel aan namen en uit te voeren functies, waarbij de 1 denkt "oh dat is een leuke naam" en de ander "oh yah 50 jaar ervaring html5 dat is ook wel handig om te vermelden"... Maar in principe is het zo dat front-enders html/css/js doen en kennis hebben van bijvoorbeeld php/mysql zodat ze dus kunnen communiceren met back-end.

Nedra schreef op zaterdag 18 januari 2014 @ 13:00:
@Animata-t3d - wat is het verchil tussen prepros of codekit? Ik doe op dit moment alles via de command line, samen met de live-reload app. Wil voor de gein eens codekit gebruiken

Het verschil is dat codekit voor mac is en prepros voor windows en (deels) gratis.

Ik zou trouwens sublime text aanraden voor algemeen coden. Heeft veel tijd besparende functies en kan uitgebreid worden. Is gratis in "proefmodus" maar dan werkt alles en na elke x keer op te slaan krijg je een boodschap die je weg kan klikken.

Tutorial: http://net.tutsplus.com/t...ime-text-2-project-bliss/

[Verwijderd]

Anima-t3d schreef op zaterdag 18 januari 2014 @ 14:06:
[...]

Door de verschillende (on)bekwame HR managers die vacatures schrijven is er een warboel aan namen en uit te voeren functies, waarbij de 1 denkt "oh dat is een leuke naam" en de ander "oh yah 50 jaar ervaring html5 dat is ook wel handig om te vermelden"... Maar in principe is het zo dat front-enders html/css/js doen en kennis hebben van bijvoorbeeld php/mysql zodat ze dus kunnen communiceren met back-end.


[...]

Het verschil is dat codekit voor mac is en prepros voor windows en (deels) gratis.

Ik zou trouwens sublime text aanraden voor algemeen coden. Heeft veel tijd besparende functies en kan uitgebreid worden. Is gratis in "proefmodus" maar dan werkt alles en na elke x keer op te slaan krijg je een boodschap die je weg kan klikken.

Tutorial: http://net.tutsplus.com/t...ime-text-2-project-bliss/

brackets all the way.

[ Voor 0% gewijzigd door Verwijderd op 18-01-2014 14:08 . Reden: typo ]

[Nedra]

Anima-t3d schreef op zaterdag 18 januari 2014 @ 14:06:
[...]

Door de verschillende (on)bekwame HR managers die vacatures schrijven is er een warboel aan namen en uit te voeren functies, waarbij de 1 denkt "oh dat is een leuke naam" en de ander "oh yah 50 jaar ervaring html5 dat is ook wel handig om te vermelden"... Maar in principe is het zo dat front-enders html/css/js doen en kennis hebben van bijvoorbeeld php/mysql zodat ze dus kunnen communiceren met back-end.


[...]

Het verschil is dat codekit voor mac is en prepros voor windows en (deels) gratis.

Ik zou trouwens sublime text aanraden voor algemeen coden. Heeft veel tijd besparende functies en kan uitgebreid worden. Is gratis in "proefmodus" maar dan werkt alles en na elke x keer op te slaan krijg je een boodschap die je weg kan klikken.

Tutorial: http://net.tutsplus.com/t...ime-text-2-project-bliss/

Ah dat idee had ik al een beetje. De definitie van front-ender wordt af en toe wel erg breed (of smal) gemaakt.

Hah Sublime Text is sinds jaar en dag mijn trouwe text-editor, heb zelfs een license . De enige reden dat ik codekit wil proberen is om een beetje te weten waar men het over heeft.

[Morphix]

Ik heb geen ervaring met Codekit, maar vziw is dat geen editor? Codekit kan (automatisch) bijvoorbeeld sass naar css compilen, min. js of css eruitgooien etc.

Je betaalt overigens enkel voor de GUI, want al die zaken kunnen prima opgelost worden met o.a. GruntJS of Guard (ruby gem).

[Nedra]

Ik zie 't inderdaad. Ik heb alles al lopen via ruby gems dus wat dat betreft is het dus een beetje overbodig.

[MoietyMe]

418O2 schreef op zaterdag 18 januari 2014 @ 11:35:
[...]

Serieus? Ik kan alleen een buildscript vinden die dat erin hackt.

De documentatie is helaas nog niet geschreven, maar in de changelog refereren ze er meermaals naar. Web Essentials heeft ook ondersteuning voor het genereren van sourcemaps.

Je kan lessc runnen zonder argumenten voor de help, daar staat het één en ander over sourcemaps

[ Voor 8% gewijzigd door MoietyMe op 20-01-2014 17:58 ]

[Anima-t3d]

Nedra schreef op zaterdag 18 januari 2014 @ 17:09:
Ik zie 't inderdaad. Ik heb alles al lopen via ruby gems dus wat dat betreft is het dus een beetje overbodig.

Codekit en dergelijke stel ik gewoon voor voor diegene die pas beginnen en afgeschrikt worden door het "console" werk

[Bosmonster]

Codekit is heel handig, maar $30 voor iets wat je ook in 5 minuten via de console leert is ook wel wat veel.

[BtM909]

Interessant artikel over SASS or LESS: LESS vs Sass? It’s time to switch to Sass

[Bosmonster]

Njah interessant, de schrijver zelf geeft al aan dat het "highly opinionated" is. Het is dus ook meer een marketingpraatje over SASS.

In this article I’ll explain why Sass really is the best

En voor mij is het een mooi artikel, met vooral veel mooie voorbeelden, over waarom ik dit allemaal niet nodig heb

[ Voor 22% gewijzigd door Bosmonster op 21-01-2014 13:45 ]

[BtM909]

Tuurlijk is het opiniated

Alhoewel ik het gevoel heb dat de "community" wel steeds meer richting SASS hangt.

[R4gnax]

Bosmonster schreef op dinsdag 21 januari 2014 @ 13:44:
Njah interessant, de schrijver zelf geeft al aan dat het "highly opinionated" is. Het is dus ook meer een marketingpraatje over SASS.

Het stuk is niet alleen opinionated maar op een aantal vlakken ook ronduit fout / misinformerend:
List variables en de mogelijkheid daar over te itereren zijn er gewoon in LESS en er wordt nog actief gewerkt aan syntactic sugar om e.e.a. te stroomlijnen.

Custom functies modeleer je in LESS als mixin met output variables. Men is daarnaast bezig met de mogelijkheid om eigen functies in JavaScript te schrijven en in de LESS compiler te importeren. (Mogelijk on-demand via een import statement o.i.d. in de te compileren LESS sheet.) Daarnaast is het reeds mogelijk om met de ~`` syntax inline JS te schrijven.

[TheNephilim]

Ook Bootstrap heeft nu ondersteuning voor SASS: http://blog.getbootstrap....bootstrap-3-1-0-released/

[Sebazzz]

Zouden ze een taal hebben die naas LESS of SASS compileert

[Nedra]

Sebazzz schreef op vrijdag 31 januari 2014 @ 19:26:
Zouden ze een taal hebben die naas LESS of SASS compileert

http://css2sass.heroku.com/