Subscribe by Email

Your email:

The Magic Software Blog

Current Articles | RSS Feed RSS Feed

The Evolution of the Browser - Ajax & Java vs uniPaaS

Share on Twitter Twitter | Share on Facebook Facebook | Submit to Digg digg it |  Add to delicious  delicious |  Submit to StumbleUpon StumbleUpon |  Share on LinkedIn LinkedIn | Submit to Reddit reddit 

Evolution of the Browser

Here's a useful graph that I found created by Gartner that nicely shows the how the browser has evolved over time.

Beginning with the origin of web applications at left hand side of the chart, we see that Ajax and HTML were designed to give application developers more power and capabilities when creating internet based applications.

It started off well enough, but Ajax never really took hold as well as initially expected. Ajax uses a combination of technologies that makes building the Client interface substantially more difficult than static web pages. It's performance is therefore relatively low when considering the effort that needs to be invested, since it's based on script that needs to be interpreted, rather than on compiled code.

The next step along the chart was the movement in the direction of plug-in's and Java. However, this also presented challenges, particularly with its compatibility with different browser types, with certain applets not being able to run properly.

The solution then, was for the industry to move to applications that run ‘outside the browser'. These apps run on the middleware stack but still use a runtime language such as Java or .NET.

This seems to be the most practical solution then, both in terms of cost and performance. Typical business application, we must remember, are characterized by complex and heavily loaded data. This data needs to be displayable and retrievable in an efficient manner.

The browser is simply not designed for that. To compound the problem, there are now so many different browser types out there (Internet Explorer, Firefox, Safari and now Google Chrome) that preparing the application to run on each is a coder's nightmare.

The solution then is obvious - scrap the browser altogether as a business application sandbox - and use a tool that has a dedicated business-optimized front-end layer. 

That's uniPaaS.

You'll find it far more secure as well.

Comments

"scrap the browser altogether" 
 
I'd like to know how you deal with client installation by scrapping the browser altogether?
Posted @ Friday, February 05, 2010 12:55 AM by arian
Hi Arian, 
 
In uniPaaS RIA deployment, the Browser is indeed used - but only the once in order to invoke the installation of the client for the first activation of the application. 
 
Once the application is installed the browser is then no longer needed. 
 
Hope this answers your question.
Posted @ Wednesday, February 10, 2010 1:55 AM by Sam Green
Post Comment
Name
 *
Email
 *
Website (optional)
Comment
 *

Allowed tags: <a> link, <b> bold, <i> italics

Demos & Videos

Nature meets Technology

iBOLT for Salesforce.com

iBOLT for SAP

uniPaaS Discovery Demo

About the author

 

 

Sam Green is the Creative and Content Manager at Magic Software.

Posts by category

Contact Us |  Call Us  |  Privacy  |  Legal  |  Blogs and Social Media |  RSS  |  Site Map

© Magic Software Enterprises