The Future of Rich Internet Applications
Can't Get Enough Ajax writes "While Ajax continues to get most of the attention these days in the space of rich Internet apps, the future 'face' of Web applications may consist of a combination of Ajax and plug-in technologies based on the new Flash development platforms or other plug-in models. Why? The challenges of building and maintaining sophisticated software in Javascript and the lack of support for audio and video are just two reasons that any RIA strategy will involve a mixture of Ajax and one or more technologies like Flex, Laszlo, or others. But while there are significant advantages to the new RIA technologies, there are also important trade-offs including breaking the model of the Web, lack of HTML support, and more. ZDNet's Dion Hinchcliffe has a round-up of the latest generation of RIA technologies, pros and cons of each, and why there is likely a 'war' brewing among them."
While Open Lazlo and other open source client solutions are exciting, I think people generally want a fully integrated, front to backend solution for developing these Rich applications. Sure they provide data binding, but solutions such as Rails that provide server-side functionality to directly manipulate the client side give me a more comfortable feeling.
I want a full unification of the front and backend. That is why Rails, Turbogears and Cake appear to be more exciting.
Jim http://www.runfatboy.net/ - Fitness for web 2.0.
Of course, none of them want to deal with the disabled-accessability part, despite a recent Court decision that's going to make this kind of stuff a very low priority for a long time.
Lacking <sarcasm> tags,
the tag should be enough for anybody.
B.G.
Ive been running applications people access on their cell phones (or blackberries) for years.
Its been common to run a backend server (tomcat/apache/oracle/Java) and use the phone as the frontend, and allow webaccess for easier changes.
AJAX is free, easy to use, and people are using it now. Not even going into first revisions of software and bugs that are associated with new software, or licensing fees.
That Adobe flex uses coldfusion, we stopped using that and migrated to Tomcat.
I predict if the WPF/E team pulls off what they are doing to bring WPF 2D applications to all browsers and platforms it could be the next generation of Rich Web Applications.
Unlike ActiveX and other things from MS in the past, WPF/E is very secure, easy to deploy, and brings a new level of functionality that surpasses JAVA/Flash/AJAX.
It will be a few years off, but it has potential to bring an XML based applicaiton model to the web where others have failed.
(Part of the reason behind this prediction is that WPF/E is far easier to develop applications for than JAVA/Flash/AJAX... So in a weird way, it will be like the VB of the early 90s and less 'technical' people will be able to write rather rich web applications easily.)
Try Flex Builder 2. It's a much better Flash IDE for application development than Flash 8 is.
Flash 8 strikes me as more for content and multimedia development. Flex, on the other hand, is geared towards web developers for web applications.
We've started using it here at work for some smaller scale applications and really enjoy working in it. It's consistent, stable, and you can put together some really kick ass apps with it.
Is that it's becomming less of a end and more of a means, and an almost invisible means at that (no stupid plugins!).
I turned on free tagging on my website to set up categories (for use with Drupal Views to get a view-content-by-category system) and all of a sudden noticed that the tag input box had a find as you type feature to match against existing tags/categories.
Highly useful, very unobtrusive and just a regualar part of the system getting on with it's job with a gracefull fallback if client side scripting isn't available. 10/10.
Think of the Children; Sleep with your Sister
Adobe's inability/uninterest in keeping Flash truly cross-platform should be a splash of cold water for folks who see it as part of a new Web generation. Adobe has proven for once and for all that using proprietary, closed tech in Web standards is a great way to cut your own throat. The coming of new demands on the Web offers a golden opportunity to get it right this time and make sure everything there is available to everybody, on any platform. Here's hoping that consideration drives the next wave of development.
... is why they are using the essentially useless HTML/HTTP stack with all the addtional layers (JS, AJAX, flash etc.) at all.
... and you can use your favourite GUI toolkit to build applications.
There are cross-platform thin-client network solutions like VNC or Nomachine's NX. They do exactly what the web x.0 wants to do, they do it fast and they do it without all the bloat and packing/unpacking of (essentially very simple) data.
Do not bring up the bandwidth argument before looking at NX first. It runs over really small links.
I also do not think that it allows additional security breaches in principle, as a web browser with all the additional plug-ins is also similar to a very high-level shell to a remote server.
I wish Webpage applets, whether Java, Flash, Javascript or other AJAX or just clientside execution objects, would all let me install them, rather than being bound to their page. Not just for easy access, rather than bookmarking their host page (which too often requires surfing several pages to build state). Also so I can combine them into single collected UIs. I want my own page with my banking client and a few shopping clients. And I want to be able to grant local access to a sandbox DB of my own data, like history and account info, that doesn't allow access to my other data, like other accounts.
If we could drag applets to our toolbars for local installation, rather than trapping them in their website context, they'd be a lot more useable. Hopefully this early stage of their development will incorporate that now/soon, rather than later when retrofitting and incompatibility will make problems last forever.
--
make install -not war
Having been around for IT for a while (20 years) and see quite a few revolutions come and go my sceptiscm with these kind of environments is that although the demo apps always look really good, the trouble comes when you take them out for a stroll in the real world and invariably you soon hit some sort of limitation on implementing something outside what the app was designed to do because the app hasn't been created with sufficient scalability or flexibility in mind. This is easily recognised when you brand-new tool whizzes through the basics as promised in a fraction of the time you would spend hand-coding, but then you loose all that time and more trying to code around the limitations when the going gets tough. Good mature development environments degrade gracefully with increasing size and complexity, poor and often new ones tend to have an asymptotic curve hidding in the undergrowth.
This isn't to say that Web 2.0 isn't wonderful. I'm doing a lot of contracts at the moment recoding old systems into browser-based ones and AJAX and partners are a joy to work with. My workbench at present is a mix of PHP using TinyButStrong http://www.tinybutstrong.com/ templates, AJAX using the xajax framework http://www.xajaxproject.org/, as much CSS 2.x as I can deploy that doesn't break on all common browsers, and whatever javascript widgets that meet the needs.
I can't recommend the two core tools in here highly enough - xajax is really nicely designed and I've only found one bug in it so far (when running a window modal), tiny-but-strong is even better - if you do any coding with PHP and havn't found this yet then you are missing the best templating system yet devised.
A quick response/overview from someone who is actually working with more or less all of these technologies.
The AJAX vs. Proprietary Debate
Isn't really a debate, which the article kind of notes but doesn't really state. AJAX doesn't compete directly with any of these tools... Asynchronous Javascript and XML is a data delivery mechanism, NOT a presentation layer (if I hear one more person use AJAX to refer to DHTML I'm gonna scream). Flex, Lazlo, Nexaweb, etc. have aspects that compete with AJAX (Real-time Push in Flex/Flash being one that competes and bests AJAX), but drawing them in parallel is misleading. With SVG more or less dead in the water (yeah, AdobeMacromedia doesn't have much of an interest in further developing an OSS competitor to Flex) and no SVG support for IE 7.0, there is no viable presentation component for AJAX to make this argument viable.
What the article gets right is that future application solutions are a combo approach that leverage a number of different technologies. For example, portals leverage AJAX/DHTML where possible to reduce page refreshes and increase basic interactive behavior (maybe with a framework to do the heavy lifting, though that has its own drawbacks) and something like Flex to supply visualization tools and whiz-bang interactive components on a more selection "superportlet" basis.
Cost Effectiveness of Proprietary Solutions
This is right on the money and a BIG reason to favor things like Flex. You'll actually spend more money developing and debugging tools in javascript and html than you will implementing with a robust end to end solution like Flex. From a UE perspective you're married to certain interactive behaviors the components you leverage (Flex isn't very good at exposing the underpinnings, read "Gold Support" here), but you get the benefit of tested methods and basic patterns that are generally at least "acceptable" from a usability perspective.
Java for Visualization
God help us all. I went there once on a trip... lost my granny, my dog got run over, and I came back with only 8 fingers.
Plug-in Limitations of Approach
Here we're mostly talking about Flash/Flex. I did an analysis not too long ago when I led a project doing a Flex 1.5 implementation (which sucked btw... don't even consider 1.5, not that Adobe would sell you on it anyway). What it comes down to is that Flash 9.0, which is the latest plug-in required to drive Flex 2.0, is at the beginning of its adoption, making this argument somewhat ligitimate. However, typical adoption patterns are a STEEP yield curve... you get to around 80%-85% within a year, get the next 10%-15% shortly thereafter (4-6 months), and pin down the final %5 over the next 5 years. Flickr has a good graphic to illustrate this.
http://www.flickr.com/photos/mannu/148867953/
The Flash 9.0 plug-in came out a couple months ago. What this means is that if you were to start developing an application now you'd likely launch with 80% adoption. So is it REALLY an issue right now? No, not unless you're developing a very targeted application on a very short timline. Additionally its worth noting that the generally plug-in updating architecture has improved dramatically after 6.0, so most users are now able to seamlessly update their players when prompted.
Basically I would say this is a legitimate concern if you're audience profile/segmentation indicates very old hardware/software with virtually no technically ability (and I mean NONE here, even more than a web neophyte) then you may need to reconsider your approach.
Application Accessibility
This subject is left only partially discussed, and its the real 800lb gorilla in the room. Last week a US court handed down a decision against Target.com (it was on Slashdot). The gist is that Target was found to be inviolation of the ADA for their use of non-accessible content formats in their web site. This was the first t
SVG is designed to fix that. It is an open standard, it looks promising but unfortunately browser support isn't quite there yet...
The web wasn't designed for applications. FULL STOP. The fact that apps run on the web at all is a testament to the sheer stubborness of developers.
You can put together an open source development toolkit for Flash development using the MTASC compiler. We use it for ActionStep development and it works great; it cut our compile time dramatically and can easily be used inside TextMate. Great stuff.
And for the language aficionados among you, MTASC itself is written in Ocaml. News for nerds...
The Army reading list
I wrote a quantum computing 3D visualization program in Java3D. The user can just click on the link in the browser and Java3D native libraries will be automatically downloaded and installed on the users' machine (of course after asking the user for permissions to do it) after that my application can use the native OpenGL drivers for fast 3D graphics. So it is both an Internet application (although it presently doesn't talk to a server in real time but it would also be possible) and it takes advantage of the fast native OpenGL graphics and the rich Swing GUI.
Take a look at content that's geared towards the Toddler to preTeen age group. Its full of flash and shockwave content. Flash is filling a niche to deliver tv/video game style content to the worlds young children. My kids even have a large number of game/applications that use flash on the desktop to deliver content.
As far as flash studio sucking, I couldn't agree more, but then again I'm a J2EE programmer. My artist friends think it rocks. Again its all about knowing your audience.
There are cross-platform thin-client network solutions like VNC or Nomachine's NX. They do exactly what the web x.0 wants to do, they do it fast and they do it without all the bloat and packing/unpacking of (essentially very simple) data.
You've got it backwards. VNC and the like send bitmaps across the wire. Bitmaps, even with compression, are more bloated and take more packing and unpacking than simple data. Other reasons to prefer AJAX, Flex, Laszlo, Altio, Nexaweb or other similar frameworks rather than terminal server type products are:
Also, the article gets it wrong when it states that these frameworks have suddenly started appearing in the last year since AJAX became popular. Aside from Flex, the products I've named above date back to around 2000. They're becoming more visible now that people are starting to see the possibilities of RIAs, but the 6+ year history behind some of these products means they're already stable, quality frameworks with good developer support.
You should check out the discussion going on at ReadWriteWeb. Ebrahim Ezzy's post is interesting, as are the comments. There's also more followup from industry as they bring Web 2.0 products to market. SharpCast, TeamDirection and x-port. Hopefully with such interesting ideas, Web 2.0 won't implode like Web 1.0 did.
Interesting, but you can already do this with or without the xmlhttprequest object. The technique is old, it's called slow load or comet. Basically you open a connection to the server, and have the server sit on it until it has something to send you. As soon as it sends its reply, that connection terminates and fires off a new one, continuing the cycle. Real-time feedback between client and server, without the need to poll or eat up bandwidth. I created a proof of concept of this using ajax here. You can build a full-fledged application like this with very low latency that looks just like a regular socket-using network app, in a web browser. The code in this posting has been revised, you need to spawn the thread off of the web server's hands to the CLR in this instance so as not to tie up web requests, and you can probably just do a thread.suspend and reawaken it instead of looping on the server, but it gets the idea across...
One thing that should be discussed when talking about the "The coming RIA wars..." (That have been going on for almost 5 years) are the benefits and limitation of the underly "VM" that the technologies are built on. For any given application one VM technology made be best suited for the application requirements. A framework can make it easy to use the VM and smooth the rough edges, add features but the true benefits and limitation come from the VM itself.
Currently there are four different VM technologies people use to build RIA applications (in no particalur order).
The article http://ajax.sys-con.com/read/232046.htm provide a good breakdown of the VMs.
Using Juggernaut for Rails you can also achieve this with a small Flash applet acting as a bridge. Have a look at http://www.clockingit.com/comet.html for a small screencast demonstrating how this can work.