Slashdot Mirror
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."
is actually meant to be a library destroyer, and has been a staple of control players for years.
It uses swing-like api and it doesn't has any overhead with pure java applet.
My friend who is a financial content provider which distribute information with the help of java applets. They just stuck with the problem with XP which does not come with Java support, which is very bad for their business because their users usually don't know(or don't want) to download and install a JRE. Let's see if it can help him.
Millstone: A heavy weight; a burden: "This job is a millstone around my neck."
The most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
The on-line demo / example pages do not appear to work without cookies. Sorry, thank you for playing! One of the cardinal rules of a good general purpose web app framework is that it should not require cookies to work. It may be that the framework itself does not require cookies. If so, it was a poor decision to write demos that do. Oh well. Next player, please!
Millstone does not seam as feature rich. I have downloaded it and after looking at a few classes for some of the features I love in echo I find it lacking for example Button There appears to be no rollover support. It seams that Millstone is a reasonable framework, but I feel that it compares better to AWT then swing where ECHO compares to SWING.
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"?
Experience is a hard school, but fools will learn no other.
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.
I can spell. I just can't type.
When I see "Millstone" I think coffee. I wonder if they did that on purpose (Java... beans... etc)... the Java PR people love the coffee terms, and it is only fitting that something that extends Java should use a coffee related term. I'm gonna make a java-based game engine called Starbuck. :)
today is spelling optional day.