Amy Fowler is a Sun engineer, and has been part of Swing, JavaServer Faces, and now Java Desktop Network Component (JDNC). Steve Lewis discusses how he found the accessment of the "holy grail of GUI development - the ability to define the UI once" spot on.

Steve's thoughts

There's an interview with Amy Fowler in JDJ this month that I found especially illuminating. In it, she explains why she thinks the "holy grail of GUI development - the ability to define the UI once" and have it map to both web and fat client, is not very feasible:

"The following is my personal assessment of why this won't work. First, each scenario has distinctly different operational characteristics .... Second, we are by nature visual creatures .... We'd never be satisfied with visuals that are generated or limited by the least common denominator."

Is this why JSF never really hit its stride? Did they get in the JCP and decide that it was pointless, but they had to produce something, so they made a very generic control flow? Then they told us that a vendor could implement controls, but is that very realistic, if the JSF itself is not very feasible? I don't think we can really expect a vendor to figure out and magically produce what the JCP could not.

Read Steve Lewis' thoughts in Amy Fowler on JSF

Read the original in Java Trends - An Interview with Amy Fowler

Is this why JSF never really hit its stride? Did they get in the JCP and decide that it was pointless, but they had to produce something, so they made a very generic control flow? Then they told us that a vendor could implement controls, but is that very realistic, if the JSF itself is not very feasible? I don't think we can really expect a vendor to figure out and magically produce what the JCP could not.

Not at all. WebObjects and Tapestry are good examples of two popular frameworks that succeeded in providing a solid, stable, feasible framework for web "controls". It *is* feasible to think about a solid way to create and reuse controls designed for a browser. It's *not* feasible to think that the same framework (and thus the controls) can be used both in rich clients and a browser.

I should have mentioned Tapestry and WebObjects when I mentioned Struts and WebWork. That was part of my point, that there are already very-mature, very-capable frameworks for the web tier.

When I speak of "controls" I was referring to it in the context of the "holy grail" where you define a control once, and then publish it to either web or fat client. Web controls in Tapestry are very effective for the web tier, I think.

So in sum, I couldn't agree with you more. :)
Steve

While we are plugging Web component frameworks, I would like to mention Echo and its companion project EchoPoint.

http://www.nextapp.com/products/echo
http://echopoint.sourceforge.net

These provide Java based (not script/page/xml based) components and allow for a Swing-like coding style to be used to develop web applications.

Echo is most similair to Tapestry except its components are (in most cases) completely defined using Java compiled code not scripts/configuration xml or html fragments.

The browser still has the same UI limitations (lag time issues, basic controls...) this can be blunted somewhat by the excellent component state management offered. Often you think you are using a true rich client.

Echo & Echopoint look really good, but the best components are in Sierra which isn't OSS :(. Have Nextapp told you not to stand on their toes with the Echopoint project, because there doesn't seem to be any overlap with the components?

Echo & Echopoint look really good, but the best components are in Sierra which isn't OSS :(. Have Nextapp told you not to stand on their toes with the Echopoint project, because there doesn't seem to be any overlap with the components?

No NetxApp have NEVER directed me on what to develop.

In fact NextApp have given me access to plans and early releases and given me direct help on the code internals.

I respect their business plan that in essence is "they have built an open source web component framework. Its open source and hence free. But they also sell a "value-add" set of components (Sierra) based on the framework."

OSS takes time and money to develop. The base Echo framework has been "greatly improved" via the open source process and hence any add ons are built on a strong foundation.

Also I would suggest that at about $500 a developer (cheaper as you add more developers) then these pre-built and tested components represent real value. gg. you would spend weeks building them yourself and that would cost a company more than $500 dollars.

With EchoPoint, we aim to develop components not already available else where. Why build another one when its already done. This probably explains the general lack of overlap.

No NetxApp have NEVER directed me on what to develop.

Sorry, didn't mean to offend at all :$ it's just many of the really useful components are in Sierra. But that doesn't detract from the fact that they are really useful and Echo does seem to allow developers to create form-based interfaces very quickly using an event-based paradigm compared to the older request-response paradigm.

