Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Less.js will obsolete CSS

fadeyev.net

Post reply on HN
Print view View original

111–120 of 131 posts

Re: Less.js will obsolete CSS

#111

Post by pyre »

jerf wrote: post #100
nex3 wrote: post #90

Earlier quoted context omitted.

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 reque…

"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…

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.

Re: Less.js will obsolete CSS

#112

Post by rimantas »

benbeltran wrote: post #12

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.

The early implementation of CSS in Netscape relied on Javascript. That was no fun.

Re: Less.js will obsolete CSS

#113

Post by nex3 »

cloudhead wrote: post #101
nex3 wrote: post #79

Earlier quoted context omitted.

Fair enough. I'm running less.js from the command line using node.js on my old-ish MacBook pro: 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 qui…

That's because the parser isn't optimized for compressed CSS. By airing the file out a bit (just adding some double line-breaks), and passing -O2, it goes down to 177ms :)

This is real CSS handwritten by real people. It's not compressed, it's just not in a fully-expanded style. If your parser is slow for reasonably formatted CSS, then your parser is slow. The best case can be as fast as you want, but real-world use is what matters.

For what it's worth, -O2 brings the compile time for github.css down to about 1.5s.

Re: Less.js will obsolete CSS

#114

Post by loup-vaillant »

huhtenberg wrote: post #108
loup-vaillant wrote: post #70

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.

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.

I understand your point of view. But you will agree that a CSS preprocessor in Javascript is a problem:

(1) It's useless. Just pre-process the style sheets statically. No need for PHP, Ruby or any server side dynamic scripting whatsoever. It's simpler, and yields less requirements for everyone.

(2) It exclude users. Not only the paranoid ones that run noscript and adBlock, but also the ones that just don't have Javascript like Dillo users. (Dillo is interesting for old, weak computers.) That's still a tiny minority, but they do exist.

Something useless that exclude users clearly isn't the best tool for the job. Unless punishing noscript users is a feature… Now, of course javascript is more capable than (pre-processed) CSS alone. But the article didn't seem to use those capabilities.

Re: Less.js will obsolete CSS

#115

Post by nex3 »

cloudhead wrote: post #106
LaPingvino wrote: post #34

Earlier quoted context omitted.

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.

The benchmark file, http://github.com/cloudhead/less.js/blob/master/benchmark/be... Which has all the features of LESS in it, and weighs 94KB (3600loc), compiles in 130ms on my macbook pro. I would say that's plenty fast. You can try it out by running `$ make benchmark`

It's impressive that your benchmark compiles that quickly. However, as I mentioned elsewhere, the real issue is how fast real-world code compiles. My benchmark uses real-world code, and it's slow.

It's also worth mentioning that plenty of people who care about page load times would still care about 130ms. It's not as glaringly awful as 1.5s, but it's definitely comparable to the sorts of times under discussion. See http://developer.yahoo.com/performance/rules.html and http://code.google.com/speed/page-speed/docs/rules_intro.htm...

Re: Less.js will obsolete CSS

#116

Post by nex3 »

tlrobinson wrote: post #99
nex3 wrote: post #16

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…

This is a red herring. Any compiler that is implemented in JavaScript can be run both in the browser at run-time (very convenient for developers), or once at deploy-time using one of the many server-side JavaScript platforms (better performance for deployments). In fact this is exactly what we do with Objective-J, and if Less.js doesn't already then I expect they will soon.

I agree. I'm objecting to the implicit suggestion in the article and more explicitly in comments here that this is in fact fast enough for production. Running it server-side is an excellent solution.

Re: Less.js will obsolete CSS

#117

Post by nex3 »

huhtenberg wrote: post #108
loup-vaillant wrote: post #70

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.

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.

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

Re: Less.js will obsolete CSS

#118

Post by nex3 »

jerf wrote: post #100
nex3 wrote: post #90

Earlier quoted context omitted.

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 reque…

"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…

I was assuming compiling to JSON wasn't an option since the point of the post was the usefulness of avoiding a manual compilation step. With such a step, yes, you could avoid all the parsing headaches. I'm not sure how useful it would be to manipulate the JSON client-side, but there are probably a few clever things one could come up with.

I'm certainly not afraid of compilers. I write Sass, so I'm pretty intimately familiar with what's going on. My point was not that compilers are inherently scary and/or slow (although I stand by my original point that if it's compiling to CSS it will always be at least somewhat slower). I was just making the claim that the current speed of less.js is too slow for practical production use.

Re: Less.js will obsolete CSS

#119

Post by cloudhead »

nex3 wrote: post #113
cloudhead wrote: post #101

Earlier quoted context omitted.

That's because the parser isn't optimized for compressed CSS. By airing the file out a bit (just adding some double line-breaks), and passing -O2, it goes down to 177ms :)

This is real CSS handwritten by real people. It's not compressed, it's just not in a fully-expanded style. If your parser is slow for reasonably formatted CSS, then your parser is slow. The best case can be as fast as you want, but real-world use is what matters. For what it's worth, -O2 brings the compile time for github.css down to about 1.5s.

The github CSS is compressed. It's fine to test worse-case scenario, but doesn't mean much.

Re: Less.js will obsolete CSS

#120

Post by rabidgnat »

huhtenberg wrote: post #107
rabidgnat wrote: post #53

Earlier quoted context omitted.

There are plenty of problems with CSS. You can't specify the width of an inline element, for one. That alone prevents a lot of reasonable layouts, like tables. Also problematic is a standards body that ignores this use case! In this case, they protect the writer from over-filling some boxes with more boxes. But that would at least be visible - in this case, the workarounds end up far worse.

> You can't specify the width of an inline element, for one. display: inline-block; width: ... ?

Unfortunately, bad browser support :/

http://www.quirksmode.org/css/display.html

Post reply on HN