Disadvantages of using presentation-layer frameworks

Since JSP was introduced in 1999 to the Java world, many web presentation frameworks have come and gone. But IMHO, none of them work well for medium-large sized projects with medium-large sized teams. Here are my thoughts on why this is the case:

1. Client-side HTML developers and server-side Java developers think, code and debug differently: When they are pushed to a common platform such as JSP, JSP, Wicket or GWT, they don't like it.

   • For instance, a type system is very useful for a server-side developer who typically maintains a large code-base with complex dependencies. But this is not true for the HTML/Javascript developer who works on smaller and relatively-independent code-bases.

   • Similarly, a fast edit-test-debug cycle (sub-second) is critical for client-side development because the right look-and-feel takes time a lot of iterations. But the edit-test-debug cycle can be slower (seconds, not minutes) for server-side development.

   • Hence, client-side developers like light-weight tools and dynamic type systems. Whereas (old school) server-side developers like IDEs that enforce static type systems, integrate with build tools, and help with tasks like unit testing.

   • So the idea of a common code-base, like JSPs, facelets, or widgets, that generates both client and server-side components is not good in practice.

2. HTML/Javascript is here to stay: The idea of having a meta-language that compiles to Javascript and Java sounds good in theory. But as a practical matter is it hard for these tools to keep up with the entire HTML/Javascript community. With the fragmentation on server-side technologies (Java, .NET, Groovy, PHP, Python, Ruby, Scala and so on), it is hard to envision skilled client-side developers specializing in such meta-languages.

3. Control over the initial HTML response is important: Search engines look at the HTML, not the final DOM. So toolkits that heavily rely on DOM manipulation (like ExtJS) and take away your control over the HTML response are not helping your site's popularity.

4. Control over URL and GET/POST parameters is important: The URL structure of your site is your contract with the rest of the Internet. The GET/POST parameters are a contract between the client and the server. Presentation-layer frameworks that automatically generate your URLs (/blah.jsp) or form parameters are going to make the transition from one technology to another difficult.

5. Control over post-load client-server requests is important: Some presentation layers hijack the communication between client-side widgets and the server. However, such asynchronous communication happens over the web and must be optimized for performance and security. Furthermore, WebSockets offer an alternative to XMLHttpRequest for two-way client-server communication. RMI WebSocket is a simple library that allows a Javascript client to make remote-method calls on the server, and vice-versa.

6. Templating helps, but composing is better at simplifying response generation: Replacement of placeholders such as $user is useful in generating responses. However, when dealing with complex pages with 1000s of tags, it is hard to lay out the entire HTML structure in one template. While includes are a solution, they don't follow the same containment rules that the HTML DOM follows. HTMLSplicer offers a more rigorous set of rules to compose complex documents from simpler ones. That said, it can be used in conjunction with a a template engine like Apache Velocity for better productivity.

7. Maintenance effort: It is easy to convert the first version of a static HTML page to a JSP or a Java class (facelet, tag-lib, etc.). But after that the original HTML is not authoritative anymore, making subsequent changes difficult due to a much slower edit-test-debug cycle. With HTMLSplicer, all DOM elements derived from static HTMLs will continue to remain in static HTML files. Only the dynamically generated tags would have to be rewritten. Even then, the rewrite would be based on the example code available in the static HTML template.