In relation to the price, I agree, $500 only equates to a couple of days work for an average java developer, it would cost much more to develop them by hand.

You should try SOFIA. All the components are included with the framework, plus plug-ins for IDEs and Dreamweaver, all free, all open source.

Is this why JSF never really hit its stride? Did they get in the JCP and decide that it was pointless, but they had to produce something, so they made a very generic control flow? Then they told us that a vendor could implement controls, but is that very realistic, if the JSF itself is not very feasible? I don't think we can really expect a vendor to figure out and magically produce what the JCP could not.

The JCP folks don't know everything! With some JSRs it seems like they don't know anything. Code designed by a big committee of people with all different agendas almost never works as well as code designed by two or three talented and focused developers all on the same page. It is absolutely possible to create a component model for web applications that focuses on getting the job done and works splendidly (see SOFIA http://www.salmonllc.com/sofia). JSF just tries to cram the ability to do everything into one model (for web based request processing applications, I don't believe JSF does rich clients).

Using the same model for rich clients, web clients and wml clients and whatever other client is going to come along in the future is a pretty pointless exercise. It is stuff that vendors use on demos, but never really works in practice. Each medium has different strengths and weaknesses and using the same design for everything boils things down to such a low level that it doesn't work right for anything.

SOFIA focuses on HTML, but also provides support for WML and Swing applications as separate libraries. You have to code each client individually using libraries suitable for the particular environment you are using and so you wind up with an application that works properly in the environment for which it was intended.

Place your bets! How long until JNDC enters the JCP?

she explains why she thinks the "holy grail of GUI development - the ability to define the UI once" and have it map to both web and fat client, is not very feasible

Amy is on to something, but it is the *physical* device that matters. It is not generally feasible to develop the same UI that runs on a desktop and a handheld, for example. This should be obvious, with different screen resolutions, input methods, and usage patterns, but many teams have pursued this grail.

It is possible to provide the exact same UI, without compromising, on both web and fat clients on a desktop.

First, each scenario has distinctly different operational characteristics ....

Only if you make it so. If you run a rich client presentation layer in the web browser, the only 'operational' difference is that the browser is already installed on every desktop.

Second, we are by nature visual creatures .... We'd never be satisfied with visuals that are generated or limited by the least common denominator.

Very true, but it is no longer true that the browser is less capable than the desktop. Desktop systems are more than 10x faster than they were when DHTML browsers were released in 1997, and rich clients have been developed on top of the browser. To give you an example, we provide interactive pivot tables (for exploring OLAP cubes), in standard web browsers, with a richer UI than you get in Excel. This wasn't possible on the average machine 3 years ago, but most desktops are running 500Mhz or higher today.


Jeff Dill
Isomorphic Software
www.smartclient.com

I found her article very interesting, not for the purpose of blaming her, or Sun or anyone else for the failure of JSF.

Maybe it is just me but I don't understand how so many people can officially deem JSF a "failure" only 2 and a half months after it's 1.0 release. I've been using JSF since it's 1.0 release and can say that I have found it very simple and effective for the form based/driven applications I have been working on.

Reading Blogs like this make me wonder if I am using a different JSF than the majority of theserverside community. :)

Mike

Perhaps you can tell us how you use it and how you find it valuable. Maybe it's not a failure, but I was just hoping for a whole lot more, I guess. Does it offer you anything you can't get from any other framework? Maybe it does. I wouldn't mind being wrong. :)

Steve

<Steve>
Does it offer you anything you can't get from any other framework? Maybe it does. I wouldn't mind being wrong. :)
</Steve>

Steve,
You are right, other frameworks provide many features. But J2EE world needs simplification; we need to ease the user interface programming. For inexperience J2EE developers, a framework with IDE support is certainly helpful.

Yet, JSF should work well with other frameworks. I know Spring guys are currently working on JSF-Spring integration. With it, JSF managed beans & Spring managed beans can be shared. For example, you may have a Spring-managed bean & JSF as below:

