The Future of Rich Internet Applications 187
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."
The future is in the Stack (Score:4, Interesting)
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/ [runfatboy.net] - Fitness for web 2.0.
Flash failed (Score:2, Interesting)
Telcos have been doing this for years. (Score:3, Interesting)
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.
Prediction.... (Score:4, Interesting)
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.)
The best thing about AJAX (Score:4, Interesting)
I turned on free tagging on my website to set up categories (for use with Drupal Views [revis.co.uk] 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.
Dump Flash (Score:2, Interesting)
Save Applets (Score:3, Interesting)
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.
Stuff like that oftens break with complexity (Score:3, Interesting)
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/ [tinybutstrong.com] templates, AJAX using the xajax framework http://www.xajaxproject.org/ [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.
Re:The future is in the Stack (Score:4, Interesting)
I want a full unification of the front and backend. That is why Rails, Turbogears and Cake appear to be more exciting.
Sounds like you're talking about ASP.NET and Atlas with Visual Studio ...
Re:Prediction.... (Score:3, Interesting)
Well, a lot of people go this route in thinking, but if you take the time to look at XAML and its capabilities, you will easily find that 80% of things it is doing or can do are not supported with the technologies you mention.
XAML is not only presentation, but handles every thing from events and hit testing to virtually every type of media. It bridges what you see and and what you can do.
One simple example is some of the graphic abilities of XAML is that can display very complex vector based images that surpass GDI+ or OSX's Display Acrobat. In fact, some of the image presentation abilities built in are on par with something you would normally see in Adobe Illustrator or CorelDraw. (Blends, transparency, effects, etc.. - And they are all extensible as well, so they are not even a locked set.)
I know WPF/E in the first release is not going to target 3D, but in response to your view of the other technologies, WPF/XAML does some really impressive things again with its ability to simply display 3D scenes, that are not only nice looking, but fully interactive UI controls as well. (Imagine a RichTextBox on the side of a Cube Spinning with Buttons on each side of the cube that are clickable.)
Not only is this beyond the 'display' capabilities of the technologies you mention, but also surpasses anything out there short of writing an OpenGL or DirectX application. Yet, a begining programmer can write a 'few' lines of XAML that does all of this that is actually easier than making a VB 2.0 Form and throwing controls on it.
This ease of programming is where it is as easy as early VB, and yet will do things that are beyond what many developers are even seeing as possible ways to create applications.
I consider myself half-way versed in WPF stuff, but everytime I look at aspects of it, I find numerous new ways of thinking in creating applications that JUST ARE NOT possible on any other platform and it also reinforces why MS could not just take SVG or other standards and bastardize them in order to achieve what they are with XAML.
In early previews of XAML concepts I was a lot like you and thought, why not just use SVG, but after seeing how much MS would of had to chop up and turn SVG into what XAML does, I'm actually glad they left SVG alone.
Re:Flash failed (Score:3, Interesting)
And for the language aficionados among you, MTASC itself is written in Ocaml. News for nerds...
Re:SVG (Score:2, Interesting)
One sweet duo is SVG + Ajax, that can vastly improve the interface with the end-user, without eating up a lot of bandwidth and most importantly, can be easily implemented so that the browser gracefully presents an downgraded version of the page if one is not supported...
Give it all to the ones that can handle it, but degrade gracefully if one cannot handle it all. That is (or should be) the future of the web.
Re:Flash failed (Score:2, Interesting)
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.
Re:SVG (Score:3, Interesting)
From what I can see, it really wouldn't take a hell of a lot of work to merge XHTML and SVG into one specification with a richer layout model than XHTML currently has.
SVG gets you no new interactivity, just the ability to better display vector graphics. Nothing to sneeze at, but current SVG-browser apps are still going to use AJAX or whatever the HTML portion of the website is using for interactivity.
I agree with the grandparent that the whole stack needs fixing, but the most broken part right now is the stateless HTTP. All we need is for a browser to step up and offer a true, full socket object. Once people have settled into that, we can figure out how to make it more convenient, if there's even an obvious consensus.
If I could go back in time and choose between the XMLHttpRequest object or a Socket object, I'd take the latter. It's what people really want, they just don't really realize it yet.
Yes, it causes some new security problems, but ultimately, not really new ones; just allowing XMLHttpRequest at all really covered most of the security problems. (You'd certainly want to block the socket just to the originating server, though.)
Re:Event Streaming to Browsers (Score:3, Interesting)
Article misses the Point (Score:2, Interesting)
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 [sys-con.com] provide a good breakdown of the VMs.