

Less.js will obsolete CSS - edanm
http://fadeyev.net/2010/06/19/lessjs-will-obsolete-css/

======
nex3
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 possible, and this is a leap in the wrong direction.

~~~
jerf
"Running a compiler in the browser in production will never be a good idea."

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.

~~~
nex3
You're right, that was too broad a statement. However, it is undeniable that
in-browser compilation of CSS will always be slower than precompilation, as
long as the compilation outputs CSS. For some people, this speed hit will
never be negligible. But for those who don't need to squeeze every bit of
performance out of their sites, it's sufficient that it only be an order of
magnitude or two faster than the HTTP request.

However, that's not the case right now. Maybe in the future Javascript's
string parsing will become dramatically faster, but in my benchmarks elsewhere
on this thread, it's clear that for large files less.js is pretty slow
relative to HTTP.

As for serving it up as JSON: no one wants to write stylesheets in JSON. The
reason Less became popular as an alternative to Sass was that it had a CSS-
like syntax.

~~~
jerf
"As for serving it up as JSON: no one wants to write stylesheets in JSON."

You don't have to. You can use a compiler to generate JSON to feed to the
system, retaining the flexibility of having the compiler running but skipping
the parsing step. Why not compile straight to CSS? Well, why not? For simple
sites that may be just fine. For more complicated sites it might be desirable
to screw with the CSS before compiling.

My real meta-point here is that compiling isn't that scary. The idea of load
you may get from g++ or GHC is not generally applicable. And as JS gets closer
and closer to C-speeds it'll matter even less. (Not saying it will _reach_
them, but you don't have to.) And there are already quite a few compilers in
the mix; every web language has one (JS, CSS, HTML, SVG) and adding another is
not like an enormous scary step. I suppose this is another consequence of the
continuing deplorable move away from having compilers be a required class for
a degree; truly it is one of the most powerful techniques of computer science
that is relatively difficult to fully encounter outside of a formal education.
(Like everything else in programming, it isn't impossible, but as it is very
easy to walk away with a _degree_ without ever having encountered one, so much
moreso it is easy to not encounter one in informal education too.)

~~~
pyre
When people talk about how Javascript is going to approach C-speeds, I have to
wonder how much cross-browser development they have actually done. Recently at
work, we found that while Chrome handled using the jQuery UI 'buttons()' to
style all of the buttons one of our pages, it was taking IE8 a full _8
seconds_. After removing it to improve page rendering times in IE8 even Chrome
felt snappier.

~~~
jerf
It depends on the constraints. The C-like speeds for pure numerical
computation are being obtained by a number of other JIT compilers too. As you
get more complicated you tend to lose the advantages.

However, I would submit that string bashing also ought to be amenable to JIT
optimization. What will kill you in the browsers is interacting with the
DOM/browser itself, and that's not going to go away as that code is
increasingly already as optimized as it's going to get. However, CSS _already_
has that problem, so if you can dynamically snap some CSS together on the
client side and then feed it to the usual CSS processes, it doesn't have to be
a large loss.

I also expect the browers to continue to work towards support more of this
stuff being done dynamically; if you can better hook into the page generation
process, you can help the browser avoid extra stupid work, like starting to
layout the page with the entirely wrong CSS. We're still a ways from this
entire process being optimized; I feel we've finally left the stupid ages in
the browser world, but we're still working.

------
jomohke
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 automatically
recompile to static CSS files.

Plus there's a firebug plugin, so you get Sass line numbers / references
instead of compiled CSS line numbers: <https://addons.mozilla.org/en-
US/firefox/addon/103988/>

~~~
rapind
Interesting. I tried both and now use LESS with the More plugin in my rails
app. I'm a huge fan of HAML, but I haven't fallen in love with SASS yet. The
big upside to LESS is it still looks like CSS. Compass is interesting though,
from the SASS side. <http://github.com/chriseppstein/compass>

~~~
jomohke
The latest version of Sass (3.0) has CSS syntax: The compiler supports both
variants - the file extension (.scss vs .sass) denotes which you want to use.

See the examples on their front page: <http://sass-lang.com>

They have a command line tool "sass-convert", which can convert between the
syntaxes (and from Less)

~~~
rapind
Thanks for pointing that out. I'll give it another go.

------
axod
Sensationalist link-bait headlines have no place here IMHO.

~~~
cubicle67
59 points and (at the time of writing) top post would indicate some disagree

~~~
muuh-gnu
Provided HN was meant to be a non-discriminatory democracy, but it to my
knowledge was not. Any news site not systematically filtering content to suit
a specific, targeted demographic will sooner or later inevitably converge
against Digg (or die like the usenet).

