Choosing a web technology

When I first started web development, which would have been around 1997 or 1998, writing web-based applications was not pleasant, and the choices were slim. You generally had to use CGI, using C or Perl, although some alternatives were being developed at that time, many of which have become major frameworks today.

For the most part, the successful frameworks, with one exception, have recognized that programmers do not make great UI designers, and UI designers do not make great programmers. I've worked with people who do fantastic jobs on the UI design front, backed with the most hideous, poorly written, unreliable, difficult to maintain, junk code on the back-end. And, well, I'd have to admit that while my UI work of late has been better, my early attempts were somewhat limited.

So, says the majority of modern frameworks, what you need to do is separate the application logic from the HTML. Different systems have achieved this to different degrees, but most now at least make a passable effort, if only by using a system of HTML templates, in which code can be embedded. A UI designer need only create the HTML templates, knowing what hooks to use to bring up the application specific logic.

Let's go through four popular web development systems, in my mind from least successful to most, and explain what's going on.


ColdFusion

ColdFusion is, well, "interesting". The system pretty much goes against the logic described above, taking the view that the UI designer should be the programmer, and designing a "programming environment" that's supposed to be familiar to anyone who can mark up HTML. And in some ways that explains its success, many UI designers love ColdFusion because the concepts are easy for them to understand, allowing them to handle the entire product development themselves.

Add additional hands, especially a split of programmer and designer people, to a CF project, and it starts to show its flaws. ColdFusion requires the same people handle both ends of the project, with a certain amount of logic embedded on every page - indeed, every CF page is by default a program. You can't design something in an HTML editor and have it run in CF without making significant changes.

And the advantage for designers, that the "code" syntax is similar to that of HTML, is a massive handicap when you put a CF project in front of a programmer. CF's native code format is difficult to read and follow. While CF also supports a more programmer friendly syntax, that syntax is a bolt-on, and so any project started by a person who used the HTML-like syntax will contain a large amount of that code that needs to be maintained.

There are workarounds for CF's issues. The major successful CF project I've been exposed to used web services to abstract as much of the programming logic as possible, ensuring the front-end only contained the code that was absolutely necessary. I still wouldn't have used CF, but it meant a UI designer could be involved who would have otherwise had issues with a different environment.

CF also, for what it's worth, has other issues, the major one being that the only complete implementation of the system is proprietary, and has licensing issues. It's hard for me to think of an occasion in which I'd recommend the use of ColdFusion for a new project, but others would.


PHP

PHP is, like ColdFusion, an established web application development system with a long history, based around a custom programming language. Unlike CF, PHP makes no attempt to provide a UI designer friendly programming system - PHP scripts look similar in many ways to Perl, a language notorious for its confusing, punctuation-based, syntax.

However, PHP changes things around in one important respect: PHP pages are, by default, HTML. Code is embedded in the HTML where needed. This critical difference makes it easier for programmers and UI designers to work together: UI designers can develop and prototype HTML templates, and programmers can modify those templates with embedded PHP mark-up, with the integrity of the HTML remaining.

PHP is free software, that is, there are no licensing implications from merely using it, and modern iterations of PHP have moderately advanced programming features. It's not a bad system, not ideal, but it works fairly well.


JSP

Early in the history of Java, there was some debate as to where the language was going and what it would be most suited to. After an abortive effort trying to promote it as a solution to cross platform development of desktop applications, its real niche as an enterprise-class secure language started to become more apparent. Sun developed various standards for web development, starting with two technologies, servlets and JavaServer Pages (JSP.)

While servlets took a strictly programmer-oriented approach to web development, similar in some ways to CGI, JSP took the same template approach that PHP was taking, and took it further. JSP pages are, like PHP, standard HTML pages with embedded Java. But JSP is a substantially more advanced framework, oriented towards larger, more difficult to maintain, applications. In particular, it is easier for a UI designer to have complete control over the HTML generation, maintaining the HTML template system, while handing over business logic tasks to a programmer. JSP achieves this in a variety of ways, allowing programmers to work at different levels with the HTML, from embedding raw code on a JSP page (as with PHP), to providing tag libraries (custom "HTML" tags the designer can embed in the page, whose logic is controlled by the programmer.) Because the programming side is Java, programmers have a wide variety of options and can make use of a well supported, modern, scalable, environment with a huge amount of support.

