I've been using the Javascript implementation of LESS for working on a project, and it works great, however I'm now finished the project and in an effort to improve site performance I'd like to get the processed version of the CSS to use directly, rather than running it through LESS every time.
Can someone tell me if/how it's possible to view the processed LESS styles on my website? Perhaps it's under the hood of developer tools or something?
Thanks
Check out a LESS compiler, here's the link from the LESS official site:
https://github.com/less/less.js/wiki/GUI-compilers-that-use-LESS.js
LESS itself comes with a command line compiler.
Related
I'm developing a web app using python and twitter-bootstrap, and my CSS would really benefit from using LESS in order to generate my styles and themes. I want to inherit from classes provided by bootstrap, which means I've got to get the bootstrap source, and compile my LESS stylesheets against the boostrap .less files.
My question is two-fold:
1) The simplest way it seems to use LESS is not to actually compile stylesheets "on-the-fly" but to have a build step that I run each time I make changes to the styles. Is this typical? It seems like a lot of people run LESS dynamically in their server process, but it's an extra headache that I probably don't need, and I don't want to run less on the client side.
2) Thanks to LESS, my project now depends not just on bootstrap, but the bootstrap "source" - What's the best way to handle this in terms of my project management? I don't want to just absorb the whole of whatever the current version of bootstrap is into my git repos, because it seems like it would be a hassle to update it as newer versions of bootstrap come out (also feels icky!) Still though, I need to have at least the minified js/css in my project tree in order to deploy my app. How do people typically handle dependencies like this when developing web apps?
There are a couple of shoices:
You could use less.js in development, so you don't have to
compile each time you change your less code. You just use *.less files instead of *.css
You could use any of the GUI tools that will automatically recompile less code. I prefer LESS.app.
I use git submodule
I would have linked you to the same post as Pavlo above. Maybe there is no best CLEAN practice for this? Neither there is any magic "package manager" i think.
I went updates BS once and it was a bit of a hassle to find out all the variable names that have been changed in the LESS files.
I'm looking into using the Less framework to build a new website, but I'm curious about one point. Is it related to the LESS stylesheet language ? Does Less even uses LESS to build its CSS ?
As far as I can tell, the Less framework and the LESS language are completely unrelated. Contrary to what you say, the framework doesn't even appear to utilize any language features of LESS — its stylesheet seems to be written purely in standard CSS. You can see it in the source preview in the Getting Started section.
I have just started using LESS CSS and it is great so far.
I do have a question or I am looking for a recommendation on the best way to use it.
I have been testing with the Mac Compiler and the client-side JS version.
I am sure there is some overhead to running it client-side and the Mac compiler works but its a bit slow because I keep having to run it.
Can anyone give me the pros and cons of each and if you have had more success doing it a certain way.
Thanks!
I'm on a mac and have been using StaticMatic.
If you're not afraid of the Terminal, you can quickly start new projects which generates some source files in HAML and SASS. Then you can run WebBrick (localhost:3000) to see you generated code on the fly.
When you're all done StaticMatic has a built in feature to "build" your site --> will generate HTML and CSS.
Hope this helps.
What are the best ways to use LESS for CSS.
Basically should the Devs write a Less File and then have it compile for production
Should I link the LESS code and the javascript file.
Or should I skip the LESS rout altogether and just remake the classes
I am trying to wrangle together some rather sloppy css and want to get control of it before making major improvements. I think it would be very good to have site wide variable so Less seems like a good thing with the variables and nesting.
I am replacing a lot of the background images with css gradients and box shadows so I am also trying to get rid of the vendor prefixes.
Sometimes I see what kindof looks like class overload but is it bad to append a lot of classes to an element such as
<div class="comment dark-shadow round-corners"></div>
Less is a great styling language. I use it extensively, and it really helps with code maintainability, as well as with speed of writing the styles.
I personally feel that your styles should not be dependent on javascript to render, so I use the less.app to compile all my LESS into CSS. I rest more peacefully knowing that all my CSS is there and that it works correctly before I put anything "live".
If you are interested I have also been compiling a LESS mixin library that can be very useful: https://github.com/jdmiller82/-lessins-
I agree with Jonathan, I don't think you should depend on the users browser to render the styles.
I came up with a solution that uses node.js on the server to intercept requests like styles.css and try to find the equivalent .less file (in this case styles.less) and parse it and return it as CSS.
So on your server you would just have styles.less but you could request the URL example.com/styles.css and get the parsed LESS file. That way the integration is seamless for the rest of your application and it doesn't require the user has JavaScript enabled either.
You don't have to be using node.js for the rest of your app either. I did this in a PHP application.
You can read my tutorial here: http://programming-perils.com/155/parse-less-files-on-the-fly-and-serve-them-as-css/
I realize this answer is about two years later than the above ones but I think the question is still relevant.
I think there are use cases where compiling some LESS client side is a good idea (provided you aren't supporting IE 8 or below) and you have a use case that validates it. For example, an application I've worked on recently has a customizable, theme-able interface where text colors, etc need to be modified based on whether the background color they're on is light or dark and may eventually need to support the ability for the user to change them and see those changes reflected on the site in realtime. This is a great use case for client side LESS I think. Note that only a small LESS stylesheet is compiled and the rest of the application LESS that's not related to theming is precompiled. I haven't seen much of a perceived difference in performance.
So when you see comments like "you don't seriously think any decent developer uses less clientside do you?", I'd take them with a grain of salt.
The way to use LESS for a production website is to compile LESS files into CSS files.
For local development you can have a file-watcher that rebuilds the CSS files for LESS files that were changed.
If you have multiple CSS files to produce from LESS, you should separate them out.
For example, if you have 30 less files and they produce two CSS files a.css and b.css, you will want to separate those two jobs so that you can compile faster. It's faster for developing because you will only compile a.css if you change any LESS files that affect it.
Did anyone has the comparison between these two libraries (Combres2 and SquishIt)? If one library is better than another one, I also want to know the reason for that.
I found the article said that Combres2 has a better compression than SquishIt. But it is almost a year ago.
http://blog.buzzuti.com/post/Combres-vs-SquishIt-e28093-A-battle-of-Minification-Combiner-and-Squishing-in-generale280a6.aspx
One thing to make note of is that SquishIt works in a different manner than Combres2, so it isn't a simple who produces better minified code.
SquishIt works very nicely with T4MVC, which you won't get with Combres2. On this basis alone I'd tell anyone to use SquishIt. Additionally, SquishIt is not xml config file based, which allows for a lot of flexibility. In fact, you could theoretically make an xml config file and mimic Combres2 if you really desired it.
In terms of minification SquishIt is actively developed, which means that if new methods to minify scripts are created you'll be more likely able to leverage that as well. Currently it supports JSMin, YUI, MS Ajax Minifier, Closure Minifier, or even no minifier.
Update 1/18/2012: There are now many other alternatives out there aside from SquishIt and Combres2. For starters, Microsoft is creating there own system for the next release of ASP.NET 4.5. Cassette, similar to SquishIt, and RequestReduce, which is quite different than anything else by automagically doing everything for you.
I'm a fan of SquishIt.. even though Combres and SquishIt both (optionally) use the YuiCompressor.NET library (which I am biased, for ;-) )
Being a fan of Justin Etheredge, I recommend/use SquishIt.
The reasons to one library is better than the other (for me) is if the final result is NOT a break code and still working.
I have test and working with the Microsoft Ajax Minifier, and I assure you that is working absolute correct - can even minifie the jQuery library with out any issue.
http://ajaxmin.codeplex.com/
http://aspnet.codeplex.com/releases/view/40584
documentaion:
http://www.asp.net/ajaxlibrary/AjaxMinDocumentation.ashx
Now if a library is one year old this have nothing to do, because they just working on javascript code that have some standards some years now.
To point again out : the better is the one that product minimum code that is still working under very complex javascript functions like the one jQuery have.
One note:a minified library can minified a full set of files at ones, do not try to minified one by one and them add them to a single file, this is not working.
This is meant as an answer to the 'Microsoft Ajax Minifier' recommendation, and a general warning for those that do so. As my reputation is a mere 41, I cannot add the comment there, where it should go. :(
For our team, the native C# VS2017 Microsoft compression (which may or may not be the same as the one labeled as 'Microsoft Ajax Minifier') failed on the css function 'calc', and badly.
That was a bit tricky to track down, since the error (obviously) only occurs during minification. And since we were minifying based on environment (interwoven with Release, Debug), that meant the calc bug (by default) never appeared on local. It just magically appeared when we pushed to production... and only on pages that used the calc function.
(Definitely agree that minimum code add-on is fantastic. But the native minifier can be faulty. So proceed with caution.)
If you are not using 'calc' (and you are noticing no other issues), then likely your team is fine with the default minification tool.
And of course, Microsoft could have fixed the bug since we discovered it. But bug reporting through msdn doesn't always lead to resolution of the issue. :(
There may be other issues. But in our case (since we use 'calc'), that was sufficient to have us investigate other minifiers, and SquishIt has been our team's choice. We had not looked at Compres2 at that time. Up until now, we've been very happy with SquishIt.
Side note: I'm in the middle of investigating minifiers again because of some sort of 'collision' between jQuery 3.6.0 and SquishIt for VS2017. (with no 'collision' between jQuery 3.4.1 and SquishIt, VS2017). Early stages of problem-solving process.
Best wishes and happy coding,
Michael M.