71–80 of 131 posts
Does the preprocessor generate raw (i.e. conventional) CSS, which it then convinces the browser to evaluate or re-evaluate as necessary, or does it actually apply the styles itself with JS? i.e. something equivalent to jQuery('.heading').css("color", "red").
Literally the only problem with CSS itself is that it doesn't have defines. Every other problem is just browser implementations.
I also have issues with the "box model." Judging by the popularity of grid layout systems like blueprint and 960 I think others also do. The box model is fine when you just need to "flow" things around things, like text around images, and typical blog designs, but when you develop complicated interfaces it really shows its limitations and costs many hours of frustrating effort.
I can see it being somewhat useful as a server-side technology or as an authoring tool that you can then "compile" to CSS. CSS is so straightforward and simple to use as-is, however, that I don't really think it needs something to make it even easier, although the support for variables is quite nice. Having said that, I have the same problem with LESS.js that I have with various other JavaScript layout techniques - I…
CSS is far from easy to use correctly. CSS is very poorly designed. Aside from all the browser hacks it's core constructs often times contradict each other (think float vs position). We do need something better but I'm not sure if LESS is it. I would much rather see something built into browsers directly.
So I still don't think something like LESS or SASS is the answer. My point was CSS is, despite its poor design, fundamentally easy to understand in terms of how it's supposed to work. No, it doesn't always work like it's supposed to and sometimes you have to work around that, but at its core, the syntax, the structure, and methodology behind it are dead simple. Building something like LESS/SASS to run on top of/underneath CSS to then generate said CSS markup seems redundant, when instead what needs to happen is that the focus needs to be on fixing the flaws of CSS, not adding another layer of abstraction.
And how does LESS/SASS handle all of those hacks? You still have to do them. You just write them a bit differently. So really, besides variables, what added value does it provide?
Running a compiler in the browser in production will never be a good idea. If you care about the speed that your website displays -- and you should -- the slowdown caused by parsing, processing, and concatenating large amounts of CSS will dwarf over-the-wire time. People who seriously care about the usability of their sites have been spending a lot of effort recently figuring out how to get load times as fast as poss…
Less.js will cache the CSS on modern browsers after the first load using HTML5 local storage, so subsequent loads aren't an issue. First load is also very fast and won't make a huge difference. Like you, I wouldn't normally recommend running the compiler live but the performance here is really impressive. Please don't assume how fast Less.js is before you try it.
Running a compiler in the browser in production will never be a good idea. If you care about the speed that your website displays -- and you should -- the slowdown caused by parsing, processing, and concatenating large amounts of CSS will dwarf over-the-wire time. People who seriously care about the usability of their sites have been spending a lot of effort recently figuring out how to get load times as fast as poss…
Well, it's way too late for that. You need to send that statement back to mid-1990s.
Or does your processor natively execute Javascript text?
That dogmatic declaration is nonsense. Compilers are just code. Certain programming language compilers are very slow due to the immense complexity of their task but there's nothing intrinsically slow about compilers/interpreters next to any number of other normal tasks. I've even sped code up by replacing large swathes of ad-hoc hard-coded crap code with a nice small interpreter that was small enough to be feasibly optimized, rather than the mass of code that was previously there that everybody was afraid to touch.
The really slow part would be the parsing, really, and if Less.js doesn't already have a "straight from JSON" mode, it would be easy enough to add one, then you could actually use the "native" Javascript parser and compiler.
One thing puzzles me: If LESS is essentially a template language specialized for CSS, why not reuse the template engine that you use in your application anyway? That way, you'd also have the benefit of defining often-used attribute values (e.g. colors) in a variable, and you could also group often-used combinations of attributes together in a variable or sub template.
Earlier quoted context omitted.
The article makes it sound like the author expects in-browser processing to be the only way it'll be used: "Less.js is a JavaScript implementation of LESS that’s run by your web browser. As any JavaScript, you include a link to the script in your HTML, and…that’s that. LESS is now going to process LESS code so instead of including a link to a CSS file, you’ll include a link directly to your LESS code. That’s right, n…
I demand a benchmark. Saying that something is just false without numbers to back it up is not something I have high trust in, and is the start of the gossip that causes internet wars. First back it up with numbers, then we talk.
A trivial CSS file (foo {a: b}) takes about 0.11s. This is probably mostly time spent spawning Node and loading the JS.
The combined CSS for GitHub, about 160K, takes about 1.6s. This is already longer than most HTTP requests.
The doubled CSS for GitHub (the same CSS twice in a row), about 316K, takes about 4s. This is quite large, although there are few sites that have this much CSS.
I tried to run it against the minified CSS for caring.com, but after 2m it hadn't terminated so I gave up. It's likely that this is due to a bug in the implementation rather than slowness.
We used Less for a project, but ended up moving to Sass: http://sass-lang.com/ The Sass compiler was (is?) more mature, and the language feels more consistent (see the '&' operator in Sass vs the :hover special case in Less). The editor/tool support was quite a bit better too. Sass doesn't have a javascript in-browser implementation (afaik), but for rapid development it can watch a folder/file for changes and automat…
There is sass in node.js/express framework. cant see why it cant ne adjusted to be use client side.