Java Web App Framework Millstone 3.0 Released

idot writes "Millstone 3.0 is a java LGPLed library for the development of networked applications. The developer doesn't have to deal with HTML or individual pages, but rather writes a very swing like continous client application. A terminal adapter converts the abstract UI together with a Java Servlet container to the desired themed client side code. In case of Web applications HTML complete with or without JavaScript. Press release millstone home page complex go example game It seems to be a very mature framework, whose first two iterations were used only internally by the developers. It will be interesting to test this library against JSF, tapestry etc. in terms of developer usability and scalability."

Comments

Clever but possibly misguided

[vbweenie]

If a calculator app which has to make round trips to the server every time you press a button is meant to be a representative demo of this application, then my response has to be: no thanks.

I tried a couple of other demos on the site, like the treeview control which seemed to need to go off to the server every time you expanded a node. Responsiveness is a key issue in usability: anything slower than PDQ (Pretty Damn Quick) ramps up the end-user's frustration levels and makes the interface feel clunky and hostile rather than intuitive and friendly. All of the stuff on their site looked great, but it handled like a pig in treacle.

Maybe they're suffering a slashdotting right now, but that actually doesn't excuse them: if the responsivity of individual elements of your user interface depends on the responsivity of your servers, then the usability of your site is - to my mind - unacceptably fragile.

Is it possible that the developers used this primarily on a small LAN or even spent their time pointing a browser at localhost, and never considered how it would feel to be using it over the web? Surely they must have load-tested it? Surely they must have thought, "hmmm, so that's why client-side scripting was invented"?

Other people agree with you

[RhetoricalQuestion]

I still have my doubts about the whole approach, but this is to some extent an ideological issue (HTTP/HTML for complex real-time client-server interaction just feels wrong to me) so basta for now.

You're not the only one who has doubts about this approach.

Because everything old is new again, many companies are starting to build hybrid J2EE systems which have a Swing GUI as a front-end instead of a broswers. The advantage is (over traditional client-server) that you can have the scalability and transaction-safe benefits of J2EE on the server, but the fast responsiveness and better UI of a GUI on the client. (As well, you can still create purely serverside applications where it's appropriate and reuse the same infrastructure.) It's far fewer roundtrips, since the client only needs to pull or commit data from the server, but can perform all the interim data manipulation and UI work client-side.

To extend your calculator example, imagine a mortgage calculator in a bank branch. The calculator would only need to talk to the server when the bank employee pulls up your customer data, or commits any changes. However, before making changes, you as the customer might want to see how much faster you could pay off the mortgage if you increased your payments, or put in a bigger down payment, or tried a different interest rate plan, etc. All of that should be calculated client-side -- there's very little need to make several server roundtrips for these temporary calculations.

As well, the bank could use that same back-end infrastructure to set up a website to allow you as the customer to check the status of your mortgage and your payments. Customers wouldn't be the same kind of power-user that the bank employee would be, so the number of roundtrips is somewhat less of a problem -- as well, the web version could be a simplified version of the GUI version.

Sun has actually addressed this (they sometimes call this architecture rich-client J2EE) through the JNLP spec and its reference implementatation, Java Web Start. Personally, I think JWS itself has limited use, but the architecture of the rich-client system is nonetheless pretty sound.

DISCLAIMER: I haven't looked at Millstone. I have spent a lot of time with these hybrid, rich-client J2EE systems, though.