There are two most common types of frameworks: server-side and client-side.
Server-side frameworks (SSF) run, as their name suggests – on the server, and are there to help with the business logic and data of your web application. They do database abstraction – ie. persistance, help with presentation – ie. templating and also with caching, authentication etc. They come in every flavor aka. dynamic language imaginable. Some come with their own webserver, as RoR or build on existing webservers in the same language (as the Java ones do) and some just come as a CGI which run in a “normal” webserver like apache or IIS. Speaking in terms of the MVC pattern, SSFs help with all 3 – the M, the V and C.
Debugging server-side code is a little bit tricky since it always involves a webserver for the page-flow and state. Debugging single scripts just does not make sense. Thankfully most dynamic languages nowadays sport a debugger (even if as a separate project/module/plugin) so there’s no need to rely on the ol’ echo technique anymore (I know, I know, you still do – and so do I). It is, however, a lot easier if the framework comes with its own webserver so that you can execute, debug and examine the output all from within a single IDE (like eclipse). Some (RoR) even offer a command-line, interactive shell to quickly test the effects of certain commands or actions (that is URLs) without the whole HTML overhead.
Debugging here is even more complicated, since it needs to be done on the client-side in the browser. Not all browsers come with a full-featured JS debugger, mostly just an error-console – which means you are doomed to use the “echo” technique. FF (mozilla) plattform browsers have a JS debugger add-on called Venkmann, but it is not easy to use nor self-explanatory. Apart from that it always involves a round trip of rewriting the JS code (on the server), emptying the browser-cache, reloading the page and then checking what and why it goes wrong: Very tedious.
One silver lining on the horizon is the GWT framework from Google which allows you to write and debug the client-side GUI code first in Java and them compile it to optimized JS. It gives you greater control over the debugging because it allows the execution of the code in ‘hosted mode’ which essentially executes a small Java-webserver on the spot which integrates well with the IDE. In the case of GWT that is eclipse. And well, Java debugging is, as we all know, standard in eclipse. It also comes with some pre-written widgets, i.e. rich interface-elements that are easy to set up and use from your code. The usage of these widgets in GWT (code-wise) follows the Swing usage very closely.
As with all JS libraries GWT makes the assumption that it is connecting/interfacing with a RESTful back-end webserver. So it can coexist with any server-side framework. There are even a small selection of plugins available that can crosscompile models from GWT to SSFs and vice-versa and export the neccessary marshalling code. Normally this is expected to be JSON or XML, although JSON is more widespread.
In my opinion, GWT is a big step in the right direction: simplifying and consolidating web-application development. What we need, and I venture that we will have this some however distant day, is a single IDE for web-development: writing, modeling, presenting, controlling and debugging all in one single place and (preferably) language. So that it can be written and debugged just like a traditional desktop application. I will expand on this more in my last, summary post, but before I can do that we need to take a little detour into the land of the MVC pattern. Come this way!