Star Script

Simplify Web Application Development

Calling for a New Templating Language

It is almost 20 years since internet entered many people’s life; more than 15 years, since the first online application is created. I still remember the excitement learning CGI and felt the WOW in my heart. CGI was a little ugly duckling that ushered in the new era of internet applications. Quickly, many companies entered the fray and pushed one technology after another. So many, in fact, I found myself constantly learning new stuff just to catch up with the trend. ASP, great idea, great technology; JSP, even better, it is free. PHP came late, hey, it is open source. Ruby on Rail is still young and is experiencing some growing pains. Node.js is the new kid in town. Every time when there was a new technology showing up, I felt excited for a little while and then the excitement subdued and the pain of real life came back. So, where is the pain?

Pain #1: brain hurting syntax

I don’t know how you feel it. But I don’t like seeing weird symbols such as “$”, “&”, “#”, “@”, “#”. I spend most of my time using one or two programming languages. For the language I use on a daily basis, I will gradually get used to its syntax, and feel less annoyed over time. But for languages I don’t use very often, probably once in a few months, looking at those symbols is a real pain. They mean different things in different languages. I just can’t hold them all in my brain. Every time, when I look at some code in a language I don’t use very often, I will try to guess what it means first, since I have learned it and knew what it meant, right? Not quite. I found myself keep pulling up language tutorial/spec to re-learn those languages again and again. As an extreme example, there is a little language called regular expression. It causes the biggest pain of all. I don’t use regular expression every day. It is something I need to use once in a while. Every single time, when I need to do something with regular expression. I felt very upset. Because I knew I will have to spend half a day or one day to learn it again. It was so annoying to the point, one day, I told myself, it had to stop. So I spent a good weekend some time ago putting up a Regular Expression Analyzer to help me understand the regular expression I wrote in the past. To build the utility, I wrote a regular expression parser in JavaScript that can handle several different flavors of regular expression. I thought, after this exercise, I would remember regular expression syntax better. I still can’t. There is nothing in real life that resembles the special symbols regular expression use. I still cannot remember clearly what those symbols mean after a few months not using it. Let’s face it: special symbols are unnatural; they should be reserved for special, uncommon use cases. When you start using special symbols for common use cases. It makes the entire language unnatural. Can you explain clearly what the “$” sign mean in all different languages such as regular expression, Perl, PHP, JSP, Java/JavaScript, etc? I can’t without googling it first. If you can, congratulations, you certainly have better memory than me.

Pain #2: awkward logic embedding

For simple things, like displaying a label, all templating systems handle it very well. However, when you need to add a little bit of logic, such as conditions, loops, suddenly, you found yourself in a hacking mode. Just pull out your favorite templating system and create a template for a table. I bet you will notice a few things looking awfully hackish, such as putting logic inside comment block, having special tokens to trigger some logic, place holders inside some special decorations such as “{}”, etc. They look hackish, because they are hacks. For all existing templating systems, there is always a distinction between first class citizen and second class citizen. When programming language is treated as first class citizen, HTML is treated as a unstructured string. When HTML is treated as first class citizen, programming language goes into the comment block. Some brave souls invented the idea of using XML tags to capture programming language structure, say tag <ns:if>. It is far from satisfying. The basic things like variable declaration, assignment are always missing or awkwardly implemented. How do you build a programming language structure without getting the basic foundations setup? Mixing program and HTML together is like mixing water and oil. They just don’t mix well.

Pain #3: context switch

Context switch is expensive, at least for me. When I have to switch from one programming language to another. It takes some effort for me to ramp up productivity. If I only switch context once a day, it would not be a problem. If I had to switch context constantly, like in every few lines of code. It becomes a real problem. JSP/JSF is by far the most advanced templating technology. It has a lot of advanced capabilities. However, to use it, you will have to deal with a lot of complexities and constantly switching between HTML/XML and Java. This is on top of the complexity of dealing with CSS and JavaScript. Switching between multiple languages also make trouble shooting and debugging quite a bit more difficult.

Pain #4: glueless

With the complexity of existing templating systems, you would expect enough power to glue various parts of a component together. For example, when you want to use a jQuery component, you typically need to include some JavaScript, some CSS, and write some other JavaScript linking code. You also need to put a few HTML tags in the page. Unfortunately, many templating systems today simple lack this capability. For systems that do support it such as JSP, making it work is very complex. When you don’t have glue in your toolbox, as you can imaging, it will be very difficult to build component. When you don’t have component, it hinders code reuse.

Pain #5: lacking code reuse

You cannot always build things from scratch. To build large systems, you need to leverage other people’s work. In fact, I would say that code reuse is the single most important thing for building large software systems. This is because, in order to reach higher, you need to stand on the shoulders of giants. Now, let’s look at what we have for building web applications. There are some good JavaScript libraries, such as JQuery. Associated with them, there are some JS based component libraries. If you look at the server side, there are some Java, Perl, PHP utility libraries. Beyond that, you are pretty much on your own.

Ok, I have complained too much. What I would like to see is a templating language that is clean, as intuitive as markup language yet as powerful as a real programming language, easy to learn, easy to build component out of it. I am very passionate to make it a reality. If you have any suggestions, please feel free to comment.

Advertisements

3 responses to “Calling for a New Templating Language

  1. sirrotn October 18, 2011 at 6:32 pm

    Hi there,
    this is very funny. I’m trying to rollout a template engine called Snippetory that addresses exactly the same pains.
    The syntax is very simple and can easily be swichted to fit the surrounding source.
    To avoid the logic embedding it works with passive templates. The logic stays in java classes.
    The combination of switchable syntax and passive templates supports useable templates. This in turn let’s me preview the template and I can work for a longer time on the template without any need to switch, and write the logic on the other day.
    At glue less I’m not really sure if we mean the same. Maybe you check out my page frame example and tell me.
    Many of these features help to reuse code.

    Would be fun to here from you.
    Have fun,
    Sir RotN

    • starscript October 18, 2011 at 10:06 pm

      thanks for your comment. glue, i mean the template system should allow multiple parts of a single component to be organized together. if i want to use jQueryUI.accordion, like the below example:
      http://jqueryui.com/demos/accordion/
      you will have to do several things, like adding a div element on the page, including bunch of JS/CSS resources, write some custom JS code to link things together. once you split one component into multiple pieces, it no longer feels like one thing. it becomes harder to code and maintain.

  2. sirrotn October 20, 2011 at 6:08 pm

    Yes, you’re absolutely right. To me this point got so self-understanding, I forgot to mention it. Templates are repositories in Snippetory, too. Which means you can store template code where it’s most easy to maintain and use it where ever needed. This is as simple as

       componentTpl.get("links").render(page, "links");
    

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: