Hacker News Reader

Comment by callahad | Hacker News Reader

The current version of Less is really impressive. It's written in JavaScript, which lets you do crazy things like:

  <link rel="stylesheet/less" type="text/css" href="styles.less">
  <script src="less.js" type="text/javascript"></script>

Since it's a superset of plain CSS, both the migration and the learning curve are really pleasant.

View on HN

It's a little absurd to about the simple changes / features necessary (variables? nesting? c'mon) to make CSS bearable again (if it ever was).

Then you take a look at some of the additional goodies - fadeout(), desaturate(), etc - that have been included in the most recent release, and you wonder how you ever kept your color palette organized before.

Less has prevented me from wanting to claw my eyes out during a recent round of frontend work - just for that, I'm incredibly grateful.

Why would you want to do this on the client and slow the whole site down? I can understand (though don’t personally want to use) a server-side preprocessor, but doing it in realtime on the client seems counterproductive.

And what? I’ve just checked out the minified version of less.js and it clocks in at 32kB. Seriously?

I think the idea is to use a pure JS implementation of CSS for debugging/dev, and do prerendering of a minimal CSS file before deploy.

Why do you say that doing this on the client would slow the site down? That's counter-intuitive to me. I'm trying to push everything I can off to the client (client machines seem pretty good) in order to keep things on the server speedy- but it's my first web app, so I'm new in this space. Thanks.

On mobile browsers, the speed at which the javascript interprets your data may actually be slower than sending the pre-interpreted data over the wire. Even on 3G.

If you do it on the server you do it once (when you deploy), if you do it on the client it happens every single time.

It's the opposite, I recommend you check out the work of Steve Souders, his blog and his books (http://stevesouders.com/). The general idea is that the server is going to be speedier (through a combination of hardware than caching) than the user's machine. And there are a lot of old machines out there.

Souders estimates that around 80-90% of a site's slowness has to do with the time it takes for the browser renders the page, js slows that down.

Thanks for the link. Browsing "Even Faster Web Sites" he cited 14 rules from the first book ("High Performance Web Sites") in the preface. Rule 1: Make Fewer HTTP Requests. I guess this is what I had in mind. I have a request get the data, but how I allow user to render it different ways. So the local rendering is done in JS.

I'm still building, but it look like I better give this a second look.

I'm also in the education space, so where there are crappy machines there are also likely crappy networks.

Reply on news.ycombinator.com