Channels ▼
RSS

Parallel

Ajax, RIAs, and the Future of Web Development


The Impact of RIAs

Rich Internet Applications are not new. Adobe's Flash plug-in has been around since the early days of the web, delivering richer experiences than standards-based browser technology allows. Yet, until recently, RIAs have largely been abandoned by web developers creating online applications. In 2000, Jakob Nielsen, preeminent web usability researcher, set the tone for RIAs, calling Adobe's Flash "99% bad." According to Nielsen, most sites would be better if rich multimedia objects, like Flash, were removed.

What's changed? Why have RIAs become so popular recently after years of developer neglect? In short, they have become developer friendly.

In 2004, Adobe introduced a new programming layer for Flash called Flex. Flex added programmability to Flash that made it much more suitable for building data-driven applications. With new APIs and a development environment geared towards developers, not designers, Flash suddenly became a rich application platform and not just a rich animation platform.

Then, in 2006, the popularity of RIAs was confirmed with the introduction of Silverlight by Microsoft. Like Flex, Silverlight is a plug-in based technology that runs in a web browser with tools aimed at enabling developers to build data-driven applications.

The appeals of RIAs for business are easy to define:

  • They overcome the limits of the browser, enabling "desktop-like" rich visual interfaces guaranteed to look and behave the same in any browser supporting the RIA plug-in.
  • They are faster to develop than standards-based applications because they don't depend on inconsistent browser implementations of web standards.
  • They evolve faster than standards, delivering support today, not 2012, for offline and out-of-browser web-delivered experiences.

For controlled Intranet environments, RIAs are often a better solution for application development than standards-based Ajax applications. They represent the closest thing to the utopian ideal of having desktop applications that can be easily delivered through the browser without requiring any IT installation support. But for all that they offer RIAs do have some serious drawbacks that even corporate Intranet developers should consider.

RIAs are inseparably tied to their vendors. Neither Adobe nor Microsoft makes their RIA platform available as an open source project, so companies that build applications targeting Flash or Silverlight are at the mercy of the vendors to improve the plug-in platform in the future. Independent companies can't build a "better" Flash or Silverlight plug-in. This may not be a problem today while Adobe and Microsoft are feverishly working to improve their RIA platforms, but once the excitement settles, companies may find themselves with applications locked-in to platforms destined to go the way of VB6.

If an organization wants to make sure its web applications are broadly accessible, especially on the exploding category of mobile devices, RIAs platforms are severely limiting. Few mobile platforms today support Flash, and none support Silverlight, though it's promised later this year. Even if Microsoft and Adobe continue to add new supported devices and browsers to their RIA plug-ins, there will always be more devices and browsers than they can reasonably address. RIAs ultimately require some software to be installed, and if that software cannot be installed, users are out of luck. That is one of the main reasons standards-based development is superior for Internet-facing applications.

RIAs are a valuable tool in the corporate application toolbox, and as we've seen with Internet video, are invaluable for overcoming the limits of browsers with "islands" of functionality in otherwise standards-based sites, but they clearly are not destined in the near-future to kill standards-based Ajax development. Each technology needs the other, and until either standards start to evolve at a faster pace or a truly open source RIA platform enters the scene and becomes as common as JavaScript in browser, neither is going to kill the other.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video