LESS

Weboldalak dizájn részének szerkesztése közben gyakran előjön az az érzés, hogy a CSS bizony egy buta jószág. Sok mindent meg lehet vele csinálni szépen, de kinek nem volt még olyan gondolata, hogy de jó lenne, ha legalább konstansokat tudnánk definiálni vagy egyik osztály örökölhetne beállításokat másik osztálytól?

A CSS ezeket nem tudja, de van más, ami igen, úgy hívják, LESS. A nagy ötlet az benne, hogy nem próbál kitalálni egy teljesen új stílusleíró nyelvet, hanem csak kiegészíti a CSS-t néhány új funkcióval: változókkal, ún. mixinekkel, műveletekkel és egymásba ágyazott szabályokkal. Nem írok ide példákat, a LESS kezdőlapján gyorsan át lehet tekinteni ezeket.

Nyilvánvalóan a böngésző nem tudja értelmezni a .less kiterjesztésű fájlokat, ezért szükséges egy fordítási lépés, melynek során a .less fájlból szabványos .css fájl lesz – erre természetesen van eszköz.

A legszebb az egészben, hogy van .NET-re portolt változata, úgy hívják .LESS (dot-less), ahol ráadásul nincs szükség explicit fordítási lépésre, mert HttpHandlerként tud beépülni az ASP.NET csővezetékbe. Sőt, a handler képes minimalizálni a generált CSS-t és cache fejléceket is be tud rájuk állítani, így csökkentve a hálózati forgalmat és a szerver terhelését. Látszik, hogy olyanok csinálták, akik láttak már valós projektet. A telepítés mindössze web.config szerkesztést igényel.

Készül hozzá Visual Studio integráció is, még az is lehet, hogy a 2010-es változat közvetlenül fogja támogatni, legalább syntax highlight szinten.

 

Technorati-címkék: ,,,

7 thoughts on “LESS

  1. László

    "Látszik, hogy olyanok csinálták, akik láttak már valós projektet." Vitatkoznék kicsit ezzel a következtetéssel… Véleményen szerint a fejlesztői környezetben a legkényelmesebb megoldás a HttpHandler használata, de egy valós környezetben sokkal kevésbé hasznos és célravezető. Az utóbbi esetre mindenféleképpen a lefordított, legenerált statikus állományok használatát javasolnám (a hab a tortán, ha erre dedikált kiszolgáló szervert használunk). Miért kell egy viszonylag ritkán változó állomány(ok) miatt a pipeline-ba kergetni az ilyen típusú kéréseket? Teljesen felesleges performance overhead-et okozunk saját magunk számára… Ne feledjük soha: a webkiszolgálás oltárán a teljesítmény áll legelöl, a kényelem és szépség csak valahol hátrébb.

  2. unbornchikken

    Szerintem Gyuri nem a .NET-es, HttpHandleres megoldásra értette, hogy "Látszik, hogy olyanok csinálták, akik láttak már valós projektet.", hanem erre a LESS dologra. Mert a CSS-en tényleg az látszik, hogy valami webes fejlesztéstől teljesen idegen gondolkodású kutyaütő dobta össze."Miért kell egy viszonylag ritkán változó állomány(ok) miatt a pipeline-ba kergetni az ilyen típusú kéréseket?"Ezt nem értem. Figyi, ha van egy HttpHandler, ami kinyom valami cuccot, amin be van állítva a cache header (jobb esetben az if_modified_since header is), akkor a kérés el sem jut az ASP.NET Pipeline-ig. Ahol kell a teljesítmény, ott az egész cucc előtt tuti van egy ISA proxy.

  3. György

    László, teljesen igazad van, ritkán változó, fejlesztési időben előállítható fájlok esetén teljesen felesleges az egészet dinamikussá tenni egy handlerrel. Ahol a teljesítmény az elsődleges szempont (szinte mindenhol annak kellene lennie, de nem az), ott valóban előre le kell fordítani és jöhet a chick által írd proxy is. Egyetértünk. Azonban sok olyan eset van, ahol az egyszerű fejlesztés és a sima "felmásolok mindent" telepítés a cél. Azért írtam, hogy olyanok csinálták, akik már láttak valós projektet, hogy még ezekből az esetekből is kihozták, amit teljesítmény szempontból lehetett: a minimalizálást és a cache-t. Aki veszi a fáradtságot, hogy előre lefordítsa a CSS-t, az szerintem fog minimalizálni és gyorsítótárazni is a hagyományos módon. Aki pedig nem, az lehet, hogy nem is gondol erre, mégis megkapja ezeket a funkciókat gratis.

  4. László

    "Ezt nem értem. Figyi, ha van egy HttpHandler, ami kinyom valami cuccot, amin be van állítva a cache header (jobb esetben az if_modified_since header is), akkor a kérés el sem jut az ASP.NET Pipeline-ig." Ez nem igaz… Azért mert a HTTP Response fejlécébe megadod a cache opciókat vagy éppen az if_modified_since headert csak annyit jelent, hogy az adott kliens esetén úszod meg a dolgot. Ha jön egy teljesen új látogató, akkor az ő kérése ugyanúgy belefut (totál feleslegesen) a csővezetékbe! Proxy helyett meg inkább ajánlom mondjuk a LightHttpd vagy Nginx használatát.

  5. László

    "egyszerű fejlesztés és a sima "felmásolok mindent" telepítés a cél." Azért ne feledjük, hogy pl. a Visual Studioban igen egyszerűen beállíthatóak post-build akciók és ezáltal szinte nullára redukálható a fordítás/minimalizálás költsége. De természetesen ezzel nem vitatni szeretném a srácok érdemét, sőt! Egyszerűern csak próbáltam kicsit hozzátenni a valós világ szemszögéből:-)

  6. György

    Ott a pont a post-build akciókkal kapcsolatban. Sajnos a Visual Studio felhasználók nagy része szerintem nem tud róluk, illetve el sem tudja képzelni, hogy egy Build nem feltétlenül csak abból áll, hogy a .cs fájljaimból valami rejtélyes módon .exe lesz. Egy másik része a valóságnak🙂

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s