Forgot your password?
typodupeerror

The Future of Rich Internet Applications 187

Posted by kdawson
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."
This discussion has been archived. No new comments can be posted.

The Future of Rich Internet Applications

Comments Filter:
  • by RunFatBoy.net (960072) * on Tuesday September 12, 2006 @12:57PM (#16090098)
    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/ [runfatboy.net] - Fitness for web 2.0.
    • Re: (Score:2, Insightful)

      by orb_fan (677056)
      I have to concur.

      While what can be done with Ajax is pretty amazing, the unfortunate truth is that the developer generally has to jump through hoops to get everything working. Simply the lack of stateful information is a major problem. What's needed is another protocol (Application Transfer Protocol?) that would provide state information to the server, true client-server event handling, etc.

      • by misleb (129952) on Tuesday September 12, 2006 @05:30PM (#16092515)
        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

    • by Randolpho (628485) on Tuesday September 12, 2006 @01:51PM (#16090542) Homepage Journal
      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.
      • SVG (Score:3, Insightful)

        by drgonzo59 (747139)
        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.

        SVG is designed to fix that. It is an open standard, it looks promising but unfortunately browser support isn't quite there yet...

        • Re: (Score:2, Interesting)

          It's not that it's not quite there yet. Native browser support for SVG is non-existing. However, you can download plug-ins to view SVG. And being a W3C Recommendation [w3.org], Netscape and IE are promising future browser support for SVG, and with browser support, the plug-in will eventually be phased out. The main problem with SVG for the moment is that hardly anyone uses it.

          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 important
          • by drgonzo59 (747139)
            Firefox support is half-way there. I was able to create a small website in SVG with Inkscape. It worked alright in the latest Firefox...

            Yeah SVG+Ajax would be a dream come true if SVG is supported _in_a_standard_ way in all the major browsers. Making users download plug-ins is a good way to not have very many users.

        • Re: (Score:3, Interesting)

          by Jerf (17166)

          SVG is designed to fix that.

          Not from what I can see. SVG is basically as designed for static display of information as HTML now is. The same "hack" for dynamism is used for both, a Javascript-exposed DOM (or DOM exposed to some other language), and the same basic set of events are available to both.

          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 a

      • You mean X Windows?

        Don't shoot!

        Seriously, though. If X were replaced with something with the same goal, but without the same "mechanism, not policy" policy, and a lot of the good design elements of News and NeXT, wouldn't that be ideal? Add some auto-launch features and SSL encryption, and you're all set. Hell, you could even have an abstraction layer to use and XML schema to control the toolkit.
        • by Nicolay77 (258497)
          You don't need to replace X. You need a MS Windows open source X server.

          However development is the other way around with mono and stuff, that's linux embracing MS technology.
          • xorg on cygwin.

            X has other problems. Inconsistent user interface, inconsistent protocol support, everybody trying to out-eye-candy each other , a system not well designed for eye candy. . . well, its pretty much the same disaster as HTTP.
        • It's "X-Windows" with a dash, if you want to maximize your chances of making people who insist on calling it "The X Window System" go apoplectic.

          And NeWS invented the BIG small BIG BIG capitalization style, long before NeXT copied it!

          -Don

      • At some point, these "rich application frameworks" will get to the point where we've got a complete re-implementation of the X protocol over HTML. What a day.
      • by arete (170676)
        In principle I don't disagree with you about the endpoint, but I think your post is missing a major point: Sandboxing.

        What Flash brings to the table is an environment that is powerful, that users will generally HAVE, and that users can trust. That's the key part - I tell everybody to disable ActiveX - if they're even using an OS/browser it's supported on, but Flash* has a very secure sandbox.

        Running things outside of a sandbox is why we have native code. Being able to run random applets I don't necessari
      • What is needed is a distributed application environment. I've been saying this in every chance I have:

        http://developers.slashdot.org/comments.pl?sid=196 101&cid=16071312 [slashdot.org]
        http://developers.slashdot.org/comments.pl?sid=195 852&cid=16052135 [slashdot.org]

        Over and over will I repeat this, until someone that has the time and resources reads it and takes the right decision.
    • by cascadingstylesheet (140919) on Tuesday September 12, 2006 @01:59PM (#16090607)

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

      • Damn.

        I was wondering if someone would actually post that.

        Even though you are correct, you must have Karma to burn dude. Did you forget where you were posting?

        Atlas and ASP.NET are going to turn some heads very shortly.

    • by drgonzo59 (747139)
      The frontend is HTML+DOM+JavaScript. Unless you know of any good database access driver from HTML or JavaScript, or know any browsers with an embeded Python/Ruby interpreter you won't have _full_ unification of the front and backend. The closest to _full_ unification that I can think of is using Java applications where both the applet/WebStart application and the backend both run Java.
    • by plague3106 (71849)
      Personally I'm hoping the .Net framework takes off. ClickOnce gives you a rich client with the ease of web deployment. As the framework install base becomes larger (I think Vista will ship with it) developing and deploying rich applications becomes very easy.

      I also really hope more people get involved in Mono. Then you can target any platform you like.
      • by killjoe (766577)
        Java never cought on .NET will not either. It's just too stodgy and "enterprisey" and complex, and verbose and tries to do too much.
        • by plague3106 (71849)
          Spoken like someone that doesn't have a job in the real world, or a clue. There are tons of jobs for both Java and .Net developers. Not nearly as many for other languages.

          To say that Java isn't huge in the world is stupid. As far as .Net goes... well, .Net today is what Win32s was in Windows 3.1x. In other words, .Net is the replacement for the Win32 API, the prefered way to talk to the kernel. Going forward, if you develop on Windows, you'll be using .Net.
    • by killjoe (766577)
      The answer was and is java. Unfortunately completely dropped the ball on the applet so now it's probably too late.
  • Flash failed (Score:2, Interesting)

    by hsmith (818216)
    As did applets, as did activex. If macromedia wanted flash to be a serious tool, they should have developed a better platform for their actionscript to be developed in, because frankly the flash studio sucks. it comes no where close to real languages like java, c# for doing massive web projects.
    • Re:Flash failed (Score:4, Informative)

      by kylner (639495) on Tuesday September 12, 2006 @01:17PM (#16090257) Homepage

      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.

      • Re: (Score:3, Interesting)

        by tcopeland (32225) *
        You can put together an open source development toolkit for Flash development using the MTASC [mtasc.org] compiler. We use it for ActionStep [actionstep.org] 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...
    • by RAMMS+EIN (578166)
      I can understand the claim that Java applets and ActiveX failed, but Flash didn't. Flash is supported in all browsers, given the right plugin, which is available and even pre-installed on the bulk of computers. Support is there. Popular sites are using it. See, for example, youtube and Google video. Usage is there. How did Flash fail?
      • Flash is supported in all browsers, given the right plugin,

        Hmm... I'm looking for flash support in Firefox on my Linux box and can't seem to get anything beyond 7.

        Some cross platform support huh? Adobe has really screwed with flash IMO by doing that...
    • Flash failed? 98% browser penetration, full cross-platform support, millions of websites developed either with or entirely on it. Google Video and YouTube, not to mention a plethora of flash-based MP3 players - not to mention it's embeddable in Win32 apps.

      When did Flash fail in your mind?
    • f macromedia wanted flash to be a serious tool, they should have developed a better platform for their actionscript to be developed in,

      AND they wouldn't alienate operating systems like Linux. I don't take flash seriously if they are two versions behind with a linux viewer. It was a good cross platform tool, now it's a pile of crap IMO that only supports Windows and Mac. /me still annoyed with that.
      • by Goaway (82658)
        I'm sure Adobe will be devastated to learn that they have earned the ire of people who use IRC commands in lieu of real words.
      • I wish SVG would take off at once. But the browser support is still lacking. I tried creating a small website in SVG using Inkscape only, it worked pretty well with Firefox but IE needed a plugin. But even Firefox still doesn't support the full 1.1 specification...
    • Re: (Score:2, Interesting)

      by draos (672972)
      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.
  • by overshoot (39700) on Tuesday September 12, 2006 @01:11PM (#16090203)
    the fact that AJAX (and XUL, actually, but never mind) are searchable. It's the first time in quite a while that an "RIA" author got past the gee-whiz eye candy to deal with usability issues.

    Of course, none of them want to deal with the disabled-accessability part, despite a recent Court decision [slashdot.org] that's going to make this kind of stuff a very low priority for a long time.

    • by Instine (963303)
      Of course, none of them want to deal with the disabled-accessability part

      Hows THIS [textictalk.com] for a turn up for the books then. An Ajax Screen Reader.
  • by Anonymous Coward on Tuesday September 12, 2006 @01:12PM (#16090215)
    the <blink> tag should be enough for anybody.

    B.G.
  • by BrookHarty (9119) on Tuesday September 12, 2006 @01:13PM (#16090221) Homepage Journal
    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.

    • Re: (Score:2, Informative)

      AJAX is free, easy to use, and people are using it now.

      Flex is free (the compiler), ease of use is a subjective measure, and people are using Flex now too.

      That Adobe flex uses coldfusion, we stopped using that and migrated to Tomcat.

      Negative. Flex has no reliance on ColdFusion. There are numerous ways for Flex (front-end) to talk to the server (back-end), ColdFusion being ONE of the ways. It can also talk to Java via Tomcat. For that matter, I can run ColdFusion ON Tomcat.

      Note that I've never written a Flex

      • by $1uck (710826)
        Well the company I work for is having a brief training tonight on the use of flex with J2EE. So I know it is definitely not reliant on Coldfusion. I got the feeling you didn't need to use any proprietary Flash development tools to use it either, but I did get the feeling it used the flash plugin someway from the brief overview I was given.
    • "AJAX is free, easy to use, and people are using it now."

      People ARE using it, but you aren't !

      No one in their right mind who has ever delivered AJAX sites would describe AJAX as easy. For what it achieves it's ridicuoulously complicated.
  • Prediction.... (Score:4, Interesting)

    by TheNetAvenger (624455) on Tuesday September 12, 2006 @01:15PM (#16090232)
    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.)

    • That's what I don't get about XAML and such: it's really just the Microsoft alternative to XUL and SVG+SMIL. Both of which have an excellent implementation that by most current estimates is used by about 10% of the surfers out there (I mean, of course, Firefox).

      Now, I'll concede that last I checked Firefox didn't have a working SMIL implementation in their SVG stuff, but my point is this: it's already here, it does what WPE is supposed to do (which I haven't seen in the wild at all), and it's an open stan

      • Re: (Score:3, Interesting)

        by TheNetAvenger (624455)
        That's what I don't get about XAML and such: it's really just the Microsoft alternative to XUL and SVG+SMIL. Both of which have an excellent implementation that by most current estimates is used by about 10% of the surfers out there (I mean, of course, Firefox).

        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 present
        • by killjoe (766577)
          Unless it runs on the mac it's dead. The world has changed and MS no longer has over 90% of the market. It's one thing to tell 5% of your customers to fuck off, it's another to tell 15 to 20% of them to fuck off.
  • Another technology to look at is Server-Sent Events (SSE), which takes AJAX one step further.

    Opera 9 added support for SSE.

    With the traditional AJAX implementation, the browser continually polls the server, sending requests to the server, asking to get data back, making new HTTP requests for every single poll, putting more strain on the server than needed.

    In Opera 9 you can instead open a persistent connection to the server, sending data to the client when new information is available, eliminating the

    • Why do we need two, brand new, incompatible protocols to push data to browsers?
    • Re: (Score:3, Interesting)

      by Unnngh! (731758)
      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 [blogspot.com]. You
    • Re: (Score:2, Insightful)

      by Fudgie (594631)
      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 [clockingit.com] for a small screencast demonstrating how this can work.
  • by also-rr (980579) on Tuesday September 12, 2006 @01:28PM (#16090350) Homepage
    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 [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.
    • I don't know when AJAX has ever been an end in and of itself to professional developers. Sites like Yahoo, Gmail, Flickr, Last.fm, etc. have always been using these technologies to simply improve usability and convenience of the interface in the ways that you are only now experiencing. This has been the expressed purpose of AJAX from the beginning. It just happens that a lot of Slashdotters decided early on that it was trendy to dismiss AJAX off hand as an emerging web trend because of its immediate popular

  • Interesting idea [ajaxian.com] - Lingr [lingr.com] is the coolest implementation I've seen so far. Super-realtime chat. Much less latency than normal Ajax-only chat
  • Dump Flash (Score:2, Interesting)

    by Perp Atuitie (919967)
    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 devel
  • by sploxx (622853) on Tuesday September 12, 2006 @01:37PM (#16090427)
    ... 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 [realvnc.com] or Nomachine's NX [nomachine.com]. 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.
    • 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 [macromedia.com], Laszlo [openlaszlo.org], Altio [altio.com], Nexaweb [nexaweb.com] or other similar frameworks rather

    • You should check out the discussion going on at ReadWriteWeb [readwriteweb.com]. 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 [readwriteweb.com], TeamDirection [blogspot.com] and x-port [x-port.net]. Hopefully with such interesting ideas, Web 2.0 won't implode like Web 1.0 did.

    • Speed:
      Remote Desktop solutions are reasonably secure (for the client) because the client only draws stuff. However, they are incredibly slow if you have a lot of users - because the you're doing ALL the work for EVERY client on the serverside. A well written Flash/Flex application does the vast majority of the work on the client side and only talks to the server when it needs to share something. This problem is tied to the responsiveness problem - even if it works over a low bandwidth connection, it can
    • Its about scale. Web-scale to be exact. RESTful architectures (like HTTP) are proven on that scale, and pretty much nothing else is. VNC and the like are nice and have their uses, but you don't want to build an application for the web in general with them. You shouldn't be thinking about bandwidth, but rather about things like maintaining state for thousands of simultanious users, naming of third party resources and how to make your application benefit from caches.

      The REST article on wikipedia is rather ter
      • I feel a bit silly replying myself, but ... Big part, possibly the biggest, of REST is that it allows the system (= web) to evolve incrementally over time.
  • Save Applets (Score:3, Interesting)

    by Doc Ruby (173196) on Tuesday September 12, 2006 @01:47PM (#16090499) Homepage Journal
    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.
    • by drgonzo59 (747139) on Tuesday September 12, 2006 @02:48PM (#16091083)
      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.

      • by Doc Ruby (173196)
        So how do I use WebStart in Firefox?
        • by jrumney (197329)

          You click on a link to a jnlp file (basically an XML file that describes what jars make up the application, how to run it, icons, splash screens etc). However this only solves your wanting to run Java web apps outside your browser and putting icons on the desktop/start menu etc. It does not solve any of the other things you'd like to do...

          • by Doc Ruby (173196)
            So the applet publisher generates their applet files and a JNLP file, marks up an HTML page embedding the applet by URL and linking to the JNLP file by URL, and puts all those files on a webserver. The user sees the page, likes the applet, clicks the link to the JNLP file and it installs to their local client machine. Does the user have to have any other software other than a standard Firefox (or other browser like IE, Mozilla, Safari) installed, like some kind of WebStart app installed (other than the JVM
            • by jrumney (197329)

              Webstart comes as part of Java 1.4 and later, and was an extra bolt-on for 1.3, at least with the Sun JVM, not so sure about Apple and others.

              The webstart application won't be exactly the same as the Applet on the page, as it runs in its own Window, not in a Panel on the webbrowser. It is possible to minimise the differences and write an Applet with a main method to make the jars the same, but at least the startup and shutdown codepaths would be different. In most cases, the developers will write one or th

        • by drgonzo59 (747139)
          Google webstart and JNLP
  • by cruachan (113813) on Tuesday September 12, 2006 @01:48PM (#16090510)
    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/ [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.
  • by rtilghman (736281) on Tuesday September 12, 2006 @01:49PM (#16090518)
    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/ [flickr.com]

    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
    • Re: (Score:3, Insightful)

      by drgonzo59 (747139)
      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.

      That's what happens when you are not prepared for travel!

      How good are you Java programming skills? What were your expectations? Have you tried WebStart?

      I think Java still has a place for specialized rich clients. I have recently released a Java3D scientific visualization application that uses WebStart. It automatically downloads all the Java3D libraries it n

      • Java is a bitch to program when you know better languages*, you feel trapped, limited and frustrated.
        But compared to AJAX? Yes, it's better, if your application is complex enough. Java looks ugly though.

        So may be he had very few programming skills. But it's entirely possible that he had superb programming skills** and still would though the same.

        * by better languages I mean Lisp, not C#.
        ** try explaining closures or continuations to a Java-only programmer.
    • MS is bringing out their own proprietary format, which is actually kind of stupid since they could easily have embraced SVG in Adobe's absence, developed an architecture that leveraged it, and relied on the OSS community to feed the beast from a component/visualization perspective.

      Yeah, they could have. However, there are at least three big show-stoppers to that idea:

      • Not Invented Here. MS simply doesn't do other people's standards unless they are playing catch-up.
      • No differentiation. Anyone can do
  • AJAX is seriously overhyped. It's been possible to do these kinds of things since the late nineties. The reason people weren't massively doing it back then is the same reason they shouldn't now: it's just not the right way. Just look at the code it generates: it's terrible.

    If what we want is truly interactive, desktop-like apps on the web, then let's make something that does that, not kludge together something that approximates that, using today's fast (really fast) hardware and enormous memories to give it
    • by mad.frog (525085)
      I don't know if there's a real programming language behind it

      Flash 9 is coded using ActionScript 3 [adobe.com], which is tracking the still-in-progress ECMAScript 4 [mozilla.org] standard.
    • by suggsjc (726146)
      Javascript isn't an entirely horrible language. It isn't as full featured as Java, C/C++/C#, perl, etc. However, it is a decent OO language. Most people don't know/use half of its capabilities. So your question of whether or not javascript can cut it...is *probably* yes.

      There are no one size fits all solutions, but XUL could be a decent platform for some projects.
    • Your Flash info is circa 2001. Now it has a real programming language behind it, and many of the most-used slownesses are optimized in the native player code so for many types of things you get surprisingly fast performance. (Obviously it's not native performance for real number crunching.. but the recent player versions take many things - like event management - and do them natively, so that part IS at native speed.)

      With Flex there's a really nice programming interface for every single part of Flash - no
  • The model of the web was broken the instant people started using it as a front-end for remote applications.

    The World Wide Web is (ostensibly) a network of hyperlinked documents. Dynamically-generated pages pulled as requests from a database is a bit of a stretch but still basically within that model, as a database record is not so different from a traditional stand-alone document: it's still just data.

    But cramming fancy interactive applications (games, etc) into this model is already a bastardization of it,
  • This was a good article up until this point, which is utterly and completely wrong.

    Flash has supported XML parsing back to version 6, I think.

    Flash 9 includes E4X [wikipedia.org] support as part of ActionScript 3, which puts it far ahead of most other solutions.
  • One way to reduce the challenges of using Javascript and AJAX across browsers is to use a library that abstracts away many of the differences from one browser to another. One such library is MochiKit [mochikit.com], which provides AJAX / remote scripting support, functional language tools, portable DOM manipulation, and event signalling. It's even got some cool flashy visual effects.

    Anyway, I'm not affiliated with the MochiKit at all; I'm just a very satisfied user and even use it on my own site [coderific.com].

  • This is slightly off-topic, but what's the point of making a diagram if you're going to make it this complicated? [zdnet.com] That diagram provides basically no information, which is pretty typical of all the diagrams in Dion Hinchcliffe's articles that I've seen. It hurts.
  • "While WPF/E itself is a powerful Flash analogue, it doesn't have its own application development model like Flex or OpenLaszlo..." WTF !!!! What planet is this guy on ? Has he never heard of .NET.... and Visual Studio .NET ? Just what the hell is an application development model if .NET and Visual Studio don't count as one ? Is this guy completely clueless or what ?
  • He missed ZOPE [zope.org], with such add-ons as the Plone content management system [plone.org], becomes very competitive in the RIA space. Zope uses the object database ZODB. Zope is written mostly in Python - and uses python as its development language of choice (although you can use others).

    Been using it for years -- it is stable as a rock, and Version 3 is looking very cool. If you love Python, then Zope is the development framework to use imho.
    • by killjoe (766577)
      Zope is not a rich client platform. Aside from that zope is too complex and poorly documented and a moving target.

      I used (not programmed) plone for a couple of years but I recently ditched. The straw that broke the camel's back was when my upgrade from plone 2.2 to plone 2.5 went horribly awry.

      Zope is a supreme waste of brilliance and innovation. How can something to innovative be so useless? Before you bring out the flamethrower ask yoursef this. How come not one plone blog tool is 1/10th as good as word
  • where I wish someone would just drop a nuc on all the participants.

    WTF does so many people crave web apps to begin with?

  • the next time i hear or see the words ' rich experience' im going to scream.
  • 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 technologie

The difficult we do today; the impossible takes a little longer.

Working...