Slashdot Mirror

← Back to Stories (view on slashdot.org)

The Future of Rich Internet Applications

Posted by ryuzaki0 on from the does-ajax-tell-flex? dept.

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."

11 of 187 comments (clear)

  1. The future is in the Stack by RunFatBoy.net · · Score: 3, Interesting

    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.

    1. Re:The future is in the Stack by Randolpho · · Score: 5, Insightful

      Yes and no.

      Rails, Cake, and Turbogears can't provide the sort of rich interaction that flash/activex/java can, no matter how great their frameworks may be. Why?

      The problem is not the stateless nature of the web as much as it is the medium with which the web is presented. HTML was designed as a document language, for the static display of information. It was never designed for any sort of interactivity other than hyperlinking. Everything else that has come along is a hack on top of a simple static display medium. Even arguably solid frameworks like Rails are nothing more than a hack to provide dynamic interactivity to a system that was designed against another way of doing things.

      If we really want remotely obtained rich interactivity, we need to rethink the medium. We need to drop HTML/Javascript and plugins like activex and flash. We need a new platform designed from the ground up to provide dynamic rich interactivity. That includes both the display medium *and* the means by which it is obtained. XUL was a baby step. The concepts behind XAML seem to go much further -- especially in the display department -- but still relies on stateless HTTP.

      All levels of the stack need fixing, not just server-side. We need more than just hacks.

      --
      "Times have not become more violent. They have just become more televised."
      -Marilyn Manson
    2. Re:The future is in the Stack by cascadingstylesheet · · Score: 3, 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 ...

    3. Re:The future is in the Stack by misleb · · Score: 4, Insightful

      On the other hand, the statelessness is what makes web applications possible. Lets say you have a web application that serves 100,000 different users during the course of an hour. Depending on the demands of your application, you might be able to support all of them on one server because the server doesn't have ot maintain a connection for each and every user for the entire duration of the session. The server just keeps a small bit of the state stored in a session and moves on to serving the next request. But if everyone has a stateful connection, you start running into trouble with resources. Even if nobody is actually DOING anything on the app, you've got these open connections.

      I dunno, at some point I think we're going to have to ask ourselves if the web/browser is really the best way to get the kind of richness people are expencting from internet applications. By the tiem you add statefulness, better UI toolkits, better event model, etc, you don't really have a "browser" anymore. You just have a virtual machine and you find that you've just reinvented Java applets.

      -matthew

      --
      "THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
  2. Well in my opinion, by Anonymous Coward · · Score: 4, Funny

    the tag should be enough for anybody.

    B.G.

  3. Prediction.... by TheNetAvenger · · Score: 3, Interesting

    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.)

  4. Re:Flash failed by kylner · · Score: 4, Informative

    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.

  5. The best thing about AJAX by also-rr · · Score: 3, Interesting

    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
  6. What I REALLY do not understand about the web 2.0 by sploxx · · Score: 3, Insightful

    ... is why they are using the essentially useless HTML/HTTP stack with all the addtional layers (JS, AJAX, flash etc.) at all.

    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. ... and you can use your favourite GUI toolkit to build applications.

    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.

  7. Some quick insights and clarifications by rtilghman · · Score: 5, Informative

    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

  8. The answer is WebStart by drgonzo59 · · Score: 3, Informative
    Java's WebStart solves this exact problem. We are not talking about Applets. These are more like full Java applications that the user can launch just by clicking on a link in the browser. The applications then load along with any necessary libraries and are cached on the users' computer. Optionally the user can even include it in the Start/Gnome/KDE menu.

    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.