* frontend: How will you translate the input (source) program into the program's internal presentation (often, this is an AST)? You know that this can be done with a parser or with an embedded DSL, as in rake or protovis. Some languages may not need an internal representation.  The decision to go with a parsed input rather than an embedded DSL was not one we made lightly. The primary advantage of the embedded DSL is simplicity; it doesn't require us to go through the trouble of writing a grammar for the input. However, that simplicity comes at the price of flexibility; the parsed input can be specified in any format we choose, whereas the input of an embedded DSL must fit into the syntax of the parent language. Considering that the main goal of this language is to provide a clean and simple syntax, restricting ourselves to the syntax of the parent language is clearly counterproductive. 

 We considered using both an AST and objects for the interpreter's internal representation of the input. In the end, we decided that objects are better suited to the data. Our input is not going to come in the form of a deeply-nested hierarchy, so the tree structure is unnecessary; the input is a collection of data points, each of which has a set of associated attributes. This lends itself very well to object representation. * interpreter/compiler: how will you interpret or compile the language? Is there a prepossessing step, eg translation from AST to bytecode? If you want to generate code, what is the target language? Why did you choose that language?  The interpretation will be fairly straightforward; the interpreter will go through the object representation of the input, generating the appropriate CSS and HTML as it goes.