------
KevinMS
I cranked out something similar to this years ago called in Lua and C called
moonfall, actually more powerful because it was extendable, even got on
smashing magazines "best of the month" or something like that, and I'm pretty
sure it didn't obsolete CSS. Actually I don't think anybody used it, not even
me. Maybe because Lua didn't have the buzz that javascript has now.
<http://moonfall.org/>

~~~
draegtun
Moonfall did (at least) inspire someone to write a Perl port of it:
<http://search.cpan.org/dist/CSS-Moonfall/>

------
SingAlong
I hope they still maintain the ruby gem version of LESS.

LESS is beautiful as it is. But processing LESS code in the browser would mean
that I can't use LESS.js for mobile web apps. Although there are mobile
devices with 1ghz processors already out in the market, there is still a lag
in rendering mediocre-weight pages that contain js on mobile devices.

P.S: Congrats on keeping LESS simpler.

~~~
stevelosh
You can run less.js from the command line to precompile if you have Node.js
installed, and it's _much_ faster than the Ruby gem.

------
benbeltran
I don't know. As a fan of CSS I don't really "get" Less.js ... Sure I
understand the benefit of defining certain properties, but are the benefits
good enough to warrant depending on an additional javascript library for
something like this? What happens if people block javascript?

I don't know. It's not bad, but it's not for me. But going as fas as to say it
will obsolete CSS, that's just too much.

~~~
nailer
> are the benefits good enough to warrant depending on an additional
> javascript library for something like this? What happens if people block
> javascript?

Nothing, in production you'd use the compiled ver. The article should make
this clearer though.

~~~
edanm
That depends. The "new" version they talk about in the article _does_ require
Javascript, since it does on-the-fly compiling. For the current version you're
right.

~~~
nailer
I understand the thing they just released allows on-the-fly compiling. I'm
just suggesting is that since the existing options remain available, you can
still use them.

------
kellishaver
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 simply don't like relying on
JavaScript to control the look and feel of a web page. I think it's awkward,
inefficient, and just asking for trouble. Mostly, I also think it's completely
unnecessary.

~~~
IgorPartola
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.

~~~
kellishaver
I hear this all the time and I really just don't see it. I'm not trying to be
argumentative, I just don't understand. Yes, it is poorly designed, no
question about that and there are certainly things that could be done better,
and one shouldn't have to use all of the "hacks" to begin with. But I do find
it incredibly easy to work with, and I'm often doing very complex layouts that
have to work in everything from IE6 up. CSS is just a matter of memorization.

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?

~~~
isleyaardvark
The value it provides is it simplifies CSS, helping maintainability and
preventing repetition. It's not a replacement for CSS, it's just a way to make
dealing with CSS easier. The syntax is easier and since it's a superset of
CSS, you can keep on using plain old CSS syntax if you want. It adds more
options and more flexibility.

