Other Tools: Why aren't we just using X?

Another way to put it is, what's so different about WebMacro?

There are lots of tools out there that are similar, but different: This page explains why we developed this product instead of using each of the following products.

My purpose here is not to start a war. Each of these technologies is appropriate to a particular purpose--I wrote this document largely as an exercise for myself, to ensure that we weren't duplicating an existing tool.

This document will help you figure out the niche that WebMacro fills in the server side tools landscape, by showing you how it is different than other tools.

Java Server Pages

WebMacro is very similar in concept to JavaSoft's JavaServer Pages (JSP) and template language. There are free software implementations of JSP available as well: GnuJSP and Gnu Server Pages.

The fundamental difference between our approach and theirs is that we have worked with SGML and XML too long to see it bastardized; and we think that scripts written in XML markup are cluttered and hard to read.

The WebMacro template language has been designed to be orthagonal to HTML/XML/SGML markup: you can stick it in a document without violating the standard. It also has a comparatively compact syntax.

JSP does have the advantage of being more standard than our approach, mostly owing to the fact that Sun is a very big company. On the other hand, WebMacro will interoperate with Java Beans, and JSP is built around this idea as well. Thus WebMacro scripts will interoperate with the raft of JSP beans that people will develop over the next while.

It comes down to whether you prefer our compact and XML friendly syntax or the verbose, non-standard (from an XML worldview) JSP syntax.

Apache JServ Templates

There's a good template package available as part of the Java-Apache project.

It has less verbose syntax than Sun's JSP templates. It also uses the <% ... %> markup.

For looping Apache JServ templates, like WebMacro eliminated the concept of an iterator and uses a looping structure called a "dataset" that repeatedly applies itself to a block. The syntax for this in JServ is much more compact and clear than in JSP.

We chose not to use this for primarily for the same reasons as JSP: Using tags to delimit the structure puts limits on what you can express with clarity. Your tags are not as visually distinct from the surrounding text, are more verbose.

There is also a problem of substituting values within the CDATA section of an attribute. It becomes difficult to create valid XML documents. In general trying to use a programming syntax that appears to be too similar to the text it's embedded into seems to create some readability problems.

Server Side EcmaScript/JavaScript

Like the WebMacro langauge, server side EcmaScript/JavaScript implementations work on the theory that you should have a template into which you stick simple programming language statements.

Unfortunately the EcmaScript/JavaScript idea of "simple" is fairly complex if you are a graphics designer--it looks and feels like a full fledged programming langauge, because it is one.

Also, most of the JavaScript statements cannot easily be embedded in HTML. There are too many conflicts between the JavaScript language and HTML, so most of the JavaScript ends up in a separate block.

The EcmaScript/JavaScript approach is likely to suit you if you want to be a programmer and a web designer at the same moment in time. If you are like most people, though, you probably switch gears when you move from analytical programming to artistic creation.

And of course our approach is much better suited to you if you are really a team of people, some of whom are web site designers and some of whom are programmers.

With WebMacro we are not adverse to server-side JavaScript at all: we want to support it in a future version. However, we also want to keep it out of the web designer's face.

Non-Java Tools

There are a ton: PHP, LiveScript, Oracle's server development toolkit, the very important embedded PERL script, and so on.

I am not aware of any tools that have taken an approach exactly like ours in other languages--but there are numerous good tools out there that solve the same problem.

Some of these have tried to invent new programming langauges for you to use (eg: PHP). These are full fledged specialized languages, but they are not as widespread or standard as Java/PERL/etc., and are not as powerful as those languages either.

Our appoach is to let you use a more powerful conventional langauge when that is appropraite; the rest of the time we provide the glue that fits that together with the web page.

Some other technologies are actually more standard languages that have been embedded into web pages. Embedded PERL in particular is pretty enticing--however it too is a non-web-design language stuck in the graphics designers face: PERL can be a pretty messy thing for a non-programmer to have to read.

Also, perhaps you have chosen to use the WebMacro package because you want to use Java on the server side. If you are looking for reasons why you would want to develop in Java:

Of course here are some reasons why you might not want to use Java: Well don't despair--WebMacro will not solve your problem yet, but we are planning to. Future versions will include support for an arbitrarily large number of langauges.

The core engine will still be based in a Java program--but we won't let that stop us from interoperating with Perl, Python, Visual Basic, JavaScript, and just about anything we can figure a way to support.

We know that other languages are frequently better suited to a particular application, and we plan to support that.

Right now, though, if you want to write Java code on the server side, and you don't want your web designer to see it--that's the main problem we're here to solve.

Drag'n'Drop Ra[bp]id development tools

Lots of vendors offer drag and drop tools for web page designers. The idea here is that by using a visual interface somehow the underlying complexity goes away. I have even seen langauges that take the extreme of trying to come up with visual metaphors for iteration and conditional expressions.

In general I don't buy it. It's a hopeful idea, and if someone actually makes it work effectively it'd be great.

But I am convinced that it is easier for a non-programmer to learn a very small number of programming concepts (very small!) than to try and force the current art of programming into a visual metaphor--and subject web page designers to that like guinea pigs.

Our approach is to try and simplify programming constructs down, rather than pretend they are not there. We have simple loops, simple conditionals, and simple variable substitution.

We abandon concepts like "loop condition" in favour of the concept of walking through all the elements of a list. We hope that it is not too much of a stretch for graphics designers to understand what a condition is, so long as we don't resort to complicated boolean expressions.

The price you pay here is of course that your language is not powerful enough to satisfy a more advanced programmer. Our answer here has been to resort to a standard programming language like Java, in its own block, that provides all the tools and power an advanced programmer would want.

We don't want to try and reinvent programming as a visual art any more than we want to try and re-invent Java, PERL, or anything else.


Introduction | Download

api | design | faq | goals | links | license | othertech | quickstart | script | status