Spring-Bean:
============
<bean id="SpringBean" class="test.SpringBean">
<property name="text"><value>some example text</value></property>
</bean>


JSF Page:
=========
<h:outputText value="#{SpringBean.text}" />


Just have a look at http://opensource.atlassian.com/confluence/spring/display/JSF/Home


regards,
netbug

Perhaps you can tell us how you use it and how you find it valuable. Maybe it's not a failure, but I was just hoping for a whole lot more, I guess. Does it offer you anything you can't get from any other framework? Maybe it does. I wouldn't mind being wrong. :)Steve

I'm not the original poster, but I'll give my .02$ anyway...

I find that JSF is a LOT easier to use than Struts. The framework is much cleaner... You Action classes need to to extend any framework class making them easier to code (and if the needs arrive, easily portable to another framework). The signature of action method is really simple : String doStuff() {...}. Most of the time, the action method has no need for the Servlet[Request|Response] so it make sense not to have them in the signature. And if you do need them, then you can easily access them with FacesContext. The declarative navigation flow is much more intuitive that in struts. The component model much more flexible. The fact that you put your validation in the JSP instead of another configuration file makes them easier to code.

The configuration file loading is really flexible (it make it really to assemble a JSF application from any number of components and modules).

I do have to say some bad stuff abour JSF... Coding new components is a pain in the *ss... There are to many classes to implement to just get your component in a usable state (I can see the opportunity for XDoclet). I beleive that they should have base the renderer on XSL transformation instead of having to code the renderer in Java. This would make creating new components less cumbersome and make the creation/extension of renderer a lot easier.

Overall, I really like JSF... For the people who needs to code the Action/Controller classes and the JSPs, it is really nice. For the people who needs to create new components, it could use some simplifications. The component offering is still pretty weak, but what's in there is still very useful.

Just wait when new components will be created by third parties, and it will quickly become amazing what you can do with it (for the rich client junkies... maybe Macromedia will release a flash renderkit with all the bells and whistles you expect ;-) ).

When it comes down to it JSF doesn't really provide much that can't be found in other frameworks. I find it to be a happy medium between the structure of Tapestry (admitting I don't know much about Tapestry) and the flexability of Webwork. Granted it does lack quite a bit in the realm of maturity.

Perhaps the only thing that JSF can officially provide, that the other frameworks don't, is the fact that it's a standard. So, theoretically by using JSF I will (eventually) be able to benefit in terms of training, learning materials, potential future employees with JSF knowledge/certifications, etc.

Anyway, I agree that JSF was well over hyped but I guess the result could have been something much worse. :) It will be interesting to see how it matures.

Mike

Mike,

At least, we are using same JSF :)

I am currently working on a project migrating from Struts to JSF/Spring. I found JSF much simpler than Struts, and its Navigation & Event models are elegant. I think web development could be even simlified if you get an JSF IDE, this is definitely what we want for J2EE community. Right ?

Regards,
netbug

Mike, I don't see any grounds for the bad rap JSF is getting either. I find it easy to comprehend, easy to extend and customize. I think it's a welcome improvement over Struts.
I failed to see the technical substance in the criticism that JSF was getting on TSS. It seems to be just the result of the fact that the official Java platform (J2SE and J2EE) are in the downward part of the hype curve and Tapestry and Webwork and Spring and whatnot are in the upward part.

groeten,
Joost

I agree that JSF is nicer then Struts, but I don't consider that much of a compliment.

The problem with JSF is that they hyped it to the hilt, took years to develop it, and then the actual release wound up doing a small percentage of what existing open source frameworks that JSF is supposed to replace do. Now they are feeling a backlash from that. Also I think Java developers tend to dislike and feel threatened by anything that promises to make development easier and more visual. Everybody seems to be afraid of hordes of VB programmers invading the Java realm and taking jobs away from the “real” Java programmers.

The good news about JSF (in my opinion) is that has a pretty good design, a lot of industry backing and will probably catch up to all the open source frameworks in a few more years. In the mean time you will have to do a lot more plumbing code then with other frameworks and that code will be more or less throw away whenever the "standard" equivalent comes out.