JSP is rarely used as-is. For all of its advantages over something like PHP, Java's infamous over-engineering frequently makes it hard to do the simplest things, and as a result a large library of third party frameworks have come into being to make it easier to develop full applications. But JSP is an extremely flexible system, and coupled with good Javascript libraries like GWT and jQuery, it's one of two I'd generally recommend for all but the smallest of projects.


JavaServer Faces and Facelets

Originally built-upon JSP, JSF has come a long way from its origins as an attempt to make an MVC-friendly Java framework. Early versions were, frankly, abysmal, notorious for inheriting Java's over-engineering and bureaucracy, undermining the principle advantages of the framework.

Over time, the major issues have been fixed, with JSF 1.2 introducing "Facelets", a replacement for JSP that more closely matched JSF's requirements, and a large collection of major improvements with JSF 2, that allowed Facelets to be built around HTML templates, and that undid massive amounts of the bureaucracy associated with JSF using a system of attributes.

In some respects, it's better to pretend JSF didn't exist until JSF2. So let's do that and discuss what JSF2 has over JSP.

With JSF2, pages are marked up using standard HTML, as with JSP and PHP before. However, standard HTML tags that need to be manipulated in some way, such as form controls, can be linked to internal JSF2 controls using a custom "jsfc" attribute, making the link between the original HTML and Facelet version even more transparent.

But that's not the major advantage. Whereas the systems mentioned previously simple allow code and HTML to be mixed, JSF introduces the concept of a "view", which matches closely the user's perception of how a website is navigated. Each view consists of an HTML template, and a set of "beans" (high level Java objects) that link to different fields on the template. When the user updates things - changes the text on forms, hits submit buttons, etc - those beans are similarly updated, and the beans are also asked whether the user should be directed to a new page (or view), or the same template with updates (ie the same view.)

This is a much more high level approach than JSP, and from a split-of-development standpoint, it makes for a much more scalable system. Programmers and UI designers can easily understand each other's work, with the UI designers doing barely any programming, and the programmers putting together reusable interfaces to the business logic. And (with JSF2, at least) development is faster - the developers do not have to concern themselves with parsing the results of every form submission, they simply have to put together the containers, the beans, that contain the data. Even if no web designer is involved, JSF is a great platform.

It's a staggeringly powerful system, and I suspect that if it wasn't for earlier releases, JSF2 would be the most popular Java web platform around. As you've probably figured out by now, JSF2 is the other of the two frameworks I would recommend (the first, as I said earlier, was something JSP based), but you'd probably want to know why I might recommend a JSP solution over a JSF solution.

JSF's Achilles heel is that it is entirely session and form based. Navigation must be done via submitting forms. The results of those form submissions modify the beans associated with the current view or session. This means that pages cannot be "spidered" - that is, a JSF application is pretty close to impossible to put into a search engine, and  users cannot bookmark pages. There are workarounds, such as PrettyFaces, but they, to a certain extent, aren't really designed for the kinds of applications you'd want JSF for in the first place.

If I was writing a Javascript-heavy interactive application where much of the logic is embedded in the scripts, there'd be little reason for me to use JSF, which would mostly get in the way. That's not a hard and fast rule, but it works as a generalization. And if I was writing something like, say, a retail front-end, where each product has its own product page, I certainly wouldn't want to use JSF, and JSP would be fine for those applications.

Conversely, if I'm writing an actual application, like an airline reservation system, or an Intranet-located front-end to a database, JSP would work, but JSF would be easier to maintain, and easier to work with.


Conclusion

In the end, there's a certain comfort factor involved, and its hard to get people used to knocking up quick and dirty tools using CF or PHP to move to a more robust, powerful, system. But I must admit, after this long in the industry, it's hard for me to recommend those kinds of systems, even for the "quick and dirty" tools. Java provides two extremely good, robust, options for web development, with features not present in CF or PHP, that suit team work and rapid development practices. So if you ever commission something from me, and want to know why I'm using JSP or JSF, you now know why.