Catalyst brought into my field of the view an easy way to do Perl website development offline. Catalyst generates ./script/myapp_server.pl as part of the project setup. Run the script, connect to http://localhost:3000 in the browser, and there I go.
CGI::Application now has related tools as well, which builds on the work done by the Catalyst team. See CGI::Application::Dispatch::Server and Test::WWW::Mechanize::CGIApp, which both provide enough of a real web server to let you work on your CGI::Application project.
Jesse was just blogging offline web applications. For applications where it's feasible to share the web-code with the client, Perl's solution with Catalyst and CGI::Application has largely solved the problem, leaving only the database sync'ing issue to remain. Some kinds of database sync'ing are simply not practical-- Think of incrementing the a sequence value in both locations and trying to reconcile!-- but for other applications like PDAs, and groupware clients, we know from example there are feasible solutions.
I foresee more web developers using these techniques to deploy desktop applications that are really locally run websites with built-in webservers. It's not too difficult to envision a browser toolkit that provides an interface that looks more like a standalone application than a web browser.
I'm glad Catalyst has helped these tools evolved, but just as I was playing with these offline web servers, as I was reminded why I prefer CGI::Application: The default Catalyst application benchmarked with a virtual memory footprint of 17.4 megs, while an empty application with CGI::Application::Dispatch::Server application benchmarked at 8.8 megs-- almost half the memory usage! Now, that's not a "real world" comparison, but it does illustrate the different philosophies: CGI::Application is the center of more an ÃÂ la carte framework, while Catalyst has more functionality built-in.