I also have a feeling that by the time JSF does everything it should, the whole request/response/generate HTML paradigm will start to be superceded by rich client technologies like XUL, XForms, Flex, Longhorn, JDNC or whoever wins the browser based rich client battles to come. So no matter what, I think JSF will always be have a bad reputation. It's just a day late and a dollar short.

That's The Server Side for ya. I've found that on TSS if there's anything about Webwork, Spring, Hivemind, etc. posters say these technologies are our saving grace and the most superior technology available. If there's anything about JBoss, posters say that JBoss is the epitomy of evil, worse than Microsoft (or maybe it's just Mike Spille that goes out of his way to say that.) If Struts, JSF or EJB's come up posters say that they are too bloated.

It's such biased postings like these that make reading comments on TSS such a waste of time.

The only reason I even read this thread at all is because a co-worker of mine told me people were talking positvely about JSF on TSS and I didn't believe him.

That's The Server Side for ya. I've found that on TSS if there's anything about Webwork, Spring, Hivemind, etc. posters say these technologies are our saving grace and the most superior technology available. If there's anything about JBoss, posters say that JBoss is the epitomy of evil, worse than Microsoft (or maybe it's just Mike Spille that goes out of his way to say that.) If Struts, JSF or EJB's come up posters say that they are too bloated.It's such biased postings like these that make reading comments on TSS such a waste of time.The only reason I even read this thread at all is because a co-worker of mine told me people were talking positvely about JSF on TSS and I didn't believe him.

Not only a waste of time but it does not do much for my blood pressure. I cannot believe how BIG-HEADED, ARROGANT and REPUGNANT some of these people are. They love to put down every initiative as if they can do better. One of the worst was some of the comments (eg. Huang Kai) that followed 'The Top 10 Elements of Good Software Design'. Makes me wonder what attracts them to the serverside.

Guess no one ever told them that Pride goes before a fall.

Equally concerning is the constant refrain that "the Sun advocated standard does not do anything that existing (open-source/free) frameworks cannot be made to do". Much the same argument could be applied to the java collections and JDBC when they came out. They did not try to out-feature the existing offerings, and they could very well be accused of plagiarizing ideas, but their stated aim was (1) standardization and (2) simplification. Now it would be difficult to find a Java developer who does not see the value of these utilities, or of the fact of their standardization.
<br>
Admittedly, this idea needs some refinement. For example, when the standard solution takes a very long time to come out, as with JSF, and thus faces the risk of always being a laggard. Or, when the similarity to an existing offering is so huge that it amounts to reinventing the wheel. For example, I cannot understand why, if the concurrency utilities could be incorporated into the JDK, log4j could not.

I do really think that UI components can be shared in web and desktop applications
, an example of this is WebOnSwing, that is a framework for multiple environment application development. With this project we could create web pages using Swing components very easy, including event handling and custom rendering.

Webonswing is definitely worth a view if you wish to write one interface and display is across multiple clients. It lets you create your interface in Swing and it will create a HTML version of it, you can also use templates to make the HTML version pretty without modifying the original version.

Fernando has also created renderers (contributors) for many of the Swing controls that translate to HTML (textboxes, radio buttons etc.). In actual fact, he has probably done a better job than the JSF commitee. The only problem is the lack of documentation for less obvious features, but I'm sure it will come with time.

I spent few days with JSF and hit couple problems which I could not resolve to my satisfaction. I tried to get some suggestions from JSF development team but was not sucessful

First issue I hit is inconsistency of data_table and DataModel behaviour with dynamic data:
- DataModel gets populated to paint a table. JSF will associate hidden field with each row and stick row number in it
- On row click this form (form around your table) submitted
- On submit DataModel gets populated again and then clicked row number parameter gets resolved to a row in DataModel. I asked them what happens if data in DataModel changes between painting and submitting of the form? I said you will resolve click to completely wrong row. they told me "That definitely *is* a trickier problem" and did not offer any reasonable solution. So I believe DataModel/data_table behaviour is inconsistent not to say that I am not happy with havint ro fetch data twice (on table paint and row click) increasing stress on my server and databases twice.
BTW the same applies to dropdown lists - data for them will be fetched twice - to paint and to resolve parameter value to object in list model

Second issue is architectural and having to do with very tight association of view and action (or backing bean). As result you virtually have 1-1 relation between you view and your controller (there are some work arounds but not pretty)

Please see following discussions:
http://forum.java.sun.com/thread.jsp?forum=427&thread=492885
http://forum.java.sun.com/thread.jsp?forum=427&thread=492036

I would greatly appreciate your comments.

I had very high hopes for JSF but not sure I want to go ahead with it

Alex

Hey Alex, from what I understand, these inconsistencies problems are not related to the JSF specification itself, but to the implementation, and in this case, if you are using Sun's RI, being it just a proof of concept, it is bound to be incomplete or not so reliable.

I recoment to you using MyFaces, or another open source or commercial implementation of JSF. Myfaces happens to have a special implementation of datatable which deals with this inconsistency problem:
http://www.marinschek.com/myfaces/tiki/tiki-index.php?page=ExtDataTable

BTW, I think the point of JSF is not to have all the greatest features, but to stablish a minimum specification so web frameworks could converge and allow for knowledge sharing and foster componentization.

Regards,
Henrique Steckelberg

Hello,

   There's no need to wait until Sun and Amy Fowler unveils Java Desktop Network Components (JDNC). You can use free, open source alternatives today such as Vexi, Luxor, SwiXml and so on. See the Open XUL Alliance online @ http://xul.sourceforge.net for more.

   - Gerald

Maybe this approch is not feasbile with the current mind-set with regard to web deployment. However, HTML never was a great way of delivering web applications. It is a little like attempting to deliver GUIs in word or pdf. Current solutions seem to be a straight hack of what is essentially a document format. Anyone remeber when applets were designed to solve this problem?

Something I am seeing more and more of (particually as bandwidth and hardware resources improve) is the use of technologies like flash to build web application GUIs. Macromedia seem to have succeeded where Sun failed with regards to rich content on the web.

So while this 'unified approach' seems infeasible given the current restrictions in web development I'm not sure that this will be the case much longer. Infact, it seems to me that the natual question soon becomes "If we can deliver fully rich content in the browser, why do we need desktop applications?"

Infact, it seems to me that the natual question soon becomes "If we can deliver fully rich content in the browser, why do we need desktop applications?"

1. Can this be done cross browser (the underlying framework is allowed to handle it)?
2. Is it cross platform?
3. Can it be done without proprietary (non-open) tools? (This is a big one)
4. Can the client be downloaded once and not again unless the code changes?
5.
  a. Can the client be created and maintained in an OO language(the underlying framework doesn't necessarily need to be)?
  b. How easy are they to maintain?
  c. How much "coding for the container" is there?
  d. Can any of the code be tested outside the container?
  e. Can components be tested separately?
6. Can all communication with "server-side" services be "data" only?
7. Can the majority of events handled on the client?
8. Can it survive the comming changes in Longhorn (and thus the assimulation of IE)?
9. Can it work without a network connection?
10. Can it launch without a network connection?
11. Does it required the latest browser?
12. Does it require the latest OS?
13. Does it require the latest hardware?
14. Can it do callbacks (polling doesn't count)?
15. Does it work outside the browser?
16. Can coding with the tool be leveraged to other frameworks (ie Echo and WebonSwing can be leveraged with Swing and SWT)?

I use Echo/Echopoint and know it comes close to saying yes to most of these.

I've been doing quite a bit of research into this very topic. I posted a presentation I did on it at the Java Lobby knowledge base (http://www.javalobby.org/kb/entry.jspa?entryID=183&categoryID=5).

I think there is a place for both HTML and rich client applications. Here is why:

1) HTML is easier to hand code and to have frameworks generate
2) HTML is easier to make look good
3) HTML is easier to deploy out to just about anybody
4) HTML is about as accepted a standard as you can get

