Discussions

News: Opinion: Rich clients are still part of serverside development

  1. Yesterday I noticed an article in our local IT newspaper that client-installed apps are so totally out and how all IT managers worth their salt are striving for to have everything browser based - to have clients so clean as possible.

    If we divide Web-apps into these with:

    1) simple interface w big load
    2) complicated (=rich interface) w big load
    3) simple w little load
    4) complicated w little load

    ...it seems to me now is the time to focus a little on 2 and 4!

    Flash MX is a possibility (remoting – new Communication Server) but Flash seems as overkill.

    I read an article in SD Times "Laszlo Takes Standards Route to ‘X-Internet’" http://www.sdtimes.com/news/075/story12.htm.

    It looked ok, they use the Flash file format, but in a more simple and intuitive way (that is what they say). On the other hand, the pricing scheme is not to my liking – the developer version is free, the runtime is not. The other way around please! You cannot download a test version without before having been contacted by a representative. It all sounds a little mystic to me!

    Why cannot Open Source develop something like useful like this? I am a little tired of this focus on "fine-grained or coarse-grained", "best tool for O/R" etc. Are all people going to discuss EJB and O/R on and on forever?

    Rich clients are still part of serverside development IMO "as long as nothing is installed on the client".

    Threaded Messages (52)

  2. Gerald Bauer has published slides from a talk he presented The Future of the Web: Rich Clients, Rich Browsers, Rich Portals that does a good job overviewing all the current intiatives towards rich client development. There is a lot going on, even in open source.

    TSS also recently did a tech talk filming with Sean Neville of Macromedia about rich clients (Sean was the architect of the JRun appserver and is a JCP executive representative), which will be put on TSS in the coming months.

    Floyd
  3. Floyd,

    Thank you for your link! But I didn’t find something new there exept Curl, but with single-vendor, closed-source, payware; "starter" kit starts at US$25.000+; runs on Windows only and plug in reqired – draws breath - kind of kills itself.

    Somehow, I am convinced that Flash (95% downloaded) is the clue to the solution. It should be something like “thinlets” powered by flash runtime instead of Java.

    Regards
    Rolf Tollerud
  4. Somehow, I am convinced that Flash (95% downloaded) is the clue to the solution. It should be something like “thinlets” powered by flash runtime instead of Java.


    I have seen way too many rich clients implemented with HTML and Javascript (even our company made a few), so that I don't consider Flash to be a necessity anymore.
    It is harder to do it without Flash (a good framework is a must), but certainly not impossible. And developers don't have to learn yet another language and platform.

    As far as whether this is server- or clientside development, I really can't decide. There is not much of an overlap between the skill sets of a server developer and that of a GUI developer. But in the current situation a developer working on the (Web) presentation tier must be proficient in both roles if he is to produce any nontrivial application.
  5. Hi all,

    Hope this doesn't seem like too much of a shameless plug, but having been working in a very focussed manner on delivering Rich Client applications by integration of Flash MX and J2EE, and continuing to work using these technologies, I'm pleased that my new book, Reality J2EE :: Architecting for Flash MX is being shipped to warehouses this week, and should be available shortly.

    Having delivered traditional J2EE web applications for a number of years, I was increasingly looking for a solution that would allow much richer and more interactive client-side development; the "better" we would get at providing a user experience with HTML/JSP, the more our clients would expect, until we came to an impasse at which we had to say, "the technology can't do that - it's a web application".

    That's when I first started working with Flash MX, and this coincided happily as it transpired, with Macromedia's release of Flash Remoting MX and Flash Communication Server MX. That's when I offered to write on these technologies from the perspective of a J2EE architect.

    My concerns were those that I'd have to address at the start of any project; do we have to sacrifice the best practices we have enjoyed with JSP front-ends ? Will we be able to adhere to recognised design patterns ? Will we be able to support quality practices, such as test-driven development, to support unit testing, regression testing and refactoring ? Can we cleanly separate content from code, can we cleanly separate the role of the J2EE Developer and the role of the UI designer (be that a graphic design team, a web development team, or a Flash design/development team) ?

    In my book, I've tried to address all of these concerns, in the context of building an online banking application (albeit a feature-stripped online bank) as a demonstration of how we can architect J2EE applications to use Flash MX as a rich-client application.

    There are a lot of misconceptions about the use of Flash, largely in part due to the days of the <
    The companion website for the book can be found at http://www.iterationtwo.com/realityj2ee/ where you will find some sample chapters (albeit the table of contents and introduction) and links to the book at Amazon, as well as some additional resource.

    The accompanying "Bank of Edinburgh" application will be up there soon as well, as soon as the book hits the shelves, and we get things up and running on our server.

    Though the book is written for Macromedia Press, we don't just discuss the use of JRun and Flash Remoting MX, but provision of Flash clients using architectures based around Jakarta Tomcat, JBoss, MySQL, etc.

    If you're really interested - then take a look at the book. But if you're marginally interested, take a look at Flash with a mind clear of your worst skip intro experience, and see what you think.

    And the usual caveat -- I don't work for Macromedia, I just enjoy building Rich Internet Applications with their tools.

    Best wishes,

    Steven Webster
    Technical Director, iteration::two
  6. Sorry guys, some of the message got mangled up there -- I meant to say that the misconceptions were due to the prevalance of "skip intro" websites. I guess my punctuation confused TSS...sorry.
  7. All About Rich Client[ Go to top ]

    Thanks for posting a link to my latest VanX talk titled "Rich Clients, Rich Browsers, Rich Portals". This talk actually is part of an ongoing series so I invite you to check out some previous episodes such as:

    * Luxor: The "Linux Kernel" for Desktop Apps
      Uniting XUL, SVG, HTML, Velocity, Web Start, XSL/T, Python and more
     
    * Luxor XUL - Beyond Swing and HTML
      Building Rich, Cross-Platform, Zero-Admin Desktop Apps on Open Standards Today
     
    * Python and Jelly: Scripting Power for Java and XML
      Do More With Less (Lines of Code)

    * Spice Up Your XML UIs with SVG
      Create High-End 2D Graphics Using XML
     
    * Web Start Overview
      Java's Comback On The Desktop

    I also publish to advocacy sites/web logs titled:

    * The Saturn Times
      Daily Web Start News From Around The Globe

    * The Richmond Post
      Chronicle of the XUL Revolution

     Enjoy.
  8. I agree with last sentence *"as long as nothing is installed on the client"*

    Take a look at Siebel's way of implementing Rich Client. As a Siebel Developer, all I use is Siebel Tool, compile the application using Siebel Tool and deploy it on Server. Application is accesible using standard URL. I have been searching for a similar solution in open source for a loooooong time. Nothing is out there which simplifies rich client development. Visual Studio is the closest, but it is not open source.
  9. how can I test the tool?[ Go to top ]

    Kumar,

    Could you eleborate a little? This Siebel tool is unfamiliar to me. Does it compile to Java bytecode? Does it need Java on the client or is is 100% serverbased? Is it a tool for Siebels customers or only for Siebels inhouse developers? When I go to Siebel site to view some demos I am first asked to install a TSCC Codec and after I have to install yet another Java JRE to add to my already considerable numbers of JRS! (Not what I call *"nothing is installed on the client"*).

    Regards
    Rolf Tollerud
  10. how can I test the tool?[ Go to top ]

    Rolf, let me try to answer your questions.

    Does it compile to Java bytecode?
    No. It is compiled in Siebel's own format. It is called Siebel Repository file (srf) which contain the model + view + Controller information bundled in one file (srf). Siebel is planning to be compatible with Websphere App server. No clue when it is going to be out.

    Does it need Java on the client or is is 100% serverbased?
    The answer is yes and no. You can invoke application either in High interactive mode (employeee facing applications) or Standard mode (Customer facing application). It true that is requires certain jre, the one that M$ ships with Service Packs on IE browsers.

    Is it a tool for Siebels customers or only for Siebels inhouse developers?
    It is for Siebel Customers as well as for inhouse developers.

    When I go to Siebel site to view some demos I am first asked to install a TSCC Codec and after I have to install yet another Java JRE to add to my already considerable numbers of JRS! (Not what I call *"nothing is installed on the client"*).
    I won't disagree with you. It is my complaint to Siebel too.

    I like its tool, because thats all I have to use. Gives a Rich Client development framework for business transaction oriented applications. Improves developers productivity and makes project managers happy. All I hope is that Java IDE tools match up with that type of functionality. Jdeveloper started that trend by including Business Component layer etc but not too well. All I dream is USE one tool to build view + controller + model, which is client and database agnostic and delployable across the platform.
  11. bibin,

    Well, no matter how it works, I am envious at you for having such a good tool!

    It is very irritating, that the browser that has the best solution only have some tiny fraction of the market.. What is MS doing? - it is not only XUL they are missing but also CSS2 (which are very useful and much easier to use than XSL to place out XML on the page). We can only hope that they wake up from their slumber!

    Meanwhile – we have to do with makeshift solutions.

    Regards
    Rolf Tollerud
  12. Why cannot Open Source develop something like useful like this?

    > I am a little tired of this focus on "fine-grained or coarse-grained",
    > "best tool for O/R" etc. Are all people going to discuss EJB and O/R on and
    > on forever?

     There are lots of open-source projects ongoing targeting rich clients. I call them XUL motors and I try to keep track of all of them in The Richmond Post Link-opida.

      Here's a sampling: XWT, Luxor, JellySWT, JellySwing, Swix, KoalaML, Thinlet, Axualize and some more.
  13. C# XUL?[ Go to top ]

    Gerald,

    I can agree with you that XUL is the way to go but why not do all XUL rendering on the server? I cannot see the advantage of doing the rendering on the client! (memory hugg - incompatible VM, etc) If everything is transformed into HTML on the server nothing needs to be installed on the client..

    Do you know of anyone that is working on a C# XUL-HTML component?

    Regards
    Rolf Tollerud
  14. Do you know of anyone that is working on a C# XUL-HTML component?


     I'm not sure why you care about C#.

     Sun and dozens other big-wigs such as Oracle, BEA and others work on the upcoming Java Server Faces spec. Java Server Faces lets you use XUL (although the call their XML UI tags somewhat differently but basicly it's the same thing) and then render the XML tags on-demand using Java servlets to HTML or HTML plus dynamic graphics or HTML plus Javascript or whatever.

     I don't agree with Sun focusing on the server, but, I see their point, that is, they sell servers not clients, thus, they don't care much about rich browsers that shift the workload away from their core business.

      - Gerald
  15. Nothing will come of Nothing[ Go to top ]

    Gerald,

    ..they (Sun)sell servers not clients, thus, they don't care much about rich browsers..

    Your remarks are persuasive – the more so in that they are accurate…

    Sun and dozens...others work on the upcoming Java Server Faces spec. Java Server Faces lets you use XUL...and then render the XML tags on-demand

    This is precisely what is in ASP.NET - called Web-forms for over two years now, it says a ton about the pace of speed JCP works. Maybe we should give them one or two years more..

    That Sun concentrate on the server is quite understandable – they never believe that Swing is capable of anything - and they are probably right.

    Regards
    Rolf Tollerud
  16. I also find this an interesting approach to note in this consideration:

    Isomorphic SmartClient
    http://www.isomorphic.com/technology/testdrive.jsp

    This is a development framework that generates *rich* DHTML UIs that are cross-browser compatible and stable.

    If something like this were free, I wonder if/how much it would affect the dependency on thicker clients?

    j f
  17. j f,

    Isomorphic SmartClient – I have tested that, IMO to heavy, depending on a 300k+ Javascript library!

    Regards
    Rolf Tollerud
  18. DHTML for rich web clients[ Go to top ]

    I think the future of rich web clients lies in the use of DHTML (HTML/XHTML+CSS+DOM+JavaScript), with perhaps a few other complementary markup languages, such as SVG and SMIL.
    All these languages are W3C or ECMA standards, and have the support of big software companies and OSS groups (MS, Mozilla, Adobe, etc.)
    XHTML 1.0, CSS 2 and DOM 2, as supported in MS IE 5.5/6 and the latest versions of Mozilla/Netscape Navigator already provide a very rich feature set. For example, it's not difficult to implement drag & drop behaviors that works in all of these browsers.
    Looking into the furute, the next major version of XHTML (XHTML 2.0) will add the new XForms and XFrames modules. XForms in particular is VERY powerfull. Of course, it's going to be several years before the browsers implement these specs in a nearly bug-free manner.
    IE 5+ for Windows (but not the Mac version) even have some proprietary extensions that allow for WYSIWYG text editing (almost like having Wordpad inside the browser), and access to the local file system.

    As for alternative approaches such as Macromedia Flash MX and XUL (Mozilla), I personally don't believe (or desire) that they will be widelly adopted. (Specially XUL - can anybody imagine MS supporting it?)
  19. Microsoft and XUL[ Go to top ]

    <Specially XUL - can anybody imagine MS supporting it/>

    Yes, I can imagine it. Why should MS leave XUL rendering to the "Opposition" when they probably can build better ("faster") rendering engines themselves? Look up http://msdn.microsoft.com/msdnmag/issues/02/11/NETGUIBliss/
  20. Industry support for XUL[ Go to top ]

    In a perfect world, XUL would become a W3C recommendation, MS IE would fully support it, and XHTML would be deprecated...

    I would love to see this happen, but in the real world, what are the chances? I could not find any concrete indications that MS or the W3C intend to adopt XUL.
    Guess only time will tell.
  21. They point of thick clients is that they are something the client demands. Not a general purpose UI framework. If your thick client requires XUL, you ship gecko with it. Flash is too ugly to code in, and most networked user input can be done in Javascript + HTML DOM. Anything more complex begs a UI, and every windowing system ships with one (is one), so why do you need another. Using an XUL like syntax and a *real* DOM (not a w3c DOM) is the way of the future. Tools like QTDesigner and Glade are 1 step away. They're at the HTML 3.2 stage where attributes litter tags. All they need to do is separate attributes and properties from elements (the way VB or CSS does) and you have a working scriptable, XML based UI. The real trick is to set all the defaults just right, and expect to see competing implementations, at least for open source toolkits like GTK, for a few years.
  22. Client installs CAN be appropriate!!![ Go to top ]

    First off, great opinion piece. I've been preaching this for a while, and even tried to get a talk at JavaOne on this subject, but lacked buzzwordability or recognition or something.

    BUT, sometimes it's OK to install stuff on the client. Those cases are for so-called "Line of Business Applications". These are applications that are used on a company intranet by various company employees, usually to do data entry or specialized reporting. A web-app is the wrong solution for these, but a Swing/SWT/WhateverWT app is a great solution, especially when using Java Web Start and J2EE.

    You get all the benefits of J2EE (server-side business logic, transactions, etc.), plus you can a _real_ UI and not a sluggish web-based thing, AND you get instant updates via WebStart.

    Note that the area of Line of Business Apps is currently dominated by crappy technologies like PowerBuilder, Delphi and VB, and Jave + J2EE is a GREAT way to get an organization into the 21st century while reducing maintenance and administration costs.
  23. if only[ Go to top ]

    "As long as the app is not installed locally" is an ideal world that unfortuantely few of us ever get to work in.

    Different versions of JVM are not compatible with each other. Which means different apps require different JVM's to others. Even if there is JVM comaptibility, you find that a software vendor providing stuff you use won't sign off on the version of java that another app requires. You can't solve this with WebStart as not every app uses it.

    The desktop support people end up trying to get >1 different versions of Java on the same client machine, and inevitably face problems.

    Sometimes it's easier on the server side.
  24. Echo / Echopoint[ Go to top ]

    What about Echo / Echopoint ?
  25. Java Web Start[ Go to top ]

    The article says "Rich clients are still part of serverside development IMO "as long as nothing is installed on the client"."

    Flash MX does not come standard with any operating system that I am aware of, so it wouldn't count. If it does count as a solution, Java Web Start counts. It is available for all the popular operating systems. It allows caching of a client application on workstations and automatic updating of the application when it changes.

    It is a valid solution to this problem.
  26. Jay and Mauro

    With Flash MX you still can save your work in Flash 5 format – which exist at over 95% of the clients. But as I said before – it is overkill to make user interfaces in Flash IMO. You are using only 5% of the functionallity of the IDE!

    Echopoint provides a nice rich collection of web components but can only be used together with Echo Framework. In addition, I cannot see how you from the client can access business logic at the server (a must so you do not have to rewrite the whole page for every adjustment).

    Overall, I think that XUL/Mozilla combination is the best solution. All components for rendering XUL are already in the browser + XMLHTTP.

    On the contrary, any solution that depends on that the correct version of JRE (or the correct version of .NET) is installed on the computer I see as naïve.

    As to whenever MS will adopt XUL the chanses are slim. The XUL advocates have still not outgrown their "Micropoly .Nyet apparatchik Billy Boy" attitude. Therefore, MS will most likely present their own - similar but improved system,– incompatible with Mozilla some time in the future.

    Regards
    Rolf Tollerud
  27. Rolf,

    > With Flash MX you still can save your work in Flash 5 format – which exist at
    > over 95% of the clients. But as I said before – it is overkill to make user
    > interfaces in Flash IMO. You are using only 5% of the functionallity of the IDE!

    I'm curious here...you're correct, in that the Flash IDE is *currently* heavily biased towards the Flash designer for creation of animations, however it doesn't make it any more difficult to design a UI using Flash MX. With the number of available components for dropping into a Flash Project, it's as easy to build a good UI with the IDE as it is to build an animation. I believe Macromedia will address the UI developer more with the Flash format, as time goes by..

    Furthermore, in writing a server-side enterprise Java application, say for online banking, I'd perhaps use only 5% of the functionality of the available Java class libraries..but that doesn't preclude Java from being a good choice of technology for my problem domain. Same argument for C#. It's not as if the "final product" is carrying around 95% excess baggage that it doesn't need...

    In terms of the Flash player, which as you point out is available on a very high percentage of desktops, it's functionality is geared towards the rendering of a rich user interface from a small footprint file, towards the interaction with that user interface, and with Flash Player 6, towards the integration of the client with application servers (J2EE, CFMX and .NET) and with Web Services. The version 6 player, in the same small footprint, also supports the real-time streaming of audio and video, which enables some pretty exciting rich-client interfaces...

    IMHO, it makes it a compelling technology as a rich-client upon a services-oriented architecture.

    Just some more thoughts,

    Steven
  28. Conflicting arguments?[ Go to top ]

    I am slightly confused by the seemingly conflicting arguments in this thread...

    1. That you should not use Java-based clients because this requires the user to download software, which they are unwilling to do.

    2. That Flash is the way to go because users are so willing to download software that Flash now exists on 95% of clients.

    If users are indeed willing to download additional software then Java apps / applets are surely the ideal solution. They confer big benefits: Use of the same language across GUI and server-side programming, the availability of the full functionality of Java to GUI programmers, utilisation of the client PC's processing power (conserving server resources), etc. However, like Bertrand says, I think SUN need to put a bit more effort into this area if it is going to succeed.

    Regards,
    Lawrie.
  29. Conflicting arguments?[ Go to top ]

    The difference between flash and java through the browser is:
    1. Size. The flash download is tiny compared to downloading the JRE, and applets are larger and slower to start than flash documents.
    2. Transparancy. Flash installation is a pretty seamless affair - you will be prompted to download it, it will download quickly, and you'll be back at your original, fully working page, never needing to worry about flash again. with an applet, unless they use an activeX control to detect what JRE you have installed (if any) the applet simply won't appear, or will break. Navigate Sun's clunkier-than-macromedia's site, downloading several megabytes of JRE, running an installation program, possibly having to reboot.
    3. Compatibility. If a user already has an early java installed (ie. the default MS jvm for IE), and you require JRE 1.4 they're going to be given a shoddy impression of the app from the outset (I've already got java, but it still doesn't work, blah blah). Using JRE1.2 and above rules out anybody on MacOS 9. Like as not you'll either have to cater to the lowest common demoninator (write 4 different applets for different JVMs, embedding methods and still not please everybody) or force everyone onto the latest JVM (lose a significant percentage of your disgruntled audience). Flash is far simpler.
    4. Quality. Simply, flash looks better. It is much easier to create good-looking results in flash than in java. Yes, it is possible to do a good applet based UI, but the glut of shockingly bad applets have hurt Java's reputation far more than all of the 'click here to skip' flash intros.

    So why will people download flash? Because it is quick, simple, works every time and regularily gets results that look good.
    Why won't people download java? Because its huge, more complicated, doesn't always work and regularily gets results that look feeble.
  30. Another point worth considering in this, is the skillbase of the UI designers. We don't have difficulty finding good UI designers, who understand design, HCI, usability, and are basically able to create good-looking UIs, who aren't also Flash users.

    However, try and find someone that has a creative bone in their body, AND is able to understand the Swing API, or similar....it's just not a common bunch of skills to find in the one person. Sure, if your UI is that of an IDE like JBuilder, or similar, you maybe don't need a designer, but for rich-client applications...think Amazon with a rich-UI, etc, we really want the skills of a designer throughout the UI process.

    Which is a bonus, for me, with Flash as a rich-client technology -- there's a wealth of talent out there that we can get instant access to.

    Just more ramblings.

    Steven
  31. Steven, I simply can't adhere to your arguments. Being a developer or an UI designer are simply two different professional jobs. I am developing commercial Swing applications and applets for years and never had to write a graphical charter myself. Simply, there are specialists out there to do that and care about UI design and usability. And believe me, these specialists have never worked with Swing and will probably never do: they are prototyping user interfaces using tools like Adobe Photoshop or Visio, and sometimes Flash when a static model of the user interface is not enough.

    Having two skill sets to develop user interfaces is very important to achieve great results. Too often, UI developers that also carry on the UI design tasks tend to immediately compromize on the usability and look of the application in favour of speed and ease of development, which is actually irrelevant to the UI design job. Yes, it sometimes happens that the UI designers, because of their more creative point of view, come up with interfaces that are a real nightmare to implement. It then depends on the amount of money the client puts on the table: either we do it anyway, or a more affordable solution has to be found. And conversely, UI designers are often poor developers that are unable to develop responsive applications, especially in the case of applications that require heavy data access.

    The drama with Flash is that it is a technique for creative people that slowly slips to a developer tool. Come on, how much regular Flash developers understand or have even worked with Flash remoting in conjunction with J2EE? 5 percent? Even less, I would not be surprised!

    Bertrand
  32. Bertrand,

    > Steven, I simply can't adhere to your arguments. Being a developer or
    > an UI designer are simply two different professional jobs.

    Again, with reference to my previous message it's really what kind of
    UI are we talking about ? I forsee the rich-client as a technology
    that can provide a better user-experience over and above JSP, not a
    better user-experience over and above a desktop application. I'm not
    suggesting that Borland rewrite JBuilder with Flash and J2EE, I am
    suggesting that Online Banking, Airline Reservations, Stock Trading,
    Online Commerce, etc, become better user-experiences using a rich-client
    technology such as Flash, rather than a thin-client, thin-experience
    technology such as JSP.

    Right now, most of us probably employ creative developers, web
    developers and graphic designer to design the front-ends for our
    web applications. To me, the rich-client is an alternative UI
    for those applications...is that fair comment ? We replace the
    HTML, Javascript, DHTML, CSS, JSP, etc, skillset, with Flash and
    ActionScript (to a much lesser extent) skills.

    And if our UI merits usability engineers, we bring them in regardless
    of technology on the presentation tier - me bringing that into this
    discussion has just clouded the point I think...sorry.


    > Swing and will probably never do: they are prototyping user interfaces
    > using tools like Adobe Photoshop or Visio, and sometimes Flash when a
    > static model of the user interface is not enough.

    I think we might have 2 different concepts here, of what kind of UI
    we're talking about.....are you using Swing as a competing technology
    for JSP ? Or are you building desktop applications ?

    > to be found. And conversely, UI designers are often poor developers
    > that are unable to develop responsive applications, especially in the
    > case of applications that require heavy data access.

    I'll concede here. I guess the thrust of my argument, is that:

    Currently - J2EE guys on server side, JSP presentation tier provided by
    the Web Developers and Graphic Designers. J2EE guys might create
    functional JSPs, but the "dressing up" is done by creative developers.

    Rich Internet Applications - J2EE guys on server side, JSP presentation
    tier skills replaced by Flash developers, with appropriate pattern based
    architecture ensuring that neither the J2EE guys or the Flash guys have
    much code to write on the client, other than that concerned with passing
    data between client and server in a suitable fashion.

    > The drama with Flash is that it is a technique for creative people
    > that slowly slips to a developer tool. Come on, how much regular Flash
    > developers understand or have even worked with Flash remoting in
    > conjunction with J2EE? 5 percent? Even less, I would not be surprised!

    You're preaching to the converted I'm afraid :) To me, Flash Remoting
    puts a Flash UI within the grasp of a J2EE developer, but in no way puts
    J2EE in the grasp of a Flash developer.

    Heaven forbid. Shudder.

    Steven
  33. Client-side Development[ Go to top ]

    I'm a senior information architect - that space between client-side and server-side development is where I am.

    Yes, I think that it's good to separate those roles, because I've found it a rare thing that someone is both an excellent J2EE developer and interested in client-side issues, like HCI, usability, look and feel, etc. Especially for enterprise applications, it makes more sense to divide the responsibilities. For me, I lead the client-side development team, and work closely with the server-side developers to keep everything coordinated.

    However, something to keep in mind - when you separate out those two roles, you have a problem of scope creep sometimes on the client side. When customers see the user interfaces, they often ask for more functionality...many times, the first time they understand a system is when they see that user interface. To keep things in sync, the client-side team needs to have a basic understanding of how things in the client affect the server-side code. Doesn't matter if it's a rich client or a thin client.

    So, I'd say encapsulate the two, but make sure messages are getting back and forth between the teams. :)
  34. Conflicting arguments?[ Go to top ]

    Tom,

    I'm not debating that a lot of what you say is currently true, however:

    1. With faster internet connection speeds a 10MB download is becoming less of a show-stopper than it once was. If users were only required to download one new version of the JRE every year or so then I don't see this being a big deal if they see benefits from it.

    2. I agree that Sun needs to do some work here. But there is no inherent reason that the experience needs to be any more painful than with Flash (apart from the download size).

    3. I don't have much experience with sites that use Flash (I seem to very rarely visit sights that use it), but I imagine that Flash apps that make use of new functionality will require you to download the latest version of Flash just like with Java (even if the download is a lot smaller)?

    I don't agree that users get a shoddy impression from having to download updates to their software (as long as it is a relatively painless experience) - by now Windows users will be very familiar with having to frequently download service packs, security updates, etc... However, I do take your point that not all OSs support the latest JRE and that there is some element of compromise necessary here.

    4. I can quite well imagine that it is much easier to create good-looking results in Flash than in Java. And my experience as a user is that they do look better. However, I do not agree that looks are the same as "quality".

    Perhaps we are just talking about different kinds of client apps. If we are just talking about apps that are basically presentation and navigation, then Flash is quite probably the way to go. However, if we are talking about significant processing on the client PC then I think Java is a better fit.

    <Steven Webster>
    However, try and find someone that has a creative bone in their body, AND is able to understand the Swing API, or similar....
    </Steven Webster>

    I would say that this also holds true in reverse: I think you will struggle to find many UI designers who really understand programming. If you require your client app to do more than just presentation and navigation then it is more important to find someone who can program well so that you end up with an app that is maintainable, flexible, and robust...

    Regards,
    Lawrie
  35. Conflicting arguments?[ Go to top ]

    Lawrie,

    > I would say that this also holds true in reverse: I think you will struggle to
    > find many UI designers who really understand programming. If you require your
    > client app to do more than just presentation and navigation then it is more
    > important to find someone who can program well so that you end up with an app
    > that is maintainable, flexible, and robust...

    Again, I wholeheartedly agree. I'm NOT advocating writing business logic on the client here, perhaps that is where the fence is implicitly put-up between those that favour Java WebStart/Swing/etc and those that favour a Flash-a-like.

    Definition of a rich-client application, to me, is all the advantages of a thin-client combined with the usability and user-experience of a desktop application.

    I would advocate that a rich-client Flash application, or RIA (Rich Internet Application) maintain business logic on the server, and that the rich-client is nothing more than a view, albeit a more interactive, responsive and engaging one.

    Steven
  36. everything work fine, but[ Go to top ]

    Steven,

    There are many things I like with using Flash MX as a rich-client application, for instance the low memory footprint – 300-400K compared to 10MB with Java, that you do not have to do everything in Flash, just a part of the page, that the XML-RPC works perfectly – you do not always need Remote Server. In short – everything work fine when finished – the problem is to finish!

    ..in writing a server-side enterprise Java application, say for online banking, I'd perhaps use only 5% of the functionality of the available Java class libraries

    The allorgy is not perfect, in Java I never need to see or care about the classes I don’t use, but in Flash everthing I don’t use is constantly present, obstructing my view. Especiallly it is difficult to get a birds view on the code, the code is hidden here or there in the most amazing places, and if you try to put the code as extern textfiles - then the debugger does not work..

    In short, I think that Macromedia has to come up with a brand new separate IDE for application developers. As it is now, the code is unmaintainable for nontrivial projects. Worse than VB in fact..

    Regards
    Rolf Tollerud
    P. S. I will certainly read your book, when it comes out!
  37. everything work fine, but[ Go to top ]

    Hi Rolf,

    > The allorgy is not perfect, in Java I never need to see or care about the
    > classes I don’t use, but in Flash everthing I don’t use is constantly present,
    > obstructing my view.

    Fair comment, which I can't disagree on. I guess one of my feelings however, is that as a J2EE developer, it's not MY job to develop the UI...I hand that over to a Flash designer/developer, who doesn't feel obstructed by THEIR tool. I'm not particularly interested in how they create the UI, but rather that they create it with some "contract" in place between J2EE and Flash.

    But I accept your point, and we agree that for real uptake of Flash and J2EE (or Flash and any serverside technology) it would be useful to have a visual interface designer that isn't so animation-centric. I'd be surprised if this hadn't gone unnoticed within Macromedia to be honest....my eyes are peeled !

    > Especiallly it is difficult to get a birds view on the code, the code is
    > hidden here or there in the most amazing places, and if you try to put the
    > code as extern textfiles - then the debugger does not work..

    Again, we share concerns. However, I would advocate that the ONLY way to develop on the client-side, is to keep code in external files; this is Macromedia Best Practice guidelines, and I stand by it from my own experience as well. As for the debugger ... well, my personal view is that the debugger is like a poor stable door; whether you shut it before or after the horse has bolted, doesn't really matter if you're the horse -- it's still getting out :) Rather, I'd advocate a proper unit-testing methodology on the client...on the server, I'd use JUnit, Cactus, etc, and the client should be the same. Well, in my book, I advocate such a methodology, using the ASUnit project that Robin Debreuil threw together....you'll find links to ASUnit and it's documentation on my companion site at the foot of this message.

    I'd much rather advocate test-driven or at least test-supported development with external ActionScript files, than, as you correcly point out, obscure and hide code mixed in with visual elements in Flash, which is a nightmare by all accounts.

    > In short, I think that Macromedia has to come up with a brand new separate IDE
    > for application developers.

    I agree....but also, if we can separate the roles required for client and server-side development, so that "each to their own" applies, that's not so much of an issue (though I do agree it's an issue Macromedia need to address, but it's not a showstopper in the slightest, and certainly not worth dismissing the technologies because of).

    My concern is putting together teams to build Enterprise rich-client applications, not in "doing it all myself" (you don't even want to see what one of my attempts at a Flash interface looks like....). Content and coders don't mix ;)

    > As it is now, the code is unmaintainable for nontrivial projects.
    > Worse than VB in fact..

    Again, I think I can confidently disagree on that *provided* that code is no longer attached to components that are nested all over the place on a Flash timeline. Keep the client-side UI and the client-side code separate, through external code files, packaged like Java files, using a design pattern inspired approach to OO code on the client, with unit-testing in place, and I don't think the code is unmaintainable at all.

    But as we both know...you can write bad code in ANY language ;)

    Best wishes,

    Steven
    Companion Site for Reality J2EE
  38. Java Web Start[ Go to top ]

    FYI, Java Web Start DOES support JVM versioning! If you don't have the appropriate JVM installed for an application, automatic download and installation is available. More information here:

    http://java.sun.com/products/javawebstart/developers.html

    All is not perfect with Java Web Start, however. For example, cache management is still too primitive for applications that rely on resources that change frequently because there is no JWS-friendly way to discard resources from old releases (JWS creates a new directory to store the new resources and keeps the old directory). There are also some stupid things: it is for example not possible to straight display a splash screen for the downloaded application (there is always the JWS-specific splash screen that pops up first) what is simply not acceptable when you write commercial applications. All in all, JWS is going into the right direction but the efforts put by SUN in client-side Java promotion are far too weak.

    Bertrand Fontaine
    INSPIRE IT - www.inspireit.biz
    JavaShelf.com: Your Java bookstore on the Web!
  39. Servus Rolf Tollerud,

      I hope you realize that I (Gerald Bauer) am the project lead of Luxor and the publisher of the Richmond Post (aka Chronicle of the XUL Revolution) when you dish out headlines like: Immature hackers behind standalone XUL

      If someone is immature and naive than it's your blind belief that you can reform Micro Willy and his Yes-Man-Brigade.

      I assume you consider yourself mature by relentlessy pushing the Microsoft agenda in a Java forum. How much do they pay you? Or do you strive for a job in Redhell?

      - Gerald
  40. It is not an Oscar but,[ Go to top ]

    Gerald,

    i>I hope you realize that I (Gerald Bauer) am the project lead of Luxor and the..

    People who know me, know that I have often criticized projects dominated by “well-meaning impractical theoreticians”. I have seen many idiotic project in my life but "Luxor: The "Linux Kernel" for Desktop Apps" takes the price! I hereby nominate you for the most well-meaning impractical theoretician of the year!

    Congratulations. The competition was stiff!

    Regards
    Rolf Tollerud
  41. Please, no insults Mr. Microsoft[ Go to top ]

    Servus Rolf,

    > I have often criticized projects dominated by “well-meaning impractical
    > theoreticians”. I have seen many idiotic project in my life but "Luxor:
    > The "Linux Kernel" for Desktop Apps" takes the price! I hereby nominate you
    > for the most well-meaning impractical theoretician of the year!

      Can you expand on how you come to the conclusion that I'm an impractical theoreticians?

      Why not show off some of your work. What projects do you lead that make you credible?

      - Gerald
  42. What projects do you lead that make you credible?

    And what projects do you lead that make you credible?

    Just a little advice. Cut the Microsoft crap - this is not Slashdot.

    Regards
    ROlf Tollerud
  43. Flash Is a Dead-End[ Go to top ]

    Looks like this thread is degenerating in a Flash love-fest. Before you embrace the closed-source payware, consider the bigger picture (a.k.a. web architecture) and why SVG (Scalable Vector graphics) for 2D graphics is the better way:

    * XML Syntax - mixes easily with established and emerging XML standards such as: XHTML, XUL, MathML, XForms; XML is the lingua franca because it's simple, extensible, royality-free; operating system or programming language independent and much more

    * Web Services - mixes easily with Web Services; send SVG diagrams or animations via SOAP messages or create rich graphical user interfaces for Web Services

    * Styling with CSS - use a single style language for XHTML, XUL and SVG

    * Animation with SMIL - use SVG docs in multimedia SMIL presentations to mix vector graphics with audio and video

    * DOM and Scripting - use Javascript to access the SVG document tree at-run-time

    * Modul-Mania - use SVG Tiny or SVG Basic on mobile-devices (cell phones, palms, etc.)
      
    For more details how SVG and Flash match up check out my SVG talks slides including:

     * Slide #41: SVG vs. Flash vs. GIF vs. PNG vs. PDF
     * Slide #42: SVG vs. Flash - What's wrong with Flash?
     * Slide #43: Why SVG? Isn't Flash, .Net GDI+ or Java2D enough?
  44. I'm also looking for such solution: rich UI web/thin client (non-java) that doesn't require big download/installation on the client machine. The thought of Flash did come across my mind, but I don't have much experience with it. We are using Java Web Start right now to provide rich UI, but it is definitely not thin client, and Java Web Start has its own share of problems.

    There is also another problem that we're building applications that require offline mode operation, and have data upload to the server when user reconnects. I haven't seen many solutions out there beside .NET which some companies such as SalesForce.com is using.

    Co
  45. Il nuce[ Go to top ]

    Co,

    IE6 have something called "Viewlink Behaviors" that can be used to parse XML and build components on the client. The problem is that it is slower (JavaScript) that Mozilla/XUL rendering - on the other hand you can build custom client components that are isolated from the main page HTML.

    The two techniques does should work very well together - but that is dreamland.

    At least Mozilla now have the all-important XMLHTTP. A way of getting data from the server without a total rewrite of the page.

    The browser wars go on - it is an outrage really.

    Regards
    Rolf Tollerud
  46. what about xforms?[ Go to top ]

    Wouldn't xforms be the answer to all this? And more: isn't it a competitor to Java Server Faces and .Net's Web Forms?
  47. what about xforms?[ Go to top ]

    Xforms is for mundane data entry, useful for seperating markup and data, but contains nothing approximately like the elegant UI widgets possible with XUL.
  48. XForms x XUL[ Go to top ]

    On the other hand, XForms supports "model item properties" such as "relevant", "required", "valid", etc., which as far as I know, XUL does not support in any shape or form. These features are very useful for client-side data validation.

    XForms will also allow the use of W3C XML Schema to specify data types (such as numbers, dates, or custom formats such as a ZIP code). Again, not supported by XUL (to the best of my knowledge).
  49. XForms x XUL[ Go to top ]

    Rogerio,

    If this is true (which I read somewhere),

    "XUL is a fine XML based language --but its goal is to create
    UI widgetry --and UI widgets alone do not an application make."

    Then XForms will still have its place, obviously. But I really do not know what I am talking of as I do not have enough information! That was why I started the thread in the first place..

    But one thing I am certain of - that neither Java or .NET have any place in the future rich client web-applications. It must be light-weight!

    Regards
    Rolf Tollerud
  50. XForms x XUL[ Go to top ]

    After visiting the mozdev.org, and played around a while, a have become convinced that MS are doing a big mistake not to support XUL. A really BIG mistake.

    Regards
    Rolf Tollerud
  51. <Co Hoang>
    There is also another problem that we're building applications that require offline mode operation, and have data upload to the server when user reconnects. I haven't seen many solutions out there beside .NET which some companies such as SalesForce.com is using.
    </Co Hoang>

    You could investigate using CachedRowSet, which is serializable, or a more advanced solution involving full bi-directional database synchronization such as Pointbase (www.pointbase.com), if needed.

    Bertrand
  52. Droplets[ Go to top ]

    I am very happy to see so much interest in rich clients these days.

    In another forum (http://www.boxesandarrows.com/archives/htmls_time_is_over_lets_move_on.php?page=discuss#7995), I recently saw what seemed like a pretty good list of characteristics for an effective rich thin-client architecture:

    1. low bandwidth
    2. large variety of prebuilt UI widgets (combo boxes, etc.)
    3. interoperable with multiple backend technologies
    4. platform independent
    5. ease of distribution (no massive runtime)
    6. code lives in a central location
    7. interactive manipulation of display
    8. refresh data without refreshing UI
    9. user-controlled access to system services (save, drag'n'drop to desktop, print, etc.)
    10. simple development/IDE
    11. vector and bitmap graphics
    12. multimedia (audio, video)
    13. open/unemcumbered by IP

    Now, I don't want this to sound like an ad, but this is the problem that my company, Droplets, specifically solves. I believe that the Droplets framework addresses every one of the characteristics above well. But don't take my word for it. If you're interested, please try it out yourself:
    http://www.droplets.com/developer/

    Thanks much.
    - Philip
  53. droplets's demo[ Go to top ]

    the email demo: tonight,I have logined in again and again.....but i only see a plan form. nothing .

       Low bandwidth? no, I use ADSL.