Discussions

News: Thinking about Macromedia Flex

  1. Thinking about Macromedia Flex (49 messages)

    Macromedia ran an interesting demo of their new technology, Flex, at TheServerSide Symposium. Howard Lewis-Ship was there, and has written up his thoughts on the product, how it can fit in with Tapestry, and the future of web applications.

    Excerpt
    So why is the Tapestry guy interested in this stuff? Because HTML is, ultimately, a dead end. Tapestry squeezes the most out of HTML that can be done, but I firmly believe that in three to five years, some form of rich client will supplant HTML for the zero-delivery cost web applications that are currently created using Tapestry, JSP, ASP or whatnot. I predict that a lot of stuff now down exclusively with HTML will be done using a mix of HTML and Flex (or whatever client-side technology emerges, should Flex fail). This could be good news for Tapestry ... the sites I envision dominating the market will consist of "boutique" HTML (HTML created by non-Java developers) and Tapestry shines at integrating that kind of HTML into a dynamic application. The HTML parts of applications will be much more focused on readable documentation (news sites, some form of community sites, blogs and the like) where the ability to print and book mark are important. The kind of applications currently shoe-horned into the HTML world (help desks, all kinds of corporate infrastructure, CRUD applications) will be easier and better using a rich-client alternative.
    Read more about Thinking about Flex

    Threaded Messages (49)

  2. Afraid of the future[ Go to top ]

    God, how I hope he is wrong!

    HTML a dead end? I don't really see why. And I don't really see the use of this technology except for "flashy" gimmicks (pun sort of intended). Because let's be honest it's not new at all they only make it easier. Of course easier might mean a broader acceptance in the market. But personally? I hope it never gets that far because I positively hate GUI made with flash: everybody just makes whatever he wants and although the designs might be breathtaking the functionality normally falls short.

    In a web design company I used to work for (years ago already) we used to ask flash-users: show us _one_ site/GUI where Flash actually works!

    Of course if this is just about "webalizing" _applications_ Flex could of course work, but so could HTML because I've seen some pretty amazing GUIs made with HTML. So what would Flex give us? Animated, rotating, waving, all dancing all singing GUIs? Please, no!

    As for Flex supplanting normal HTML pages (the ones that are not applications but "jsut" resevoirs of information) that would be even worse! How would I search for information (what would Google make of Flex pages)? How would I copy a piece of interesting text and paste it in an email? How could I link to an intereseting subsection from within my own website? Etc.

    No, I think HTML still has some life left in it.
  3. Afraid of the future[ Go to top ]

    I hope he's right! Aren't you sick of the limitations of html/javascript and trying to code around the statelessness of http?

    Have a look at http://january.rr.com/flash/ for an example of a flash-based portal. None of the hardship of dealing with portlet state that required a JSR to over-come. Also (re)look at the Flash Remoting front-end for petstore (http://blueprints.macromedia.com/PetMarket/flashstore.html) for an example of a web-based application that behaves like an application, not just a web-site.

    The fact is HTML is for documents _only_, something has got to replace it and macromedia are probably in the best position to do it. Also look at openamf for a FOSS implementation of remoting. I believe our friends at JBoss are also looking into remoting, but I haven't looked at their efforts yet.
  4. RE: Afraid of the future[ Go to top ]

    One problem I found using the flash site is that text zooming does not work. I rely on this Mozilla/Firebird feature as my screen is a bit too small for the resolution (I have my reasons). If they can solve the text zooming, and the fact that I cannot cut&paste text, then I can imagine this as a potential HTML replacement.

    Peace.
  5. RE: Afraid of the future[ Go to top ]

    heres a link to a previous post about accessibility

    http://www.theserverside.com/news/thread.tss?thread_id=22465
  6. Afraid of the future[ Go to top ]

    I hope it never gets that far because I positively hate GUI made with flash: everybody just makes whatever he wants and although the designs might be breathtaking the functionality normally falls short.
    Well its too late already. Look at longhorn and see it coming. XAML. And don't think that this is just MS pushing this. Look at Mozilla and Gnome. Or IBM's recently announced Lotus Workplace based on Eclipse. Sorry!
    Of course if this is just about "webalizing" _applications_ Flex could of course work, but so could HTML because I've seen some pretty amazing GUIs made with HTML. So what would Flex give us? Animated, rotating, waving, all dancing all singing GUIs? Please, no!
    Doesn't this make more sense. I mean HTML is getting pretty rich, but it's still not extensible. You need applets to really draw dynamically. You can't create truly custom controls in pure HTML. Its just not there. Anything from Macromedia is better than ActiveX controls in the browser.
    As for Flex supplanting normal HTML pages (the ones that are not applications but "jsut" resevoirs of information) that would be even worse! How would I search for information (what would Google make of Flex pages)? How would I copy a piece of interesting text and paste it in an email? How could I link to an intereseting subsection from within my own website? Etc.No, I think HTML still has some life left in it.
    With all the time saved from squeezing all the power of HTML we wil lahve time ot set up standard API's for google to interface to. WOuldn't it be great if instead of putting out crummily formatted web pages and poorly indexed sites google could tap directly into a content database? Forget looking at data through a flash page or someone's blinking text. Google creates its own format. then you go to the site if it seems interesting enough to actually open up.
  7. Been traveling last forever hours, just caught up on this thread. A few responses and observations:

    The KEY thing that Flex seems to give you is to localize client-specific state on the client. That is the major pain of all web application development; Tapestry gives you the tools to address those problems, but there is no panacea.

    The text-heavy applications (such as blogs, communities, forums and news sites) can and should stay HTML. More searchable, more "rich". It's rich interactive (rather than merely dynamically rendered) where Flex and its ilk may grow to have the advantage.

    People claim a lot with DHTML and Tapestry certainly can make use of it (with its powerful scripting subsystem). But it's a lot of bits and pieces. I'd like to create more involved Tapestry components, leveraging DomAPI or a similar library, but can't (due to licensing concerns, not to mention browser compatibility concerns). To me, the response to "how to I build a cross-browser rich application using DHTML" is "Mu", meaning "unask the question".

    Back to the client ... more later. Thanks for the discussion!
  8. Let me share an experience I had with "rich client" web applications:

    I was able to "emulate" a "rich client" environment using plain HTML and some javascript code (using the jsolait XMLRPC library I posted the link earlier). I set up a tomcat server, installed apache's XMLRPC library and a servlet to receive XMLRPC connections, and in the HTML page, every communication to the server was done through XMLRPC using jsolait XMLRPC library, with no page refreshes at all. Worked nicely, although it was a relatively simple page with some text inputs and comboboxes, with some dependencies between them (the values of a combobox changed when another one was selected, etc). I was able to transfer "objects" to and from the server, just by serializing them to the XML format. I imagine more complex pages would not be hard to code.

    The nice thing in such a solution is that there's a clear separation of client-side code (javascript + html) and server-side (POJO accessed through the XMLRPC server). I did set up all the environment in 2 days, given that I had to learn to setup the XMLRPC communication, both the server side and the client side. The bad thing is that client-side code is Javascript, with all the portability problems between different browsers and versions. Although Jsolait library seems to be very well coded and can shield you from these problems, at least regarding XMLRPC communication.

    It was funny to have that "client-server" feeling again, but in a web page... weird even! :)

    Regards,
    Henrique Steckelberg
  9. Afraid of the future - NOT[ Go to top ]

    The KEY thing that Flex seems to give you is to localize client-specific state on the client. That is the major pain of all web application development
    Yes, that is key. But it certainly isn't new.

    This is the same architecture implemented by DHTML clients like SmartClient, Java clients like UltraLightClient, plug-in clients like Curl, and other Flash clients like Laszlo.

    If you have been too busy to track this space in recent years, just follow the links above. They all have plenty of live examples. And there are other vendors on all of these platforms.

    We have been doing client-resident DHTML applications with background client-server communication, component-level refresh, and desktop-style GUIs for over 5 years. Yes, this removes the major pain of web app development.

    Thing is, many developers rely on that pain for job security, product security, or the foundation of a belief system. Change is very a slow process--but it will happen. Dumb-client web applications are too badly broken to ignore.


    Jeff Dill
    Isomorphic Software
    www.isomorphic.com
  10. Thinking about Macromedia Flex[ Go to top ]

    Flex will be more compelling when Macromedia releases "Brady"

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

    Brady is the code name for Macromedia's forthcoming Flex IDE.

    If you are using IBM Websphere Studio Application Developer,
    take a look at IBM's Flex plugin:

    http://www.alphaworks.ibm.com/tech/wsadflex
  11. This could be good news for Tapestry ... the sites I envision dominating the market will consist of "boutique" HTML (HTML created by non-Java developers) and Tapestry shines at integrating that kind of HTML into a dynamic application.
    There is Dynamator ( http://dynamator.sourceforge.net/ ) which is backend agnostic and can dynamite static HTML with any backend technology: ASP, PHP, etc. plus Dynamator works at development time that eliminates need for page parsing at runtime.

    I am agreed that HTML + something should not be used for building rich applications, but I would not say there is real need for inventing something new. There are Applet and JavaWebStart technologies already available and all is really necessary is just slight polishing.

    If we are looking for really simple connectivity then Burlap/Hessian protocols really shine : http://www.caucho.com/resin-3.0/protocols/index.xtp , but IMO CORBA and IDL should be used for serious stuff and we should stop that bs about CORBA firewall non-friendliness etc.

    Another thing to consider: in 5 years we will have plenty of bandwidth and good-old XWindow will work just fine.

    IMO: lets stop reinventing wheels. It is time to use what is already here and do something useful.
  12. Thinking about Macromedia Flex[ Go to top ]

    Very impressive! End users are tired of hearing from us that they can't do this and that on the web. Time for rich clients.

    I'm wondering if there is an opensource project that does the same. Flex seems to be quite expensive.
  13. Because HTML is, ultimately, a dead end. Tapestry squeezes the most out of HTML that can be done, but I firmly believe that in three to five years, some form of rich client will supplant HTML for the zero-delivery cost web applications that are currently created using Tapestry, JSP, ASP or whatnot.
    Howard is right that rich clients will supplant HTML, but only from the perspective of the application developer.

    HTML as a platform technology will not be supplanted. It will be hidden behind the high-level interfaces of rich client systems, just as Flash primitives are hidden behind Flex or Laszlo, or Java GUI calls are hidden behind Nexaweb or Altio. Ideally a single standard language will emerge for all of these rendering systems. (Gerald, where is your XUL plug? :)

    Tapestry does not even scratch the surface of Dynamic HTML (DHTML) capabilities. Flash, Java, and DHTML all have their place, but DHTML rich clients have significant advantages:

      * they are based on open standards (HTML, JavaScript, CSS, DOM)

      * they integrate seamlessly and incrementally with existing HTML code

      * they do not require plug-in installation and administration


    The downside? It is very difficult to build a cross-platform rich client in native DHTML. The solution? Don't build it yourself. You wouldn't build your own operating system, or JVM, or browser, right? These clients are available right now, both commercially and in open source projects.

    Don't get me wrong--Flash has its place. It is the most broadly deployed cross-platform vector graphics engine, which makes it a great choice for interactive charting, mapping, and graphing. But this isn't an either/or choice. DHTML encompasses Flash, ActiveX, applets, SVG, and other plug-ins. You should pick the right rendering system for the job at hand.


    Jeff Dill
    Isomorphic Software
    www.smartclient.com
  14. same as the hobbits[ Go to top ]

    "DHTML rich clients are at least as capable as Flash"

    Yes, but it is a form of special competence, you not only have to be a good programmer, but also be comfortable with the 5000 properties and methods of DHTML and the most important, Domain business knowledge. (the knowledge that usually belongs to "power-users").

    I short, nothing for J2EE developers that rather prefer discussing in infinidium different transparent persistence.

    A sentences from Tolkien comes to mind.

    "Hobbits can sit on the brink of disaster and discuss some odd, peculiar habit of some ancestors"

    Regards
    Rolf Tollerud
  15. same as the hobbits[ Go to top ]

    Yes, but it is a form of special competence, you not only have to be a good programmer, but also be comfortable with the 5000 properties and methods of DHTML and the most important, Domain business knowledge. (the knowledge that usually belongs to "power-users"). I short, nothing for J2EE developers that rather prefer discussing in infinidium different transparent persistence.
    Yes, this is definitely not the level that J2EE developers should be working at. That is exactly the point of these rich client systems. Whatever the underlying client-side technology (DHTML, Flash, Java GUI) they hide that complexity from J2EE developers. You no longer work with HTML tags and JavaScript--that's the equivalent of assembly language in this new world. You work with tags like <datasource>, <treegrid>, <tabset>, <searchform>, etc.

    Yes, creating these systems requires special competence. Just like developing the microcode in your CPU, or the OS that runs on that CPU, or the VM that runs on that OS. Building on top of the last platform is how software advances, roughly every decade, and it always met by our natural resistance to change.
    Hobbits can sit on the brink of disaster and discuss some odd, peculiar habit of some ancestors
    Exactly. Like programming in assembly, while the rest of the world moves on. :)


    The future is in declarative application development. That's what these systems are about. That's what Microsoft's latest advances with XAML are about. Encapsulate the complexity, and advance the state of the art.


    Jeff Dill
    Isomorphic Software
    www.smartclient.com
  16. the future again[ Go to top ]

    "The future is in declarative application development"

    The future is in top of the line high quality -handcrafted software as I see it.
  17. Although I am interested in declarative app development, I don't agree that DHTML is bad just because its complicated.

    It may be complicated to *you*, but as a seasoned DHTML developer I can tell you that J2EE seems unbelievably complicated to me sometimes, too.

    It takes different talents, skills, etc, to make a good GUI compared with the other development tasks. Why is it so unreasonable for people to think that one developer can do it all?

    I feel this one of the most crippling issues with our industry today. If I were to build a house, I really doubt I'd want the electrician trying his hand at laying the brick ;-)
  18. I feel this one of the most crippling issues with our industry today.
    I couldn't agree more. I've seen this time and time again. Somehow just because you are a developer means you are a general tech person who can morph into a usability specialist, sysadmin, release specialist, QA/testing dude, and sometimes even a requirement/functional person. Without a doubt these are distinct skill sets that require different sensibilities and ultimately different people.

    Probably the start-up mentality and economic pressures have fueled this issue, because management somehow thinks that a "renaissance man" tech guy is more cost effective than multiple people, when in reality a late or poor quality product is much more expensive then just acquiring the correct skills sets from the beginning.
  19. I guess in the ultimate situation you could have the choice of either because there is a suitably high level of abstraction provided by a framework or a toolset to allow you to easily swap between DHTML or Flash or some other technology.

    I think the big trouble with DHTML is that it's not yet got (that I've found) a strong enough set of frameworks or tools/libraries to allow you to do anything decent in a reasonable amount of time.

    There's probably still life in HTML for a few years yet, as you can have some quite nice looking sites, but if you want full on graphical-paint-to-the-screen-anywhere type stuff with graphs and animations, pictures, drag and drop etc etc, then flash/flex is a good solution

    PS and didn't the demo at TSSS look amazing with just 10 lines of XML..

    regards,
    Nathan Lee
  20. ...Flex would not be needed at all.

    Really, besides a large installed base, what does the Flash plugin have that could not be duplicated in a Java VM?

    You guys have been doing server side HTML based apps too long. In the past, I have deployed very large applet based apps to very large customers with great success.

    The ball and chain on applets was Sun's refusal to make a distro that wasn't a burdon to download or to administer in the enterprise.

    Running a Flex app in the Flash plugin is like having a 1.1.X VM stripped of the server side cruft that's collected like sediment in J2SE. (for example, JDBC, JNDI, and now generics and metadata).
  21. Thinking about Macromedia Flex[ Go to top ]

    I was also present at the luntime session. My thoughts based on what I saw,

    (i) It relies on having Flash player running your machine. I know the majority of people do but it is an issue if you wish to support those who do not.
    (ii) By the sheer fact you need flash player I would imagine you now have to worry about versioning of the player on the client. Does this version support my new widget?
    (iii) You are buying into a vendor product.
    (iv) Bandwidth, Bandwidth, Bandwidth (yes there are people using Modems out there).
    (v) It contacts the server using a webservice. This means people will end up designing "Page Oriented" web services rather than service oriented to cut down on the number of over the wire calls.

    David

    David
  22. Sorry to raise this subject again, but I find strange that Howard got impressed with Flex, after all the grips he had with JSF in another discussion. Both technologies are so similar in many aspects, and have almost the same capabilities, so for me it is indeed strange to hear this from him.

    I've read in Howard's blog about his concerns regarding vendor lock-in. As "old" as this may sound to some, I'd suggest taking a (second) look at JSF: it has the same capabilities Flex has, new tools are already being launched, and being it a specification, there is no chance to get vendor lock-in. People have already demonstrated JSF working with SVG, which would get you the same rich UI Flash has. Together with XMLRPC, you can create a statefull SVG client or even an HTML one. So all the benefits of Flex but no vendor lock-in. This could be greatly benefitial to Tapestry if it became JSF compliant, it would allow it to create a even stronger user base, raise industry acceptance and foster component reuse with different tools and frameworks, not just inside tapestry itself, all this by leveraging upon an official specification.

    Sorry if I am being repetitive, off-topic or plainly boring, it is not my intention. I'd just like to understand the reasoning behind some people's actions and reactions.

    Regards,
    Henrique Steckelberg
  23. JSF + SVG[ Go to top ]

    Hi, Henrique.

    Do you have a reference for the JSF with SVG work? That sounds very interesting to me and I wonder if more people might be interested in learning more about that.

    Thanks!

    --Kevin
  24. JSF + SVG[ Go to top ]

    Okay, I found this JavaOne presentation:

    http://servlet.java.sun.com/javaone/resources/content/sf2003/conf/sessions/pdfs/2058.pdf

    Apparently, I've been out of the loop--should have already heard about this.

    --Kevin
  25. JSF + SVG[ Go to top ]

    Okay, I found this JavaOne presentation:
    http://servlet.java.sun.com/javaone/resources/content/sf2003/conf/sessions/pdfs/2058.pdf

    Apparently, I've been out of the loop--should have already heard about this.--Kevin
    I don't want to hijack another thread about Tapestry, so I'll be brief and try not to turn this into another tapestry x JSF thread. Some links to stuff that I found that could help integrating JSF and SVG:
    Batik (SVG Java Toolkit)
    Jsolait (XMLRPC in Javascript)
    Neuromancer (Web Services in Javascript)

    The problem right now with SVG is that it lacks a set of standard widgets, even for simple components (text fields, lists, etc.).

    Regards,
    Henrique Steckelberg
  26. Henrique,

    If all Java developers was like you, J2EE would not have any problem.
  27. I'm yet to see JSF / SVG / DHTML / javascript providing quality user experience as flex does.

    just see some examples:
    http://www.macromedia.com/resources/business/rich_internet_apps/
    http://www.cbc.ca/sports/afp/wc-flash/2/gametracker.html
    http://www.macromedia.com/devnet/flex/example_apps.html

    Is there something similar in other technology?
  28. If you had the combined power of XUL, SVG, Java and Javascript + a nice IDE to bring it all together you could make this applications load faster and being more responsive then Flash. That is what Microsoft is planning for Longhorn. (AVALON/XAML, C# + Orcas). What the Java world need is something similar that is free with no runtime fees (like MS)- that is 10 times as powerful as Flash/Flex.

    Should we developers accept a $25000 runtime fee! No way. Will the developers accept only JavaScript (ECMAScript) to program the client? No way.

    But what is good is that examples like Word Cup 2002 raise the rib and give us some feeling what the user will be expecting in the future. Rich Clients where the state is kept by the client and the server is kept nice and stateless is the way to go. What is important today is that the Java world must concentrate on their own competive stack and tools against MS AVALON/XAML, C# + Orcas instead of this endless bickering of what is the best transparent persistent mechanism and other similar pointless details.

    Regards
    Rolf Tollerud
  29. JSF + SVG[ Go to top ]

    The best-for-all thing just doesn't exist. And it doesn't really hurt when we have one more optional way to choose.
  30. Thinking about JSF[ Go to top ]

    Here's my prediction: Majority of developers will move towards JSF because it's more of a gradual change than a radical one like Flex. Just now we have frameworks like Struts with overall acceptance, JSF is step up. Proprietary stuff like Microsoft's XAML and Macromedia's FLEX will have their niche but it will be slow to catch on. Granted I'm speaking of the business world here...
  31. Henrique,

    I really, really hope you're right about JSF/SVG as being a viable option (not alternative) in the rich client development toolset because SVG is very, very nice, IMO. However, having two SVG-based applications under my belt (one with JSP/Struts and another in ASP.NET), I think SVG is going to have to come a long way before it can be considered prime-time. Not just the spec (there are significant pieces of necessary functionality unspecified at present), but also the viewers that implement it. And where does that leave us with regard to the DHTML alternative? We still have inconsistencies and versioning issues across viewers so how does JSF/SVG solve the especially nagging problem of developing for moving targets (the rendering tech)?

    I would suggest that Macromedia's offerings are superior when compared to an SVG/(insert server-side app development tools here) approach at present. They are more mature, better-integrated (thanks to Macromedia's demonstrated desire to provide integration with server technologies), at least as viscerally compelling, and I would argue a de facto standard (for the moment at least).

    My only concern with Flex is it's price. When one begins to compare the cost of entry with Macromedia's tools versus the inferior (and I mean that in the kindest way) but far less expensive (in many cases free) competing technologies, combinations like JSF/SVG begin to look more and more desirable. But one must also consider the cost in terms of finding developers familiar with the newer (and more exotic) technologies. This could be mitigated by a Visual Basic-like wealth of Macromedia developers driving the cost of recruiting down to the point where I'd rather pay 10K once for a tool than an extra 20K per developer per year. I have yet to find a client who has sidled up to the notion of hiring a Flash developer over a .NET or Java person when it comes to applications development.

    Best regards,

    Craig McWherter
  32. Craig, I agree that both JSF and SVG are maybe too new to be taken as a viable choice together _now_, but I believe both are good options indeed in the long run, being them evolving open standards. From what I have seen of SVG's direction, it can fully replace HTML in the future. I just hope that none of that "browser war" comes to this technology, and we have no inconsistencies between different viewers in the future.

    Regards,
    Henrique Steckelberg
  33. only concern with Flex is it's price.

    If you program with XMLRPC, then the cost is nothing. The money they want is for the server side software, which you really do not need, you can replace it with your own solution, as Henrique did.

    Regards
    Rolf Tollerud
  34. Yep, I also think that you could quite easily build a small framework (in ActionScript) to handle wiring of components to data (I know there are binding features available but they are too constrained), actions and "communicators" (components speaking to servers) to make it more friendly to java developers. When you're finished you have something quite similar to Swing and Spring (Spring-RCP) in a combo with rather small efforts.

    I've done it in a DHTML environment where I also (apart from the things mentioned above) had to come up with a component model(to implement rich components that had a common API towards actions), event framework to dispatch things inside the framework and a windowing system. Most things (GUI, action mappings, data bindings) are done in a declarative fashion. It works splendid (so good that I want a similar framework in Java/Swing badly) and is completely agnostic of the server tech (just serve me XML). So far it's only usable in IE since it requires XML/XSLT(with node-set())/XPath support and it also uses VML (Microsofts pre-SVG thing) to do some stuff. But it should be possible to implement this quite easily with even better results in Mozilla.

    It should be easy to do these kinds of things in Flash since ActionScript is better than JavaScript and there are much more functionality in the Flash environment from the beginning.
  35. And, with just a tiny bit more effort you can communicate with SOAP, and be a consumer of the forthcoming Indigo webservice distributed transaction system or whatever IBM & the Java world is planning in the same vain.

    Regards
    Rolf Tollerud
  36. And, with just a tiny bit more effort you can communicate with SOAP, and be a consumer of the forthcoming Indigo webservice distributed transaction system or whatever IBM & the Java world is planning in the same vain.RegardsRolf Tollerud
    Exactly! And we're there already since we have the concept of communicators that abstracts the protocol (more or less) from the actions (processes written in XML really). We have implementations for GET/POST, XML-RPC and SOAP.

    And we're thinking Novell exteNd as an excellent server back-end to map legacy systems to web services / XML (if it works). Or whatever solution that serves me XML...
  37. Goodness knows the non-Microsoft world needs a response to Longhorn and maybe this is part of it. My understanding is that Flex can be viewed as a progression of web applications with a MXML payload being delivered to a Flash runtime hosted by the browser. Life is simple as long as the application is monolithic, all written in ActionScript and can display everything via Flash. Presumably from the browser's perspective the entire interaction with the application represents just a single page download. Some people seem to think that is alright because HTML/Javascript is a dead-end, but I would prefer a range of tools available to me.

    Of course there is an alternative approach based on enhancing what were standalone applications to be more web-friendly rather than extending web applications to be 'richer'. Imagine small, downloadable applications which can use the browser that downloaded them for their user-interface. This approach doesn't dead-end HTML/Javascript and consign the browser to be a convenient host. Ideally if I have an application to write I would prefer to have a choice of languages, I would expect my application to be able to talk to multiple web services hosted on different sites and when I want to put up a help page I expect to be able to use HTML (I have been unable to discover how Flex renders HTML: if it can get the browser to do it all well and good but if it duplicates this functionality then you have to wonder).

    I've tried to put these sorts of thoughts together before (http://adriancuthbert.blogspot.com/2004/05/ria-and-mozilla.html).
  38. Flex seems promising[ Go to top ]

    How many of the people who think that Flex is useless or overrated or re-inventing the wheel, have actually had a chance to play with it?

    The reason I ask, is because I recently had a chance to work with it to evaluate if it could meet our needs. I went into the evaluation extremely skeptical, but I was quite blown away with how easy it was to create very complex and useful UIs. I heard the argument over Applets or Java WebStart, but I personally think that it's a much easier transition into something like this. Since it is so easy to use (easier than HTML is some cases) I think we are going to try it with an application we are starting to build. Hopefully this decision doesn't bite us in the...
  39. What about usability[ Go to top ]

    The problem I have with most of the flash stuff, is that it's barely usable. Ok, it does look nice, most of the time, but forget about usability. First, you have to use your mouse. Second, because there are controls all over the place, you cannot navigate between them in any intuitive way.

    Also, these technologies do not support accessibility very nicely.

    While flash based UI are nice for informative site that need to get your attention, they are not appropriate for workflow based transactionnal applications. I'm sorry, the the sample petstore made with flex, while it has a very nice look, is barely usable.

    DHTML with Javascript (and the help of stuff like DynAPI) are a lot better for business application. You can easily create usable dynamic stuff, and because it's standard base, it will run fine on recent browsers. And because DHTML has accessibility stuff built-in, you can easily make your application availlable to people with disabilities (the money you save on runtime license can be used for the little additional effort to "accessibilize" your application).
  40. I looked at it ...[ Go to top ]

    Hi,

    I've quickly walked into some other comments, and some made me realize that really a few people actually tried or have seen Flex.

    I had the occasion to play with it and I must admit that it is pretty impressive (although I find it a bit slow ...). Nothing new but it seems all well designed. MXML is a pretty clear and intuitive syntax.

    The nice thing also is that you can modify your JSP pages to produce MXML instead of the current HTML, thus keeping the current page-based request/response paradigm (that is really problematic sometimes).
    You can also create a whole UI (with many screens and some UI logic) in Flex and retrieve the data from HTTP or SOAP (no need to build "page-oriented" web services, like I read before ...).

    Although it is maybe not desirable in all situations, Flex has many advantages over/like (D)HTML : it's clean, easy, (very) powerfull, extensible. Not mentioning that you can integrate audio, SVG, SWF and streaming video into your UI. It really feels "professional".

    The problems with that technology might be its pricing, and the fact that it's all propriatary (which I tend to avoid when possible).
    I also hope that Macromedia will make it easier to get a trial copy.

    BTW, I don't work for Macromedia, nor do I have any interest in that company.

    Cheers,
    Sebastien.

    http://www.jroller.com/page/spetrucci
  41. Re: I looked at it ...[ Go to top ]

    @Nathan: there are several extremely good toolkits because I've seen them, one of them is http://www.backbase.nl and the other is http://www.javeline.nl, unfortunately none of them seem to have (public) demos :-(

    @Sebastien: I don't need to see or use Flex because I'm sure it will be very easy to make rich GUIs with it, this can already be done with Flash so I'm sure that Flex will be able to do the same or more and better and easier. But the point is: I don't care! It still results in a Flash interface and for me(!) they just suck. There are some links in Erik's message above that point to some examples of supposedly good interfaces but while they look nice they work just like any ordinary application GUI the whole point of having a webinterface is gone.

    But like I said in my first message: if it's an applpication you want to make (little to no valuable information, it's the process that's important) then by all means make an application. A user can either download and install it, have it installed automatically in the form of ActiveX or WebStart or maybe Flex if you want full artistic control over your GUI. But to have Flex as an HTML-killer and that all webcontent will at one time be Flex would be a nightmare IMO.
  42. Re: I looked at it ...[ Go to top ]

    Most of the problems that people are describing about flash interfaces come from the fact that they have been designed by grpahic artists who try to create visually impressive interface rather focussing on the functionality. Thats not to say that flash can't be as funational as HTML. Tha macromedia site itself is a great case study for flash and it doesn't suffer from many of the problems outlined.

    Flash has always had a barrier to application development, and that was the use of movie-terminology which application developers found unintuitive. Flex seems to be like flash without the artistic overtones, so developers can create applications themselves without handing the work over to designers.

    The biggest problem with macromedia's server products is the price. Flex is just too expensive for smaller companies and development houses. Similarly, JRun 4 is actually quite a nice application server and boasts many interesting features such as jini clustering. But it appeals to smaller companies rather than big deployments, but the per cpu pricing is still too high for many people to incur.

    Macromedia are doing a good job at the moment, plus the flash format is open (http://www.openswf.org/), something many people seem to ignorant of. If you have to back a rich web-based client, I reckon thats where the smart money would go.
  43. Re: I looked at it ...[ Go to top ]

    What I forgot to mention is that Flex is not targeted at "Artists", but really at web developpers.

    When you create a UI in Flex, you deal with buttons, labels, layouts, trees a tree models, tables & models, ... To me, it's somehow closer to Swing than to HTML, and light-years away from Flash (at least, from what I know about it). As a bonus, you can include some "Flash-like" effects like zooming/moving components, but it is not the main feature of Flex.

    Indeed, the rendering uses Flash but that's all. Just as Swing will/already use OpenGL for its rendering.

    Cheers,
    Sebastien.

    http://www.jroller.com/page/spetrucci
  44. test[ Go to top ]

    test
  45. Here is a previous discussion, worthy of reading:

    http://www.theserverside.com/discussions/thread.tss?thread_id=24836#116166

    Here is the summary:

    Overall assessment for selecting an RIA vendor:
    High end graphics like 3D rendering: curl;
    Sexy animation, cool effects, even video/audio etc: Flex(Flash MX if you're cheap);
    Enterprise apps: Nexaweb ;
    Sexy consumer websites/web apps: Lazslo ;
    Others: Dreamfactory, DigitalHarbor;

    .....
  46. I absolutely love what Macromedia has contributed to the web development arena with Dreamweaver and the Flash technology but they cannot possibly think that people are going to shell out $6K/cpu for a relatively new technology that very few developers have the skillset for. I'm an enterprise J2EE developer for a Fortune 100 company and basically if I were to go to my superiors and ask them to fund this product, the cost would be something like this:

    3 environments (dev,test,prod) x 2 servers x 4 processors x $6K = $144,000

    Now from what I have read and played with (I created a simple Flex interface in an existing war), I see MM has made it alot easier for code junkies and web developer types to create Flash interfaces. This said there is still a training ramp up time issue. Granted ActionScript is alot like Java, etc. and MXML is basically a step child of XML, I see a significant investment of time being used to figure out stuff like learning the nuances of the components that are available and integrating them with existing apps.

    I commend MM for realizing that there is a tremendous gap between the artsy fartsy types who are used to using the timeline based IDE's and the Java code junkies but they need a serious kick in the head to think people are going to pay $6K a cpu.
  47. Flex is a very high profile example of a common approach to RIA. Maybe in an attempt to carry the momentum that Java has on the server side, people are looking for solutions that work today. Looking to the future, and not wishing to close any doors, people are looking for solutions based on standards or, at least, ubiquitous technology. Meanwhile Microsoft is able to take the longer view with Longhorn and develop complementary pieces of both browser and server technology.
  48. Although one may debate the relative merits of Flash and DHTML on the browser, both Macromedia's Flex and Isomorphic's SmartClient share many architectural similarities. In both cases the Java contribution is reduced to delivering an XML definition of the client application. This is then sent to the browser, possibly transformed by some intermediate server-side gateway. The client payload executes either in some sort of plug-in (Flash) or directly on the browser (DHTML/javascript). The browser communicates back to the server via the gateway. Both systems abstract out the details of the rendering and communications technology used. From the application developer's perspective, the key issue is the power and expressiveness of the XML dialect.

    Ignoring whether such XML dialects are proprietary, such approaches have nothing to say about Java on the browser - in fact such solutions can and should take advantage of whatever technology is available on the browser. Similarly they don't have much to say about Java on the server side, with the exception of what environment their initial gateway implementation is targeted at.

    This retreat of Java from the browser seems premature. Java's WORA credentials should make it a good candidate for delivering to browsers on a variety of operating systems. Applets show that, WebStart shows that, indeed I had thought we were in a better position than ever with respect to deploying the Java runtime. Maybe, rather than trying to find something to graft onto J2EE that will allow Java to deliver RIA, we should be asking what stops Java from delivering in the browser?
  49. Sorry about this naff three-part posting, the system kept complaining about bad HTML tags
    To take the benchmark example of our time, an RSS reader, what stops JNN being a RIA? It is easily deployed over the web, it accesses a multitude of web resources. It has some cool layout and drag-and-drop features. It's big problem is that it lives apart from the browser. Worse still it needs a browser to display full web pages and only communicates with the browser at the coarse level of 'display this page'. If JNN could be activated (once downloaded) from a bookmark, and if it could request a 'pane' on the browser when it started up, then it would pass my definition of a RIA. How would a future Flex architecture handle that?
    Of course that means looking to the future, and Microsoft’s XAML-enabled browsers are not going to allow downloaded Java code to run 'inside' the browser using some backdoor. But today there is a growing community of desktop users that have a Microsoft-free software stack. They will develop an architecture to deliver on RIA; they may adopt one based on today’s constraints, but I wouldn’t bet on it. Shouldn’t the Java community, or at least part of it, be putting the case for Java on the browser?
  50. Adrian,

    To add to your statements, I'd suggest that RIA also needs to account for clients that are occasionally connected. With the growing availability of Wi-Fi Hot Spots and 3G wireless (it will happen someday :), more computers are used with occasional or offline connectivity. These clients also need to be supported such that they leverage the cost savings that Internet/Web based deployment impart.

    One could also suggest that clients with lower bandwidth (56Kb dial-up or VSAT satellite) also fall into this category as moving lots of data back and forth to a server is a serious impediment for providing an interactive user experience.

    Java on the client certainly makes it easier to realize such a vision today, on existing, older systems; no need to force user to upgrade to the latest and greatest machine / OS just to run a web app... Saying this it also aligns nicely with the Linux Desktop movement of late, that I find quite interesting. no need to use the biggest, baddest machine for a call center application hosted in a browser - just run Linux/Java/Web on a modest machine.

    What would be good examples of applications that would benefit from this type of approach?

    JNN, the RSS Reader, is interesting, but I'm not sure how excited a business would be about providing a news reader to employess who should be working versus reading news ... or posting to TheServerSide.com ;-)

    Scott Cranton
    Nexaweb Technologies
    www.nexaweb.com