Comparison

Comparison Criteria and Comments

The table above compares Dynamator with popular Java technologies claiming to separate program logic from static content, using the following criteria:

HTML purity and validity

Can the technology use pure HTML without the addition of server-side program logic? Can someone knowledgeable only in HTML and web applications in general develop and maintain HTML templates that can be used without modification by this technology? Given an HTML marked up to use this technology, would an HTML validator consider it valid?

Dynamator and XMLC use the same HTML interface, leveraging the HTML standard. Tapestry is nearly pure, but requires a non-standard attribute. The others aren't even close.

Architectural neutrality

Are web applications that use this technology free to choose any server-side presentation architecture without constraint? (Note that a negative in this category is not necessarily a bad thing, if you can commit to a single architecture across an application portfolio.)

With a much larger scope than any of the other products listed, Tapestry is on the opposite end of this spectrum from Dynamator, which is a small tool that focuses on doing one thing without imposing architectural constraints.

Supports non-web applications

Can the technology be used with applications that run outside a servlet container? Can the technology be used for a command-line application without mock servlet scaffolding?

Dynamator, Velocity, and XMLC can be used with batch programs for document generation.

Language independence

Does the technology assume Java, or can it work with other languages as well?

JSP theoretically supports multiple languages, but in practice works only with Java. Because Dynamator is specifically designed for use with multiple languages, it can supply a degree of consistency to a multi-technology portfolio. For example, Dynamator can be used to generate JSP, servlets, and XSL.

Freedom from run-time components

Is it possible to run an application that uses this technology without deploying a technology-specific run-time library?

Dynamator doesn't require any run-time library, because Dynamator executes in the development environment. Generated pages or programs stand on their own. This makes for a simpler execution environment, simplifies debugging, and reduces tool dependence. If you run into a problem with an output library component, you don't have many options. If you run into a problem with Dynamator, you can always tweak the generated source code.

Efficient run-time

Is the technology as efficient as a hand-coded program containing out.println statements?

All of these technologies claim to be "efficient enough". But it's hard to match Dynamator for efficiency, since it has a run-time overhead of zero. (Java code generated by Dynamator may actually be more efficient than a hand-coded program that uses string concatenation.) This is one of Dynamator's biggest advantages over XMLC.

Note: Even though they appear as competitors in the chart above, Dynamator can generate JSP (scripts or taglibs) and Velocity. Although it's often better to just generate straight Java.