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
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.
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.
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.
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.
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!
Let me share an experience I had with "rich client" web applications:
It was funny to have that "client-server" feeling again, but in a web page... weird even! :)
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.
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
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.
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.
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 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.
"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"
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
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.
"The future is in declarative application development"
The future is in top of the line high quality -handcrafted software as I see it.
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 ;-)
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.
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..
...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).
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.
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.
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.
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.
Okay, I found this JavaOne presentation:
Apparently, I've been out of the loop--should have already heard about this.--Kevin
The problem right now with SVG is that it lacks a set of standard widgets, even for simple components (text fields, lists, etc.).
If all Java developers was like you, J2EE would not have any problem.
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.
The best-for-all thing just doesn't exist. And it doesn't really hurt when we have one more optional way to choose.
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...
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.
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.
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.
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.
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.
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...
I've tried to put these sorts of thoughts together before (http://adriancuthbert.blogspot.com/2004/05/ria-and-mozilla.html
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...
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.
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.
@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.
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.
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.
Here is a previous discussion, worthy of reading:https://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;
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.
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.
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?
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 Microsofts 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 todays constraints, but I wouldnt bet on it. Shouldnt the Java community, or at least part of it, be putting the case for Java on the browser?
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 ;-)