Excellent critique. We have been waiting for this.

Improvement in screenshots: at the bottom of this page

On to the crux of the biscuit:

...you spend much time explaining what Rui does, but you don't spend much time giving concrete examples of why I would want it...

For some reason we expected that everyone has done both desktop + web UIs, and would immediately see why Rui is useful.

...take a problem and show me why Rui is a good answer. Walk me through the problem step by step and then compare and contrast the Rui solution to alternatives...

Let us compare Rui vs. existing Perl web app technologies. We will compare it to a CGI + Template Toolkit solution. This is pretty much the best that Perl can offer for web UIs.

The application is a simple contact manager. It is the demo project included with the distribution. The use cases are:

1. Create contact
2. Remove contact
3. Change contact name, phone, email

We will ignore persistence, so that we can focus on the UI stuff. The model will be plain old Perl objects. They could be persisted with the amazing Tangram, or even Storable. The domain model for both versions is:

1. Model::PhoneBook: entry point object. Keeps a collection of all contacts
2. Model::Contact: model of a contact, with name, phone, and email.

Web Application

We have two pages:

1. Contact Manager: shows a list of all contacts. Each contact is shown with 2 links: edit, and delete. There is also one link for creating a new contact. Hitting edit/new sends you to the contact editor, hitting delete removes the contact and refreshes the list.
2. Contact Editor: a form with 3 fields- name, email, phone. There are 2 buttons: apply and cancel. Both send you to the contact manager.

We chose a design which is typical of the current wen UI situation. There will be a Perl class for each page. They will use TT2 templates for generating the HTML. They could be CGIs, mod_perl handlers, or some kind of view object dispatched by a front controller. This is how they work:

1. Get the HTTP request and translate it into an application event (new/delete/edit/cancel/update)
2. Translate the event into a set of method calls on the domain model, read the form result values and set them on a contact
3. Now that the request has been processed, find the page that handles the response, and call it
4. Generate data for the template, interpolate it, and return the HTML to the client

Some of this work can be done by frameworks such such as Mason, but as you can see on this page, it is still a very strange, HTTP/HTML centered, way to build a UI. Especially when compared to desktop UI frameworks like WxPerl.

Rui

Screenshot here. We have 3 classes- two views and an application:

1. View::Contact (source): shows 3 text fields for editing a contact
2. View::PhoneBook (source): shows a toolbar with new and delete buttons, a listbox of all contacts, and a View::Contact for editing the selected contact
3. Application::PhoneBook (source): setup the model and create the PhoneBook view

Comparison

1. Checkout the source code links above. With Rui it is easier to create quality code. Web apps force the developer to slave under the tyranny of the HTTP request-response cycle, and to worry about producing HTML markup. These implementation details have nothing to do with your UI requirements. Rui feels like a desktop UI framework, just like Gtk or WxPerl. As the UI gets richer (as all UIs do, unless they die), the difference between developing a web UI vs. a desktop UI increases.
2. With the web app we had to write in Perl, TT2, and HTML. With Rui there is only Perl. As web applications evolve, they all eventually require Javascript to increase usability. With Rui there is still only Perl.
3. Layout: Rui uses layout managers. Widgets resize automatically when the window is resized, you can easily align widgets, and there is a splitter between the list box and the contact editing form. HTML layout is horrible, unless you want to read mind boggling words from the W3C, find out what your browser supports from all this, and then write resize handlers in Javascript.
4. Bandwidth: with the web application, the entire list of contacts is sent to client on every other event. Rui only sends the UI deltas. The web application also resends the buttons, forms, and labels, with every event. Rui will never send more that 50 byte per event in this application. You could use frames for better control of bandwidth, but that complicates other things.
5. Reuse: it is hard to reuse web application artifacts. Compare the number of PerlTk widgets on CPAN (stopped counting after 10) to the number of web application widgets available there (?). Despite the fact that there are probably 10^2 - 10^4 web applications in Perl for each single PerlTk application, I could not find an HTML directory tree widget.
6. Usability: the winner is obvious. Which is more usable: Hotmail or Outlook? You could increase usability using fancy javascript, but then you would just be recreating Rui. And recreating it again, in the next application you develop. Have you ever seen a web application with an Undo button? This humble button has been around for some time, almost all desktop apps have it, and humans are known to make mistakes. Current web app technologies suck for rich UI work. Rui sucks less.
7. State: as the application becomes more complex, the developer will have to think about keeping session state. She is expected to work with a session object. CPAN modules help (CGI::Session), but they have to be learned and used. In desktop apps you dont think about state at all. Its just there.

And we could go on. For links on the issue of web vs. presentation server see the Rui related page.

Web applications are a hiccup in the evolution of rich UIs. They are excellent for things like PerlMonks.org, but when the UI grows, desktop UIs are the way to go. With Rui you can write desktop apps that deploy to the web.