Imagine, if you will, a Content Management System (CMS) that uses Cascading Style Sheets (CSS) to make things look pretty. I'm told they are all the rage these days; even I wrote something using CSS with what called itself DHTML back in... 1997 or so.
Anyway, so web developers used to focus on making pretty things, but in doing so came to realize that it'd be useful to apply certain logic constructs, transformations and a little of the usual this'n'that. And thus, following the general rule that another layer of abstraction cannot possibly hurt, people came up with CSS metalanguages, such as SASS and LESS. That is, after processing the input these "languages" generate valid CSS as output. (Some people like to call this "compiling", but in my funny little world "compilation" has to do with translation of one language into a lower-level language such as assembly or machine code. Oh well.)
The general development/deployment process then seems naturally to be something along the lines of:
Well, here come the web developers again, with their desire to make pretty things. Turns out, it's frequently not entirely unreasonable to wish to perform the LESS=>CSS translation on the fly, allowing your developers and designers to build dynamic templates and such that get your approved-prettiness stamp of approval. And so you start down the road of dynamic translation (or "Just-In-Time (JIT) compilation").
There are a number of different ways that you can perform this JIT translation; two common ways are to use either Rhino or Node.js. If, to come up with an arbitrary example, you were running your web application inside of tomcat, then choosing Rhino would seem to make sense, since you already have the JVM loaded.
Turns out, Rhino sucks donkey balls when it comes to performance. Running a node.js webserver alongside your tomcat and have your application interface with node.js over HTTP is by an order of magnitude faster. So your process flow is then:
But now things are getting interesting: people realize that it would be wonderful to let your users supply their own stylesheets. Let them monkey around with the layout to their heart's content - what's the harm? It's just CSS, static text, right?
Look back at the process flow above and think about where content comes from and where it executes. If you allow users to supply their own LESS, you then end up executing user-provided code on your machine!
But, but, but... LESS only allows you to do a few minor things, it's not more than a bit of syntactic sugar on top of CSS, right? Well, I'm afraid the answer is: no, that is not quite correct. Here are a few things to be careful about in this context:
(It should be noted that it's quite likely that the same problem currently exists with the Rhino implementation. There, it's just a question of what functionality is exposed by Rhino and what can be done within the Rhino context. Since Rhino runs within the tomcat/jvm context, that might actually be even scarier, but I have not looked into this.)
Well, I for one know what I'd prefer, but it's rare that I get what I want. I really miss the days where an HTTP server was an HTTP server and served you a static file that you could hunt down and inspect on the server's filesystem...
February 27, 2012