The big problems with HTML business applications are:

1) It's really hard to get a truly intuitive and interactive user interface, without turning JavaScript inside out and upside down, debugging on every browser, etc...
2) The GUI state information really needs to live on the client, but instead most of it winds up on the server, which gives you a bunch of unpleasant choices. Use a lot of server memory, use a lot of bandwidth piping the state back and forth, or weaken your GUI so there isn't much state to keep. Meanwhile, the average client PC has megs of unused memory.
3) You can't do partial page refreshes very well so you always get clicks and blinks when ever the user does anything interactive outside JavaScript. The server has to generate and send a whole new page even for a simple GUI state change. So you get a clunky GUI, and the server is doing a ton of work while there are lots of unused CPU cycles on the client.
4) The browser back button is just a misery for business applications, but users expect it and want it.
5) Printing formatted reports in HTML is a misery as well.

If you really look at it, most of a typical browser application doesn't need to be that interactive and isn't worth all the extra work for programmers to make is so. For those pages generated HTML is fine. But some sections of every business application will benefit greatly from a rich client. For things that end users spend a lot of time in, like high volume data entry screens, or high volume reposts you can save them a lot of clicks, the server a lot of load and the network a lot of bandwidth with a rich client. So I think a typical business application will in the future consist of around 70% generated HTML and 30% rich client.