Variables alone make LESS/SASS worthwhile, but even putting those aside, let
me give you an example of added value: importing other files. With LESS/SASS
you can import different files, and they get compiled into one CSS file. With
CSS if you use @import, you've got an additional HTTP request, which
negatively impacts performance. LESS/SASS gives you additional flexibility in
organizing your CSS. In LESS/SASS you can just go to the individual file that
deals with typography, as opposed to the tricks designers have used to find
things in a large CSS file (e.g. putting a table of contents at the top of the
CSS in comments, with a unique string for each section, which you then use
Ctrl-F to look for to find the section of rules you're interested in.)

I'd recommend trying it out on a small project if you haven't already, to see
for yourself.

------
risotto
Sensationalist headline but I can't wait to try this. When you start
representing everything as JSON trees, web programming gets so much more
consistent, compact, and easier.

Also see:

MongoDB - save data in BSON (binary JSON) And query with JSON

Node.js - Build an entire smoking fast server side web app with JavaScript
objects. Bonus: run a node app on Heroku to compile and varnish cash less.js
if you are worried about performance

Mustache.js or Pure - JavaScript templating to turn JSON into HTML

V8, tracemonkey, Nitro - blazing fast JS interpreters everywhere that will
.eval JSON

Convergence anyone?

------
nathansobo
I've tried css-dryer, which is similar in concept to server side LESS and
SASS. I found it to be problematic on a large project because even though the
CSS was compact in its source form, what actually got compiled ended up
getting huge. It was slow to download and inefficient for the browser to
process. The brevity of the source language ended up being an invitation to
use CSS in a style was extremely verbose upon compilation. It also added
operational complexity to have to deal with compiling the css. For example we
wanted to use CSS in some of our javascript tests and then we had to deal with
running the dryer from the test server. We eventually ripped it out at fairly
great cost and went back to vanilla css, where it was clear to everyone what
everything meant and we didn't have to worry about a huge inflation of the
code. Maybe there's something smarter about these frameworks that avoids these
issues?

------
tjogin
Sure, and PHP will obsolete HTML.

~~~
adamdecaf

         for (var $i = 0; $i < count($nav_links); $i++) {
              echo '<li><a href="' . $nav_links[$i] . '"></a></li>';
         }
    

I can see it now, a day without HTML!

</sarcasm>

------
duairc
Nonsense about obsoleting CSS aside, I've downloaded this Javascript version
and I've been using it as a standalone program with Node. The command-line
tool is a lot less mature than the Ruby version, but it's so much faster. The
Ruby one was really painfully slow. It was really frustrating to have to wait
a whole five seconds for it to regenerate your CSS files every time you make a
small little change. This one will regenerate your CSS in comfortably less
than a second. It's much better.

------
vog
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.

~~~
edanm
I wonder why there is no general "template" language that you can use on any
text/source file. For example, I'm writing a lot of AutoHotKey code lately,
and I find myself wishing I had some of the expressive power of Python so I
wouldn't have to repeat things.

I'm seriously considering writing a Python-based "Preprocessor" language which
lets me drop in Python code on any file, and deals with transforming it into
the final "compiled" file.

~~~
ori_b
We're going back to M4 now, but with python?

~~~
edanm
Thanks for that, never heard of that.

Link for anyone interested:
<http://en.wikipedia.org/wiki/M4_(computer_language)>.

By the way, I really think that to work (i.e. become usable, maybe even
popular), this needs to be built on an existing and popular language.
Otherwise it's too steep a learning curve.

Ideally, I'd like to be able to put in code in the text file wherever I want,
be able to put the value of expressions in the code, and that's it.

~~~
vog
M4 is not as unpopular as you might think.

It is the base of GNU Autoconf, so everyone who touched a _configure.in_ /
_configure.ac_ file did in fact work on M4 code.

(... which is then expanded to a portable shell script also known as the
_./configure_ script.)

------
sams99
Great, now my web pages will look like rubbish when people disable javascript

------
baddox
Literally the only problem with CSS itself is that it doesn't have defines.
Every other problem is just browser implementations.

~~~
KevinMS
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.

~~~
noibl
Not sure if this is what you're referring to, but you can have a box model
that includes padding and border in the width using CSS3:

    
    
      box-sizing: border-box
    

with -ms- (IE8), -moz- and -webkit- prefixes.

<http://www.quirksmode.org/css/box.html>

~~~
KevinMS
<http://www.w3.org/TR/css3-box/>

~~~
stan_rogers
Right CSS version, wrong module: <http://www.w3.org/TR/css3-ui/#box-sizing>

The CSS3 UI module is a candidate recommendation. Setting:

box-sizing: border-box;

essentially puts the CSS box model render mode to where it was in IE5 (which
is, frankly, the only sensible way to do it). Right now, it is available with
Mozilla, Webkit and Microsoft prefixes (as are most of the UI module
properties).

------
loup-vaillant
What if the user uses noscript, or otherwise disable Javascript? Preventing
cautious people from seeing the eye candy doesn't sound like a good idea.

~~~
huhtenberg
Users running noscript are typically prepared for any site to look broken or
not work as expected. They also comprise a tiny majority of visitors, so for
all practical intents and purposes accommodating their case is not really a
development priority.

~~~
nex3
Don't forget the accessibility considerations: screenreaders typically don't
run Javascript either.

~~~
loup-vaillant
Yes, but screen readers don't care about CSS either.

------
rriepe
Looks interesting. I don't know how many times I wished I could define a color
like thatin CSS.

I'll definitely be keeping an eye on this.

------
bodytitle
Is this really solving a problem? I mean CSS itself has issues but wrapping a
developer centric toolkit around it doesn't seem to help. In my view CSS is a
necessary evil but it is also primarily used by designers. Forcing them to use
variables and learn classes and adhere to another syntax would seem counter
productive to most of the gains.

------
mjs
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").

~~~
fadeyev
Conventional CSS

------
lowkey
Admitedly, I'm a relative n00b when it comes to development but seriously "I
do not get it". There doesn't appear to be much in the way of reduced syntax,
at least not in the example provided. Can someone explain why this is better
or clearer than CSS?

~~~
weego
There is genuinely a tiny benefit because you don't need to declare colors etc
more than once, everything else about it is trying to wedge ideas from other
areas of programming into a language that contains so many abstract concepts
as to not benefit from it at all.

I've worked as a UI developer for 12 years now and I wouldn't go near
something like this because there is no value. At least the server side
version you can pre-process and package up for live after your developers have
saved literally minutes by using it. You need to know CSS inside out, so you
have to then unlearn and relearn different parts just to do something you can
already do with find + replace.

And worse, you are even including and downloading files that the browser
cannot even interpret itself without relying on another download of JavaScript
as well, so you're giving something that works 100% of the time (assuming
someone has CSS on) another point of failure. Most of my time in UI has been
in public sector education trying to push standards and quality from various
suppliers to the Govt and seeing things like this from said suppliers (I've
seen worse to be fair, but I've seen something like this before) is always an
unpleasant experience.

~~~
edanm
Let me give an example use case, something I've wanted.

Lots of developers will tell you that it's fine to use systems like the 960
Grid System for rapid prototyping, but you shouldn't use them for final,
"production" sites. Their argument is that "littering" your code with classes
like "grid_4", etc. is not semantic (and they're right).

So here's what I would love to do: use a system like 960 in development, but
instead of using names like "grid_4", use actual, semantic names. But behind
the scenes, I'll use less to "inherit" the grid_4 properties into the semantic
name.

E.g., assuming I have: "<div class="grid_4 article_header>", I'll remove
grid_4, but use less to make "article_header" inherit grid_4's properties.
That way my html remains semantic, but I get the full power of systems like
960.gs.

~~~
isleyaardvark
I'll give another example with mixins: clearfix. I've seen webpages littered
with class="clearfix" all over the HTML. That doesn't do anybody any good.
With a CSS preprocessor you can define a clearfix mixin and just write it
something like:

.class-name .clearfix font-size: 1.2em

There are other ways to do it like one long string of selectors followed by
the clearfix code, but they're not as convenient or readable.

------
folktales
BTW, the fix for Chrome is to start it with --disable-web-security.

------
ivanzhao
instead of learning new abstraction like this, maybe more useful to sharpen up
text editor skills? I found css very vim-friendly

~~~
humbledrone
That's like saying that instead of learning how to write functions, one should
just get better at copying and pasting (because VIM is good at that).

~~~
vog
CSS has very flexible selectors, so in a sense it already has some abstraction
features. Those differ from what we know from other languages, but they are
still very useful and should be exploited.

I was never forced to define important colors more than twice in my CSS style
sheets, usually defining them just once. Maybe my document structures are too
simple to get into trouble - but maybe that's the whole trick.

(i.e. producing less bloat rather than making bloat more manageable.)

~~~
chc
Complexity is not all bloat. For a given set of data with a given list of
goals, there's an optimal level of complexity. More than this and it's bloat —
but less than this and you're not accomplishing what you set out to do.

~~~
vog
There's still a maximum level of complexity for presentations (here: HTML
presentation of a set of data). That level is independent of the content.
Anything above that is just irritating for the viewing persons.

This is especially true for web sites which should at least _look_ as simple
as possible. So in principle, there should be always a way to produce HTML
whose DOM structure isn't too complicated, no matter what the content is.

------
Kilimanjaro
Def, we need def in css.

Def initely

------
mmaunder
Oh cool, another layer of abstraction.

------
whughes
Please, _no_. This is terrifying. Let us browse without JavaScript and in
peace. Please.

~~~
rrhyne
To me that's like saying let us browse without CSS in peace.

~~~
jufemaiz
Browsing without v interacting without may be a better way to view it.

------
oladon
Obsolete isn't a verb.

~~~
portman
Says who?

<http://www.merriam-webster.com/dictionary/obsoleted>

<http://en.wiktionary.org/wiki/obsolete>

~~~
trebor
Obsolete is a verb, but it is a poor choice. A better choice would be
obsolesce, as in: "LESS.js will obsolesce CSS". This is because LESS.js won't
obsolete CSS, but it may well start the industry on the path. Obsolete has a
feeling of immediacy to it, and obsolesce has a feeling of lethargy or a
gradual process which is why it's the better choice.

It's an opinion, take it with a grain of salt.

(BTW, I dislike MW because it takes all nuance out of the language and dumbs
it down to an inexpressive mess.)

~~~
danieldon

      Obsolete is a verb, but it is a poor choice. A better
      choice would be obsolesce, as in: "LESS.js will 
      obsolesce CSS"
    

"Obsolete" is the correct word because it's a transitive verb (eg, [subject]
obsoletes [object]), while obsolesce is an intransitive verb (eg, [subject]
obsolesces).

~~~
GavinB
I would have gone with "Less.js Will Render CSS Obsolete."

