Comment by jerf | Hacker News Reader

Comment by jerf | Hacker News Reader

Parent Full thread

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

Reply on news.ycombinator.com