The question is what technology will be used for the rich client. That's very murky right now. I looked at a bunch of technologies and some are very promising, but none are there yet. (Sorry Amy Fowler, but applets and webstart are still far from an ideal deployment platform, although making Swing easier to work with using a tag language is a great idea).

I'm really interested in XForms which is supposed to be the latest W3C extension to HTML. The thing about XForms is that it is basically an HTML/XHTML page, with charged up form processing. It has an independent XML model on the client and it supports partial page submits. You can just submit and get back just the model and not the whole page, and the view automatically rebuilds from the new model. So you get some state on the client, no clicking and blinking on submits and fewer bandwidth problems. Also XForms are an extension to HTML and so one document can have both. The problem with XForms is that it is very bleeding edge and browser support is terrible at the moment. If good implementations where available on IE and Mozilla (or looked like they were coming) I would seriously think of rewriting my open source framework around this technology. Unfortunately I don't expect any really good XForms browser implementations any time soon, but there are quite a lot of bad ones out there. Maybe somebody will get it right eventually.

Of the other technologies out there, Macromedia Flex seems most promising because it's the only one that at this moment can run on most browsers out there. The problem with that is that it's proprietary and expensive. And I really don't know if I want to be subject to the whim of Macromedia. I suggested to a customer they try it and they told me if they wanted something proprietary they would be using Microsoft. If only Flex were open source…

Your points matching "HTML is easier *" are true only untill you start code real funcionality. HTML is simple only for simple things.
In my company we are using XML based rich GUIs for 5 years, with great success. Clear separation between MVC is great. Pure Java environment on client side with JDK 1.1 inside IE 5.0.

I'm not sure but when I looked at XForms it looked like pure forms without graphical representation. Layouting have to come from some (semi)automatic robot which will do work for your.

For me primary problem on client side is GUI model. I have to choose some point between two extreme sollutions:
a) Simple model with autoformating
b) Complete absolute position with everything wired

In old days we was doing everything wired b). Now when we found that simple HTML, as GUI model, should be suffiecient we are confused. That's only problem. We, as programmers, can imagine to use something like sollution a) in real life, but than customer come and want just simple change: "move please this button 2 milimeters left" ;-). That's only thing which break us from using a).

If you really like HTML then you can set your XML schema (GUI model) near to HTML and use nice XMLs with very small framework for rendering rich GUIs in Java on client side, no problem with this.

We've pretty much been using HTML for the last five years and it's worked for us. I've found that you can get great looking visuals from it, but the interactive parts are hard without doing full page refreshes. Our framework, SOFIA simulates rich client with some really smart HTML based GUI components, but you have to get around all the problems I mentioned above.

