Simply defining, a conversion engine is tool that one uses to convert one form of text into another. Here, I am talking about converting plain text to formatted coding. If you want a better idea of what I am talking about, take a look at the excellent Markdown text-to-HTML engine. That is what I use to write my posts, and I highly recommend it to anyone who hates filling up their article with < and >s to make them look good.

Conversion engines are amazing because all the changes happen behind the scenes. What we get to see is what we’ve written in our own special formatting (defined by the engine), and what comes out is perfectly coded text. When we come back to edit, we see it the way we left it. It increases readability and usability. You don’t need to know any code to use such engines, but still get the desired output. Of course, a text-to-HTML engine is a rather measly thing (a rich-editor can do the same), but it’s the concept that is so interesting.

I am beginning work on a CSS-engine, which will take specially formatted plain text document, and output W3C valid CSS. This will be my first time writing a parser of any kind, so I am expecting to run into a lot of hurdles and over-night coding sessions. But the outcome will be worth it, in the form of knowledge, and my first major mass-use project.

I picked CSS as the output because it is the second most repetitive markup that I’ve come across (HTML being the first. Damn you angled brackets!). People sometimes end up defining the same styles for the same elements in multiple classes, which adds to bloat and also throws validation errors. There are things like colours and sizes which need to be re-used, but since CSS offers no system of variables and constants, the tedious look up process is annoying. Compression is my last and most important goal. Just like packed JS files are all the rage, I want to try and reduce the file-size of parsed CSS as much as possible. This will be mostly achieved by grouping declarations, removing white-space and unsupported attributes from element selectors. The result will be well formed and very small CSS output, while keeping your side of the style easy to decipher and change in the future.

I will release a pre-development documentation which will contain all the formatting details, limitations, and specifications in the coming days. I plan on documenting the process, for both self-notes and future reference for anyone wanting to embark on the same journey. Wish me luck!

I like how Google service pages load up faster than others. Most of it can be attributed to their minimalistic design, but if you ever open up Firebug’s console, you’ll see the actual reason.

The good thing about Javascript is that it’s multi-threaded — as far as asynchronous calls are concerned at least. When you make an XMLHTTPRequest call to external files, it forgets about the process and continues while the content is loaded in the background. I’m going to call out Deepak on this, because even though his method is good, the problem is what he points out himself. Different browsers handle the loading differently. Also, it involves DOM manipulation, which restricts your script to the speed of (X)HTML.

With an asynchronous call, we are bootstrapping our scripts. It allows them to load nicely in the background, while the browser continues to render the markup. One they’re done, they will always be executed in the sequence they are loaded. Gives you at least one constant to work with. If your scripts are large, they will take longer to load. Calling functions that are yet to be loaded is always dangerous, which is why you should use fallback mechanisms.

A call to eval() with the Javascript file’s content passed as a string will result in it being ready for use on the current page. You will have to rewrite your code to JSON so that the evaluation doesn’t throw errors, which will not take too much time. Using the jQuery framework, the code can simply be:

$(document).ready(function(){
    $.ajax({
        type: "GET",
        url: "futureload.js",
        data: "ver=1.0",
        success: function(content){
                eval('js ='+content);
        }
    });
});

And the corresponding Javascript file could be:

{
    alert1: function(){
        alert('Greetings from "alert1"');
    },

    alert2: function(){
        alert('Greetings from "alert2"');
    }
}

Then call js.function-name() to display the required alert. Using the same skeleton, you can complicate your Javascript file while not losing out on page load times.

Your mileage might vary, and this is definitely the wrong way to make something right. But we’re all for hacks, aren’t we?