You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Bruce Atherton <br...@callenish.com> on 2007/08/31 01:31:41 UTC

RIA technologies - which technology will "win"

Unfortunately, that is not true of all environments. Many large 
organizations such as governments and big corporations will not allow 
their users to install ANY plugins to their browsers for security 
reasons. A team of testers has to examine every piece of software 
installed on the network and approve it. Getting variances for a 
particular application is beyond most people's level of bureaucratic 
tolerance. And since providing their employees access to sites like 
Youtube is pretty low on these organizations' radar, a Flash player is 
not something that it is easy to get passed as an accepted piece of 
software unless they have purchased other software that requires it. And 
THAT is unlikely because developing software for large organizations 
that requires Flash causes this major friction point for sales. For 
Flash, it is a vicious circle.

Given how much development is paid for by large organizations, I think 
it unlikely any RIA technology will become dominant unless it is 
embedded in something else. That means SilverLight embedded in the 
browser with the most market share; JavaFX embedded in the JRE since 
many of these organizations see Java as mission critical; or Ajax, 
support for which is already embedded into existing browsers. Of these, 
Ajax is the only technology that is currently generally available within 
these large organizations.

Just thought I'd offer another perspective.

Grzegorz Kossakowski wrote:
> I'm taking installation issues into consideration but if your application is worth downloading and
> installing some VM people will do it. As long as it's matter of one-click installation people will
> do it even if they will have to go for a five minutes break caused by download size.
>   

Re: RIA technologies - which technology will "win"

Posted by Dev at weitling <de...@weitling.net>.
> Unfortunately, that is not true of all environments. Many large
> organizations such as governments and big corporations will not allow
> their users to install ANY plugins to their browsers for security
> reasons. A team of testers has to examine every piece of software
> installed on the network and approve it. Getting variances for a
> particular application is beyond most people's level of bureaucratic
> tolerance. And since providing their employees access to sites like
> Youtube is pretty low on these organizations' radar, a Flash player is
> not something that it is easy to get passed as an accepted piece of
> software unless they have purchased other software that requires it.
> And THAT is unlikely because developing software for large
> organizations that requires Flash causes this major friction point for
> sales. For Flash, it is a vicious circle.
>
> Given how much development is paid for by large organizations, I think
> it unlikely any RIA technology will become dominant unless it is
> embedded in something else. That means SilverLight embedded in the
> browser with the most market share; JavaFX embedded in the JRE since
> many of these organizations see Java as mission critical; or Ajax,
> support for which is already embedded into existing browsers. Of
> these, Ajax is the only technology that is currently generally
> available within these large organizations.
>
> Just thought I'd offer another perspective.

Full ack. And some other points:
- Flash is proprietary. I don't complain about the "Flash isn't OS
issue" but it introduces dependencies we should avoid.
- As with better javascript interpreters (as shall come with new
Firefox) rendering time shall increase. BTW: 300 ms on client side is no
problem. If it slowed down every request on server it would be...
- IIRC Flash started as interpreted, too. Java is kind of interpreted.
Both are (partially) precompiled. Why shouldn't javascript go the same way?
- With the current Ajax/CForms solution we have a fallback option for
non javascript-capable browsers and even for non HTML. Cocoon is still
an XML-publishing-system so we are neither bound to HTML/browsers nor
HTTP (what about the refactorings of that ServletRequest thingie?)

Just my four dashes...
Florian