Our framework used to be based entirely on a Swing type coding model where you instantiate Java GUI components that generate the HTML and put them into containers/layouts to get them on the screen (I think like Echo does). That was pretty good, but it took a lot of code to build even a simple GUI (just like with Swing). Also web site designers were giving us a hard time because we couldn't always get the page to look exactly the way they wanted it (it would sometimes lose stuff in the translation from HTML to Java components).

So we added a JSP tag library wrapper around our components. The tags basically instantiate the Java GUI components for you. The Swing-like coding model is still under there if you want to use it, but it's much easier to build a GUI out of JSP tags then with straight Java code so developers mostly use the tag library instead. It's also easier to put in some arbitrary bit of HTML in the JSP and it's much easier to work with tools like Dreamweaver and also accomodate fussy web designers.

I have been trying to get more actual rich client stuff in SOFIA for over a year, and have add some Java Swing support and researched other technologies, like XForms, XUL, Flex, etc. But there is some problem with just about every technology. I think somebody will eventually solve the problem and come out with a universally standard, web delivered, rich client technology where the screens are described with XML tags. Unfortunately I think it will be Microsoft with Avalon in Longhorn. Since they own the browser market they can more or less keep technologies like XForms or XUL suppressed just by not supporting it in IE. As a matter of fact, they haven't even released a new browser version since they buried Netscape and that's frozen the whole web innovation process quite a bit I think. I guess it turns out that a single vendor controlling an important technology isn't so good for the world after all...

Dan: "Unfortunately I think it will be Microsoft with Avalon in Longhorn"

Unfortunately I think you are right. All the various solutions today have one thing in common: They are to slow compared to HTML.

It could be a lesson to all the hackers that all times advocates some new and exiting latest fashion computer language. They all think that only because you have an interesting core language you are in the free, disregarding the fact that you have to build up a entire library around it (40 MB unpacked now for .NET, 3000 classes), IDEs and tools and at last the most daunting task of all, adapt a whole operating system to the language.

Think of that next time somebody is enthusiastic over some new language. Only when you have it all, WinFx/Avalon/XAML/Aero/Longorn with all the APIs speaking "native C#" will you get performance similar to the ordinary current vanilla HTML today.

Regards
Rolf Tollerud

Only when you have it all, WinFx/Avalon/XAML/Aero/Longorn with all the APIs speaking "native C#" will you get performance similar to the ordinary current vanilla HTML today.

Didn't an MS evangelist recently suggest that Mozilla adopt some of these technologies into their browser? If they are making such suggestions, would you think it fair to read between the lines and conclude that MS are so impressed by Mozilla's XUL and are trying to nip it's popularity in the bud by trying to get them to drop it on the MS platform?

For those who haven't tried Mozilla XUL ,have a look at the tutorials on MosDev. It makes it very simple to create interfaces using web-type tools such as XML for the interface (obviously), CSS for decoration and javascript for interactivity. Using the core of Mozilla, it becomes easy to add a new chrome (etc.) to develop a new application, just change the parameters passed to the executable at start up.

The problem with it is that it can only be used with Mozilla, but at least Mozilla is available for many platforms (more than IE), XAML will only ever be available on windows. An seeing as it is using XML, it could also be transformed into pure HTML for thinner clients.

There are only some commons grounds of concept between Mozilla XUL and the Avalon/XAML but, it is the incredible scale of the Microsoft project the buggies the mind.

To build a new Boeing Jumbo jet model is both easier and far cheaper.

You know about proportions, I presume.

Regards
Rolf Tollerud

I was really excited about XUL myself, but it really only works well in Mozilla and that elmiminates 80% of the market. I found a fellow with an open source IE plug-in for Mozilla (embeds Mozilla in IE so XUL can run). It worked, but the XUL examples ran ten times slower with it in IE then in Mozilla. The XUL community seems unfocused to me also (lots of projects on mozdev.org seemed to have been dropped right in the middle of development).

XUL feels to me more on its way down then up. I really wish the XUL community could get their act together. Potentially they have some world changing technology in there: browser delivered rich client that works and is open.

As an addon: If you have any question about XAML and Mono/Linux I invite you to join us on the xaml-talk mailinglist over at Yahoo! Groups that includes Mr. MyXAML aka Marc Clifton himself. See http://groups.yahoo.com/group/xaml-talk for details.

