Star Script

Simplify Web Application Development

Monthly Archives: October 2011

Templating Programming Language

Usually, people use the term templating language and programming langauge separately. Templating language refers to the language used by a template system for building online applications, such as JSP/ASP. Programming language refers to the imperative language that is used to build business logic, such as Java/C#/PHP/Ruby. They are like Oil and water that does not mix well. Templating programming language is the combination of the two. You can use it to directly write web pages, or write business logic. All in the same language.

A templating programming langauge should have the below characteristics:

  • Taking arbitrary input: this is a major feature for templating language. Programming languages are usually very picky on what input to take on – only syntactically and semantically correct input are compiled and executed. Templating langauge takes a different approach. It usually can process arbitrary input. Actions are triggered when certain patterns are encountered in the input template. When there is no such pattern, the template is output directly without any change. This is a major convenience for templating language users. It allows the user to start writing template right away without any learning. They can delay the learning until they actually need to do certain things such as creating a placeholder and replace it with a value. A templating programming langauge should inherit this usability feature.
  • Having all major programming constructs: all major programming constructs, such as variable declaration, expression, assignment, conditional statement, loop statement, functions are useful in a templating programming language. Just look at all the advanced templating systems. They have all of them. Without loop, how do you render tables? Without conditional statement, how do you greet user based on their title? Once you start adding conditional statement and loop, all the other basic structures such as variable declaration, expression, assignment have to be added as well.
  • Linking between template structure and programming structure. It does not make sense to combine two types of languages without having a mechanism to make them interact and work with each other. Ideally, the linking should be deep and cohesive.
Advertisements

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.