Hacker News Reader

Comment by nex3 | Hacker News Reader

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.

View on HN

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

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.

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

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.

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.

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.

> Or does your processor natively execute Javascript text?

Even better: Or does your processor natively execute HTML text?

The less compilation, the better.

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.

The first load is the important thing: it's when people first see your website. I've done plenty of speed testing of less.js, and on large CSS files it's seriously slow. I'll post the exact numbers elsewhere in the thread.

less and sass both allow you to compile to css. The live, in browser compiler is just intended to speed up development.

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, no CSS pre-processing, LESS will handle it live."

No mention that that would be ineffective for a production site. In fact, he claims that live processing won't have noticeable lag, which is just false.

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.

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

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.

No it's not. Look at it: it's one-selector-per-line, which is a very common style for handwritten CSS. If it were compressed, it would have no line breaks.

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

As it's cached, it's only the first load that will have the lag. I'd guess it will be quite small as well. If the CSS makes heavy use of mixins and the nesting ability then the lag may even be smaller than the time to transfer the compiled CSS.

Maybe.

First load is where it counts! This is when users first see your site: their first impression. This is an important time that should be kept as fast as possible. Subsequent loads, for most sites, are likely not as important speed wise.

Remember, we have to design our sites as if the user is poised over the back button.

I can imagine a scenario where the bandwidth is so slow, and the client CPU is so fast, that theoretically sending a small file that is expanded into CSS would result in a faster page load. The use of JS Web Workers might further this.

In addition, with more mobile internet providers capping monthly usage, every byte counts.

I'm assuming that these CSS compilers generate larger output CSS files than their input.

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.

I agree with your last point, but things like extensive jQuery and TypeKit usage are demonstrating there's an appetite to do a lot of semi-essential rendering and event processing in JavaScript nowadays. I can't wait to see some benchmarks, but I can't imagine Less.js would affect page load times as severely as Typekit seems to sometimes.

Reply on news.ycombinator.com