Macromedia launches New Rich Client Platform Flex

Discussions

News: Macromedia launches New Rich Client Platform Flex

Bookmark and Share Get thread feed

  1. Macromedia launches New Rich Client Platform Flex (50 messages)

    Macromedia today unveiled Flex, a rich client presentation tier development platform that allows developers to define rich UIs using an XML-based language (through which a great class library and runtime services can be accessed) that gets rendered into a rich apps using using Flash & J2EE servers as the standard deployment infrastructure. Flex is currently in public beta, with full launch occuring in the second half of 2004.

    Flex will allow you to create apps that are richer, with more logic running in the client, while developing in a manner reminiscent of JSP. Flex code gets compiled into a standard Flash SWF file and deployed into a Java Servlet egnine as a WAR file. The initial Flex release will run on top WebLogic, Websphere, Tomcat, and JRun (only a servlet engine is required).

    Flex is not a competitor to JSF. Whereas JSF is more about simplifying model 2 development, Flex is about enabling rich client development over existing standard infrastructures (Flash and Java, although a .NET version is also planned for next year).

    Check out:
    Flex homepage, white paper and press release.

    Macromedia engineers Sean Neville and Christophe Coenraets have also blogged about Flex today.

    Also, Kris Thomson did a similar news post on this same topic, today (the body of which is included here):

    Macromedia is currently developing technology they call Macromedia Flex expecting to release in the first half of 2004. This product attempts to fill in the void created by HTML based web application to help business provide their customers with a richer experience on the web using Flash and make it easier for developers to work with Flash.

    Besides the obvious reasons for considering this technology which are the limitations that HTML is bound to for web applications, there are also business drivers too. These drivers are largely due to the common trend by companies to utilize the web as a means to communicate with their customers which decreases personal interactions they have with their customers. While is good at driving down costs, the long term affect on the relationship with the custom is uncertain.

    Many developers, especially those who come from a client side application development have complained for years about the limitations that are inherent of HTML. Java Server Faces is trying to capture some of that weakness in the user experience but still in the end JSF will be using HTML. Are we going to see a rebellion of business demanding we give their clients a richer experience currently not available on the web meaning either product like Macromedia Flex or back to client server solutions?
      
    Any thoughts?
    Reply to this

    Threaded Messages (50)

  2. DHTML can do better than Flash[ Go to top ]

    With the exception of vector graphics, DHTML is a better platform than Flash for data-intensive rich clients. DHTML-based rich-client application frameworks have been on the market for a couple of years now, and they are more advanced than anything done in Flash. They provide:

     with declarative (XML tag) develop

    For vector graphics, Flash is the most broadly deployed plug-in. But SVG is gaining more acceptance, as an open standard, in organizations that can accept plug-ins.




    Besides the obvious reasons for considering this technology which are the limitations that HTML is bound to for web applications, there are also business drivers too. These drivers are largely due to the common trend by companies to utilize the web as a means to communicate with their customers which decreases personal interactions they have with their customers. While is good at driving down costs, the long term affect on the relationship with the custom is uncertain.

    Many developers, especially those who come from a client side application development have complained for years about the limitations that are inherent of HTML. Java Server Faces is trying to capture some of that weakness in the user experience but still in the end JSF will be using HTML. Are we going to see a rebellion of business demanding we give their clients a richer experience currently not available on the web meaning either product like Macromedia Flex or back to client server solutions?
    Reply to this Reply to original

  3. DHTML can do better than Flash (repost)[ Go to top ]

    (oops -- hit Reply too soon by mistake...)

    With the exception of vector graphics, DHTML is a better platform than Flash for data-intensive rich clients. DHTML-based rich-client application frameworks have been on the market for a couple of years now, and they are more advanced than anything done in Flash. They provide:

      * richer GUI controls (ever see a pivot table in flash?)

      * declarative development in XML tag languages (a standard will prevail!)

      * background client-server communication without page reloads (commonly held up by Macromedia and others as the big limitation of HTML)

    DHTML is like the assembly language of the web. It ~is~ very difficult to work with, but you can build abstraction layers on top of it. Client CPUs are fast enough to handle these layers now. And the clients that run them are truly ubiquitous, open, and standard.

    For vector graphics, Flash is the most broadly deployed plug-in. But SVG is also gaining more acceptance, as an open standard, in organizations that can accept plug-ins.

    Just my biased 2 cents. :o)

    Jeff Dill
    Isomorphic Software
    www.smartclient.com
    Reply to this Reply to original

  4. DHTML can do better than Flash (repost)[ Go to top ]

    As for DHTML, like you said it's too hard to use for most web guys and it also pretty much means you depend on IE's version of DHTML which is a dead end even as far as the evil empire is concerned as in case you haven't noticed they're busy ditching it for XAML.

    As for SVG, did you read the original posts? It looks like you can use SVG in Flex if you want. CSS, too.
    Reply to this Reply to original

  5. DHTML is not browser specific any more!!![ Go to top ]

    As for DHTML, like you said it's too hard to use for most web guys and it also pretty much means you depend on IE's version of DHTML which is a dead end even as far as the evil empire is concerned as in case you haven't noticed they're busy ditching it for XAML.


    DHTML is not browser specific any more, it IS now possible to write DHTML/JavaScirpt that works well in all major browsers.

    We are developing rich UI web application using DHTML and JavaScript on the client side. We have no major problems with different browsers and we have successfully developed a number of DHTML/JavaScript controls (tree, button, image button, date picker, tabbed pane, popup menu...) that runs equaly well in IE 5.0, 5.5, 6.0, Mozila and Netscape 6 and 7. These controls are then wrapped by JSP tags for easier use and some of them are client-server based (like tree control). So we have nice apstraction layer over DHTML/JavaScript in the form of standard ('desktop') UI components. We look forward to develop Grid, SpinEdit, ProgressBar and other controls and to integrate them in JSF when it goes final.

    Mileta
    Reply to this Reply to original

  6. DHTML can do better than Flash (repost)[ Go to top ]

    Flex does support SVG and CSS. You can integrate it into your other XML or point to external files and wraper it as an image, etc. (as I remember). The beta for the product contains examples to this end.
    Reply to this Reply to original

  7. DHTML can do better than Flash (repost)[ Go to top ]

    No , not really!

    DHTM ,in my limited experience , has the following problems
    a) Messsy Java Scripts
    b) Slow rendering : If your UI has to render a lot of objects , the rendering just doesn't keep up e.g. a Tree with over 200 nodes , a DHTML render will take ages to diplay all the nodes
    d) Platform support -- the evil empire imposes non standard DHTML behaviour and code that doesnt work on Mozilla or Opera.
    e) RPC : when you want to keep parts of your screen same while changing some sections based on user actions, there isn't much that DHTML can do for you. YOu have two eqally bad choices -- Frames or Pop-Up with javascript -- both make the user experience unpleasant.


    I use DHTML for light fluffy stuff that makes a user happy with the interface(thems, skins etc.). However when the requirement is for a rich user interface that can scale and is fast , I only have two choices -- Java Applet and Java Webstart. It will be nice to see how Flex measures up.
    Reply to this Reply to original

  8. you can have rpc, sorta[ Go to top ]

    e) RPC : when you want to keep parts of your screen same while changing some sections based on user actions, there isn't much that DHTML can do for you. YOu have two eqally bad choices -- Frames or Pop-Up with javascript -- both make the user experience unpleasant.


    if you use a small i frame as the transport, you can send requests from that, that return xml, which can be copied to the places you need them.

    with some tweaking, this actually works ok

    sincerely
    morten wilken
    Reply to this Reply to original

  9. you can have rpc, sorta[ Go to top ]

    e) RPC : when you want to keep parts of your screen same while changing some sections based on user actions, there isn't much that DHTML can do for you. YOu have two eqally bad choices -- Frames or Pop-Up with javascript -- both make the user experience unpleasant.

    >
    > if you use a small i frame as the transport, you can send requests from that, that return xml, which can be copied to the places you need them.
    >
    > with some tweaking, this actually works ok
    >
    > sincerely
    > morten wilken

    The problem is in inconsistent behaviour -- e.g. iframes based DOHICKEY solutions may work for in on IE but fail on Mozilla and Opera.

    -manish
    Reply to this Reply to original

  10. dhtml has RPC support[ Go to top ]

    Am I the only one that uses activex in javascript, they have a nice xmlhttprequest object, or you can use the Netscape version which Netscape designed to follow along the lines of the xmlhttprequest activex object. Also there is another activex object that will do webservices calls (I haven't actually gotten it to work). But the support for any of this is spotty at best, I usually refer to Netscape for the xmlhttprequest object they have much more friendly documentation. I do look forward to seeing FLEX come alive. I think it'll take a step in the right direction to making it easier to make richer clients. Also I wonder if the FLEX will be compatable with the new Macromedia's Code Central.
    Reply to this Reply to original

  11. You can have cross-browser DHTML RPC[ Go to top ]

    The problem is in inconsistent behaviour -- e.g. iframes based DOHICKEY solutions may work for in on IE but fail on Mozilla and Opera.


    I have had good success with a cross-browser DHTML library called DynAPI3 -dynapi.sf.net. It provides both synchronous and asynchronous RPC mechanisms and is claimed to work on many different browsers (although I've only used it on IE5, IE6 & Mozilla1.4). It's not too hard to connect to a Java servlet and you can build a rich UI that looks almost indistinguishable between IE & Mozilla.

    Having said that, I'll concede that are issues with the rendering speed when the number of screen objects becomes large. Also, I would only consider using it in and intranet situation where you had some assurance re browsers versions.

    - Andrew Gillett
    Reply to this Reply to original

  12. DHTML can do better than Flash (repost)[ Go to top ]

    No , not really!


    Yes, really!!

    I know this is hard to believe if you have struggled with HTML, CSS, and JavaScript for the past five years, but it is possible.

    Can you point to any Flash application on the web that is more advanced than the DHTML-based examples at smartclient.com?


    > DHTM ,in my limited experience , has the following problems
    > a) Messsy Java Scripts

    This situation is ~exactly~ the same as with Flash. You either program your own messy JavaScript, or someone else builds a system that supports an easy-to-use XML tag language.

    Currently Flash developers have to use ActionScript, which is essentially JavaScript. For XML development, Laszlo (laszlosystems.com) is a couple of years ahead of Macromedia. They have a product ~now~. Flex is due in late 2004.


    > b) Slow rendering : If your UI has to render a lot of objects ,
    > the rendering just doesn't keep up e.g. a Tree with over 200 nodes ,
    > a DHTML render will take ages to diplay all the nodes

    Very hard problem, but it has been solved.

    DHTML is currently ~faster~ than Flash for text-heavy components like trees and tables. Go to smartclient.com with Netscape 4, Netscape 7, Mozilla, or IE and see for yourself.

    Charting and graphing are good applications for Flash, which can be embedded and controlled by a DHTML application.


    > d) Platform support -- the evil empire imposes non standard DHTML
    > behaviour and code that doesnt work on Mozilla or Opera.

    See platform list above. IE, Netscape, Mozilla, and Safari are the dominant desktop browsers. Opera is not a contender on the desktop. Their focus has shifted to embedded browsers on mobile devices.


    > e) RPC : when you want to keep parts of your screen same while changing some sections based on user actions, there isn't much that DHTML can do for you. YOu have two eqally bad choices -- Frames or Pop-Up with javascript -- both make the user experience unpleasant.

    Another tough problem, but it was solved years ago. DHTML client/server communication over HTTP can be completely transparent to the end user. Go to smartclient.com and see for yourself.


    Jeff Dill
    Isomorphic Software
    www.smartclient.com
    Reply to this Reply to original

  13. DHTML can do better than Flash (repost)? What a bullshit![ Go to top ]

    I can not agree with you guys and i think flash still is the better way to go.

    Now your guys check these sites firstly:
    www.yugop.com
    www.praystation.com
    www.flight404.com
    www.balthaser.com

    Now you can say that your DHTML is smart enough?

    flash supports webservice.
    flash supports access data remotely.
    flash supports video(only a 400k plugin).
    flash can works perfectly on almost platform include embed device(Nokia9210,3650,7210.NTT DOCOMO)
    flash has lots of components and could accelerats your development.
    ........
    Reply to this Reply to original

  14. DHTML can do better than Flash (repost)? What a bullshit![ Go to top ]

    www.yugop.com

    > www.praystation.com
    > www.flight404.com
    > www.balthaser.com

    Yes some of those sites *look* great, but they are all utterly
    unusable if you are trying to get to some information. And what about
    this:

    o flash does not support the browser's bookmarks
    o flash does not support the browser's "Back" button
    o flash content is not indexed by Google
    o most flash pages do not scale (I can barely read the text on all
      those sites except the last one)

    Flash is great for artists. Reserve it for small interactive portions
    of your Web sites that really benefit from it.

    -Erik
    Reply to this Reply to original

  15. Re: DHTML can do better than Flash (repost)? What a bullshit![ Go to top ]

    o flash does not support the browser's bookmarks

    Yup, doesn't.

    o flash does not support the browser's "Back" button

    It does. Take a look at the Macromedia site itself, it handles the back button gracefully.

    o flash content is not indexed by Google

    Point.

    o most flash pages do not scale (I can barely read the text on all
      those sites except the last one)

    This is more of a problem with accessibility than with Flash itself, as a technology. One huge downside of using Flash, though, is that you make your content impossible to use by anything that's not a Flash-enabled HTTP client, and graphic browsers are not the only HTTP clients out there - Google is one, but think about screen readers for blind people, proxies, WAP proxies (well, those are dead anyways), text-based browsers and the like.
    Reply to this Reply to original

  16. Re: DHTML can do better than Flash (repost)? What a bullshit![ Go to top ]

    Hi ,Flash does suppport accessibility. Pls check Macromedia's site.
    Flash supports scale. I can send you all a copy of my work.
    Reply to this Reply to original

  17. Re: DHTML can do better than Flash (repost)? What a bullshit![ Go to top ]

    Flash supports scale. I can send you all a copy of my work.


    Please do :-)

    It's interesting that almost nobody mentions Java applets in this topic. The idea of applets is surely not dead?!

    Rationally, Java / applets with a programming interface designed for business app UI (= Swing) _should_ be more suitable for the typical rich client than Flash technology that was originally designed for animations.

    Applets also have more chance especially now that all major PC vendors have promised to provide Sun's JRE installed. Java on the client side, cooperating with Java on the server side (= one common language), is much simpler than Flex client + Java on server (i.e. 2 languages). E.g. just think about the simplicity of object serlialization.

    BTW, I checked some of the above mentioned Flash sites. The download sizes are anything between 200k and 1.2 Megs! In the long run, applets may be faster to donwload, as they are faster to display things.

    What do you think?
    Reply to this Reply to original

  18. Re: DHTML can do better than Flash (repost)? What a bullshit![ Go to top ]

    Applets are sure the way to go, BUT, there is only one problem with applets:
    You need JRE on the client, and that can be a BIG problem. I this is solved (which I doubt it will), then nothing is better then applets!
    Reply to this Reply to original

  19. Flash vs Applets[ Go to top ]

    I have developed an application with applets.... and the client decided not to deploy it, it was so very, very slow.

    Flash is realtively smaller and faster and has richer UI and is easer to install as a plug in. The brodbad is comming and users want the "MTV" experience.
    There is no comparision, flash is much better. "Java everywhere" is not an archtecure, for example you need SQL for a model. Take a look at the eval version of Flash 2004 Pro with a data grid you just place on stage.
    Take a look at the BluePrints petstore for relative comparision, applets can't dream of this:
    http://www.macromedia.com/devnet/mx/blueprint/instructions_cf.html

    It works in Linux browsers, Pcoket PC and most every PC browser.
    .V
    Reply to this Reply to original

  20. RE: Flash vs Applets[ Go to top ]

    Have you looked at Thnlets (http://thinlet.sourceforge.net)? This is a very fast rendering framework with a small download footprint (38K + your code). The demo is here, so you can check for yourself http://thinlet.sourceforge.net/demo.html
    Reply to this Reply to original

  21. Flash vs Applets vs DHTML[ Go to top ]

    I think Flash has a bright future on the client side, because:

    1.The host plugin has the largest deployment base
    - It is claimed that is bigger than Java on both desktops and mobile devices
    - I may be wrong but, I think DHTML is not supported on mobile devices

    2.There are no compatibility issues. A flash application behaves identically on different platforms/hosts
    - I think I can say the same thing about Java here
    - DHTML has compatibility issues, same goes for Javascript, and I think we all know this.

    3.The same code can be compiled an deployed as a web client or as a standalone application
    - Java requires different design strategies for desktop apps vs applets
    - I'm not aware of any dhtml compilers that generate standalone applications (is there such a beast?)

    4. It may be just a matter of taste here, but I think Flash can give user a more pleasant experience
    - better than applets or Swing based applications (a notable difference: IntelliJ IDEA)
    - smoother and richer than DHTML (again I may be subjective)

    Ovi Comes
    zulu.netspedition.com
    Reply to this Reply to original

  22. Flash and Accessibility[ Go to top ]

    | This is more of a problem with accessibility than with Flash itself, as a
    | technology. One huge downside of using Flash, though, is that you make your
    | content impossible to use by anything that's not a Flash-enabled HTTP client,
    | and graphic browsers are not the only HTTP clients out there - Google is one,
    | but think about screen readers for blind people, proxies, WAP proxies (well,
    | those are dead anyways), text-based browsers and the like.

    Guys - not any more; Flash is more than capable of supporting accessibility,
    and ships with an accessibility API that makes it easy to make sites
    compatible with screenreaders such as JAWS and Window Eyes.

    Check out http://www.macromedia.com/macromedia/accessibility/ for the
    wealth of information about how Flash is an accessible user interface
    technology.

    On a more general note - I'm already seeing a lot of FUD here about
    what Flash is and isn't, and what it can and can't do.

    Steven
    --
    Steven Webster
    Technical Director
    http://www.iterationtwo.com/
    Reply to this Reply to original

  23. Flash for Rich Internet Applications[ Go to top ]

    Flash is great for artists. Reserve it for small interactive portions

    > of your Web sites that really benefit from it.

    This is the *point* of technologies such as Flash Remoting, the
    features released in Flash MX 2004 Professional, and the forthcoming
    Flex initiative.

    It's a shift in emphasis, or rather an alternative emphasis, in using
    the Flash player (which let's be honest, is pretty damn ubiquitous,
    is a tiny download if you're one of the 2 or 3% that don't have it
    installed, and is available also for devices, phones, PDAs, set top
    boxes, etc) as a renderer for a rich and interactive user interface.

    Once we stop using Flash to deliver skip-intros, it becomes a very
    viable technology for delivering rich and interactive user interfaces,
    that are fast, that are responsive, and that are able to tightly
    integrate with a J2EE infrastructure.

    There are a lot of really nice Rich Internet Applications out there
    that use Flash, but more importantly, the technology is not an
    impedance to developing fast, rich and interactive user experiences,
    but rather the people who use the technology.

    Bad user experiences can be built in XUL, Flash, DHTML, HTML, Java
    Applets, etc....it's down to the team involved.

    Steven Webster
    Technical Director
    www.iterationtwo.com
    Reply to this Reply to original

  24. DHTML can do better than Flash (repost)[ Go to top ]

    actually charting can be done with dhtml aswell , if you don't mind being
    restricted to ie that is

    see:

    http://www.i-see.net/bindows/
    Reply to this Reply to original

  25. DHTML can do better than Flash (repost)[ Go to top ]

    Currently Flash developers have to use ActionScript, which is

    > essentially JavaScript.

    ActionScript 2.0 has moved on a great deal from the scripting language
    that *was* ActionScript. It's a full object-oriented implementation,
    based on the ECMA-262 specification - indeed Macromedia just announced
    their joining of the ECMA International association:

    http://www.macromedia.com/macromedia/proom/pr/2003/joins_ecma.html

    With AS2.0, we now have a class-based language that is *incredibly*
    similar to Java, which makes client and server-side development
    very similar; we can share object-models on the client and server,
    and in our experience, a decent Java developer is up-to-speed
    writing AS2.0 in days rather than weeks.

    We have even offered a unit-testing framework to the development
    community, called AS2Unit (http://www.as2unit.org) which has
    allowed us to perform test-driven development and unit-testing
    of client-side code -- something we haven't been able to achieve
    so easily with other technologies such as DHTML or XUL for
    instance.

    With AS2.0, moving business logic to the client isn't a technical
    risk for us, as we can still support it through our best
    practices such as test-driven development, use of design patterns,
    refactoring, etc.

    I appreciate many probably have the experience of ActionScript
    up there with the horror of having to develop applications with
    lots of JavaScript in them - I know I did :) - but things really
    have moved on significantly.

    We recently contributed a chapter "ActionScript 2.0 Design
    Patterns for Rich Internet Applications" to the recently
    launched ActionScript 2.0 Dictionary, if anyone is interested
    in seeing how design patterns such as Service Locator, Business
    Delegate, Value Object, Command Pattern and Front Controller,
    can be migrated onto a rich-client using ActionScript 2.0,
    rather than Java.

    Steven Webster
    Technical Director
    http://www.iterationtwo.com/
    Reply to this Reply to original

  26. AS 2.0 not quite OO yet[ Go to top ]

    ActionScript 2.0 has moved on a great deal from the scripting language

    > that *was* ActionScript. It's a full object-oriented implementation,
    > based on the ECMA-262 specification - indeed Macromedia just announced
    > their joining of the ECMA International association:

    As someone who does alot of Actionscript/Flash programming on the side just for fun and J2EE for $$, Actionscript 2.0 is NOT fully object oriented. The lack of method overloading is a glaring weakness for any language which bills itself as Object Oriented. Actionscript 2.0 is essentially a new syntax for the same language. All your actionscript is compiled down to actionscript 1.0 anyways.

    Also, where's the compiler? I'm not cheap, I have Studio MX 04, but I'd much prefer Macromdia release an actionscript compiler to the general public, allowing more tools grow around it. Working with flash makes me feel like I'm using Photoshop to develop Java.

    I'll stick with DHTML/APPLETS for now and wait for SVG/XUL/JSF/Some sort of open flash to come around for client apps.
    Reply to this Reply to original

  27. AS 2.0 not quite OO yet[ Go to top ]

    Also, where's the compiler? I'm not cheap, I have Studio MX 04, but I'd much prefer Macromdia release an actionscript compiler to the general public, allowing more tools grow around it.


    I totally agree. The community needs a standalone compiler asap.

    > Working with flash makes me feel like I'm using Photoshop to develop Java.

    That was exactly my feeling too... until my .fla file became: #include "main.as"


    Ovi Comes
    zulu.netspedition.com
    Reply to this Reply to original

  28. Flash better than DHTML ;-)[ Go to top ]

    Can you point to any Flash application on the web that is more advanced

    > than the DHTML-based examples at smartclient.com

    At iteration::two, we built and delivered a Flash rich-client
    application called Opal, which delivered a rich internet user
    experience upon significant amounts of server-side J2EE services
    that delivered mobile messages in and out of a number of UK
    mobile networks.

    Essentially, the UI is "Outlook for Mobile Messages". Jeff, I took
    a look at your Outlook-like application - it's a very impressive
    DHTML implementation, and does a great job of mimicking the look
    of the application.

    We can't give a live online demo of Opal as it can deliver mobile
    messages into mobile networks, and must be purchased as a product
    from our client, *however*, you can get a look at the user interface
    at http://opal.telrock.com/

    Objectively, I can promise that it does deliver a much more
    interactive and responsive user-interface than the DHTML examples
    you've given, as well as support a number of visual cues that
    cannot be built with DHTML.

    I'm not interested in a holy war; I've built online banks in the
    UK in my time with Applet technology (never again :) ) with DHTML
    and we're now building RIAs with Flash -- we found Flash because
    of the limitations of the aforementioned technologies, and not
    because we had any incentive to pin our colours on any one mast.

    Often, I'm sure, DHTML will be the tool for the job, or good old
    HTML will be. But, I strongly believe that to build richer, more
    interactive user interfaces, we have to look past HTML based
    technologies, and right now, Flash is a strong candidate as such
    a technology. Flex will, I'm sure, lower the barrier for entry
    for J2EE developers such as Server Side readers, and empower us
    with being able to deliver richer user experiences as easily
    as we build JSP based applications.

    Hope that helps,

    Steven Webster
    Technical Director
    http://www.iterationtwo.com/
    Reply to this Reply to original

  29. SVG as an open-standard alternative?[ Go to top ]

    I'd be more interested in an open standard version of flash.
    Is SVG comparable in functionality? Has anybody built a rich-client webapplication in SVG?
    Would be interesting to hear about experiences with SVG.

    The web is built on open standards after all.

    Joost
    Reply to this Reply to original

  30. Static HTML is done[ Go to top ]

    For 10 years we had problem with it, it is outdated.

    Flash runs on PocketPC, Linux browsers and all other popular browsers.
    Sorts and other UI can execute on the client PC, plus ActionScript is better than JavaScript.

    JSF is a huge mistake, since it's designed mostly for the server, when UI is in the browser.

    .V
    Reply to this Reply to original

  31. How about performance ?[ Go to top ]

    Rich flash is so damn slow too... and then ofcourse u have to download the irritating plug in etc.
    Last year there was a thinking that flash was going to be a next big thing after dhtml. but given flash's performance and othe r issues like browsers need to have plug in etc and client side execution - flash has just had limited success,. It is restricted to some intro pages and some stupid jazzy stuff on some very less visited site, may be some cool products advertizement. Think of the flash develeopment also - its quite a bit time consuming.

    To me its just one fancy tool with limited functionality. Lets see how people accept it in future.
    Reply to this Reply to original

  32. Yet Another XUL Motor - Yawn[ Go to top ]

    Flex will allow you to create apps that are richer, with more logic running in

    > the client, while developing in a manner reminiscent of JSP.

      Just to let you know that there are plenty of free, open-source alternatives that use XML ("in a manner reminiscent of JSP") to build rich UIs.

      For example, the XUL Alliance site lists more than a dozen XUL motors/runtimes/browsers/players in Java such XWT, Luxor, Swix, JellySWT, Bamboo, Thinlet and many more.

      - Gerald

    PS: What is XUL (XML UI Language)?

    To get started check out the XUL Alliance Link-opida online @ http://xul.sourceforge.net/links.html
    Reply to this Reply to original

  33. Is there a XUL plugin for IE?[ Go to top ]

    NT
    Reply to this Reply to original

  34. XUL Plugins For Internet Exploder Abound[ Go to top ]

    Is there a XUL plugin for IE?


     Check out the XUL Alliance site online @ http://xul.sourceforge.net for some choices such as XWT, Bamboo, Swix, and so on.
    Reply to this Reply to original

  35. Anyone used RUI? (Remote User Interface)[ Go to top ]

    Anyone used this thing at all:
    http://www.cortext.co.il/

    It's IE6 only, but it looks kinda neat.
    But it seems to have no community; and I have to take that as meaning that no-one uses it.
    Reply to this Reply to original

  36. Where is Flash MX[ Go to top ]

    It is great to know that Macromedia came up with another technology for the Rich Client, "Flex"....But, I am expecting an answer from the Macromedia people as to how it is different from Flah MX (action Scripting) coding. I had developed quite a Lot Action Scripting programs which formed the Rich Client...connecting to the Server (servlets, asp) thru XML.....I had thought Macromedia would provide some better development platform for Developing Action Scripting rather than releasing a altogether new product....is Flex is what I thonk so???? If yes, then where is Flash MX heading for????

    Cheers,
    Manjunath Rane
    Reply to this Reply to original

  37. Offline work[ Go to top ]

    I especially like the capabilities listed that allow clients to continue to use an application offline, with synchronisation occurring when connected. This is tricky to reproduce with today's webapps. I'm already convinced that we will see more technologies like Flex in the future.
    Reply to this Reply to original

  38. the market will decide[ Go to top ]

    It is the wrong forum (theserverside - remember!)
    These people don't care about user experience and are actually hostile (afraid of) "power users".
    Nevertheless rich clients are coming sooner or later, in one way or other - nothing beats working with components and events.

    It was the same before with the mainframes. They though they could ignore the users also!

    Nowhere in my 15 years in computing have I seen anything so pathetique as all these Java Frameworks.

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  39. Informal Responses to Comments and Questions[ Go to top ]

    Thanks for the great comments, even the competitive ones about other products and the ones about Flash's previous limitations are good to hear. I've tried to answer some of the recurring questions, namely about DHTML, XUL, SVG, JavaServer Faces and the existing Flash MX tool.

    My answers, informal as they are, were lengthy so I blogged them so as to avoid hurting this thread on TSS. What's that Blaise Pascal was supposed to have said? "I apologize for the length of this letter, I did not have time to make it shorter" -- something like that.

    Responses here: http://www.artima.com/weblogs/viewpost.jsp?thread=22035

    I write the software not the marketing message, and my responses shouldn't be taken as any sort of official word from Macromedia. Official word should probably be taken from Christophe and others off of macromedia.com.

    Cheers,
    Sean
    Reply to this Reply to original

  40. Any alternative ![ Go to top ]

    Flash is not only for jazzy unvisited web pages. With Flash remoting Flash can be very useful. I might be slow but it is the most viable rich client J2ee platform can use.
    Reply to this Reply to original

  41. Show me some enterprise Flash solutions[ Go to top ]

    Having followed this thread a lot since I helped start it I haven't see any examples of Flash that complete with the typical J2EE problem space. I *have* seen some nice Flash solutions on simple broceure sites and I have seen some very nice DHTML solutions that were argueably enterprise quality. Are folks simply not using Flash because without something like Flex it is too difficult to use? One site I did see Flash used nicely was where they used it as a fancy navigation bar. Is that how we will be using Flash with Flex?
    Reply to this Reply to original

  42. Rich clients and Swing on the web[ Go to top ]

    I think Flash is a pretty good choice static sites that need fancy animation and MTV-style effects. Most of the enterprises, where Java apps are written, do not (unfortunately in my opinion) want to spend money to spice up the UIs. Only a very small portion of sites require the effects that can be delivered only by a plugin like Flash. I have seen a lot more environments where plugins are simply not allowed. Even though it's very common, it's not as ubiquitous as the browser. But admittedly better then JRE:-(

    While it is possible to do just about anything in DHTML/JavaScript, it is definitely not meant for rich UIs. Up until today there is no standard Tree, Table and Editable Combobox which is pathetic. I am afraid that the evil empire will have a big say in what will be the future rich client because they control the browser market. For Java desktop Swing is pretty decent and it can be webified using WebCream (http://www.creamtec.com/webcream).

    The future will tell... And welcome back Rolf!
    Reply to this Reply to original

  43. Macromedia launches New Rich Client Platform Flex[ Go to top ]

    Despite the Frankenstein arguments ("DHTML GOOOOOD! FIRE BAAAAD!", etc.), I'll post a reply.

    It is interesting to see that they're addressing the lack of support for "slap an interface on it" development, which shields developers from building everything from scratch every time, or handing everything to an overworked designer. This is a major reason Flash hasn't been accepted into corporate computing.

    I wonder about the MXML stuff, though. I don't find XML to be a very friendly syntax for programming, in general. Is there a tool to generate this for us?
    Reply to this Reply to original

  44. Weakness: Required plugin installation[ Go to top ]

    Actually both Java Webstart and dotnet are much better GUI clients than Flash or DHTML. The only weakness in those technologies - required plug-in installation.
    But I think one company is on a mission to solve this issue and make its product available everywhere without any installation :))
    Reply to this Reply to original

  45. What is the significance of Web Services connectivity?[ Go to top ]

    There's been much talk about the Rich Client GUI nature of Flex. Flex uses Web Services to enable communication to remote hosts. Is that an interesting new development? How so? I guess I don't fully understaand how Web Services might replace the traditional client server type model of computing with html pages.

    For example.. one might download a standard set of GUI components that represent a stage, and then transparently (to the user).. keep updating various payloads of data without page transitions.. thereby improving the productivity and performance of the user computing experience.

    Web Services enables this model and does so in a standard open approach so that the Flex client can easily speak to multiple back end systems, (with the understanding that there is a Web Proxy system that governs that connectivity to some extent).

    Any further thoughts?
    Reply to this Reply to original

  46. How do rich clients fit into the world of Apache Cocoon...?[ Go to top ]

    Much of the talk around Flex has suggested that Flex can fit into a computing infrastructure of JSP, etc. How, if at all would Flex and other rich clients integrate with document centric type computing offered by technologies such as Cocoon?

    In my experience, there's an emerging need for something I jokingly call StruCoon.. sort of a mix of Struts and Cocoon.. Oberon and the Model 2X might be a good redention of a product that meets the emerging need.

    What all this really means is that there's a certain need to render back end data payloads via XSL pipelines on the way back to the client. Would Flex play in this strategy. I would think that it would and well. The nature of the Cocoon rendering of payloads speaks to the need to format multi-part XML type documents (like Insurance).. And Flex would provide rich validation intelligence to that mission.

    Any thoughts?
    Reply to this Reply to original

  47. ULC - an alternative to Flash & DHTML[ Go to top ]

    ULC from Canoo (www.canoo.com/ulc) is a pure Java, serverside GUI framework
    for developing Rich yet Thin clients for J2EE applications. ULC can be used to "slap on" a Rich yet Thin GUI on J2EE business objects and services. It
    combines the advantages of HTML (easy deloyability) and fat clients (rich GUIs)
    without the disadvantages of both.

    ULC features:

    - J2EE compliant applications (run as servlets or ejbs)
    - Pure Java based programming model (exactly similar to Swing).
    - Server centric apps, only server side programming
    - Rich widget set
      - Good support for data intensive widgets - trees, tables, ...
      - with built in optimisations to reduce client server roundtrips
    - Thin (300kb), pure Java, Swing based presentation engine
    - Client side deployment as an Applet or using Java Web Start
    - Faster develoment
      - GUI builder for WebSphere Studio
      - GUI builder for Eclipse (in develoment)
      - Framework handles C/S communication, distribution, optimisations
      - Extensible framework
    - Can coexist with an existing DHTML based GUIs

    The UI of an aplication is developed using a rich set of ULC GUI components.
    These are Java classes with names, API and programming model similar to
    Swing, only that these classes are server side classes. A ULC application is
    totally J2EE comliant and run in a J2EE container as a servlet or a EJB session bean. Being a pure Java J2EE application it can access other Servlets, EJBs, and enterprise applications using various Java contectors.

    The UI is rendered on the client side by a thin (300KB), pure Java based presentation engine. It renders the GUI (defined on the server side) using Swing. Unlike in the case of applets and Flash there is no movement
    of code between the client and the server. The UI Engine can be deployed as an Applet or through Java Web Start. ULC as can coexist with HTML based GUIs in a browser.

    The GUI and data are instantiated on the client on demand and through lazy loading - thus reducing traffic and increasing responsiveness. The ULC widgets come with lot of parameterised built in optimisations like caching, request batching, to reduce roundtrips.

    ULC is mature and has been in production since 2001. The present version is 5.3.1.
    Reply to this Reply to original

  48. What other alternatives?[ Go to top ]

    For some time I have been looking for frameworks to build a rich client for J2EE. What alternatives for a rich client framework are there besides ULC?
    I know of Eclipse (doesn't support Swing widgets) and Netbeans (I did not find programmers' doc).
    What do your companies use for Java rich clients? Until now, we wrote a small framework ourselves, but similar to using an app server for server side code we would like to have an app server for Rich client code.
    Reply to this Reply to original

  49. JDJ review of Canoo ULC[ Go to top ]

    The current April issue of JDJ includes a product review of ULtraLightClient:

    http://www.sys-con.com/story/?storyid=44378&DE=1). 

    greetings,
    Sandra
    Reply to this Reply to original

  50. expensive![ Go to top ]

    The UCl seems to work quite well, better than any other RIA I have seen or at least the demos are more impressive,
    http://www.canoo.com/ulc/demos/index.html

    But the prices! They charge $1500 for every client..

    What a relief to work with the forms once downloaded, this is what I want.

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  51. re: expensive - no charge for client[ Go to top ]

    The ULC developer license costs US$ 1495.- per developer seat.
    This includes deployment, i.e. no further runtime licenses are required.

    See:
    http://www.canoo.com/ulc/products/canooulc.html
    Reply to this Reply to original