Thank you for the link to
http://myxaml.com/marcclifton/archive/2004/05/21/290.aspx

And it work with Linux too! Without a single change..

I knew all along that Open Source was not to allow Microsoft to "propriteriaze" XAML :)

So with Mono, MyXAML and Spring all released and working on Windows/Unix/Linux this year we don't have to wait for Longhorn. And with Spring on the server!

Regards
Rolf Tollerud

Why we don't choose HTML:
- HTML is very statical - no interactive things like in rich clients
- Every new version of browser come with new type of headache (specially JS)
- Network traffic - with rich GUI, 10 clients on ISDN line is no problem
- Server load - just standard PC for server and database for many clients
- Server memory - sessions in HTML solution are really hungry
- Average office PC is soooo huuuuge that use it as browser is waste of money

In reality only problem with Java client is distribution. However we found following:
- JDK 1.1 compatible code work inside IE with no problems (some tuning on framework level was of course necessary). With signed code you can copy even whole new JVM and start your application from there.
- It's very easy for windows users on corporate networks double click batch file on some windows share (or batch distributed via e-mail). This batch should copy whole JVM together with client code into client machine and install icons on desktop and menu or just start JVM from remote share (depends on application type)
- New machines are comming with JVM preinstalled
- WebStart will be really useful if it will have better GUI

- People are willing to spent 5-8 minutes with installation if it's only once and installation run absolutely automatically

Of the other technologies out there, Macromedia Flex seems most promising because it's the only one that at this moment can run on most browsers out there. The problem with that is that it's proprietary and expensive. And I really don't know if I want to be subject to the whim of Macromedia. I suggested to a customer they try it and they told me if they wanted something proprietary they would be using Microsoft. If only Flex were open source…

Currently, Flex is lacking a good visual IDE.

Flex will be more compelling when Macromedia ships the "Brady" IDE.

http://www.macromedia.com/software/flex/productinfo/tooling/brady/

It is worth mentioning that IBM has a Flex plugin for Websphere Studio

http://www.alphaworks.ibm.com/tech/wsadflex

Look at wingS. It is using the event- and model-classes of swing and has nearly the same API. Porting simple applications from swing to wings is a matter of concerting Js to Ss. From the developers point of view there is not much of a difference between coding swing and wings guis.

In order to meet every visual creature's expectations, you can develop pluggable LaFs. Making heavy use of javascript, you can achieve nearly everything, you can achieve with swing.

It's so simple. You need:

o a component object model
o layout managers
o an highlevel eventmodel
o an event dispatcher
o a rendering mechanism (pluggable)
o a reloadmanager (something that keeps track of changes and knows, what updates
  have to be sent to the client)
o a resource manager (that makes resources accessible via urls)

You don't need:

o a state machine
o xml configuration
o taglibs
o pages

Amy Fowler is a Sun engineer, and has been part of Swing, JavaServer Faces, and now Java Desktop Network Component (JDNC).

There will be a JNDC presentation at this year's JavaOne conference.

JDesktop Network Components (JDNC): Simplifying Java Desktop Client Construction

http://www.javaone04.com/session-html/TS-2865.html

[quote]
JDNC is a new technology aimed at radically simplifying the task of constructing and deploying rich stateful JavaTM technology clients. JDNC provides a suite of high-level JavaBeansTM components that take advantage of J.F.C./Swing GUI APIs, in addition to providing built-in data-binding, networking, upscale visuals, and usability features. Components can be created and manipulated through a first-class Java API. Alternatively, they can be realized through an easy-to-use markup language called Java Component Configuration Language (JCCL). Neither the Java API for JDNC nor the XML schema for it require J.F.C./Swing technology expertise.

In this session, the JDNC development team first describes what you need to know as a developer using JDNC to construct an application — the JDNC programming model, component APIs, and XML schema. The second half of the session takes a peek under the covers and talks about the architecture and its evolution, providing perspective for developers who wish to extend or plug into JDNC at both the XML and Java technology level.

[/quote]